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

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

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!