[clue] Eric Rescorla's No Objection on draft-ietf-clue-protocol-17: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-clue-protocol-17: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/



----------------------------------------------------------------------
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 <ack> 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.
>     <xs:anyAttribute namespace="##other" processContents="lax"/>
>   </xs:complexType>
>                  Figure 3: Structure of CLUE 'options' message
>   
>      <supportedVersions> contains the list of the versions that are
>      supported by the CI, each one represented in a child <version>

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 <mediaProvider>,
>      <mediaConsumer>, <version> and <commonExtensions> elements; it MAY
>      include them for any other response code.  <mediaProvider> and
>      <mediaConsumer> 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 <version> 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 <version> 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.
>      </xs:complexType>
>   
>                 Figure 7: Structure of CLUE 'configure' message
>   
>      The <advSequenceNr> 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.
>   </xs:schema>
>   
>                    Figure 16: Schema defining CLUE messages
>   
>   10.  Call flow example
>   

This would be vastly more useful earlier.