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

On 11/7/16 1:02 PM, Christian Groves wrote:
> Hello Paul,
>
> 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

> Regards, Christian
>
>
> On 8/11/2016 4:13 AM, Paul Kyzivat wrote:
>> 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:
>>> 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
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>>
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>