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

[Simon Pietro Romano <[e-mail]>]

Dear Christian,

please find in-line our answers to your comments.

> ..snip
>>> 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.
> [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. 

>> 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."
> [CNG] That's OK except that i'd remove "We remark that..." and just keep it at "There is no....”.

OK. Done.

>> 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.
> [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.

> ..snip
>> Cl.6 para 5: "Otherwise <if> ("channel error")…"
>> 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 …"

You’re the English master! We modified accordingly: 

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

>> 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 <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.
> [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: [phone] -- Fax: [phone]
                                           e-mail: [e-mail] <mailto:[e-mail]>

		    <<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 <[e-mail]> wrote:
> 
> Hello Simon,
> 
> Sorry about the slow response. I've been travelling. Please see my responses below.
> 
> Regards, Christian
> 
> 
> ..snip
>>> 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.
> [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
>> 
>>> 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”).
> [CNG] OK
> 
> ..snip
>> 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?
> [CNG] OK
> 
> ..snip
>> 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."
> [CNG] That's OK except that i'd remove "We remark that..." and just keep it at "There is no....".
>> 
>>> 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.
> [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
>> Cl.6 para 5: "Otherwise <if> ("channel error")…"
>> 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
>> 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.
> [CNG] OK.
>> 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”.
> [CNG] OK that makes sense.
> 
> ..snip
>> 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.
> [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.
>> 
>> 
> 
>