Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 2 Jan 2017 17:18:54 +0100

Dear Christian,

thanks a lot for your review. Please find in-line our answers.

Cheers,

Simon & Roberta

> Here are my comments:
> 
> Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't some future thing.

Fixed.

> Cl.1 para 2: Change "upon" to "over". There's other instances in the draft also.

Fixed.

> Cl.1 para 3: The section says "Participant state machines" whereas the referred to section 6 is called "Protocol state machines”.

Fixed.

> Cl.2 Endpoint: "...and exactly one [RFC4353 <https://tools.ietf.org/html/rfc4353>] Participant (which, in turn, includes exactly one SIP User Agent)." Can we make the SIP aspect more as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. How about something like "...and exactly one participant (e.g. a [RFC4353] paricipant).”

Fixed.

> Cl.4 para 1: change "...we are not able..." -> "...it is not possible…"

Fixed.

> Cl.4 para 1: change "Such information is designed...." -> "Such information is contained…"

Fixed.

> Cl.4 para 2: "Three main communication layers" would it be better to say "phases" instead of "layers”?

Fixed.

> Cl.4 bullet 2: "The version and options negotiation can be performed once and only at this stage." clarification "... can be performed once during the CLUE session and …."

Fixed.

> Cl.4 para 3: "is is", delete one.

Fixed.

> Cl.4 para 4:"After that negotiation..." -> "After the negotiation…"

Fixed.

> Cl.4 para last: "Such messages will be..." -> "Such messages are…"

Fixed.

> Cl.5: "The basic structure determines the mandatory information that is
>   carried within each CLUE message.  Such an information is made by:" can this be simplified to say "The mandatory information contained in each CLUE message is:”?

Fixed.

> Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", etc." change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the values are normative.

Fixed.

> General: The document talks about extensions and options. Are they different? if not should we use one term.

The difference is indeed a subtle one. The idea should be that an option is a predefined capability of the protocol that is not mandatory, whereas an extension is a brand new feature one might be interested in defining for their own purpose. Technically speaking, they look exactly the same, as section 8 clearly illustrates. 

> Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a mandatory…"

Fixed.

> Cl.5.2: Is there a reason why we indicated that both the response code AND string are mandatory? It seems like an unnecessary duplication. Its not clear that text other than what has be defined may be sent.

OK. We made the "reasonString” element become optional in version-11 of the schema (minOccurs=“0”).

> Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType”.

Fixed.

> Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon reception of the OPTIONS RESPONSE the version to be used is provided in the <version> tag of the message.”?

Done.

> Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE dialogue are those”

Fixed.

> Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP sends an ADV to the MC as soon…"

Fixed.

> Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> "its CLUE telepresence media capabilities change”

Fixed.

> Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be better?

Fixed.

> Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising how each message section describes this.

We replaced “picture” with “schema excerpt”. Does this look ok?

> Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType”.

Fixed.

> Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode is of type "xs:short" in section 9 its type "type="responseCodeType”.

Fixed.

> Cl.5.6/General: Do we need some text indicating that there's no partial execution of commands. E.g. If a MP is able to understand all the selected capture encodings bar one. The whole command fails and nothing is instantiated.

We added the following sentence at the end of the section:

"We remark that there is no partial execution of commands. As an example, if a MP is able to understand all the selected capture encodings except one, then the whole command fails and nothing is instantiated."

> Cl.5.7: It says future protocol version can introduce error codes? How about options? It seems like an option could introduce a specific error code.

Based on the discussion in section 8, a new response code might indeed be added through the “extension” mechanism. Though, the “cleanest” way for achieving such a task in a formal way is by adding
the new response code to the list of codes published in the dedicated IANA registry (see section 12.4.2 fo the draft). In the mentioned section, we refer to future versions of the standard. 

> Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303.

Fixed.

> Cl.6 para 5: "Otherwise <if> ("channel error")…"

Should we add an "if" between “Otherwise” and the parenthesis? Please advise on that.

> Cl.6 para 1: "the MP is preparing" -> "the MP prepares”

Fixed.

> Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport.

Namely, we state that the CLUE (application layer) protocol relies on timeouts and retransmissions. Our interpretation is that we do need timeouts and retransmissions for application-layer errors.

> Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC stays in…"

Fixed.

> Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV processing…"

Fixed.

> Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message.

The idea here is that the MC avoids entering a loop where the MP keeps on sending an erroneous ADV hence forcing the MC to respond with a NACK. If this situation iterates for a while (# of retries), the MC terminates the ongoing CLUE “session”.

> 
> Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an
>   error response code) to the MP describing the problem via a proper
>   reason phrase." Isn't the reason code enough?

Yep. Based on your suggestion, we made the reason phrase optional.

> Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares”.

Fixed.

> Cl.6.2 para 5: "the MC is waiting" -> "the MC waits”.

Fixed.

> Cl.7 para 3:  "The version of the XML schema contained in the standard document deriving from this draft will be 1.0." -> "This document defines XML schema version 1.0”.

Fixed.

> Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields may be added”

Fixed.

> Cl.8 I think it would be very helpful to include an example syntax showing the definition of a new capture attribute that could be used by future people as a template. Its still not clear if there's any distinction between "option" and "extension”.

See our answer above regarding extensions vs options. If we all agree that they are practically the same thing, we can properly re-word things in the document.

About the example, a new capture attribute could be defined in a separate schema to further describe, e.g., a video capture.
Indeed, looking at the data model XML definition of a video capture, it is possible to see that there is an <any> element allowing for the introduction of a new XML field in the XML description of the capture, by keeping the compatibility with the CLUE data model schema:

<!-- VIDEO CAPTURE TYPE -->
   <xs:complexType name="videoCaptureType">
    <xs:complexContent>
     <xs:extension base="tns:mediaCaptureType">
      <xs:sequence>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:extension>
    </xs:complexContent>
   </xs:complexType>

That means that a video capture might have, after the set of the generic media capture attributes, a set of new attributes defined elsewhere, i.e., in an XML schema defining an extension.
Such a schema might look like the following:

<?xml version="1.0" encoding="UTF-8" ?>
<xs:schema
version="1.0"
targetNamespace="clue-info-extension-myVideoExtensions"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="clue-info-extension-myVideoExtensions"
elementFormDefault="qualified"
attributeFormDefault="unqualified">

<!-- this is the new element to be put in place of the <any>
element in the video capture definition 
of the CLUE data model schema -->

<xs:element name="myVideoExtension">
<xs:complexType>
<xs:sequence>
<xs:element ref="newVideoAttribute1"/>
<xs:element ref="newVideoAttribute2"/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name="newVideoAttribute1" type = "xs:string">
</xs:element>

<xs:element name = "newVideoAttribute2" type = "xs:boolean">
</xs:element>

</xs:schema>

The video capture could be further described in the advertisement  using the <myVideoExtension> element containing two extra information (<newVideoAttribute1> and <newVideoAttribute2>) besides using the attributes envisioned for a generic media capture. 
As stated in this document, both the CP must be aware of the extension schema and related semantics to use such an extension and negotiate it via the OPTIONS and OPTIONS RESPONSE mechanism.

> Cl.9: <xs:import namespace="urn:ietf:params:xml:ns:clue-info"
> schemaLocation="data-model-schema-12.xsd"/> Should this be "17" instead of "12" to match the version number?

Yes. Fixed.

> Does this get updated to the relevant RFC number?

This looks reasonable to me. 
> 
> Cl.10.1: "The associated Media Provider's telepresence capabilities are
>   described in [I-D.ietf-clue-data-model-schema], Section "Sample XML
>   file"." I'm a bit confused because the example in 10.1 doesn't match the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of the attribute values are different. Some of the syntax has different names. e.g. capturePoint->captureOrigin.

Fixed (the excerpt from the data model was not up to date).

> Cl.10.1/10.2: protocol="CLUE" v="0.4" should this be "1.0" given this is going for WGLC?

Fixed.

> Cl.12. Do we need to establish IANA registry for clue options/extensions to manage the option names?

Again, options/extensions probably deserve a further (final) thought. We would like to hear feedback from the group.

> Regards, Christian

Thanks 1k for your precious review!

---

From: Christian Groves <[email-masked]>
Date: Fri, 6 Jan 2017 23:58:06 +1100

Hello Simon,

Sorry about the slow response. I've been travelling. Please see my 
responses below.

Regards, Christian

..snip
> The difference is indeed a subtle one. The idea should be that an option is a predefined capability of the protocol that is not mandatory, whereas an extension is a brand new feature one might be i…
[CNG]I think we need to separate whether something is an optional 
capability or not from extending the protocol/data model. Extensions I 
see are additions to the protocol.

..snip
> OK. We made the "reasonString” element become optional in version-11 of the schema (minOccurs=“0”).
[CNG] OK

..snip
> We replaced “picture” with “schema excerpt”. Does this look ok?
[CNG] OK

..snip
> "We remark that there is no partial execution of commands. As an example, if a MP is able to understand all the selected capture encodings except one, then the whole command fails and nothing is in…
[CNG] That's OK except that i'd remove "We remark that..." and just keep 
it at "There is no....".
> the new response code to the list of codes published in the dedicated IANA registry (see section 12.4.2 fo the draft). In the mentioned section, we refer to future versions of the standard.
[CNG] By saying that error codes can be designed in future versions 
seems to preclude them being defined by extensions. (BTW 5.7 uses 
"designed", I think "defined" would be better).

I agree one could simply update the IANA registry with the new code but 
I was thinking more of how an end point would know that it would be 
used. That's where registering an extension would make sense. Of course 
if you made a new version you wouldn't need an extension.

..snip
> Should we add an "if" between “Otherwise” and the parenthesis? Please advise on that.
[CNG] If doesn't need to be in parentheses just "Otherwise if ..."

..snip
> Namely, we state that the CLUE (application layer) protocol relies on timeouts and retransmissions. Our interpretation is that we do need timeouts and retransmissions for application-layer errors.
[CNG] OK.
> The idea here is that the MC avoids entering a loop where the MP keeps on sending an erroneous ADV hence forcing the MC to respond with a NACK. If this situation iterates for a while (# of retries)…
[CNG] OK that makes sense.

..snip
> As stated in this document, both the CP must be aware of the extension schema and related semantics to use such an extension and negotiate it via the OPTIONS and OPTIONS RESPONSE mechanism.
[CNG] I think its valuable to have such an example on extending the 
clue-info and clue-protocol schemas.

..snip
> Thanks 1k for your precious review!
[CNG] No problem.

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 23 Jan 2017 10:00:46 +0100

Dear Christian,

please find in-line our answers to your comments.

> [CNG]I think we need to separate whether something is an optional capability or not from extending the protocol/data model. Extensions I see are additions to the protocol.

OK. We made this distinction clear, by redefining the <option> element and its related <optionsType> definition. Such pieces of information are now called, respectively, <extension> and <extensionType>. The document now makes a coherent use of the terms. 

> [CNG] That's OK except that i'd remove "We remark that..." and just keep it at "There is no....”.

OK. Done.

> [CNG] By saying that error codes can be designed in future versions seems to preclude them being defined by extensions. (BTW 5.7 uses "designed", I think "defined" would be better).

We rephrased the sentence as follows:

"Further response codes can be either defined in future versions of the 
protocol (by adding them to the related IANA registry), or defined 
by leveraging the extension mechanism. In any case, such new response
codes MUST NOT overwrite the ones here defined and they MUST 
respect the semantics of the first code digit.”

Does this sound OK to you?

> I agree one could simply update the IANA registry with the new code but I was thinking more of how an end point would know that it would be used. That's where registering an extension would make sense. Of course if you made a new version you wouldn't need an extension.

OK. See above.

> [CNG] If doesn't need to be in parentheses just "Otherwise if …"

You’re the English master! We modified accordingly: 

"Otherwise if ("channel error"), it moves back to the IDLE state.”

>> xmlns:xs="http://www.w3.org/2001/XMLSchema <http://www.w3.org/2001/XMLSchema>"
> [CNG] I think its valuable to have such an example on extending the clue-info and clue-protocol schemas.

OK. Example added.

Cheers,

Simon & Roberta
                     				            _\\|//_
                           				   ( O-O )
      ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked] <mailto:[email-masked]>

		    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
       ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

> On 06 Jan 2017, at 13:58, Christian Groves <[email-masked]> wrote:
> 
> Hello Simon,
> 
> Sorry about the slow response. I've been travelling. Please see my responses below.
> 
> Regards, Christian
> 
> 
> ..snip
> [CNG]I think we need to separate whether something is an optional capability or not from extending the protocol/data model. Extensions I see are additions to the protocol.
> 
> ..snip
>> 
> [CNG] That's OK except that i'd remove "We remark that..." and just keep it at "There is no....".
>> 
> [CNG] By saying that error codes can be designed in future versions seems to preclude them being defined by extensions. (BTW 5.7 uses "designed", I think "defined" would be better).
> 
> I agree one could simply update the IANA registry with the new code but I was thinking more of how an end point would know that it would be used. That's where registering an extension would make sense. Of course if you made a new version you wouldn't need an extension.
> 
> ..snip
> [CNG] I think its valuable to have such an example on extending the clue-info and clue-protocol schemas.
> 
> ..snip

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jan 2017 12:04:38 -0500

> Does this sound OK to you?

I don't see how having two different mechanisms for defining new 
response codes can work.

If a new response code is defined in an extension, and thus doesn't 
update the registry, then what is to prevent that code from being reused 
in a conflicting way? Considering that (IIUC) extensions don't need to 
be registered with the IETF it seems entirely possible that somebody 
defining a new one might not be aware of another that used the same new 
response code.

So, ISTM that new response codes will always need to be registered with 
IANA, and we will thus need a suitable approval mechanism for that.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 24 Jan 2017 16:08:45 +1100

Hello Simon and Roberta,

Thanks for addressing the comments. Please see below.

Regards, Christian

..snip
>
>>> Cl.5.7: It says future protocol version can introduce error codes? 
>>> How about options? It seems like an option could introduce a 
>>> specific error code.
>>> Based on the discussion in section 8, a new response code might 
>>> indeed be added through the “extension” mechanism. Though, the 
>>> “cleanest” way for achieving such a task in a formal way is by adding
>>> the new response code to the list of codes published in the 
>>> dedicated IANA registry (see section 12.4.2 fo the draft). In the 
>>> mentioned section, we refer to future versions of the standard.
> protocol  or defined
[CNG] I agree with Paul in that any new response code will need to be 
registered by IANA. However I don't see the problem with having two 
mechanisms to define codes within the protocol. It should be possible to 
add an error code to CLUE without having to bump the version. I think if 
you delete "(by adding them to the related IANA registry)," and add a 
sentence along the lines of:
"In both cases the new response code MUST be registered with IANA".

>
>> I agree one could simply update the IANA registry with the new code 
>> but I was thinking more of how an end point would know that it would 
>> be used. That's where registering an extension would make sense. Of 
>> course if you made a new version you wouldn't need an extension.
>
> OK. See above.
>
>> ..snip
[CNG] You can delete the ( and ), i.e. just "Otherwise if "channel 
error", it... "

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2017 11:10:55 -0500

> "In both cases the new response code MUST be registered with IANA".

In principle that would work. But that leaves the issue of what policy 
to use for the registry. A new version of the protocol will be standards 
track, which is sufficient to control the registry. But IIUC anybody can 
define an extension. I doubt we would want to make the registry FCFS 
because the codes are a limited resource.

For simplicity in the interest of getting this done I would be satisfied 
with requiring a new version to define a new response code.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 25 Jan 2017 09:20:46 +1100

The current section 12.4.2 in the protocol indicates that to register a 
response code "specification is required". I can't see why this cannot 
apply to extensions? Having to up the version seems to be a very high 
bar for a response code. The document already has the registration 
information so I don't see how it delays things?

Christian

On 25/01/2017 3:10 AM, Paul Kyzivat wrote:
> to use for the registry. A new version of the protocol will be 
> standards track, which is sufficient to control the registry. But IIUC 
> anybody can define an extension. I doubt we would want to make the 
> registry FCFS because the codes are a limited resource.
>
> For simplicity in the interest of getting this done I would be 
> satisfied with requiring a new version to define a new response code.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Jan 2017 20:56:15 -0500

> information so I don't see how it delays things?

OK, yes - if you still need s specification for the response code that 
is good enough for me.

	Thanks,
	Paul