From nobody Fri Oct 6 11:34:12 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B4E7C134C1D; Fri, 6 Oct 2017 11:34:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: clue@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150731485068.13352.18267161124573289065@ietfa.amsl.com> Date: Fri, 06 Oct 2017 11:34:10 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-protocol-14.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:34:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-14.txt Pages : 62 Date : 2017-10-06 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-14 https://datatracker.ietf.org/doc/html/draft-ietf-clue-protocol-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-14 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Oct 6 11:35:26 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20C42134C01 for ; Fri, 6 Oct 2017 11:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_2pz8xMNTfK for ; Fri, 6 Oct 2017 11:35:15 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ACE5134C02 for ; Fri, 6 Oct 2017 11:34:54 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by leas1.unina.it with ESMTP id v96IYqUl007430-v96IYqUn007430 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Oct 2017 20:34:52 +0200 Received: from [192.168.1.65] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v96IYokf005300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Oct 2017 20:34:50 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_817B078B-E4A9-4125-BBBD-73C63CA87E30" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano In-Reply-To: Date: Fri, 6 Oct 2017 20:37:08 +0200 Cc: clue@ietf.org, Roberta Presta , Simon Pietro Romano Message-Id: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> References: To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 18:35:24 -0000 --Apple-Mail=_817B078B-E4A9-4125-BBBD-73C63CA87E30 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Adam, let me first of all apologize for the incredibly long time it took to = produce this revised version of the draft. Your review actually deserved = a lot of attention. We have submitted a new version of the document. Though, you will notice = that at least a couple of important (i.e., BLOCKING) questions are still = in place. We would like to get your further input on those points before = proceeding with an updated revision. Please find in-line our answers to = your comments, preceded by [SPR]. > Most of my comments below are feedback that the document authors = should treat as normal last call comments. The feedback that I consider = to block progressing the document, in my role as AD, is explicitly = marked with the prefix "BLOCKER", and these will need to be resolved in = a new version of the document before progressing it further. Note that = it is entirely possible that something I have marked "BLOCKER" may stem = from an error on my part; so recognize that these are not demands for = change, as much as a need to have things either fixed in the document or = explained to me. >=20 [SPR] Gotcha. > Title: The rule of thumb is that all but a small handful of well-known = acronyms need to be expanded in titles and abstracts. I recognize that = "CLUE" is a bit tortured, as acronyms go, but the title of this document = is, broadly speaking, opaque. Please change it to something meaningful, = such as "Protocol for Controlling Multiple Streams for Telepresence = (CLUE)=E2=80=9D >=20 [SPR] Done. > General: There are three instances of excessively long lines in the = document. >=20 [SPR] ??? > General: Please number and caption the figures in this document. Also, = please refer to the figure numbers when pointing to them (e.g., the = first paragraph of section 6.1 should read something like: "As soon as = the sub-state machine of the MP (Figure 1) is activated...=E2=80=9D." >=20 [SPR] Done. > BLOCKER: General: There are several mentions of timeouts and retry = thresholds in the text and its corresponding state machines; however, = the document neither defines nor cites a document as defining what these = timeout and retry values are. These need to be defined and described. If = the timer and retry scheme allows the two ends of the connection to have = different values for timeouts and number of retries, then there need to = be additional error procedures that allow the MC and MP state machines = to stay in sync (if the timer/retry values can be different, it's = possible for one state machine to transition to "terminated," while the = other is still active, and you need messaging to clean this up). >=20 [SPR] Our idea was to rely on a single, fixed, application-level (i.e., = CLUE-level) timeout value, rather than leveraging a number of them (T1, = T2, T4, plus Timer A through Timer K) as in SIP. The value of the one = and only timer would be the usual RTT estimate (~500ms). Differently = from protocols like SIP, we are also leveraging retransmit counts to get = out of a timeout-driven retransmission loop. We=E2=80=99re not adding = such information to the revised version of the draft, because we=E2=80=99d= first like to get your feedback on the approach. If you (and the rest = of the group) believe this is a feasible approach, we can expand on that = in a further version of the document. > The remainder of this comment is non-blocking: Related to this, the = document frequently refers to retries as "expiring" (e.g., "retry = expired" on the state diagrams). That doesn't really make sense unless = "retry" is the name of a timer rather than a counter; I think you mean = to say "exhausted" or something similar. >=20 [SPR] Done. =E2=80=9CExpired" had been replaced with =E2=80=9Cexhausted=E2= =80=9D. > General: This document defines six message types, all of which have at = least two names, many of which have more. It would be a lot easier to = keep track of what is being described if these were kept consistent. I = suggest choosing one term for each concept and sticking with it. In = other words, please pick only one name from each of the following lines, = and do not use any of the others: >=20 [SPR] We decided to stick with the names contained in the schema. See = below for the details. > OPTIONS, options [SPR] options > OPTIONS RESPONSE, optionsResponse [SPR] optionsResponse > ADVERTISEMENT, ADV, advertisement [SPR] advertisement > ADVERTISEMENT ACKNOWLEDGEMENT, ADV ACK, ACK, NACK, ack [SPR] ack.=20 We left the NACK definition (ack carrying back an error code), since it = makes sense from the semantics perspective, in our opinion. > CONFIGURE, CONF, CONF+ACK, configure [SPR] configure. Also here, we have left the =E2=80=9Cconcept=E2=80=9D = of the configure+ack, i.e. an ack piggy-backed onto a configure message. > CONFIGURE RESPONSE, CONF RESPONSE, configureResponse [SPR] configureResponse > The terminology section appears to be in alphabetical order, except = for "Capture Encoding" (which was presumably "Media Capture Encoding" in = some earlier version). Please fix. >=20 [SPR] Done. > The definitions for "Endpoint", "MCU", and "Media Stream/Stream" vary = from the definition given in draft-ietf-clue-framework. Is this = intentional? >=20 [SPR] Not really. They have now been aligned with version -25 of the = framework. > The first paragraph of section 4 mentions the framework and data model = documents without citations. There should probably be citations to the = corresponding documents. >=20 [SPR] Done. > Section 4 contains the following text: >=20 > The CLUE protocol represents the mechanism > for the exchange of CLUE information between CLUE Participants > This is sufficiently circular as to be basically meaningless. Suggest: = "...for the exchange of telepresence information between..." >=20 [SPR] Done. > Section 5: The versioning scheme in here is rather perplexing. Is = there some technical reason the protocol restricts major version numbers = to a single digit and minor versions to a single digit? Strongly suggest = that this should be expanded to allow multiple digits for both the major = and minor versions. >=20 [SPR] Done. The new pattern is now "[1-9][0-9]*\.[0-9]+" > Section 5: It should be made clear that the XML Schema excerpts in = section 5 are non-normative. In particular, I recommend adding the = following text to the end of the first paragraph of section 5: "This = section includes non-normative excerpts of the schema to aid in = describing it.=E2=80=9D >=20 [SPR] Done. > Section 5: If the single-digit version numbers are maintained (and, = again, I strongly recommend against this), the definition of versionType = appears to be wrong: it allows a major version digit of "0", which would = seem to be precluded by the way versions are currently defined. >=20 [SPR] This should now be all good, with the pattern = "[1-9][0-9]*\.[0-9]+" > Section 5: The XML definition allows zero or more elements to = appear in a message. If more than one is allowed, the document should = explain how multiple IDs are handled. If they are not, then the schema = and/or text needs to prohibit having more than one. >=20 [SPR] Actually, the schema states: This should indicate that clueId can appear either 0 or 1 times in a = valid XML document. The default value for maxOccurs is in fact 1. = Don=E2=80=99t you agree on that? > Section 5: The description for says that a 402 will be = sent in the case of an "unexpected" sequence number. This needs = clarification: is this for case where a sequence number gap is detected? = A repeated sequence number? A number that is too small? All of the = above? >=20 [SPR] All of the above. > At least describe this with the 402 error code, and point to that = description from here. >=20 [SPR] Done. > Section 5: The description for would benefit from the addition of = "This document describes version 1.0". >=20 [SPR] Done. > Section 5.1: "The OPTIONS message is sent by the CP which is the CI to = the CP which is the CR as soon as the CLUE data channel is ready." = Although it's a problem in other parts of the document too, the dense = use of nearly identical two-letter acronyms in here makes it quite hard = to read. I had to keep consulting the definitions of those acronyms to = decode this sentence (as well as several similar ones). Consider just = expanding these terms (as well as "MP" and "MC") instead of using them = in prose. >=20 [SPR] Done (here). Acronyms are always a nasty beast; though, they prove = useful when you have to write tens of times the same long-enough terms. > Section 5.1 starts to wobble back and forth between referring to = elements with and without angle brackets (e.g., it uses both = "supportedVersions" and ""). Please pick one and = stick with it. >=20 [SPR] Done. > BLOCKER: Section 5.1: The description of describes = a scheme in which multiple supported versions can be listed; and, if the = list is omitted, it implies that only the version described in is = supported. This text does not define (nor does any other text that I can = find) what should be set to when is used. = Intuitively, it seems that should be set to the largest minor = version of the smallest major version advertised in , = but that (or whatever the correct answer is) needs to be clearly spelled = out. >=20 [SPR] I believe we were giving for granted that =E2=80=9Cv=E2=80=9D = should be, in such case, the highest supported version (i.e., largest = major and larger minor numbers). Now that you make me think around that, = I would simply say that the =E2=80=9Cv=E2=80=9D attribute MUST be set to = one of the versions that the entity in question supports, as per the = list. I can, e.g., decide that I send an = =E2=80=98options=E2=80=99 with =E2=80=9Cv=3D12.23=E2=80=9D if the = list is like in the following: 33.44 27.0 12.345 1.44 > BLOCKER: Section 5.2: "If the responseCode is of the type 2xx the = response MUST also include..." -- you can't use "2xx" in a normative = statement without first defining what it means. As you don't use the = "#xx" format anywhere else, I suggest rephrasing: "If the = is between 200 and 299 inclusive, the response MUST also include...=E2=80=9D= >=20 [SPR] Done. > Sections 5.2, 5.4, 5.6: It seems really odd that the document defines = a base clueMessageType that all messages derive from, but then leaves = all the response types (optionsResponse, ack, configureResponse) = to repeatedly and independently add ,, and = the sequence number of the corresponding message over and over again. I = would strongly suggest adding something like: >=20 > > > > > > > > > > > > > [SPR] Done (without =E2=80=9CrequestSequenceNr=E2=80=9D, which is not = present inside the optionsResponse message). >=20 > ...and then defining those three response types as being extensions of = "clueResponse" instead of "clueMessage", like this: > > > > > > > > [SPR] Done. > Regardless of how you do this, any section that adds > "responseCode" and "reasonString" needs to point to section 5.7 = in > its description to explain how those fields are populated and > interpreted. [SPR] Done. > Section 5.5: This section allows a boolean flag in a = message to acknowledge an . Is this intended to always be = handled like a 200? Consider: if you define a 201 response code in the = future, will implementations be unable to convey its meaning in a CONF + = ACK? Given that the document defines a class of codes for success rather = than a simple success flag in general, it seems that this element = should carry a success response code rather than just a boolean. If you = decide to keep the boolean, be very clear that it is to be treated as a = 200 rather than any other potential success code; and that conveying any = other kind of success requires a separate message. >=20 [SPR] We modified the element as follows: With: > Section 5.5: the final paragraph mentions the = element -- it would be helpful to add something like "see = [I-D.ietf-clue-datamodel] for the definition of .=E2=80=9D= >=20 [SPR] Done. > BLOCKER: Section 5.7 indicates that there is a class of response = codes, starting with "1", which are used to indicate "delayed or = incomplete" responses. The document does not describe any protocol = behavior for this class of response. The description of the meaning of = this class (and the obvious parallels to HTTP and SIP) imply that some = subsequent response associated with the same request will be arriving at = some point in the future. If that's the intention, this document needs a = *lot* more text (and corresponding adjustments to the state machines) to = explain how these 100-class codes are handled. In practice, since the = current version of the document does not define nor make use of = 100-class codes, I suggest that the most reasonable path forward is to = remove discussion of codes starting with "1" from the first paragraph of = section 5.7, instead adding a paragraph immediately following it that = says something like:=20 > This document does not define response codes starting with "1", and = such > response codes are not allowed to appear in major version 1 of the = CLUE > protocol. The range from 100 to 199 inclusive is reserved for future = major > versions of the protocol to define response codes for delayed or = incomplete > operations if necessary. Response codes starting with "5" through = "9" are > reserved for future major versions of the protocol to define new = classes of > response, and are not allowed in major version 1 of the CLUE = protocol. > Response codes starting with "0" are not allowed. >=20 [SPR] Done. > Section 5.7: "The response codes and strings defined for use with CLUE = are as follows" - this strongly implies that the descriptions given in = this table are the only ones that are allowed in CLUE = element, and that any other messages should presumably be treated as an = error. Surely that's not what you mean. Suggest rephrasing to indicate = that the "Description" text can be sent in the , but that = implementations can (and are encouraged to) include more specific = descriptions of the error condition, if possible. >=20 [SPR] Done. > Section 5.7: I can't figure out how an implementation could ever send = a "300" response code. If the XML syntax is incorrect, that's a 301. If = the message contains an invalid value, that's a 302. And those are the = only two conditions that are described for 300. I think you need to give = "300" a bit more thought -- if you can't come up with a more generic = description (e.g., "low-level request error"), you probably want to = remove it. >=20 [SPR] We opted for your suggested =E2=80=9Clow-level request error". > Section 5.7: for 403, be clear which identifier is meant. Do you mean = "The used in the message is not valid..."? >=20 [SPR] Yep. added. > Section 5.7: for 404, please be clear that you're talking about the = sequence number rather than just using "number" without qualification. >=20 [SPR] OK. > Section 5.7: The description for 405 uses the acronym "MCC" without = expanding it. Please expand it. >=20 [SPR] Done. > BLOCKING: The state machines in section 6 and its subsections don't = have transitions for all possible messages that could arrive in a state. = This can cause interop issues. Please add text that clearly indicates = whether such messages do or do not cause a transition. (This might be as = simple as "messages not shown for a state do not cause the state to = change," but only if you carefully check that this is true -- for = example, what should an MP state machine do do if it gets a "CONF + ACK" = in the state "WAIT FOR CONF"?) >=20 [SPR] In the specific case you mention, I would expect that a 302 is = generated (Invalid Parameter), since the incoming CONF should not = contain the element. This said, I see your point related to the = potential lack of some edges in the state machine graph. This point is = obviously also related to the =E2=80=9Ctimeout=E2=80=9D issue you raised = before. Different ways of managing timeouts will definitely have = different impacts on the current state machines. We will defer the modification of the diagrams in question to the next = revision round. In the meanwhile, we=E2=80=99ll give a thought to = potential further unexpected transactions to be taken into account. > Section 6: The fifth paragraph says "CLUE channel" where it means = "CLUE data channel.=E2=80=9D >=20 [SPR] Done. > Section 6: The eighth paragraph says: >=20 > The CP moves from the ACTIVE state to the IDLE one when the = sub-state > machines that have been activated are (both) in the relative > TERMINATED state (see sections Section 6.1 and Section 6.2). > The "both" in this paragraph is confusing, since it's possible to have = only one or the other machine running. Please rephrase. >=20 [SPR] Done. > Section 6.2 describes a state machine that starts in a state called = "WAIT FOR ADV." This state does not appear to be timer-supervised, = meaning that implementations of this state machine can stay in this = state literally forever. Is that the intention? >=20 [SPR] The idea would be to open a socket and start listening for = incoming advertisements. Isn=E2=80=99t that OK? > Section 6.2 also describes the possibility of sending a and = separately or as a combined message. I would have expected = to see some discussion here about why implementations might choose one = behavior over the other. >=20 [SPR] The idea is that if the configure does not take too much time to = get prepared, you can send it in conjunction with the ack. Otherwise = (i.e., if you need some more time to build your configure message) you = start by acking the advertisement and send the configure when it is = ready to go. We rephrased the text in the draft accordingly. > Section 7: The second sentence of the second paragraph needs a verb. >=20 [SPR] Done. > Section 7, paragraph 3: this claims that versions are a non-negative = *integer* rather than a *digit*. As I mention above, this seems to be = the right way to handle versions, but it is decidedly at odds with text = elsewhere in the document and in the schema. Regardless of how you = choose to treat versions, the text needs to be consistent. >=20 [SPR] This should now be all set (see above answers about version = definition). > Section 7, final paragraph: replace "Clue" with "CLUE.=E2=80=9D >=20 [SPR] Done. > Section 8 contains a paragraph starting with "In that case, the new = informationn..." but it's not clear which case it's referring to. Please = replace "In that case" with a description of the case under = consideration. >=20 [SPR] We removed =E2=80=9CIn that case=E2=80=A6=E2=80=9D, since the = thing was quite clear. > Section 8 contains the phrase "Similarly to what said before..." -- = this is ungrammatical and needs to be rephrased. >=20 [SPR] Wrong terms removed. > Section 8 indicates that extensions need to indicate "the standard = version of the protocol the extension refers to." Given that there is = compatibility within a major version of a protocol, I think this means = to say "the major standard version of the protocol that the extension = refers to.=E2=80=9D >=20 [SPR] My extension might be associated with version 3.6 of the protocol. = This means that it will need to be supported by all versions higher than = that (3.7 onwards). Though, this does not entail that versions 3.5 and = lower should understand it. Right? > Section 8 has a paragraph starting "For that reason..." -- it's not = clear what reason is being referred to here. Please clarify. >=20 [SPR] Removed. > Section 8 contains schema that contains a element. It should = be clarified that this is the *protocol* version, not the *extension* = version (or, if it's the extension version, that needs to be spelled out = too, but I think you'll need a new namespace for that...?) >=20 [SPR] I thought this was clear from the third bullet point in the list: - the standard version of the protocol the extension refers to. Isn=E2=80=99t this enough? In such a case, what would you suggest to = add? > BLOCKING: Section 8.1 is an example section, which are non-normative = in IETF documents. It contains 2119-style normative language, however. = These normative statements need to be moved out of the example section = (and probably into section 8). >=20 [SPR] Done. > The remainder of this comment is non-blocking: I also find the = "SHOULD" in this section to be highly perplexing. Can you explain the = rationale behind requiring schema, but not requiring any description of = what the schema *means?) >=20 [SPR] It is like coding without adding comments/documentation. = Documentation is most welcome, but not mandatory. Don=E2=80=99t you = agree? > BLOCKING: The example in section 8.1 includes the following: >=20 > xmlns=3D"clue-info-extension-myVideoExtensions" > I'm pretty certain that namespaces are required to be identified by = URIs rather than arbitrary strings. >=20 [SPR] Right! Namespace updated. > Section 8.1: The final paragraph also has normative language in it, = although it appears to be reiterating requirements from elsewhere in the = document. I suggest lowercasing "MUST" in this paragraph. >=20 [SPR] Done. > Section 8.1: The final paragraph mentions the use of and = to negotiate the extension. An example demonstrating = this negotiation would be extremely useful. >=20 > The schema in section 9 contains: >=20 > schemaLocation=3D"data-model-schema-17.xsd"/> > If you do not intend to bake this "-17" into the document (and I can't = imagine you do), please add an RFC editor note to change it to something = else upon publication. >=20 [SPR] Done. I am not very familiar with RFC editor notes, indeed. Here = is what we added at the beginning of section 9: "NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd" with = the right schema location for the CLUE data model schema document (which = is still to be defined at the time of this writing) in this section = prior to publication as an RFC.=E2=80=9D Does this work for you? > Also, the schema in section 9 is (with rare exception) unindented. = This makes it *very* hard to read. Please consider formatting it with = conventional XML indentation. (This also applies to the schema excerpts = earlier in the document.) >=20 [SPR] Done. > Has there been any automated tool-based checking that the examples in = section 10 to verify that they conform to the schema in section 9 (and = the schemata it imports)? >=20 [SPR] Yep. We did not test the modifications we have just applied with = this review of the draft. Will check asap. > Section 10.2: Please expand the acronym "MCCs" in the section title = (keep in mind that this appears in the table of contents, where it needs = to makes sense). >=20 [SPR] Done. > Section 10 in general: While it does consume a lot of space, I don't = think that defining six rather different message types and then showing = only *one* type in the examples is very illustrative of the = protocol. I would *STRONGLY* suggest adding at least a response message, = and ideally the example section should contain at least one example for = each of the six message types. >=20 [SPR] Will do in the (hopefully final) revision of the document. Let=E2=80= =99s first double check that the proposed modifications are OK. > Section 11, paragraph 4: Replace "Clue" with "CLUE.=E2=80=9D >=20 [SPR] Done. > Section 12.1 has a strange double-double quote around the URN name, = and section 12.3 repeats this for the MIME type. >=20 [SPR] I don=E2=80=99t understand this. Can you please clarify? > All subsections of section 12: please update all registrant contact = information to point to the IESG (iesg@ietf.org ) = rather than the CLUE working group and one of the authors. >=20 [SPR] Done. > Section 12.4.1: These descriptions will appear in an IANA registry, = where the phrase "in this document" will have no context and be rather = nonsensical. Please rephrase. >=20 [SPR] Done. > Sections 13 through 23 should include an RFC editor note asking for = removal before publication. >=20 [SPR] Those sections have been just removed. > /a Thanks a lot! Simon & Roberta _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_817B078B-E4A9-4125-BBBD-73C63CA87E30 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello Adam,

let me = first of all apologize for the incredibly long time it took to produce = this revised version of the draft. Your review actually deserved a lot = of attention.
We have submitted a new version of the document. = Though, you will notice that at least a couple of important (i.e., = BLOCKING) questions are still in place. We would like to get your = further input on those points before proceeding with an updated = revision. Please find in-line our answers to your comments, preceded by = [SPR].

Most of my comments below are feedback that the document = authors should treat as normal last call comments. The feedback that I consider to block progressing the document, in my role as AD, is explicitly marked with the prefix "BLOCKER", and these will need to be resolved in a new version of the document before progressing it further. Note that it is entirely possible that something I have marked "BLOCKER" may stem from an error on my part; so recognize that these are not demands for change, as much as a need to have things either fixed in the document or explained to = me.

[SPR] Gotcha.

Title: The rule of thumb is = that all but a small handful of well-known acronyms need to be expanded in titles and abstracts. I recognize that "CLUE" is a bit tortured, as acronyms go, but the title of this document is, broadly speaking, opaque. Please change it to something meaningful, such as "Protocol for Controlling Multiple Streams for Telepresence = (CLUE)=E2=80=9D

[SPR] Done.

General: There are three = instances of excessively long lines in the document.

[SPR] ???

General: Please number and = caption the figures in this document. Also, please refer to the figure numbers when pointing to them (e.g., the first paragraph of section 6.1 should read something like: "As soon as the sub-state machine of the MP (Figure 1) is activated...=E2=80=9D."


[SPR] = Done.

BLOCKER: General: There are several mentions of = timeouts and retry thresholds in the text and its corresponding state machines; however, the document neither defines nor cites a document as defining what these timeout and retry values are. These need to be defined and described. If the timer and retry scheme allows the two ends of the connection to have different values for timeouts and number of retries, then there need to be additional error procedures that allow the MC and MP state machines to stay in sync (if the timer/retry values can be different, it's possible for one state machine to transition to "terminated," while the other is still active, and you need messaging to clean this up). =

[SPR] Our idea was to rely on a single, fixed, = application-level (i.e., CLUE-level) timeout value, rather than = leveraging a number of them (T1, T2, T4, plus Timer A through Timer K) = as in SIP. The value of the one and only timer would be the usual RTT = estimate (~500ms). Differently from protocols like SIP, we are also = leveraging retransmit counts to get out of a timeout-driven = retransmission loop. We=E2=80=99re not adding such information to the = revised version of the draft, because we=E2=80=99d first like to get = your feedback on the approach. If you (and the rest of the group) = believe this is a feasible approach, we can expand on that in a further = version of the document.

The remainder of this comment is non-blocking: Related to this, the document frequently refers to retries as "expiring" (e.g., "retry expired" on the state diagrams). That doesn't really make sense unless "retry" is the name of a timer rather than a counter; I think you mean to say "exhausted" or something similar.


[SPR] Done. = =E2=80=9CExpired" had been replaced with =E2=80=9Cexhausted=E2=80=9D.

General: This document defines six message types, = all of which have at least two names, many of which have more. It would be a lot easier to keep track of what is being described if these were kept consistent. I suggest choosing one term for each concept and sticking with it. In other words, please pick only one name from each of the following lines, and do not use any of the others:

[SPR] We decided to stick with the = names contained in the schema. See below for the details.

  1. OPTIONS, options
[SPR] = options

  1. OPTIONS RESPONSE, = optionsResponse
[SPR] optionsResponse
  1. ADVERTISEMENT, ADV, = advertisement
[SPR] advertisement
  1. ADVERTISEMENT ACKNOWLEDGEMENT, ADV ACK, ACK, NACK, = ack
[SPR] ack. 
We left the = NACK definition (ack carrying back an error code), since it makes sense = from the semantics perspective, in our opinion.
  1. CONFIGURE, CONF, CONF+ACK, = configure
[SPR] configure. Also here, we = have left the =E2=80=9Cconcept=E2=80=9D of the configure+ack, i.e. an = ack piggy-backed onto a configure message.
  1. CONFIGURE RESPONSE, CONF RESPONSE, = configureResponse

[SPR] configureResponse

The terminology section appears to be in = alphabetical order, except for "Capture Encoding" (which was presumably "Media Capture Encoding" in some earlier version). Please = fix.

[SPR] Done.

The definitions for "Endpoint", "MCU", and = "Media Stream/Stream" vary from the definition given in draft-ietf-clue-framework. Is this intentional?

[SPR] Not really. They = have now been aligned with version -25 of the framework.

The first paragraph of = section 4 mentions the framework and data model documents without citations. There should probably be citations to the corresponding = documents.

[SPR] Done.

Section 4 contains the following text:

   The CLUE protocol represents the mechanism
   for the exchange of CLUE information between CLUE =
Participants

This is sufficiently circular as to be = basically meaningless. Suggest: "...for the exchange of telepresence information between..."

[SPR] Done.

Section 5: The versioning = scheme in here is rather perplexing. Is there some technical reason the protocol restricts major version numbers to a single digit and minor versions to a single digit? Strongly suggest that this should be expanded to allow multiple digits for both the major and minor = versions.

[SPR] Done. The new pattern is now = "[1-9][0-9]*\.[0-9]+"

Section 5: It should be made clear that the XML Schema = excerpts in section 5 are non-normative. In particular, I recommend adding the following text to the end of the first paragraph of section 5: "This section includes non-normative excerpts of the schema to aid in describing it.=E2=80=9D

[SPR] Done.

Section 5: If the = single-digit version numbers are maintained (and, again, I strongly recommend against this), the definition of versionType appears to be wrong: it allows a major version digit of "0", which would seem to be precluded by the way versions are currently defined.

[SPR] This should now be = all good, with the pattern "[1-9][0-9]*\.[0-9]+"

Section 5: The XML definition allows zero or = more <clueId> elements to appear in a message. If more than one is allowed, the document should explain how multiple IDs are handled. If they are not, then the schema and/or text needs to prohibit having more than one.

[SPR] Actually, the schema = states:

<xs:element = name=3D"clueId" type=3D"xs:string" minOccurs=3D"0=E2=80=9D/>
=
This should indicate that clueId can appear = either 0 or 1 times in a valid XML document. The default value for = maxOccurs is in fact 1. Don=E2=80=99t you agree on = that?

Section 5: The description = for <sequenceNr> says that a 402 will be sent in the case of an "unexpected" sequence number. This needs clarification: is this for case where a sequence number gap is detected? A repeated sequence number? A number that is too small? All of the above?

[SPR] All of the = above.

At least = describe this with the 402 error code, and point to that description from = here.

[SPR] Done.

Section 5: The description for <v> would = benefit from the addition of "This document describes version = 1.0".

[SPR] Done.

Section 5.1: "The OPTIONS message is sent by = the CP which is the CI to the CP which is the CR as soon as the CLUE data channel is ready." Although it's a problem in other parts of the document too, the dense use of nearly identical two-letter acronyms in here makes it quite hard to read. I had to keep consulting the definitions of those acronyms to decode this sentence (as well as several similar ones). Consider just expanding these terms (as well as "MP" and "MC") instead of using them in prose.

[SPR] Done (here). Acronyms are = always a nasty beast; though, they prove useful when you have to write = tens of times the same long-enough terms.

Section 5.1 starts to wobble back and forth = between referring to elements with and without angle brackets (e.g., it uses both "supportedVersions" and "<supportedVersions>"). Please pick one and stick with it.

[SPR] Done.

BLOCKER: Section 5.1: The = description of <supportedVersions> describes a scheme in which multiple supported versions can be listed; and, if the list is omitted, it implies that only the version described in <v> is supported. This text does not define (nor does any other text that I can find) what <v> should be set to when <supportedVersions> is used. Intuitively, it seems that <v> should be set to the largest minor version of the smallest major version advertised in <supportedVersions>, but that (or whatever the correct answer is) needs to be clearly spelled out.

[SPR] I believe we were giving = for granted that =E2=80=9Cv=E2=80=9D should be, in such case, the = highest supported version (i.e., largest major and larger minor = numbers). Now that you make me think around that, I would simply say = that the =E2=80=9Cv=E2=80=9D attribute MUST be set to one of the = versions that the entity in question supports, as per the = <supportedVersions> list. I can, e.g., decide that I send an = =E2=80=98options=E2=80=99 with =E2=80=9Cv=3D12.23=E2=80=9D if the = <supportedVersions> list is like in the following:

<version>33.44</version>
<v= ersion>27.0</version>
<version>12.345</version= >
<version>1.44</version>

BLOCKER: Section 5.2: "If = the responseCode is of the type 2xx the response MUST also include..." -- you can't use "2xx" in a normative statement without first defining what it means. As you don't use the "#xx" format anywhere else, I suggest rephrasing: "If the <responseCode> is between 200 and 299 inclusive, the response MUST also include...=E2=80=9D

[SPR] = Done.

Sections = 5.2, 5.4, 5.6: It seems really odd that the document defines a base clueMessageType that all messages derive from, but then leaves all the response types (optionsResponse, ack, configureResponse) to repeatedly and independently add <responseCode>,<responseString>, and the sequence number of the corresponding message over and over again. I would strongly suggest adding something like:

   <!-- CLUE RESPONSE TYPE -->
   <xs:complexType name=3D"clueResponseType">
   <xs:complexContent>
   <xs:extension base=3D"clueMessageType">
   <xs:sequence>
   <xs:element name=3D"responseCode" type=3D"responseCodeType"/>
   <xs:element name=3D"reasonString" type=3D"xs:string" =
minOccurs=3D"0"/>
   <xs:element name=3D"requestSequenceNr" =
type=3D"xs:positiveInteger"/>
   <xs:any namespace=3D"##other" processContents=3D"lax" =
minOccurs=3D"0"/>
   </xs:sequence>
   </xs:extension>
   </xs:complexContent>
   </xs:complexType>

[SPR] Done (without =E2=80=9CrequestSequenceNr=E2=80=9D, = which is not present inside the optionsResponse message).

...and then defining those three response types = as being extensions of "clueResponse" instead of "clueMessage", like = this:

   <!-- ADV ACK MESSAGE TYPE -->
   <xs:complexType name=3D"advAcknowledgementMessageType">
   <xs:complexContent>
   <xs:extension base=3D"clueResponseType">
   <xs:anyAttribute namespace=3D"##other" processContents=3D"lax"/>
   </xs:extension>
   </xs:complexContent>
   </xs:complexType>
[SPR] Done.
Regardless of how you do this, any section =
that adds
      "responseCode" and "reasonString" needs to point to section 5.7 in
      its description to explain how those fields are populated and
      interpreted.

[SPR]= Done.

Section = 5.5: This section allows a boolean flag in a <configure> message to acknowledge an <advertisement>. Is this intended to always be handled like a 200? Consider: if you define a 201 response code in the future, will implementations be unable to convey its meaning in a CONF + ACK? Given that the document defines a class of codes for success rather than a simple success flag in general, it seems that this <ack> element should carry a success response code rather than just a boolean. If you decide to keep the boolean, be very clear that it is to be treated as a 200 rather than any other potential success code; and that conveying any other kind of success requires a separate <ack> message.

[SPR] We modified the = <ack> element as follows:

<xs:element name=3D"ack" = type=3D"successResponseCodeType" minOccurs=3D"0=E2=80=9D/>
With:

<xs:simpleType = name=3D"successResponseCodeType">
  <xs:restriction = base=3D"xs:integer">
   <xs:pattern = value=3D"2[0-9][0-9]"/>
  = </xs:restriction>
</xs:simpleType>

Section 5.5: the final paragraph mentions the <captureEncodings> element -- it would be helpful to add something like "see [I-D.ietf-clue-datamodel] for the definition of <captureEncodings>.=E2=80=9D

[SPR] = Done.

BLOCKER: = Section 5.7 indicates that there is a class of response codes, starting with "1", which are used to indicate "delayed or incomplete" responses. The document does not describe any protocol behavior for this class of response. The description of the meaning of this class (and the obvious parallels to HTTP and SIP) imply that some subsequent response associated with the same request will be arriving at some point in the future. If that's the intention, this document needs a *lot* more text (and corresponding adjustments to the state machines) to explain how these 100-class codes are handled. In practice, since the current version of the document does not define nor make use of 100-class codes, I suggest that the most reasonable path forward is to remove discussion of codes starting with "1" from the first paragraph of section 5.7, instead adding a paragraph immediately following it that says something like:

  This document does not = define response codes starting with "1", and such
  response codes are not allowed to = appear in major version 1 of the CLUE
  protocol. The range from 100 to 199 = inclusive is reserved for future major
  versions of the protocol to define = response codes for delayed or incomplete
  operations if necessary. Response codes = starting with "5" through "9" are
  reserved for future major versions of = the protocol to define new classes of
  response, and are not allowed in major = version 1 of the CLUE protocol.
  Response codes starting with "0" are = not allowed.


[SPR] Done.

Section 5.7: "The response codes and strings = defined for use with CLUE are as follows" - this strongly implies that the descriptions given in this table are the only ones that are allowed in CLUE <reasonString> element, and that any other messages should presumably be treated as an error. Surely that's not what you mean. Suggest rephrasing to indicate that the "Description" text can be sent in the <reasonString>, but that implementations can (and are encouraged to) include more specific descriptions of the error condition, if possible.

[SPR] = Done.

Section = 5.7: I can't figure out how an implementation could ever send a "300" response code. If the XML syntax is incorrect, that's a 301. If the message contains an invalid value, that's a 302. And those are the only two conditions that are described for 300. I think you need to give "300" a bit more thought -- if you can't come up with a more generic description (e.g., "low-level request error"), you probably want to remove = it.

[SPR] We opted for your suggested =E2=80=9Clow-l= evel request error".

Section 5.7: for 403, be clear which identifier is meant. Do = you mean "The <clueId> used in the message is not = valid..."?

[SPR] Yep. <clueId> added.

Section 5.7: for 404, = please be clear that you're talking about the sequence number rather than just using "number" without qualification.

[SPR] OK.

Section 5.7: The = description for 405 uses the acronym "MCC" without expanding it. Please expand = it.

[SPR] Done.

BLOCKING: The state = machines in section 6 and its subsections don't have transitions for all possible messages that could arrive in a state. This can cause interop issues. Please add text that clearly indicates whether such messages do or do not cause a transition. (This might be as simple as "messages not shown for a state do not cause the state to change," but only if you carefully check that this is true -- for example, what should an MP state machine do do if it gets a "CONF + ACK" in the state "WAIT FOR CONF"?)

[SPR] In the specific case you = mention, I would expect that a 302 is generated (Invalid Parameter), = since the incoming CONF should not contain the <ack> element. This = said, I see your point related to the potential lack of some edges in = the state machine graph. This point is obviously also related to the = =E2=80=9Ctimeout=E2=80=9D issue you raised before. Different ways of = managing timeouts will definitely have different impacts on the current = state machines.
We will defer the modification of the diagrams = in question to the next revision round. In the meanwhile, we=E2=80=99ll = give a thought to potential further unexpected transactions to be taken = into account.

Section 6: = The fifth paragraph says "CLUE channel" where it means "CLUE data channel.=E2=80=9D

[SPR] Done.

Section 6: The eighth = paragraph says:

   The CP moves from the ACTIVE state to the IDLE =
one when the sub-state
   machines that have been activated are (both) in the relative
   TERMINATED state (see sections Section 6.1 and Section 6.2).

The "both" in this paragraph is confusing, since it's = possible to have only one or the other machine running. Please = rephrase.

[SPR] Done.

Section 6.2 describes a state machine that = starts in a state called "WAIT FOR ADV." This state does not appear to be timer-supervised, meaning that implementations of this state machine can stay in this state literally forever. Is that the intention?

[SPR] The idea would be to open a = socket and start listening for incoming advertisements. Isn=E2=80=99t = that OK?

Section = 6.2 also describes the possibility of sending a <ack> and <configure> separately or as a combined message. I would have expected to see some discussion here about why implementations might choose one behavior over the = other.

[SPR] The idea is that if the configure = does not take too much time to get prepared, you can send it in = conjunction with the ack. Otherwise (i.e., if you need some more time to = build your configure message) you start by  acking the = advertisement and send the configure when it is ready to go. We = rephrased the text in the draft accordingly.

Section 7: The second sentence of the second = paragraph needs a verb.

[SPR] Done.

Section 7, paragraph 3: this claims that = versions are a non-negative *integer* rather than a *digit*. As I mention above, this seems to be the right way to handle versions, but it is decidedly at odds with text elsewhere in the document and in the schema. Regardless of how you choose to treat versions, the text needs to be consistent.

[SPR] This should = now be all set (see above answers about version definition).

Section 7, final paragraph: = replace "Clue" with "CLUE.=E2=80=9D

[SPR] Done.

Section 8 contains a = paragraph starting with "In that case, the new informationn..." but it's not clear which case it's referring to. Please replace "In that case" with a description of the case under consideration.

[SPR] We removed =E2=80=9C= In that case=E2=80=A6=E2=80=9D, since the thing was quite clear.

Section 8 contains the = phrase "Similarly to what said before..." -- this is ungrammatical and needs to be = rephrased.

[SPR] Wrong terms removed.

Section 8 indicates that = extensions need to indicate "the standard version of the protocol the extension refers to." Given that there is compatibility within a major version of a protocol, I think this means to say "the major standard version of the protocol that the extension refers = to.=E2=80=9D

[SPR] My extension might be = associated with version 3.6 of the protocol. This means that it will = need to be supported by all versions higher than that (3.7 onwards). = Though, this does not entail that versions 3.5 and lower should = understand it. Right?

Section 8 has a paragraph starting "For that reason..." -- = it's not clear what reason is being referred to here. Please = clarify.

[SPR] Removed.

Section 8 contains schema that contains a = <version> element. It should be clarified that this is the *protocol* version, not the *extension* version (or, if it's the extension version, that needs to be spelled out too, but I think you'll need a new namespace for that...?)

[SPR] I = thought this was clear from the third bullet point in the = list:

- the standard version of = the protocol the extension refers to.

Isn=E2=80=99t this enough? In such a case, what = would you suggest to add?

BLOCKING: Section 8.1 is an example section, which are non-normative in IETF documents. It contains 2119-style normative language, however. These normative statements need to be moved out of the example section (and probably into section 8). =

[SPR] Done.

The remainder of this comment is non-blocking: I also find the "SHOULD" in this section to be highly perplexing. Can you explain the rationale behind requiring schema, but not requiring any description of what the schema = *means?)

[SPR] It is like coding without adding = comments/documentation. Documentation is most welcome, but not = mandatory. Don=E2=80=99t you agree?

BLOCKING: The example in section 8.1 includes = the following:

   =
xmlns=3D"clue-info-extension-myVideoExtensions"

I'm = pretty certain that namespaces are required to be identified by URIs rather than arbitrary strings.

[SPR] = Right! Namespace updated.

Section 8.1: The final paragraph also has normative language = in it, although it appears to be reiterating requirements from elsewhere in the document. I suggest lowercasing "MUST" in this paragraph.

[SPR] Done.

Section 8.1: The final = paragraph mentions the use of <options> and <optionsResponse> to negotiate the extension. An example demonstrating this negotiation would be extremely useful.

The schema in section 9 = contains:

<xs:import =
namespace=3D"urn:ietf:params:xml:ns:clue-info"
schemaLocation=3D"data-model-schema-17.xsd"/>

If = you do not intend to bake this "-17" into the document (and I can't imagine you do), please add an RFC editor note to change it to something else upon = publication.

[SPR] Done. I am not very = familiar with RFC editor notes, indeed. Here is what we added at the = beginning of section 9:

"NOTE TO THE = RFC-Editor: Please replace "data-model-schema-17.xsd" with the right = schema location for the CLUE data model schema document (which is still = to be defined at the time of this writing) in this section prior to = publication as an RFC.=E2=80=9D

Does = this work for you?

Also, the schema in section 9 is (with rare exception) unindented. This makes it *very* hard to read. Please consider formatting it with conventional XML indentation. (This also applies to the schema excerpts earlier in the document.)


[SPR] = Done.

Has there been any automated tool-based checking = that the examples in section 10 to verify that they conform to the schema in section 9 (and the schemata it = imports)?

[SPR] Yep. We did not test the = modifications we have just applied with this review of the draft. Will = check asap.

Section = 10.2: Please expand the acronym "MCCs" in the section title (keep in mind that this appears in the table of contents, where it needs to makes sense).

[SPR] = Done.

Section 10 = in general: While it does consume a lot of space, I don't think that defining six rather different message types and then showing only *one* type in the examples is very illustrative of the protocol. I would *STRONGLY* suggest adding at least a response message, and ideally the example section should contain at least one example for each of the six message = types.

[SPR] Will do in the (hopefully final) = revision of the document. Let=E2=80=99s first double check that the = proposed modifications are OK.

Section 11, paragraph 4: Replace "Clue" with = "CLUE.=E2=80=9D

[SPR] Done.

Section 12.1 has a strange = double-double quote around the URN name, and section 12.3 repeats this for the MIME type.

[SPR] I don=E2=80=99t understand = this. Can you please clarify?

All subsections of section 12: please update all = registrant contact information to point to the IESG (iesg@ietf.org) rather than the CLUE working group and one of the = authors.

[SPR] Done.

Section 12.4.1: These descriptions will appear = in an IANA registry, where the phrase "in this document" will have no context and be rather nonsensical. Please = rephrase.

[SPR] Done.

Sections 13 through 23 should include an RFC = editor note asking for removal before publication.

[SPR] Those = sections have been just removed.

/a


Thanks a lot!

Simon & Roberta

        =               =   _\\|//_
    =                     =     = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/

= --Apple-Mail=_817B078B-E4A9-4125-BBBD-73C63CA87E30--