Subject: [clue] Review of draft-ietf-clue-protocol-03

From: Christian Groves <[email-masked]>
Date: Thu, 19 Mar 2015 14:49:32 +1100

Hello Simon and Roberta,

I've reviewed draft-ietf-clue-protocol-03 please find my comments below:

Cl.1 bullet 2: "enabling a MC to request the desired multimedia streams 
<from> the
        offering MP."

Cl.1 3rd para: "...and established as <described> in..."

Cl.2 1st para: "I-D.ietf-clue-telepresence-requirements" is now rfc7262

Cl.4 clueID: Should we recommend a particular format for this e.g. URI 
or similar instead of just a simple string?

Cl.4 I don't understand the significance of "/Each CP should manage up 
to three streams of sequence numbers: (i) one for the messages exchanged 
in the initiation phase, (ii) one for the messages exchanged as MP, and 
(iii) one for the messages exchanged as MC./"**Would it just have to 
manage the sequence numbers it sent vs received sequence numbers? Why 
would it have to have multiple streams of numbers?
*
*Cl.4.6 Last para: "...field contains the <sequence> number of the CONF..."

Cl.4.7 "Examples of response codes" would suggest that this list is 
informative and there are other response codes. Perhaps we should say 
"The response codes and strings defined for use with CLUE are as follows:"?

Cl.4.7 Do we need a response code to deal with the situation where a MC 
tries to request a subset of individual MC from MCC even when the MP 
indicates to not allow a subset choice?

Cl.4.7: There appears to be two error codes 312 and 510 for version not 
supported.

Cl.6 2nd para: The paragraph (and other places in the draft) talks about 
"telepresence devices" we should probably be consistent with the 
terminology in the signalling draft and use "clue-capable device".

Cl.6 3rd para: "...("start channel setup")..." this is simply called 
"start channel" in the state diagram. They should be consistent.

Cl.6 4th para: "... if the telepresence session ends" is that referring 
to disabling CLUE or the SIP session ending? "Telepresence session" is 
used several times so it would be good to define what it exactly means. 
I guess this really is "CLUE session".

Cl.6 5th para: What happens if the CI and CR are unable to agree on a 
mutual CLUE version. i.e. CI support v1.5 and CR only support v2.5. Is 
the error code 312 (or 510) sufficient for this?

Cl.6 Pg17 "/If the CP receives a further OPTIONS/OPTIONS RESPONSE 
message, it MUST ignore the message and stay in the ACTIVE state./" This 
implies then that options or version can never be negotiated whilst CLUE 
is enabled and these messages can only be successful sent once. I think 
it would be good to make this clear in section 4.1/4.2.

Cl.6.1 3rd para: "In case of a timeout..." this follows text regarding 
the CONF arrival. Is this timeout related to a MP never receiving a CONF?

Cl.6.1 4th para: "...CONF RESPONSE state <processes> the..."

Cl.6.1 4th para: "...sends a 200 OK CONF RESPONSE...", section 4.7 
doesn't have an OK code. I propose rewording to "... send a CONF 
RESPONSE with a 200 "Success" response code...". There's also a similar 
issue in Cl.6.2 para 5.

Cl.6.2 3rd para: I wonder if we need a note here outlining the 
interaction with SDP for the encodings here before a CONF can be sent. I 
don't think we need to go into detail but it may be helpful to reference 
the relevant section in the CLUE signalling draft.

Cl6.2 State diagram: It shows CONF+ACK sent transitioning from ADV 
processing to WAIT FOR CONF RESPONSE. I wonder if this should transition 
through the CONF state? This seems more natural as there will help to be 
other inputs into the selection of configures/encodings that wouldn't 
necessarily occur in a ADV processing state.

Cl.7 There's seems to be a lot of overlap between this section and 
section 4.1. Perhaps we can rationalise the text?

Cl.8 1st para: "Although the standard version of the CLUE protocol XML 
schema <is>
    designed..."

Cl.10 This still contains XML for readv and readvresponse. These should 
be removed.

Cl.11.2: The MCC example needs to have "Allow Subset Choice" from the 
Framework. This isn't reflected in the data model yet.

Regards, Christian