Protocol for Controlling Multiple Streams for Telepresence (CLUE)
draft-ietf-clue-protocol-19

[Ballot comment]
I'm balloting No Objection, as the concerns noted in my previous Discuss ballot
position are not necessarily blocking issues for an Experimental document, and
in fact further experience might be helpful to reveal the appropriate values and
behaviors to use for timeouts and loop-avoidance.

My previous ballot position is preserved below; I note that some of the "substantial
comments that do not rise to Discuss level" seem to still be present in the -19.

DISCUSS

Thanks for the generally clear and well-written document!
I would like to discuss whether there needs to be more prominent coverage
of timers/timeouts, especially as relating to the state machines.  (I'd be happy
to learn that this is well-covered elsewhere in the document set; I just haven't
run into it yet.)

In a similar vein, do we want to have any treatment of avoiding infinite loops
(e.g., when a 'configure' or 'advertisement' is rejected in expectation of modification
but the sending implementation continues to generate an identical message)?

It is not clear to me that any change to the document text is needed in either case,
but I don't know to what extent the topics have already been discussed.

COMMENT

I also have some substantial comments that do not rise to Discuss-level.

How do I know which endpoint is the channel initiator and which is the
channel receiver?
draft-ietf-clue-signaling suggests that the DTLS client is the channel
initiator, but even that is not explicit about it -- the protocol could be
considered under-specified if there is insufficient clarity.

Section 2

The MCU definition doesn't actually expand the acronym, which seems a
little reader-unfriendly.

Section 5.1

There are perhaps more XML extension points in here than is reasonable for
some of these elements (e.g., ).

Section 5.2

                          If the responseCode is between 200 and 299
  inclusive, the response MUST also include ,
  ,  and  elements;

Maybe re-mention that MP and MC are booleans here.

  Finally, the commonly supported extensions are copied in the
    field.

Does this need to say that only extensions that are applicable to the
negotiated protocol version are included?  (Also, how does one handle an
extension that exists for multiple major versions -- are there two
elments for it in the  message?)

  Upon reception of the 'optionsResponse' the version to be used is the
  one provided in the  tag of the message.  The following CLUE
  messages MUST use such a version number in the "v" attribute.  The
  allowed extensions in the CLUE dialogue are those indicated in the
    of the 'optionsResponse' message.

Couldn't this restriction on the "v" value apply even to the
'optionsResponse' message?

Section 5.3

  The 'advertisement' message is used by the MP to advertise the
  available media captures and related information to the MC.  [...]

I'd consider avoiding the definite article "the" to refer to MP/MC roles,
since in many caess there will be 2+ of each, and we don't want to confuse
the reader into thinking that there is an MP/CR equivalence or something
like that.  So, perhaps "each MP" and "the corresponding MC".

Section 5.4

                            As it can be seen from the message schema
  provided in the following excerpt (Figure 6), the 'ack' contains a
  response code and a reason string for describing the processing
  result of the 'advertisement'.  [...]

[the reason string is part of the base clueResponseType]
The text quoted here could be read as implying that the reason string is
required in the 'ack' message, a stronger requirement than of the base
clueResponseType where it has minOccurs=0.  Some greater clarity in the
text here is probably called for, especially since when the 'ack' is
piggybacked on a 'configure' message, there is no provision for a reason
string at all.

Section 5.5

                            The  element MUST NOT be present if an
  'ack' message has been already sent back to the MP.

I think you need to clarify that this is scoped to the current
advSequenceNr.

Section 5.6

                                            It contains (Figure 8) a
  response code with a reason string indicating either the success or
  the failure (along with failure details) of a 'configure' request
  processing.  [...]

[Same comment about reason string as for 'ack']

Section 5.7
 
  Such new response codes MUST NOT overwrite the ones here defined and
  they MUST respect the semantics of the first code digit.

nit: is this "overwrite" or "override"?
 
  This document does not define response codes starting with "1", and
  such response codes are not allowed to appear in major version 1 of
  the CLUE protocol.  The range from 100 to 199 inclusive is reserved
  for future major versions of the protocol to define response codes
  for delayed or incomplete operations if necessary.  Response codes
  starting with "5" through "9" are reserved for future major versions
  of the protocol to define new classes of response, and are not
  allowed in major version 1 of the CLUE protocol.  Response codes
  starting with "0" are not allowed.
 
This text seems to also preclude extensions to major version '1' from
defining 1xx or [5-9]xx reason codes; is that the intent?

Section 6

  When the CLUE data channel set up starts ("start channel"), the CP
  moves from the IDLE state to the CHANNEL SETUP state.

nit: only one of "sets up" and "starts" is needed.

  When in the ACTIVE state, the CP starts the envisioned sub-state
  machines (i.e., the MP state machine and the MC state machine)
  according to the roles it plays in the telepresence sessions.  Such
  roles have been previously declared in the 'options' and
  'optionsResponse' messages involved in the initiation phase (see
  OPTIONS sections Section 5.1 and Section 5.2 for the details).  [...]
 
My reading of the initiation phase is that each CP sends only a boolean
indication of whether it supports the MP/MC roles, and so each party has to
determine on its own whether it will act as a MP and/or MC; is that
correct?  If so, do we need to say anything about how the boolean matrix
translates to activating the respective sub-state machines?

Section 6.1

                        'configure+ack' messages referring to out-of-
  date (i.e., having a sequence number equal to or less than the
  highest seen so far) advertisements MUST be ignored, i.e., they do
  not trigger any state transition.  [...]

Is this really less than or equal or just less than?  Also, is "seen" the
right verb, since IIUC these are sequence numbers that the MP has
*generated* in its advertisements?

Section 7

                                                          In other
  words, in this example, the MP MUST use version 1.4 and downgrade to
  the lower version.  [...]

nit: does the phrase "and downgrade to the lower version" add any value
here?  The word "downgrade" can have negative connotations in some other
contexts, so if it's not adding value I'd suggest avoiding it.

Section 8

  As reported in Figure 13, the values of the fields of the
  element (either new information or new messages) take the following
  values:
[...]
  o  the major standard version of the protocol that the extension
      refers to.

The XSL includes a full version (including minor), even though the
semantics basically only use the major version.  That said, why is the
'version' element minOccurs="0" -- what are the semantics when it is
absent?

Section 8.1

  The CLUE data model document ([I-D.ietf-clue-data-model-schema])
  envisions the possibility of adding this kind of "extra" information
  in the description of a video capture by keeping the compatibility
  with the CLUE data model schema.  [...]

nit: I don't think this is grammatical; maybe just "keeping compatibility".

Section 10

This claims to be a "call flow" example, but the described flows only
contain a single unidirectional media flow, which is not really consistent
with the normal usage of the word "call".  Buried in the body text there is
a disclaimer:
  [...]                      For the sake of simplicity, the following
  call flow focuses only on the dialogue between MP CP1 and MC CP2.
I would suggest making the presence of this simplification much clearer
from the start, perhaps "CLUE protocol messages exchanged in the following
call flow are detailed; only one direction of media is shown for
simplicity, as the other direction is precisely symmetric".

  CP2 acknowledges the second 'advertisement' message with an 'ack'
  message (Section 10.7).

  In a second moment, CP2 changes the requested media streams from CP1
  by sending to CP1 a 'configure' message replacing the previously
  selected video streams with the new composed media streams advertised
  by CP1 (Section 10.8).

This might be an appropriate place to indicate that media from the previous
configuration continue to flow during the reconfiguration process.

It might also be worth noting again somewhere in here (or a subsection)
that there are three (well, two, since we only show one direction of media)
distinct sequence number spaces per sender, and that the discontinuity
between Section 10.2 and 10.3's numbers is correct.

Section 11

Thanks for the well-thought-through security considerations; in combination
with the linked documents (particularly the framework), they cover all the
considerations (especially privacy considerations) that I had in mind.

Section 14.2

We appear to be citing both 5117 and 7667, whereas the latter obsoletes the
former.

The document needs to be updated to reflect IESG feedback as well as input from the IANA XML expert (his comment to IANA: "I've provided comments to the authors directly. There is a blocking comment in there, so I expect to see another revision later.")

[Ballot comment]
Please address the Gen-ART review comments.

Section 5.7: I don't understand why the 100-199 range is reserved for a specific purpose for a future major version rather than having codes in that range defined now. That is, if it is discovered that delay or incompleteness is useful to signal, why would establishing support for that necessarily require some other backwards-incompatible change to the protocol?

Section 8: In addition to Benjamin's question about the version I don't understand how the schemaRef having minOccurs=0 makes sense. Doesn't it need to be included?

[Ballot comment]
Section 5.7: I don't understand why the 100-199 range is reserved for a specific purpose for a future major version rather than having codes in that range defined now. That is, if it is discovered that delay or incompleteness is useful to signal, why would establishing support for that necessarily require some other backwards-incompatible change to the protocol?

Section 8: In addition to Benjamin's question about the version I don't understand how the schemaRef having minOccurs=0 makes sense. Doesn't it need to be included?

[Ballot comment]
I support Ben's DISCUSS.

A couple of extra nits, which I think need addressing:

XML and XML Schema need to be a Normative References.

12.4.1.  CLUE Message Types

  +-------------------+-----------------------------------+-----------+
  | Message          | Description                      | Reference |
  +-------------------+-----------------------------------+-----------+
  | options          | Sent by the CI to the CR  in the  | RFCXXXX  |
  |                  | initiation phase to specify the  |          |
  |                  | roles played by the CI, the      |          |
  |                  | supported versions and the        |          |
  |                  | supported extensions.            |          |
  | optionsResponse  | Sent by the CI to the CR in reply | RFCXXXX  |

Should the above be: "Sent by the CR to the CI ..."

  |                  | to an 'options' message to        |          |
  |                  | finally estabilsh the version and |          |

Typo: establish

  |                  | the extensions to be used in the  |          |
  |                  | following CLUE messages exchange. |          |

Examples in Section 10 contain URI "http://wpage.unina.it/spromano/clue-protocol-17-schema-file.xsd". Maybe they shouldn't.

[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3717


I have noted a number of points where I think this is not fully
specified. I am not marking this DISCUSS because I believe they are
easy to fix and assume the AD will take care of them.


IMPORTANT
S 5.1.
>      detailed in Section 5.7
> 
>  5.1.  options
> 
>      The 'options' message is sent by the CLUE Participant which is the
>      Channel Initiator to the CLUE Participant which is the Channel

How do I know who is the CI and CR


S 6.
>      moves from the IDLE state to the CHANNEL SETUP state.
> 
>      If the CLUE data channel is successfully set up ("channel
>      established"), the CP moves from the CHANNEL SETUP state to the
>      OPTIONS state.  Otherwise if "channel error", it moves back to the
>      IDLE state.  The same transition happens if the CLUE-enabled

Is it possible to re-start the setup phase? If not, perhaps you want
an ERROR state. If so, maybe describe how


S 6.1.
>      MP moves to the WAIT FOR CONF state.  If a NACK arrives (i.e., an
>      'ack' message with an error response code), the MP moves back to the
>      ADV state for preparing a new 'advertisement'.  When in the WAIT FOR
>      ACK state, if a 'configure' message with the  element set to
>      TRUE arrives ("configure+ack received"), the MP goes directly to the
>      CONF RESPONSE state.  'configure+ack' messages referring to out-of-

What about a configure without an ACK?


S 6.1.
>      date (i.e., having a sequence number equal to or less than the
>      highest seen so far) advertisements MUST be ignored, i.e., they do
>      not trigger any state transition.  If the telepresence settings of
>      the MP change while in the WAIT FOR ACK state ("changed telepresence
>      settings"), the MP switches from the WAIT FOR ACK state to the ADV
>      state to create a new 'advertisement'.

What happens if I receive configure while in ADV?


S 7.
>      the lower version.  This said, and coherently with the general IETF
>      "protocol robustness principle" stating that "an implementation must
>      be conservative in its sending behavior, and liberal in its receiving
>      behavior" [RFC1122], CLUE Participants MUST ignore unknown elements
>      or attributes that are not envisioned in the negotiated protocol
>      version and related extensions.

This seems to mean that if you speak X.Y, then you need to minimally
have a map of all features in [0..Y-1]. Is that correct?

COMMENTS
S 5.1.
>   
> 
>                  Figure 3: Structure of CLUE 'options' message
> 
>      contains the list of the versions that are
>      supported by the CI, each one represented in a child

Are these ordered?


S 5.1.
>      misinterpreting the contents of messages.  The minor version is
>      obviously less useful in this context, since minor versions are
>      defined to be both backwards and forwards compatible, but it is more
>      useful to know the highest minor version supported than some random
>      minor version, as it indicates the full feature set that is
>      supported.  The reason why it is less useful is that the value can in

I'm not quite following the juxtaposition of "full feature set" and
"backwards and forwards compatible". Can you spell out the guarantees
more precisely


S 5.2.
>      inclusive, the response MUST also include ,
>      ,  and  elements; it MAY
>      include them for any other response code.  and
>      elements are associated with the supported roles (in
>      terms of, respectively MP and MC), similarly to what the CI does in
>      the 'options' message.  The  field indicates the highest

What does it mean to provide these for other codes?


S 5.2.
> 
>              Figure 4: Structure of CLUE 'optionsResponse' message
> 
>      Upon reception of the 'optionsResponse' the version to be used is the
>      one provided in the  tag of the message.  The following CLUE
>      messages MUST use such a version number in the "v" attribute.  The

What goes in the "v" attribute for this message?


S 5.5.
>     
> 
>                Figure 7: Structure of CLUE 'configure' message
> 
>      The  element contains the sequence number of the
>      'advertisement' message the 'configure' refers to.

It would be useful to mention here how out of date configures are
handled.


S 6.
>      herein discuss the state machines associated, respectively, with the
>      CLUE Participant (Figure 10), with the MC process (Figure 11) and
>      with the MP process (Figure 12).  Endpoints often wish to both send
>      and receive media, i.e., act as both MP and MC.  As such there will
>      often be two sets of messages flowing in opposite directions; the
>      state machines of these two flows do not interact with each other.

This point would have been useful to make earlier.


S 6.2.
>      successfully agreed on the media streams to be shared.  Then, the MC
>      can move to the ESTABLISHED state.  On the other hand, if an error
>      response is received ("error configureResponse received"), the MC
>      moves back to the CONF state to prepare a new 'configure' request.
>      If a new 'advertisement' is received in the WAIT FOR CONF RESPONSE
>      state, the MC switches to the ADV PROCESSING state.

I agree with what others have said here. It seems like only certain
errors merit this.


S 10.
> 
> 
>                    Figure 16: Schema defining CLUE messages
> 
>  10.  Call flow example
> 

This would be vastly more useful earlier.

[Ballot discuss]
Thanks for all the work on this over the years. I have a few concerns that I think require discussion prior to publication:

§5.7: Is the "description" field expected to be human readable? If so, are there internationalization issues to consider?

§6.2, 5th paragraph: This says that if you get an error back for a configure message, you send a new configure message. This seems likely to cause an infinite loop unless some guidance is given about escaping the loop when the endpoints cannot agree on a configuration.

§7:  I’m confused by the versioning mechanisms. This section requires an endpoint to ignore unknown elements, but it also requires the peer to downgrade to the highest shared version. These requirements seem to be at cross purposes. If the peer downgrades, one should only see unknown elements in the case of implementation errors. The requirement to ignore unknown elements does not come for free; nor does the requirement to downgrade.

§5.1 and §8: The use of the options message to negotiate extensions seems underspecified. How does an endpoint compare extensionType elements?  Is a spec required or expected? Is the extension spec expected to register the URI for schemaRef somewhere? Does this need to be in IANA?

[Ballot comment]
I've got a number of additional comments that do not seem to rise to the level of a DISCUSS:

*** Substantive Comments ***

I support Benjamin Kaduk's DISCUSS.

Additionally, I think there's some missing sub-transaction states, at least in the state machine in Figure 10. When an endpoint sends a message and is waiting for a response, shouldn't there be a separate waiting state (for example, when waiting for optionsResponse)? The MP and MC state machines include this sort of thing but the initial state machine does not. Also, I wonder if there are some unhandled cases where a configure and advertise message cross on the wire.

- §1 ( also §2, definition of "endpoint"):
I'd like to see a few more words about the relationship between this, the framework draft, the datachannel draft, and SIP.  Am I correct to understand that is the only environment the protocol is ever expected to operate in? That is, is there room for different signaling protocols, different transports, etc? This also impacts the security considerations. For example if this depends on the security properties of datachannels (over SCTP and DTLS), then it's worth some language to the effect that it MUST not be used on other transports, or that if it is used on other transports they must have similar security properties.

§2, definition of endpoint: Please cite RFC3261 for SIP. (I have mixed feelings whether this needs to be normative or informational.)

§4:
- "a lack of interoperability between the
protocol implementations. In order to correctly establish a CLUE
dialogue, the involved CPs MUST have in common a major version number"

That seems like a statement of fact. I suggest reserving the normative keywords for the actual procedures that require this.

§5:
- ClueID: Is this truly optional in the sence of never required under any circumstances?
- sequenceNr: Is the language about incrementing intended to use normative keywords? (e.g MUST)?
Why do implementations need to send errors for unexpected sequence numbers when using a reliable protocol? That would only happen in the case of implementation errors, right?
Why is it optional to start with a random sequence number? Is there a concern about fingerprinting if people choose otherwise? (I guess as the security considerations mention, there's a lot of other things to fingerprint.)

- Protocol field: Do you envision non-CLUE messages will ever occur on the same SCTP association? if not, then why require this? If so, then what should an endpoint do if it gets a message with something other than "clue" here?

§5.1: "since minor versions are
defined to be both backwards and forwards compatible,"
Please see related DISCUSS comment.

§5.7:

- What is the reason for defining meaning the "100" response code range if no codes in that range are defined? Why is this different from the 500-900 ranges that are merely reserved for future use? (I gather there was an intent to be consistent with SIP error codes, but why not leave that to the first spec that defines a 1XX code, assuming that ever happens?

- "message. Implementations can (and are encouraged to)
include more specific descriptions of the error condition, if
possible."

Am I correct to assume that implementations should not expect any particular description text for a given error code? (That used to be a common interop problem for SIP.)

§6:
- "When the CLUE data channel set up starts ("start channel"), the CP
moves from the IDLE state to the CHANNEL SETUP state."

What does "set up starts" mean? Is this trigged by SDP signaling? SCTP connection? Is it different for the SCTP client and server? (I suspect the data-channel draft answers this, but it should at least be cited here.)

§6.1:
- "Finally, if there are changes
in the MP’s telepresence settings ("changed telepresence settings"),
the MP switches to the ADV state."
If I understand correctly, the MC can send new configure messages at any time. What happens if one arrives in the ADV state but before sending the advertise?

6.2, 2nd paragraph:
-  Is the MC forbidden from sending a configure without the ack field set prior to sending an ack?
- Is the response code limited to 200, are or other 2XX codes allowed if defined?

§12.3: The mime type isn’t mentioned anywhere else in the doc? Why is it registered here? What is it used for?

§12.4.1: Why is it necessary to both register these directly in IANA and define them in a (presumably registered) schema? Am I correct to assume new message types must also be defined in a schema?

*** Editorial Comments ***

- General:
-- Please proofread for "which" vs "that" usage.
-- Please proofread for null words, especially "obviously" and similar terms, which some readers might read as condescending.

- Abstract: Is CLUE an acronym? If so, what is its expansion? (If the title is the expansion, it's very obscure.). If not, why all-caps?

§2: Please expand MCU on first mention.

§4:
- "The subset of the extensions
that are allowed within the CLUE session is also determined in the initiation phase, such subset being the one including only the extensions that are supported by both parties"
Convoluted sentence, can it be simplified?

- "Hence in a call between two
CPs, A and B, there would be two separate dialogs, as follows:"
Please define the meaning of "dialog" as used in this document. In particular, that it is not related to SIP's usage of the term.

§5:
"While the ’options’ and ’optionsResponse’ messages are exchanged in
the initiation phase between the CPs, the other messages are involved
in MP-MC dialogues."
This also needs a definition of "dialog" for the meaning to be clear.

§5.5:

- "The MC can send a
’configure’ after the reception of an ’advertisement’ or each time it
wants to request other captures that have been previously advertised
by the MP."
The use of "can" makes this seem optional. I gather from the state machine this is not the case.

- "It indicates that the ’configure’
message also acknowledges with success the referred advertisement
(’configure’ + ’ack’ message), by applying in that way a piggybacking
mechanism for simultaneously acknowledging and replying to the
’advertisement’ message."
Convoluted sentence.

5.7:
- "200, 300 and 400 codes are considered catch-alls."
Please elaborate on what "catch-all" means in context.

- "Further response codes can be either defined
in future versions of the protocol (by adding them to the related
IANA registry)..."
The parenthetical phrase is redundant to the next sentence.

§6:

- First Paragraph: The first and last sentences are redundant with earlier text in the draft. Should "MC process" and "MP process" be "MC role" and "MP role"?

§6.1, 3rd paragrap: The first sentence seems out of place, given that much of the previous paragraph was about what happens in the WAIT FOR CONF state.

- 5th paragraph: "If there are
changes in the MP’s telepresence settings ("changed telepresence
settings"), the MP moves back to the ADV state."
Redundant to previous paragraph.

§8.1, 2nd paragraph: The second sentence is redundant to similar text in §8.

[Ballot comment]
I found the document to be well written and easy to read. I just had a concern about the response codes. I did not find text either in this on in draft-ietf-clue-signaling that describes the behavior that results in a specific response code. e.g. 402 and 404 seem to have some overlap but there is no text for when a 404 will be sent to disambiguate it from 402. Likewise for the other response codes. I did not find any prescriptive behavior that results in these codes.

[Ballot comment]
I'd like to thank Benjamin for his detailed review! Also, Zitao Wang for the OpsDir review - it contains some useful nits, and I'd encourage the authors to address them.

[Ballot discuss]
Thanks for the generally clear and well-written document!
I would like to discuss whether there needs to be more prominent coverage
of timers/timeouts, especially as relating to the state machines.  (I'd be happy
to learn that this is well-covered elsewhere in the document set; I just haven't
run into it yet.)

In a similar vein, do we want to have any treatment of avoiding infinite loops
(e.g., when a 'configure' or 'advertisement' is rejected in expectation of modification
but the sending implementation continues to generate an identical message)?

It is not clear to me that any change to the document text is needed in either case,
but I don't know to what extent the topics have already been discussed.

[Ballot comment]
I also have some substantial comments that do not rise to Discuss-level.

How do I know which endpoint is the channel initiator and which is the
channel receiver?
draft-ietf-clue-signaling suggests that the DTLS client is the channel
initiator, but even that is not explicit about it -- the protocol could be
considered under-specified if there is insufficient clarity.

Section 2

The MCU definition doesn't actually expand the acronym, which seems a
little reader-unfriendly.

Section 5.1

There are perhaps more XML extension points in here than is reasonable for
some of these elements (e.g., ).

Section 5.2

                          If the responseCode is between 200 and 299
  inclusive, the response MUST also include ,
  ,  and  elements;

Maybe re-mention that MP and MC are booleans here.

  Finally, the commonly supported extensions are copied in the
    field.

Does this need to say that only extensions that are applicable to the
negotiated protocol version are included?  (Also, how does one handle an
extension that exists for multiple major versions -- are there two
elments for it in the  message?)

  Upon reception of the 'optionsResponse' the version to be used is the
  one provided in the  tag of the message.  The following CLUE
  messages MUST use such a version number in the "v" attribute.  The
  allowed extensions in the CLUE dialogue are those indicated in the
    of the 'optionsResponse' message.

Couldn't this restriction on the "v" value apply even to the
'optionsResponse' message?

Section 5.3

  The 'advertisement' message is used by the MP to advertise the
  available media captures and related information to the MC.  [...]

I'd consider avoiding the definite article "the" to refer to MP/MC roles,
since in many caess there will be 2+ of each, and we don't want to confuse
the reader into thinking that there is an MP/CR equivalence or something
like that.  So, perhaps "each MP" and "the corresponding MC".

Section 5.4

                            As it can be seen from the message schema
  provided in the following excerpt (Figure 6), the 'ack' contains a
  response code and a reason string for describing the processing
  result of the 'advertisement'.  [...]

[the reason string is part of the base clueResponseType]
The text quoted here could be read as implying that the reason string is
required in the 'ack' message, a stronger requirement than of the base
clueResponseType where it has minOccurs=0.  Some greater clarity in the
text here is probably called for, especially since when the 'ack' is
piggybacked on a 'configure' message, there is no provision for a reason
string at all.

Section 5.5

                            The  element MUST NOT be present if an
  'ack' message has been already sent back to the MP.

I think you need to clarify that this is scoped to the current
advSequenceNr.

Section 5.6

                                            It contains (Figure 8) a
  response code with a reason string indicating either the success or
  the failure (along with failure details) of a 'configure' request
  processing.  [...]

[Same comment about reason string as for 'ack']

Section 5.7
 
  Such new response codes MUST NOT overwrite the ones here defined and
  they MUST respect the semantics of the first code digit.

nit: is this "overwrite" or "override"?
 
  This document does not define response codes starting with "1", and
  such response codes are not allowed to appear in major version 1 of
  the CLUE protocol.  The range from 100 to 199 inclusive is reserved
  for future major versions of the protocol to define response codes
  for delayed or incomplete operations if necessary.  Response codes
  starting with "5" through "9" are reserved for future major versions
  of the protocol to define new classes of response, and are not
  allowed in major version 1 of the CLUE protocol.  Response codes
  starting with "0" are not allowed.
 
This text seems to also preclude extensions to major version '1' from
defining 1xx or [5-9]xx reason codes; is that the intent?

Section 6

  When the CLUE data channel set up starts ("start channel"), the CP
  moves from the IDLE state to the CHANNEL SETUP state.

nit: only one of "sets up" and "starts" is needed.

  When in the ACTIVE state, the CP starts the envisioned sub-state
  machines (i.e., the MP state machine and the MC state machine)
  according to the roles it plays in the telepresence sessions.  Such
  roles have been previously declared in the 'options' and
  'optionsResponse' messages involved in the initiation phase (see
  OPTIONS sections Section 5.1 and Section 5.2 for the details).  [...]
 
My reading of the initiation phase is that each CP sends only a boolean
indication of whether it supports the MP/MC roles, and so each party has to
determine on its own whether it will act as a MP and/or MC; is that
correct?  If so, do we need to say anything about how the boolean matrix
translates to activating the respective sub-state machines?

Section 6.1

                        'configure+ack' messages referring to out-of-
  date (i.e., having a sequence number equal to or less than the
  highest seen so far) advertisements MUST be ignored, i.e., they do
  not trigger any state transition.  [...]

Is this really less than or equal or just less than?  Also, is "seen" the
right verb, since IIUC these are sequence numbers that the MP has
*generated* in its advertisements?

Section 7

                                                          In other
  words, in this example, the MP MUST use version 1.4 and downgrade to
  the lower version.  [...]

nit: does the phrase "and downgrade to the lower version" add any value
here?  The word "downgrade" can have negative connotations in some other
contexts, so if it's not adding value I'd suggest avoiding it.

Section 8

  As reported in Figure 13, the values of the fields of the
  element (either new information or new messages) take the following
  values:
[...]
  o  the major standard version of the protocol that the extension
      refers to.

The XSL includes a full version (including minor), even though the
semantics basically only use the major version.  That said, why is the
'version' element minOccurs="0" -- what are the semantics when it is
absent?

Section 8.1

  The CLUE data model document ([I-D.ietf-clue-data-model-schema])
  envisions the possibility of adding this kind of "extra" information
  in the description of a video capture by keeping the compatibility
  with the CLUE data model schema.  [...]

nit: I don't think this is grammatical; maybe just "keeping compatibility".

Section 10

This claims to be a "call flow" example, but the described flows only
contain a single unidirectional media flow, which is not really consistent
with the normal usage of the word "call".  Buried in the body text there is
a disclaimer:
  [...]                      For the sake of simplicity, the following
  call flow focuses only on the dialogue between MP CP1 and MC CP2.
I would suggest making the presence of this simplification much clearer
from the start, perhaps "CLUE protocol messages exchanged in the following
call flow are detailed; only one direction of media is shown for
simplicity, as the other direction is precisely symmetric".

  CP2 acknowledges the second 'advertisement' message with an 'ack'
  message (Section 10.7).

  In a second moment, CP2 changes the requested media streams from CP1
  by sending to CP1 a 'configure' message replacing the previously
  selected video streams with the new composed media streams advertised
  by CP1 (Section 10.8).

This might be an appropriate place to indicate that media from the previous
configuration continue to flow during the reconfiguration process.

It might also be worth noting again somewhere in here (or a subsection)
that there are three (well, two, since we only show one direction of media)
distinct sequence number spaces per sender, and that the discontinuity
between Section 10.2 and 10.3's numbers is correct.

Section 11

Thanks for the well-thought-through security considerations; in combination
with the linked documents (particularly the framework), they cover all the
considerations (especially privacy considerations) that I had in mind.

Section 14.2

We appear to be citing both 5117 and 7667, whereas the latter obsoletes the
former.

[Ballot comment]
Update: Revising my discuss, as I missed the pointer to draft-ietf-clue-signaling. Sorry for that!

Two minor editorial commets:

1) In the terminology section: What does MCU actually stand for?

2) sec 4:
"CLUE protocol version numbers are
  characterized by a major version number (single digit) and a minor
  version number (single digit)..."
However, later on the text says that the numbers can also consist of multiple digits...

[Ballot discuss]
This document does not discuss any interactions with the transport protocol (e.g. who establishes the connection? what happens if the connections breaks; who should re-establish?). Also, I assume that SCTP is used (instead of TCP) because the idea is to use different SCTP streams for the different directions of the communication...? However, this is a complete guess, as the document does unfortunately not say nothing about the mapping of CLUE messages to SCTP sessions. In case all message are assumed to be send over the same stream instead, why is SCTP used and not TCP? Please provide more information and guidance on the use of SCTP!

[Ballot comment]
Two minor editorial commets:

1) In the terminology section: What does MCU actually stand for?

2) sec 4:
"CLUE protocol version numbers are
  characterized by a major version number (single digit) and a minor
  version number (single digit)..."
However, later on the text says that the numbers can also consist of multiple digits...

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-clue-protocol-17. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration is to be made as follows:

ID: clue-protocol
URI: urn:ietf:params:xml:ns:clue-protocol
Filename: [ TBD-at-Registration ]
Refernece: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Second, in the ns registry also on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new registration is to be made as follows:

ID: clue-protocol
URI: urn:ietf:params:xml:schema:clue-protocol
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this action also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the application registry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single, new registration will be made as follows:

Name: clue+xml
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the CLUE Message Types Registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Specification Required as defined by RFC 8126.

The new registry has initial registrations as follows:

+-------------------+-----------------------------------+-----------------+
| Message | Description | Reference |
+-------------------+-----------------------------------+-----------------+
| options | Sent by the CI to the CR in the | [ RFC-to-be ] |
| | initiation phase to specify the | |
| | roles played by the CI, the | |
| | supported versions and the | |
| | supported extensions. | |
| optionsResponse | Sent by the CI to the CR in reply | [ RFC-to-be ] |
| | to an 'options' message to | |
| | finally estabilsh the version and | |
| | the extensions to be used in the | |
| | following CLUE messages exchange. | |
| advertisement | Sent by the MP to the MC to | [ RFC-to-be ] |
| | specify the telepresence | |
| | capabilities of the MP expressed | |
| | according to the CLUE framework. | |
| ack | Sent by the MC to the MP to | [ RFC-to-be ] |
| | acknowledge the reception of an | |
| | 'advertisement' message. | |
| configure | Sent by the MC to the MP to | [ RFC-to-be ] |
| | specify the desired media | |
| | captures among those specified in | |
| | the 'advertisement'. | |
| configureResponse | Sent by the MP to the MC in reply | [ RFC-to-be ] |
| | to a CONFIGURE message to | |
| | communicate if the configuration | |
| | request has been successfully | |
| | processed or not. | |
+-------------------+-----------------------------------+-----------------+

Fifth, a new registry is to be created called the CLUE Response Codes Registry.

IANA Question --> As before, where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

The new registry is to be managed via Specification Required as defined by RFC 8126.

The new registry has initial registrations as follows:

+--------+---------------+------------------------------+-----------------+
| Number | Default | Description | Reference |
| | Response | | |
| | String | | |
+--------+---------------+------------------------------+-----------------+
| 200 | Success | The request has been | [ RFC-to-be ] |
| | | successfully processed. | |
| 300 | Low-level | A generic low-level request | [ RFC-to-be ] |
| | request | error has occurred. | |
| | error. | | |
| 301 | Bad syntax | The XML syntax of the | [ RFC-to-be ] |
| | | message is not correct. | |
| 302 | Invalid value | The message contains an | [ RFC-to-be ] |
| | | invalid parameter value. | |
| 303 | Conficting | The message contains values | [ RFC-to-be ] |
| | values | that cannot be used | |
| | | together. | |
| 400 | Semantic | Semantic errors in the | [ RFC-to-be ] |
| | errors | received CLUE protocol | |
| | | message. | |
| 401 | Version not | The protocol version used in | [ RFC-to-be ] |
| | supported | the message is not | |
| | | supported. | |
| 402 | Invalid | Sequence number gap; | [ RFC-to-be ] |
| | sequencing | repeated sequence number; | |
| | | sequence number outdated. | |
| 403 | Invalid | The clueId used in the | [ RFC-to-be ] |
| | identifier | message is not valid or | |
| | | unknown. | |
| 404 | advertisement | The sequence number of the | [ RFC-to-be ] |
| | Expired | advertisement the configure | |
| | | refers to is out of date. | |
| 405 | Subset choice | The subset choice is not | [ RFC-to-be ] |
| | not allowed | allowed for the specified | |
| | | Multiple Content Capture. | |
+--------+---------------+------------------------------+-----------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-10-17):

From: The IESG
To: IETF-Announce
CC: adam@nostrum.com, "Daniel C. Burnett" , clue@ietf.org, pkyzivat@alum.mit.edu, clue-chairs@ietf.org, Paul Kyzivat , draft-ietf-clue-protocol@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Protocol for Controlling Multiple Streams for Telepresence (CLUE)) to Proposed Standard


The IESG has received a request from the ControLling mUltiple streams for
tElepresence WG (clue) to consider the following document: - 'Protocol for
Controlling Multiple Streams for Telepresence (CLUE)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-10-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The CLUE protocol is an application protocol conceived for the
  description and negotiation of a telepresence session.  The design of
  the CLUE protocol takes into account the requirements and the
  framework defined within the IETF CLUE working group.  A companion
  document delves into CLUE signaling details, as well as on the SIP/
  SDP session establishment phase.  CLUE messages flow over the CLUE
  data channel, based on reliable and ordered SCTP over DTLS transport.
  Message details, together with the behavior of CLUE Participants
  acting as Media Providers and/or Media Consumers, are herein
  discussed.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2273/
  https://datatracker.ietf.org/ipr/2274/

The authors have identified an issue with the definition of the type for the XML  element, and are waiting for confirmation of their proposed solution by the working group. Regardless of the outcome of this conversation, a revised ID will be required before the document can be progressed (as this issue prevents the currently defined XML from validating).

AD review Sent to CLUE WG and document authors:

I have completed my AD review for the CLUE protocol document. Based on my reading, I do not think it is yet ready for IETF last call.

Most of my comments below are feedback that the document authors should treat as normal last call comments. The feedback that I consider to block progressing the document, in my role as AD, is explicitly marked with the prefix "BLOCKER", and these will need to be resolved in a new version of the document before progressing it further. Note that it is entirely possible that something I have marked "BLOCKER" may stem from an error on my part; so recognize that these are not demands for change, as much as a need to have things either fixed in the document or explained to me.

Title: The rule of thumb is that all but a small handful of well-known acronyms need to be expanded in titles and abstracts. I recognize that "CLUE" is a bit tortured, as acronyms go, but the title of this document is, broadly speaking, opaque. Please change it to something meaningful, such as "Protocol for Controlling Multiple Streams for Telepresence (CLUE)"

General: There are three instances of excessively long lines in the document.

General: Please number and caption the figures in this document. Also, please refer to the figure numbers when pointing to them (e.g., the first paragraph of section 6.1 should read something like: "As soon as the sub-state machine of the MP (Figure 1) is activated..."."

BLOCKER: General: There are several mentions of timeouts and retry thresholds in the text and its corresponding state machines; however, the document neither defines nor cites a document as defining what these timeout and retry values are. These need to be defined and described. If the timer and retry scheme allows the two ends of the connection to have different values for timeouts and number of retries, then there need to be additional error procedures that allow the MC and MP state machines to stay in sync (if the timer/retry values can be different, it's possible for one state machine to transition to "terminated," while the other is still active, and you need messaging to clean this up). The remainder of this comment is non-blocking: Related to this, the document frequently refers to retries as "expiring" (e.g., "retry expired" on the state diagrams). That doesn't really make sense unless "retry" is the name of a timer rather than a counter; I think you mean to say "exhausted" or something similar.

General: This document defines six message types, all of which have at least two names, many of which have more. It would be a lot easier to keep track of what is being described if these were kept consistent. I suggest choosing one term for each concept and sticking with it. In other words, please pick only one name from each of the following lines, and do not use any of the others:

    OPTIONS, options
    OPTIONS RESPONSE, optionsResponse
    ADVERTISEMENT, ADV, advertisement
    ADVERTISEMENT ACKNOWLEDGEMENT, ADV ACK, ACK, NACK, ack
    CONFIGURE, CONF, CONF+ACK, configure
    CONFIGURE RESPONSE, CONF RESPONSE, configureResponse

The terminology section appears to be in alphabetical order, except for "Capture Encoding" (which was presumably "Media Capture Encoding" in some earlier version). Please fix.

The definitions for "Endpoint", "MCU", and "Media Stream/Stream" vary from the definition given in draft-ietf-clue-framework. Is this intentional?

The first paragraph of section 4 mentions the framework and data model documents without citations. There should probably be citations to the corresponding documents.

Section 4 contains the following text:

  The CLUE protocol represents the mechanism
  for the exchange of CLUE information between CLUE Participants

This is sufficiently circular as to be basically meaningless. Suggest: "...for the exchange of telepresence information between..."

Section 5: The versioning scheme in here is rather perplexing. Is there some technical reason the protocol restricts major version numbers to a single digit and minor versions to a single digit? Strongly suggest that this should be expanded to allow multiple digits for both the major and minor versions.

Section 5: It should be made clear that the XML Schema excerpts in section 5 are non-normative. In particular, I recommend adding the following text to the end of the first paragraph of section 5: "This section includes non-normative excerpts of the schema to aid in describing it."

Section 5: If the single-digit version numbers are maintained (and, again, I strongly recommend against this), the definition of versionType appears to be wrong: it allows a major version digit of "0", which would seem to be precluded by the way versions are currently defined.

Section 5: The XML definition allows zero or more  elements to appear in a message. If more than one is allowed, the document should explain how multiple IDs are handled. If they are not, then the schema and/or text needs to prohibit having more than one.

Section 5: The description for  says that a 402 will be sent in the case of an "unexpected" sequence number. This needs clarification: is this for case where a sequence number gap is detected? A repeated sequence number? A number that is too small? All of the above? At least describe this with the 402 error code, and point to that description from here.

Section 5: The description for  would benefit from the addition of "This document describes version 1.0".

Section 5.1: "The OPTIONS message is sent by the CP which is the CI to the CP which is the CR as soon as the CLUE data channel is ready." Although it's a problem in other parts of the document too, the dense use of nearly identical two-letter acronyms in here makes it quite hard to read. I had to keep consulting the definitions of those acronyms to decode this sentence (as well as several similar ones). Consider just expanding these terms (as well as "MP" and "MC") instead of using them in prose.

Section 5.1 starts to wobble back and forth between referring to elements with and without angle brackets (e.g., it uses both "supportedVersions" and ""). Please pick one and stick with it.

BLOCKER: Section 5.1: The description of  describes a scheme in which multiple supported versions can be listed; and, if the list is omitted, it implies that only the version described in  is supported. This text does not define (nor does any other text that I can find) what  should be set to when  is used. Intuitively, it seems that  should be set to the largest minor version of the smallest major version advertised in , but that (or whatever the correct answer is) needs to be clearly spelled out.

BLOCKER: Section 5.2: "If the responseCode is of the type 2xx the response MUST also include..." -- you can't use "2xx" in a normative statement without first defining what it means. As you don't use the "#xx" format anywhere else, I suggest rephrasing: "If the  is between 200 and 299 inclusive, the response MUST also include..."

Sections 5.2, 5.4, 5.6: It seems really odd that the document defines a base clueMessageType that all messages derive from, but then leaves all the response types (optionsResponse, ack, configureResponse) to repeatedly and independently add ,, and the sequence number of the corresponding message over and over again. I would strongly suggest adding something like:

 
 
 
 
 
 
 
 
 
 
 
 
 

...and then defining those three response types as being extensions of "clueResponse" instead of "clueMessage", like this:

 
 
 
 
 
 
 
 

Regardless of how you do this, any section that adds "responseCode" and "reasonString" needs to point to section 5.7 in its description to explain how those fields are populated and interpreted.

Section 5.5: This section allows a boolean flag in a  message to acknowledge an . Is this intended to always be handled like a 200? Consider: if you define a 201 response code in the future, will implementations be unable to convey its meaning in a CONF + ACK? Given that the document defines a class of codes for success rather than a simple success flag in general, it seems that this  element should carry a success response code rather than just a boolean. If you decide to keep the boolean, be very clear that it is to be treated as a 200 rather than any other potential success code; and that conveying any other kind of success requires a separate  message.

Section 5.5: the final paragraph mentions the  element -- it would be helpful to add something like "see [I-D.ietf-clue-datamodel] for the definition of ."

BLOCKER: Section 5.7 indicates that there is a class of response codes, starting with "1", which are used to indicate "delayed or incomplete" responses. The document does not describe any protocol behavior for this class of response. The description of the meaning of this class (and the obvious parallels to HTTP and SIP) imply that some subsequent response associated with the same request will be arriving at some point in the future. If that's the intention, this document needs a *lot* more text (and corresponding adjustments to the state machines) to explain how these 100-class codes are handled. In practice, since the current version of the document does not define nor make use of 100-class codes, I suggest that the most reasonable path forward is to remove discussion of codes starting with "1" from the first paragraph of section 5.7, instead adding a paragraph immediately following it that says something like:

  This document does not define response codes starting with "1", and such
  response codes are not allowed to appear in major version 1 of the CLUE
  protocol. The range from 100 to 199 inclusive is reserved for future major
  versions of the protocol to define response codes for delayed or incomplete
  operations if necessary. Response codes starting with "5" through "9" are
  reserved for future major versions of the protocol to define new classes of
  response, and are not allowed in major version 1 of the CLUE protocol.
  Response codes starting with "0" are not allowed.

Section 5.7: "The response codes and strings defined for use with CLUE are as follows" - this strongly implies that the descriptions given in this table are the only ones that are allowed in CLUE  element, and that any other messages should presumably be treated as an error. Surely that's not what you mean. Suggest rephrasing to indicate that the "Description" text can be sent in the , but that implementations can (and are encouraged to) include more specific descriptions of the error condition, if possible.

Section 5.7: I can't figure out how an implementation could ever send a "300" response code. If the XML syntax is incorrect, that's a 301. If the message contains an invalid value, that's a 302. And those are the only two conditions that are described for 300. I think you need to give "300" a bit more thought -- if you can't come up with a more generic description (e.g., "low-level request error"), you probably want to remove it.

Section 5.7: for 403, be clear which identifier is meant. Do you mean "The  used in the message is not valid..."?

Section 5.7: for 404, please be clear that you're talking about the sequence number rather than just using "number" without qualification.

Section 5.7: The description for 405 uses the acronym "MCC" without expanding it. Please expand it.

BLOCKING: The state machines in section 6 and its subsections don't have transitions for all possible messages that could arrive in a state. This can cause interop issues. Please add text that clearly indicates whether such messages do or do not cause a transition. (This might be as simple as "messages not shown for a state do not cause the state to change," but only if you carefully check that this is true -- for example, what should an MP state machine do do if it gets a "CONF + ACK" in the state "WAIT FOR CONF"?)

Section 6: The fifth paragraph says "CLUE channel" where it means "CLUE data channel."

Section 6: The eighth paragraph says:

  The CP moves from the ACTIVE state to the IDLE one when the sub-state
  machines that have been activated are (both) in the relative
  TERMINATED state (see sections Section 6.1 and Section 6.2).

The "both" in this paragraph is confusing, since it's possible to have only one or the other machine running. Please rephrase.

Section 6.2 describes a state machine that starts in a state called "WAIT FOR ADV." This state does not appear to be timer-supervised, meaning that implementations of this state machine can stay in this state literally forever. Is that the intention?

Section 6.2 also describes the possibility of sending a  and  separately or as a combined message. I would have expected to see some discussion here about why implementations might choose one behavior over the other.

Section 7: The second sentence of the second paragraph needs a verb.

Section 7, paragraph 3: this claims that versions are a non-negative *integer* rather than a *digit*. As I mention above, this seems to be the right way to handle versions, but it is decidedly at odds with text elsewhere in the document and in the schema. Regardless of how you choose to treat versions, the text needs to be consistent.

Section 7, final paragraph: replace "Clue" with "CLUE."

Section 8 contains a paragraph starting with "In that case, the new information..." but it's not clear which case it's referring to. Please replace "In that case" with a description of the case under consideration.

Section 8 contains the phrase "Similarly to what said before..." -- this is ungrammatical and needs to be rephrased.

Section 8 indicates that extensions need to indicate "the standard version of the protocol the extension refers to." Given that there is compatibility within a major version of a protocol, I think this means to say "the major standard version of the protocol that the extension refers to."

Section 8 has a paragraph starting "For that reason..." -- it's not clear what reason is being referred to here. Please clarify.

Section 8 contains schema that contains a  element. It should be clarified that this is the *protocol* version, not the *extension* version (or, if it's the extension version, that needs to be spelled out too, but I think you'll need a new namespace for that...?)

BLOCKING: Section 8.1 is an example section, which are non-normative in IETF documents. It contains 2119-style normative language, however. These normative statements need to be moved out of the example section (and probably into section 8). The remainder of this comment is non-blocking: I also find the "SHOULD" in this section to be highly perplexing. Can you explain the rationale behind requiring schema, but not requiring any description of what the schema *means?)

BLOCKING: The example in section 8.1 includes the following:

  xmlns="clue-info-extension-myVideoExtensions"

I'm pretty certain that namespaces are required to be identified by URIs rather than arbitrary strings.

Section 8.1: The final paragraph also has normative language in it, although it appears to be reiterating requirements from elsewhere in the document. I suggest lowercasing "MUST" in this paragraph.

Section 8.1: The final paragraph mentions the use of  and  to negotiate the extension. An example demonstrating this negotiation would be extremely useful.

The schema in section 9 contains:



If you do not intend to bake this "-17" into the document (and I can't imagine you do), please add an RFC editor note to change it to something else upon publication.

Also, the schema in section 9 is (with rare exception) unindented. This makes it *very* hard to read. Please consider formatting it with conventional XML indentation. (This also applies to the schema excerpts earlier in the document.)

Has there been any automated tool-based checking that the examples in section 10 to verify that they conform to the schema in section 9 (and the schemata it imports)?

Section 10.2: Please expand the acronym "MCCs" in the section title (keep in mind that this appears in the table of contents, where it needs to makes sense).

Section 10 in general: While it does consume a lot of space, I don't think that defining six rather different message types and then showing only *one* type in the examples is very illustrative of the protocol. I would *STRONGLY* suggest adding at least a response message, and ideally the example section should contain at least one example for each of the six message types.

Section 11, paragraph 4: Replace "Clue" with "CLUE."

Section 12.1 has a strange double-double quote around the URN name, and section 12.3 repeats this for the MIME type.

All subsections of section 12: please update all registrant contact information to point to the IESG (iesg@ietf.org) rather than the CLUE working group and one of the authors.

Section 12.4.1: These descriptions will appear in an IANA registry, where the phrase "in this document" will have no context and be rather nonsensical. Please rephrase.

Sections 13 through 23 should include an RFC editor note asking for removal before publication.

Shepherd writeup for draft-ietf-clue-protocol-13:

[This is based on the template version dated 24 February 2012.]

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  This document is marked as Standards Track in the title page header,
  and that is appropriate - it is defining required behavior for CLUE.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The CLUE protocol is an application protocol conceived for the
  description and negotiation of a telepresence session.  The design of
  the CLUE protocol takes into account the requirements and the
  framework defined within the IETF CLUE working group.  A companion
  document delves into CLUE signaling details, as well as on the SIP/
  SDP session establishment phase.  CLUE messages flow over the CLUE
  data channel, based on reliable and ordered SCTP over DTLS transport.
  Message details, together with the behavior of CLUE Participants
  acting as Media Providers and/or Media Consumers, are herein
  discussed.

Working Group Summary

  Nothing of particular note occurred during the development of
  this document.

Document Quality

  Are there existing implementations of the protocol?

    A prototype implementation of an earlier version was built and
    demonstrated.

  Have a significant number of vendors indicated their plan to
  implement the specification?

    Not yet.

  Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues?

    None that stand out.

  If there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

    A Media Type review has *not* been requested.

Personnel

  Who is the Document Shepherd?

    Paul Kyzivat

  Who is the Responsible Area Director?

    Alissa Cooper

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The shepherd has been an active reviewer of this document throughout
  its development, and reviewed it again in its entirety while preparing
  this writeup.

  In the view of this shepherd the document is ready for
  publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No concerns. The document has been well reviewed.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  The document contains an XML schema definition and examples
  of XML documents using this schema and the one in the data
  model draft. The authors are the people in the WG with the
  most XML expertise. Others in the WG have reviewed the XML,
  but are not experts. The document could benefit from a
  review by an outside XML expert.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes, each author has stated they have no IPR claims on the document.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR has been filed against this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  There is strong WG consensus for this document by all those who have
  actively participated in the group.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There are three long lines that need to be fixed.

  There are a few other bogus warnings about line spacing and missing
  references.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  As stated above, there has been no XML review.

  (Looking back, I see that there was discussion of having both this
  and the closely related CLUE schema document reviewed together.
  But it appears that only the schema was reviewed.)

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  There are normative references to several other CLUE drafts.
  The intent is that these will all progress together.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  There are no downrefs.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  This document doesn't change the status of any other document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  The IANA considerations section is in good order.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  N/A - no new registries are defined.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  None.