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

From: Roberta Presta <[email-masked]>
Date: Wed, 22 Apr 2015 19:00:30 +0200

Dear Christian,
we have updated the protocol draft according to your comments.
Thank you for the review.
Please find below some answers.
Regards,

Roberta

Il 19/03/2015 04:49, Christian Groves ha scritto:
> Cl.4 clueID: Should we recommend a particular format for this e.g. URI 
> or similar instead of just a simple string?
>
We have left the definition of the clueID as is.
The alternative is to change the XS definition by specifying the 
xs:anyUri type and by adding in the document both the textual 
specification and the IANA consideration for the CLUE-URI definition, as 
follows:

  * XS definition: <xs:element name="clueId" type="xs:anyUri"/>
  * XML example: <clueId>clue:[email-masked]</clueId>
  * Textual specification of the CLUE-URI for the CP:Â
      o The <clueId> element contains the CLUE-URI of the CP. The
        CLUE-URI of the CP identifies the CP in the CLUE-enabled
        telepresence session at the CLUE application level.
      o The syntax is defined by the following ABNF [RFC5234] rules.
          + CLUE-URI = "clue" ":" [cp-id-string "@"] host
          + cp-id-string = 1*( unreserved / "+" / "=" / "/" )
      o Note: host and unreserved are defined in RFC 3986 [RFC3986].
      o A CLUE-URI is not designed to be resolved, and an application
        MUST NOT attempt to perform a standard DNS lookup on the host
        portion of such a URI in an attempt to discover an IP address or
        port at whichÂ  to connect.
  * IANA consideration:
      o URI scheme name: clue
      o ...

Should the framework include such a definition?

> 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?
There are three distinct CLUE dialogues (i.e., the one of the initiation 
phase, the one performed as a MP, and the one performed as a MC) with 
associated mechanisms involving sequence numbers, so they should be 
separate.

>
> 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:"?
We have made some changes in the section about response codes.
We have associated a meaning to response codes on the basis of the first 
digit of the code. The response codes defined are mandatory, but other 
response codes can be used, provided that they respect the XS 
definition, the semantic associated to the first digit, and do not 
overwrite existing codes.

> 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".
>
The "session ends" event  refers to the SDP negotiation for removing the 
CLUE channel.
We have added such specification in the draft.

> 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?
>
Yes, it is.

> 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.
>
We have added claryfing text in the introduction section when the 
initiation phase is introduced.

> 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? 
Yes, it is. Replaced with "If the CONF does not arrive within the 
timeout interval and the retry threshold has not been overcome".

> 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.
We added a reference to the signaling draft for the interaction between 
CLUE and SDP in the introductory part of the state machines section.
>
> 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.
>
We prefer to keep the transitions separate.
In order to clarify the description, we changed the text of the ADV 
PROCESSING state as follows:
"In the ADV PROCESSING state, the ADV is parsed by the MC. If the ADV is 
successfully processed, there are two possibilities. According to the 
first one, the MC issues a successful ACK message to the MP ("ACK sent") 
and moves to the CONF state. In the second one, the MC prepares and 
sends a CONF message with the <ack> field set to "true" ("CONF+ACK 
sent") and goes directly to the WAIT FOR CONF RESPONSE state. "

>
> Cl.11.2: The MCC example needs to have "Allow Subset Choice" from the 
> Framework. This isn't reflected in the data model yet.
We updated the MCC ADV example by adding the <allowSubsetChoice> element 
that has been added also into the data model schema (version 9, to appear).

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Apr 2015 11:42:53 +1000

Hello Roberta,

Thanks for the answers. Please see my responses below.

Regards, Christian

On 23/04/2015 3:00 AM, Roberta Presta wrote:
>> Cl.4 clueID: Should we recommend a particular format for this e.g. 
>> URI or similar instead of just a simple string?
>>
> specification and the IANA consideration for the CLUE-URI definition, 
> as follows:
>
>         portion of such a URI in an attempt to discover an IP address
>         or port at whichÂ  to connect.
>   * IANA consideration:
>       o URI scheme name: clue
>       o ...
>
[CNG] I'm not sure. clueID isn't covered by the framework. The protocol 
document defines it as:
"clueId: an XML element containing the identifier of the CP within the 
telepresence system;" It doesn't say what it is actually used for. There 
no uniqueness requirement. So its hard to say whether we need a formal 
specification or not?

>
>> 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?
> There are three distinct CLUE dialogues (i.e., the one of the 
> initiation phase, the one performed as a MP, and the one performed as 
> a MC) with associated mechanisms involving sequence numbers, so they 
> should be separate.
[CNG] I think I'm having trouble with the word "streams" maybe it would 
be better to say "... manage up to three sets of sequence...".

> We have associated a meaning to response codes on the basis of the 
> first digit of the code. The response codes defined are mandatory, but 
> other response codes can be used, provided that they respect the XS 
[CNG] OK

> The "session ends" event  refers to the SDP negotiation for removing 
> the CLUE channel.
[CNG] OK
>> 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?
>>
> Yes, it is.
[CNG] I see that error code 400 is now defined for this.

> initiation phase is introduced.
[CNG] OK
>
>> 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? 
[CNG] OK
>> 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.
> We added a reference to the signaling draft for the interaction 
> between CLUE and SDP in the introductory part of the state machines 
> section.
[CNG] OK
> "In the ADV PROCESSING state, the ADV is parsed by the MC. If the ADV 
> is successfully processed, there are two possibilities. According to 
> the first one, the MC issues a successful ACK message to the MP ("ACK 
> sent") and moves to the CONF state. In the second one, the MC prepares 
> and sends a CONF message with the <ack> field set to "true" ("CONF+ACK 
[CNG] OK
> We updated the MCC ADV example by adding the <allowSubsetChoice> 
> element that has been added also into the data model schema (version 
> 9, to appear).
[CNG] OK
> DELL'UNIVERSITA' DI NAPOLI