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

Hello Paul,

Here are my comments:

Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't 
some future thing.

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

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

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)."

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

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

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

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

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

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

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

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:"?

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.

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

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

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.

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

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."?

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

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

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

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

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

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

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

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.

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.

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

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

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

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.

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

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

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.

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?

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

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

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

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

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

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? Does this get updated to 
the relevant RFC number?

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.

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

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

Regards, Christian

On 5/11/2016 3:26 AM, Paul Kyzivat wrote:
> This message announces the start of a WGLC for 
> draft-ietf-clue-protocol-10.
>
> The last time we had a WGLC on this document was -04. Since then there 
> have been substantial changes:
>
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-10.txt;url1=draft-ietf-clue-protocol-04.txt 
>
>
> I have the sense that I have been the only one reviewing and 
> commenting on this document along the way. It is important that we 
> have thorough review by others in the wg. So please give careful 
> attention to this document and comment back. Note that this is the 
> last piece of CLUE. Once this one is done we can declare victory and 
> close down the wg.
>
> Unfortunately this review is starting at a busy time: the Seoul IETF 
> meeting is coming in a week, and so some people will be busy with 
> that. And the week after that is Thanksgiving in the US, so some 
> people won't be off some of that week. As a result, I'm giving a 
> longer duration for this review, so that everyone will have an 
> opportunity to fit the work into their schedule somewhere.
>
> Starting Date: Friday, November 4, 2016
> Ending Date:   Wednesday, Novemeber 30, 2016
>
> Please do this so we can wrap things up.
>
>     Thanks,
>     Paul
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>