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

From: Paul Kyzivat <[email-masked]>
Date: Fri, 4 Nov 2016 12:26:21 -0400

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 7 Nov 2016 22:53:28 +1100

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:
> 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.
>
> 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.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Nov 2016 12:13:13 -0500

Christian,

Thanks for the detailed comments. This doc really needs that level of 
scrutiny by a variety of people. I'll leave it to Simon to respond in 
detail. But some of your comments suggest to me that you were reviewing 
-09 rather than -10. Please double check and update your comments if needed.

	Thanks,
	Paul

On 11/7/16 6:53 AM, Christian Groves wrote:
>  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?
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 8 Nov 2016 05:02:38 +1100

Hello Paul,

Pretty sure I reviewed v10. What makes you think its v9?

Regards, Christian

On 8/11/2016 4:13 AM, Paul Kyzivat wrote:
> detail. But some of your comments suggest to me that you were 
> reviewing -09 rather than -10. Please double check and update your 
> comments if needed.
>
>     Thanks,
>     Paul
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Nov 2016 17:38:26 -0500

> Pretty sure I reviewed v10. What makes you think its v9?

Sorry, I take it back. I was working from memory at the time, and 
misinterpreted a couple of things you called out that was thinking had 
been fixed in the move from -09 to -10.

	Sorry,
	Paul