From nobody Thu Jul 4 05:22:14 2019 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 29F70120026; Thu, 4 Jul 2019 05:22:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 Knf4g3LD1LAF; Thu, 4 Jul 2019 05:22:00 -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 EB9F21204E8; Thu, 4 Jul 2019 05:21:59 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id x64CLvfv027694-x64CLvfx027694 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:21:57 +0200 Received: from [10.20.1.250] (iw452509.net.t-com.hr [195.29.56.30]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id x64CLuSi030989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:21:56 +0200 From: Simon Pietro Romano Message-Id: <708B1967-B935-46E9-88F4-6E01F52362BA@unina.it> Content-Type: multipart/alternative; boundary="Apple-Mail=_B216C493-80EB-4851-B9F7-7FC902266DEC" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Jul 2019 14:21:55 +0200 In-Reply-To: <154265195328.5264.10510811874699482118.idtracker@ietfa.amsl.com> Cc: The IESG , clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-protocol@ietf.org To: Benjamin Kaduk References: <154265195328.5264.10510811874699482118.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [clue] Benjamin Kaduk's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 12:22:06 -0000 --Apple-Mail=_B216C493-80EB-4851-B9F7-7FC902266DEC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Benjamin, we finally managed to work on the new version of the draft. Please find = below our answers (preceded by [SPR]) to your comments and suggestions. Thanks a lot for your precious review! Simon & Roberta = **************************************************************************= **************************************************************** Benjamin Kaduk [KADUK] Discuss Discuss (2018-11-19) [KADUK] Thanks for the generally clear and well-written document! I would like to discuss whether there needs to be more prominent = coverage of timers/timeouts, especially as relating to the state machines. (I'd = be happy to learn that this is well-covered elsewhere in the document set; I just = haven't run into it yet.) [SPR] We have indeed discussed this extensively within the WG. I believe = the final resolution=20 was not to cover timers/timeouts in a more prominent fashion and go for = an experimental RFC type. For the sake of completeness, I am reporting below the core part of the = above mentioned discussions. The following excerpts relate to Adam Roach=E2=80=99s AD review (and = associated responses from the authors): [ADAM] 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. [ADAM] In thinking through what this scheme should look like, it occurs = to me that the CLUE messages are defined to be sent over a reliable = transport (SCTP), which has its own retransmission timers and eventual = timeouts. Implementing a retransmission scheme on top of a reliable = transport -- especially one as aggressive as you suggest above -- will = put more traffic on the network when congestion occurs rather than less. So, in the final analysis, I think the action here is to remove = retransmission timers and retry counts altogether. If the underlying = transport takes longer to detect a failure than is sensible for CLUE = (and it likely does), then a supervisory timer that declares the session = failed might make sense. [KADUK] In a similar vein, do we want to have any treatment of avoiding = infinite loops (e.g., when a 'configure' or 'advertisement' is rejected in expectation = of modification but the sending implementation continues to generate an identical = message)? [SPR] As per above. [KADUK] It is not clear to me that any change to the document text is = needed in either case, but I don't know to what extent the topics have already been discussed. = **************************************************************************= **************************************************************** [KADUK]=20 I also have some substantial comments that do not rise to Discuss-level. How do I know which endpoint is the channel initiator and which is the channel receiver? draft-ietf-clue-signaling suggests that the DTLS client is the channel initiator, but even that is not explicit about it -- the protocol could = be considered under-specified if there is insufficient clarity. [SPR] The CLUE data Chanel is established as described in = draft-ietf-clue-datachannel. The cited document clearly states the = following: "This document defines how to use the WebRTC data channel mechanism [I-D.ietf-rtcweb-data-channel] to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol [I-D.ietf-clue-protocol] messages between two CLUE entities." The CLUE channel initiator is hence the peer which creates the WebRTC = data channel (e.g., which calls=20 RTCPeerConnection.createDataChannel()) in the first place. [KADUK] Section 2 The MCU definition doesn't actually expand the acronym, which seems a little reader-unfriendly. [SPR] Fixed [KADUK] Section 5.1 There are perhaps more XML extension points in here than is reasonable = for some of these elements (e.g., ). [SPR] I'm not sure I understand this correctly. Is this a request for = changing the schema? If so, what is the suggested change? [KADUK] Section 5.2 If the responseCode is between 200 and 299 inclusive, the response MUST also include , , and elements; Maybe re-mention that MP and MC are booleans here. [SPR] Done. [KADUK] Finally, the commonly supported extensions are copied in the field. Does this need to say that only extensions that are applicable to the negotiated protocol version are included? =20 [SPR] YES. [KADUK] (Also, how does one handle an extension that exists for multiple major versions -- are there two elments for it in the message?) [SPR] YES. Each element includes a child element = for this purpose. See, e.g., the example in section 10.1 [KADUK]=20 Upon reception of the 'optionsResponse' the version to be used is the one provided in the tag of the message. The following CLUE messages MUST use such a version number in the "v" attribute. The allowed extensions in the CLUE dialogue are those indicated in the of the 'optionsResponse' message. Couldn't this restriction on the "v" value apply even to the 'optionsResponse' message? [SPR] The "v" attribute value in the "optionsResponse" message contains = the name of the agreed-upon version. If present, the child element in the optionsResponse message contains the list of the = commonly extensions extensions for the agree-upon protocol version. See, e.g., section 10.2 in the draft. [KADUK] Section 5.3 The 'advertisement' message is used by the MP to advertise the available media captures and related information to the MC. [...] I'd consider avoiding the definite article "the" to refer to MP/MC = roles, since in many caess there will be 2+ of each, and we don't want to = confuse the reader into thinking that there is an MP/CR equivalence or something like that. So, perhaps "each MP" and "the corresponding MC". [SPR] Good catch. Fixed. [KADUK] Section 5.4 As it can be seen from the message schema provided in the following excerpt (Figure 6), the 'ack' contains a response code and a reason string for describing the processing result of the 'advertisement'. [...] [the reason string is part of the base clueResponseType] The text quoted here could be read as implying that the reason string is required in the 'ack' message, a stronger requirement than of the base clueResponseType where it has minOccurs=3D0. Some greater clarity in = the text here is probably called for, especially since when the 'ack' is piggybacked on a 'configure' message, there is no provision for a reason string at all.=20 [SPR] Right. Modified as follows: "the 'ack' contains a response code and may contain a reason string for describing the = processing result of the 'advertisement'". [KADUK] Section 5.5 The element MUST NOT be present if an 'ack' message has been already sent back to the MP. I think you need to clarify that this is scoped to the current advSequenceNr. [SPR] Right. Modified accordingly. [KADUK] Section 5.6 It contains (Figure 8) a response code with a reason string indicating either the success or=20= the failure (along with failure details) of a 'configure' request processing. [...] [Same comment about reason string as for 'ack'] [SPR] Same fix as per above. [KADUK] Section 5.7 =20 Such new response codes MUST NOT overwrite the ones here defined and they MUST respect the semantics of the first code digit. nit: is this "overwrite" or "override"? [SPR] "Override", thanx for spotting that out. =20 [KADUK] 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=20 allowed in major version 1 of the CLUE protocol. Response codes=20 starting with "0" are not allowed. =20 This text seems to also preclude extensions to major version '1' from defining 1xx or [5-9]xx reason codes; is that the intent? [SPR] Yes, it is. Extensions can indeed define new pieces of information = to be carried within existing CLUE messages;=20 though, they must provide their own schema and be defined in the = framework of external namespaces. [KADUK] Section 6 When the CLUE data channel set up starts ("start channel"), the CP moves from the IDLE state to the CHANNEL SETUP state. nit: only one of "sets up" and "starts" is needed. [SPR] Fixed.=20 [KADUK] When in the ACTIVE state, the CP starts the envisioned sub-state machines (i.e., the MP state machine and the MC state machine) according to the roles it plays in the telepresence sessions. Such roles have been previously declared in the 'options' and 'optionsResponse' messages involved in the initiation phase (see OPTIONS sections Section 5.1 and Section 5.2 for the details). [...] =20 My reading of the initiation phase is that each CP sends only a boolean indication of whether it supports the MP/MC roles, and so each party has = to determine on its own whether it will act as a MP and/or MC; is that correct? If so, do we need to say anything about how the boolean matrix translates to activating the respective sub-state machines? [SPR] Are you suggesting that we remove the second part of the sentence = from there? [KADUK] Section 6.1 'configure+ack' messages referring to out-of- date (i.e., having a sequence number equal to or less than the highest seen so far) advertisements MUST be ignored, i.e., they do not trigger any state transition. [...] Is this really less than or equal or just less than? Also, is "seen" = the right verb, since IIUC these are sequence numbers that the MP has *generated* in its advertisements? [SPR] Good catch. Both comments are valid. Text modified accordingly. [KADUK] Section 7 In other words, in this example, the MP MUST use version 1.4 and downgrade to the lower version. [...] nit: does the phrase "and downgrade to the lower version" add any value here? The word "downgrade" can have negative connotations in some other contexts, so if it's not adding value I'd suggest avoiding it. [SPR] Agreed. [KADUK] Section 8 As reported in Figure 13, the values of the fields of the element (either new information or new messages) take the following values: [...] o the major standard version of the protocol that the extension refers to. The XSL includes a full version (including minor), even though the semantics basically only use the major version. That said, why is the 'version' element minOccurs=3D"0" -- what are the semantics when it is absent? [SPR] You're right. We removed the minoccurs=3D"0" from both "schemaRef" = and "version". [KADUK] Section 8.1 The CLUE data model document ([I-D.ietf-clue-data-model-schema]) envisions the possibility of adding this kind of "extra" information in the description of a video capture by keeping the compatibility with the CLUE data model schema. [...] nit: I don't think this is grammatical; maybe just "keeping = compatibility". [SPR] We removed "by keeping compatibility..." from the sentence. [KADUK] Section 10 This claims to be a "call flow" example, but the described flows only contain a single unidirectional media flow, which is not really = consistent with the normal usage of the word "call". Buried in the body text there = is a disclaimer: [...] For the sake of simplicity, the following call flow focuses only on the dialogue between MP CP1 and MC CP2. I would suggest making the presence of this simplification much clearer from the start, perhaps "CLUE protocol messages exchanged in the = following call flow are detailed; only one direction of media is shown for simplicity, as the other direction is precisely symmetric". [SPR] Fixed. [KADUK] CP2 acknowledges the second 'advertisement' message with an 'ack' message (Section 10.7). In a second moment, CP2 changes the requested media streams from CP1 by sending to CP1 a 'configure' message replacing the previously selected video streams with the new composed media streams advertised by CP1 (Section 10.8). This might be an appropriate place to indicate that media from the = previous configuration continue to flow during the reconfiguration process. [SPR] Done. [KADUK] It might also be worth noting again somewhere in here (or a subsection) that there are three (well, two, since we only show one direction of = media) distinct sequence number spaces per sender, and that the discontinuity between Section 10.2 and 10.3's numbers is correct. [SPR] Done [KADUK] Section 11 Thanks for the well-thought-through security considerations; in = combination with the linked documents (particularly the framework), they cover all = the considerations (especially privacy considerations) that I had in mind. [SPR] Thanx! [KADUK] Section 14.2 We appear to be citing both 5117 and 7667, whereas the latter obsoletes = the former. [SPR] Fixed. _\\|//_ ( 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > Il giorno 19 nov 2018, alle ore 19:25, Benjamin Kaduk = ha scritto: >=20 > Benjamin Kaduk has entered the following ballot position for > draft-ietf-clue-protocol-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for the generally clear and well-written document! > I would like to discuss whether there needs to be more prominent = coverage > of timers/timeouts, especially as relating to the state machines. = (I'd be happy > to learn that this is well-covered elsewhere in the document set; I = just haven't > run into it yet.) >=20 > In a similar vein, do we want to have any treatment of avoiding = infinite loops > (e.g., when a 'configure' or 'advertisement' is rejected in = expectation of modification > but the sending implementation continues to generate an identical = message)? >=20 > It is not clear to me that any change to the document text is needed = in either case, > but I don't know to what extent the topics have already been = discussed. >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I also have some substantial comments that do not rise to = Discuss-level. >=20 > How do I know which endpoint is the channel initiator and which is the > channel receiver? > draft-ietf-clue-signaling suggests that the DTLS client is the channel > initiator, but even that is not explicit about it -- the protocol = could be > considered under-specified if there is insufficient clarity. >=20 > Section 2 >=20 > The MCU definition doesn't actually expand the acronym, which seems a > little reader-unfriendly. >=20 > Section 5.1 >=20 > There are perhaps more XML extension points in here than is reasonable = for > some of these elements (e.g., ). >=20 > Section 5.2 >=20 > If the responseCode is between 200 and 299 > inclusive, the response MUST also include , > , and elements; >=20 > Maybe re-mention that MP and MC are booleans here. >=20 > Finally, the commonly supported extensions are copied in the > field. >=20 > Does this need to say that only extensions that are applicable to the > negotiated protocol version are included? (Also, how does one handle = an > extension that exists for multiple major versions -- are there two > elments for it in the message?) >=20 > Upon reception of the 'optionsResponse' the version to be used is = the > one provided in the tag of the message. The following = CLUE > messages MUST use such a version number in the "v" attribute. The > allowed extensions in the CLUE dialogue are those indicated in the > of the 'optionsResponse' message. >=20 > Couldn't this restriction on the "v" value apply even to the > 'optionsResponse' message? >=20 > Section 5.3 >=20 > The 'advertisement' message is used by the MP to advertise the > available media captures and related information to the MC. [...] >=20 > I'd consider avoiding the definite article "the" to refer to MP/MC = roles, > since in many caess there will be 2+ of each, and we don't want to = confuse > the reader into thinking that there is an MP/CR equivalence or = something > like that. So, perhaps "each MP" and "the corresponding MC". >=20 > Section 5.4 >=20 > As it can be seen from the message schema > provided in the following excerpt (Figure 6), the 'ack' contains a > response code and a reason string for describing the processing > result of the 'advertisement'. [...] >=20 > [the reason string is part of the base clueResponseType] > The text quoted here could be read as implying that the reason string = is > required in the 'ack' message, a stronger requirement than of the base > clueResponseType where it has minOccurs=3D0. Some greater clarity in = the > text here is probably called for, especially since when the 'ack' is > piggybacked on a 'configure' message, there is no provision for a = reason > string at all. >=20 > Section 5.5 >=20 > The element MUST NOT be present if = an > 'ack' message has been already sent back to the MP. >=20 > I think you need to clarify that this is scoped to the current > advSequenceNr. >=20 > Section 5.6 >=20 > It contains (Figure 8) a > response code with a reason string indicating either the success or > the failure (along with failure details) of a 'configure' request > processing. [...] >=20 > [Same comment about reason string as for 'ack'] >=20 > Section 5.7 >=20 > Such new response codes MUST NOT overwrite the ones here defined and > they MUST respect the semantics of the first code digit. >=20 > nit: is this "overwrite" or "override"? >=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 > This text seems to also preclude extensions to major version '1' from > defining 1xx or [5-9]xx reason codes; is that the intent? >=20 > Section 6 >=20 > When the CLUE data channel set up starts ("start channel"), the CP > moves from the IDLE state to the CHANNEL SETUP state. >=20 > nit: only one of "sets up" and "starts" is needed. >=20 > When in the ACTIVE state, the CP starts the envisioned sub-state > machines (i.e., the MP state machine and the MC state machine) > according to the roles it plays in the telepresence sessions. Such > roles have been previously declared in the 'options' and > 'optionsResponse' messages involved in the initiation phase (see > OPTIONS sections Section 5.1 and Section 5.2 for the details). = [...] >=20 > My reading of the initiation phase is that each CP sends only a = boolean > indication of whether it supports the MP/MC roles, and so each party = has to > determine on its own whether it will act as a MP and/or MC; is that > correct? If so, do we need to say anything about how the boolean = matrix > translates to activating the respective sub-state machines? >=20 > Section 6.1 >=20 > 'configure+ack' messages referring to out-of- > date (i.e., having a sequence number equal to or less than the > highest seen so far) advertisements MUST be ignored, i.e., they do > not trigger any state transition. [...] >=20 > Is this really less than or equal or just less than? Also, is "seen" = the > right verb, since IIUC these are sequence numbers that the MP has > *generated* in its advertisements? >=20 > Section 7 >=20 > In other > words, in this example, the MP MUST use version 1.4 and downgrade to > the lower version. [...] >=20 > nit: does the phrase "and downgrade to the lower version" add any = value > here? The word "downgrade" can have negative connotations in some = other > contexts, so if it's not adding value I'd suggest avoiding it. >=20 > Section 8 >=20 > As reported in Figure 13, the values of the fields of the = > element (either new information or new messages) take the following > values: > [...] > o the major standard version of the protocol that the extension > refers to. >=20 > The XSL includes a full version (including minor), even though the > semantics basically only use the major version. That said, why is the > 'version' element minOccurs=3D"0" -- what are the semantics when it is > absent? >=20 > Section 8.1 >=20 > The CLUE data model document ([I-D.ietf-clue-data-model-schema]) > envisions the possibility of adding this kind of "extra" information > in the description of a video capture by keeping the compatibility > with the CLUE data model schema. [...] >=20 > nit: I don't think this is grammatical; maybe just "keeping = compatibility". >=20 > Section 10 >=20 > This claims to be a "call flow" example, but the described flows only > contain a single unidirectional media flow, which is not really = consistent > with the normal usage of the word "call". Buried in the body text = there is > a disclaimer: > [...] For the sake of simplicity, the following > call flow focuses only on the dialogue between MP CP1 and MC CP2. > I would suggest making the presence of this simplification much = clearer > from the start, perhaps "CLUE protocol messages exchanged in the = following > call flow are detailed; only one direction of media is shown for > simplicity, as the other direction is precisely symmetric". >=20 > CP2 acknowledges the second 'advertisement' message with an 'ack' > message (Section 10.7). >=20 > In a second moment, CP2 changes the requested media streams from CP1 > by sending to CP1 a 'configure' message replacing the previously > selected video streams with the new composed media streams = advertised > by CP1 (Section 10.8). >=20 > This might be an appropriate place to indicate that media from the = previous > configuration continue to flow during the reconfiguration process. >=20 > It might also be worth noting again somewhere in here (or a = subsection) > that there are three (well, two, since we only show one direction of = media) > distinct sequence number spaces per sender, and that the discontinuity > between Section 10.2 and 10.3's numbers is correct. >=20 > Section 11 >=20 > Thanks for the well-thought-through security considerations; in = combination > with the linked documents (particularly the framework), they cover all = the > considerations (especially privacy considerations) that I had in mind. >=20 > Section 14.2 >=20 > We appear to be citing both 5117 and 7667, whereas the latter = obsoletes the > former. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 --Apple-Mail=_B216C493-80EB-4851-B9F7-7FC902266DEC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Benjamin,


we finally managed to work on the new = version of the draft. Please find below our answers (preceded by [SPR]) = to your comments and suggestions.
Thanks a lot for = your precious review!

Simon & Roberta

***************************************************************= **************************************************************************= *
Benjamin Kaduk = [KADUK]
Discuss
Discuss (2018-11-19)

[KADUK] Thanks for = the generally clear and well-written document!
I would like to discuss whether there = needs to be more prominent coverage
of timers/timeouts, especially as relating to the = state machines.  (I'd be happy
to learn that this is well-covered elsewhere in the = document set; I just haven't
run into it yet.)

[SPR] We have = indeed discussed this extensively within the WG. I believe the final = resolution 
was= not to cover timers/timeouts in a more prominent fashion and go for an = experimental RFC type.

For the sake of completeness, I am = reporting below the core part of the above mentioned = discussions.
The= following excerpts relate to Adam Roach=E2=80=99s AD review (and associated = responses from the authors):

[ADAM] 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.

[ADAM] In thinking through what this = scheme should look like, it occurs to me that the CLUE messages are = defined to be sent over a reliable transport (SCTP), which has its own = retransmission timers and eventual timeouts. Implementing a = retransmission scheme on top of a reliable transport -- especially one = as aggressive as you suggest above -- will put more traffic on the = network when congestion occurs rather than less.
So, in the final = analysis, I think the action here is to remove retransmission timers and = retry counts altogether. If the underlying transport takes longer to = detect a failure than is sensible for CLUE (and it likely does), then a = supervisory timer that declares the session failed might make = sense.

[KADUK] In a similar vein, do we want to have any treatment = of avoiding infinite loops
(e.g., when a 'configure' or 'advertisement' is rejected in = expectation of modification
but the sending implementation continues to generate = an identical message)?

[SPR] As per above.

[KADUK] It is not clear to me that any change to the document = text is needed in either case,
but I don't know to what extent the topics have = already been discussed.

***************************************************************= **************************************************************************= *

[KADUK] 
I also have some substantial comments that do not rise to = Discuss-level.

How do I know which endpoint is the channel initiator and which = is the
channel = receiver?
draft-ietf-clue-signaling suggests that the DTLS client is = the channel
initiator, but even that is not explicit about it -- the = protocol could be
considered under-specified if there is insufficient = clarity.

[SPR] The CLUE data Chanel is established as described in = draft-ietf-clue-datachannel. The cited document clearly states the = following:

"This document defines how to use the WebRTC data = channel mechanism
   [I-D.ietf-rtcweb-data-channel] to realize a data = channel, referred to
   as a CLUE data channel, for transporting CLUE = protocol
   [I-D.ietf-clue-protocol] messages between two = CLUE entities."

The CLUE channel initiator is hence the peer which = creates the WebRTC data channel (e.g., which calls 
RTCPeerConnection.createDataChannel()) in the first = place.


[KADUK] Section 2

The MCU definition doesn't actually expand the acronym, which = seems a
little = reader-unfriendly.

[SPR] Fixed

[KADUK]

Section 5.1

There are perhaps more XML extension = points in here than is reasonable for
some of these elements (e.g., = <versionsListType>).

[SPR] I'm not sure I understand this = correctly. Is this a request for changing the schema? If so, what is the = suggested change?

[KADUK]

Section = 5.2

                 =           If the responseCode is between 200 = and 299
   = inclusive, the response MUST also include = <mediaProvider>,
   <mediaConsumer>, <version> and = <commonExtensions> elements;

Maybe re-mention = that MP and MC are booleans here.

[SPR] = Done.

[KADUK]

   Finally, the commonly supported = extensions are copied in the
   <commonExtensions> = field.

Does this need to say that only extensions that are = applicable to the
negotiated protocol version are included?  

[SPR] YES.

[KADUK]

(Also, how does = one handle an
extension that exists for multiple major versions -- are = there two
<extension> elments for it in the <options> = message?)

[SPR] YES. Each <extension> element includes a = child <version> element for this purpose. See, e.g., the example = in section 10.1

[KADUK] 

   Upon = reception of the 'optionsResponse' the version to be used is = the
   = one provided in the <version> tag of the message.  The = following CLUE
   messages MUST use such a version number in the = "v" attribute.  The
   allowed extensions in the CLUE dialogue are = those indicated in the
   <commonExtensions> of the = 'optionsResponse' message.

Couldn't this restriction on the "v" = value apply even to the
'optionsResponse' message?

[SPR] The "v" = attribute value in the "optionsResponse" message contains the name of = the agreed-upon version. If present, the = <commonExtensions>
child element in the optionsResponse message contains the = list of the commonly extensions extensions for the agree-upon protocol = version.
See, e.g., section 10.2 in the draft.


[KADUK]

Section = 5.3

   The 'advertisement' message is used by the MP to = advertise the
   available media captures and related information = to the MC.  [...]

I'd consider avoiding the definite = article "the" to refer to MP/MC roles,
since in many caess there will be 2+ of each, and we = don't want to confuse
the reader into thinking that there is an MP/CR equivalence = or something
like that.  So, perhaps "each MP" and "the corresponding = MC".

[SPR] Good catch. Fixed.

[KADUK]

Section 5.4

         =                     As = it can be seen from the message schema
   provided in the following excerpt = (Figure 6), the 'ack' contains a
   response code and a reason string for = describing the processing
   result of the 'advertisement'.  = [...]

[the reason string is part of the base = clueResponseType]
The= text quoted here could be read as implying that the reason string = is
required in = the 'ack' = message, a stronger requirement than of the base
clueResponseType = where it has minOccurs=3D0.  Some greater clarity in the
text here is = probably called for, especially since when the 'ack' is
piggybacked on a = 'configure' message, there is no provision for a reason
string at = all. 

[SPR] Right. Modified as follows: "the 'ack' contains = a
   = response code and may contain a reason string for describing the = processing
   result of the 'advertisement'".

[KADUK]

Section 5.5

   =                     =       The <ack> element MUST NOT be present if = an
   = 'ack' = message has been already sent back to the MP.

I = think you need to clarify that this is scoped to the current
advSequenceNr.

[SPR] Right. Modified = accordingly.

[KADUK]

Section = 5.6

                 =                     =         It contains (Figure 8) a
   = response code with a reason string indicating either the success = or 
   the failure (along with failure details) of a = 'configure' request
   processing.  [...]

[Same comment about reason string as for 'ack']

[SPR] Same fix as per above.

[KADUK]

Section 5.7

   

   Such new response codes MUST NOT = overwrite the ones here defined and
   they MUST respect the semantics of the = first code digit.

nit: is this "overwrite" or "override"?

[SPR] "Override", thanx for spotting that out.

  

[KADUK]

   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.

   

This text seems to = also preclude extensions to major version '1' from
defining 1xx or = [5-9]xx reason codes; is that the intent?

[SPR] Yes, it is. Extensions can indeed define new pieces of = information to be carried within existing CLUE messages; 
though, they must = provide their own schema and be defined in the framework of external = namespaces.

[KADUK]

Section 6

   When the CLUE data channel = set up starts ("start channel"), the CP
   moves from the IDLE state to the = CHANNEL SETUP state.

nit: only one of "sets up" and "starts" is = needed.

[SPR] Fixed. 

[KADUK]

   When in the ACTIVE state, the CP starts the = envisioned sub-state
   machines (i.e., the MP state machine and the MC = state machine)
   according to the roles it plays in the telepresence = sessions.  Such
   roles have been previously declared in the = 'options' and
   'optionsResponse' messages involved in the = initiation phase (see
   OPTIONS sections Section 5.1 and Section 5.2 for = the details).  [...]

   

My reading of the initiation phase is that each CP = sends only a boolean
indication of whether it supports the MP/MC roles, and so = each party has to
determine on its own whether it will act as a MP and/or MC; = is that
correct? = If so, do we need to say anything about how the boolean = matrix
translates = to activating the respective sub-state machines?

[SPR] Are you suggesting that we remove the second part of = the sentence from there?

[KADUK]

Section = 6.1

                 =         'configure+ack' messages referring to = out-of-
   = date (i.e., having a sequence number equal to or less than the
   = highest seen so far) advertisements MUST be ignored, i.e., they = do
   = not trigger any state transition.  [...]

Is = this really less than or equal or just less than?  Also, is "seen" = the
right verb, = since IIUC these are sequence numbers that the MP has
*generated* in its = advertisements?

[SPR] Good catch. Both comments are valid. Text = modified accordingly.

[KADUK]

Section = 7

                =                     =                     =   In other
   words, in this example, the MP MUST use version = 1.4 and downgrade to
   the lower version.  = [...]

nit: does the phrase "and downgrade to the = lower version" add any value
here?  The word "downgrade" can have negative connotations in = some other
contexts, so if it's not adding value I'd suggest avoiding = it.

[SPR] Agreed.

[KADUK]

Section = 8

   As reported in Figure 13, the values of the = fields of the <extension>
   element (either new information or new = messages) take the following
   values:
[...]
   o  the major standard version of the = protocol that the extension
      refers to.

The XSL includes a full version (including minor), even = though the
semantics basically only use the major version.  That = said, why is the
'version' element minOccurs=3D"0" -- what are the semantics = when it is
absent?

[SPR] You're right. We removed the minoccurs=3D"0" = from both "schemaRef" and "version".

[KADUK]

Section 8.1

   The CLUE data model = document ([I-D.ietf-clue-data-model-schema])
   envisions the possibility = of adding this kind of "extra" information
   in the description of a = video capture by keeping the compatibility
   with the CLUE data model = schema.  [...]

nit: I don't think this is grammatical; = maybe just "keeping compatibility".

[SPR] We removed = "by keeping compatibility..." from the sentence.

[KADUK]

Section 10

This claims to be = a "call flow" example, but the described flows only
contain a single = unidirectional media flow, which is not really consistent
with the normal = usage of the word "call".  Buried in the body text there = is
a = disclaimer:
   [...]            =           For the sake of simplicity, the = following
   call flow focuses only on the dialogue between = MP CP1 and MC CP2.
I = would suggest making the presence of this simplification much = clearer
from the = start, perhaps "CLUE protocol messages exchanged in the = following
call flow are detailed; only one direction of media is shown = for
simplicity, = as the other direction is precisely symmetric".

[SPR] Fixed.

[KADUK]

   CP2 = acknowledges the second 'advertisement' message with an 'ack'
   = message (Section 10.7).

   In a second moment, CP2 = changes the requested media streams from CP1
   by sending to CP1 a = 'configure' message replacing the previously
   selected video streams = with the new composed media streams advertised
   by CP1 (Section = 10.8).

This might be an appropriate place to indicate that media = from the previous
configuration continue to flow during the reconfiguration = process.

[SPR] Done.

[KADUK]

It might also be worth noting again somewhere in here (or a = subsection)
that there are three (well, two, since we only show one = direction of media)
distinct sequence number spaces per sender, and that the = discontinuity
between Section 10.2 and 10.3's numbers is correct.

[SPR] Done

[KADUK]

Section = 11

Thanks for the well-thought-through security considerations; = in combination
with the linked documents (particularly the framework), they = cover all the
considerations (especially privacy considerations) that I had = in mind.

[SPR] Thanx!


[KADUK]

Section 14.2

We appear to be = citing both 5117 and 7667, whereas the latter obsoletes the
former.

[SPR] Fixed.



      =                 =      =        _\\|//_
      =                     =   =    ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
      =                     =                     =                     =      (_/



Il giorno 19 nov 2018, alle ore 19:25, Benjamin Kaduk <kaduk@mit.edu> ha = scritto:

Benjamin Kaduk has entered the following ballot position = for
draft-ietf-clue-protocol-17: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/<= br class=3D"">


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for the generally clear and = well-written document!
I would like to discuss whether = there needs to be more prominent coverage
of = timers/timeouts, especially as relating to the state machines. =  (I'd be happy
to learn that this is well-covered = elsewhere in the document set; I just haven't
run into it = yet.)

In a similar vein, do we want to have = any treatment of avoiding infinite loops
(e.g., when a = 'configure' or 'advertisement' is rejected in expectation of = modification
but the sending implementation continues to = generate an identical message)?

It is not = clear to me that any change to the document text is needed in either = case,
but I don't know to what extent the topics have = already been discussed.


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I also have some substantial = comments that do not rise to Discuss-level.

How do I know which endpoint is the channel initiator and = which is the
channel receiver?
draft-ietf-clue-signaling suggests that the DTLS client is = the channel
initiator, but even that is not explicit about = it -- the protocol could be
considered under-specified if = there is insufficient clarity.

Section 2

The MCU definition doesn't actually expand the = acronym, which seems a
little reader-unfriendly.

Section 5.1

There = are perhaps more XML extension points in here than is reasonable for
some of these elements (e.g., <versionsListType>).

Section 5.2

=             &n= bsp;           &nbs= p; If the responseCode is between 200 and 299
=   inclusive, the response MUST also include = <mediaProvider>,
  <mediaConsumer>, = <version> and <commonExtensions> elements;

Maybe re-mention that MP and MC are booleans here.

  Finally, the commonly supported = extensions are copied in the
=   <commonExtensions> field.

Does this need to say that only extensions that are = applicable to the
negotiated protocol version are = included?  (Also, how does one handle an
extension = that exists for multiple major versions -- are there two
<extension> elments for it in the <options> = message?)

  Upon reception of = the 'optionsResponse' the version to be used is the
=   one provided in the <version> tag of the message. =  The following CLUE
  messages MUST use = such a version number in the "v" attribute.  The
=   allowed extensions in the CLUE dialogue are those indicated = in the
  <commonExtensions> of the = 'optionsResponse' message.

Couldn't this = restriction on the "v" value apply even to the
'optionsResponse' message?

Section= 5.3

  The 'advertisement' = message is used by the MP to advertise the
=   available media captures and related information to the MC. =  [...]

I'd consider avoiding the = definite article "the" to refer to MP/MC roles,
since in = many caess there will be 2+ of each, and we don't want to confuse
the reader into thinking that there is an MP/CR equivalence = or something
like that.  So, perhaps "each MP" and = "the corresponding MC".

Section 5.4

=             &n= bsp;           &nbs= p;   As it can be seen from the message schema
  provided in the following excerpt (Figure 6), = the 'ack' contains a
  response code and a = reason string for describing the processing
=   result of the 'advertisement'.  [...]

[the reason string is part of the base clueResponseType]
The text quoted here could be read as implying that the = reason string is
required in the 'ack' message, a stronger = requirement than of the base
clueResponseType where it has = minOccurs=3D0.  Some greater clarity in the
text here = is probably called for, especially since when the 'ack' is
piggybacked on a 'configure' message, there is no provision = for a reason
string at all.

Section 5.5

=             &n= bsp;           &nbs= p;   The <ack> element MUST NOT be present if an
  'ack' message has been already sent back to the = MP.

I think you need to clarify that this = is scoped to the current
advSequenceNr.

Section 5.6

=             &n= bsp;           &nbs= p;            =        It contains (Figure 8) a
  response code with a reason string indicating = either the success or
  the failure (along with = failure details) of a 'configure' request
=   processing.  [...]

[Same = comment about reason string as for 'ack']

Section 5.7

  Such = new response codes MUST NOT overwrite the ones here defined and
  they MUST respect the semantics of the first = code digit.

nit: is this "overwrite" or = "override"?

  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.

This text seems to = also preclude extensions to major version '1' from
defining = 1xx or [5-9]xx reason codes; is that the intent?

Section 6

  When the = CLUE data channel set up starts ("start channel"), the CP
=   moves from the IDLE state to the CHANNEL SETUP state.

nit: only one of "sets up" and "starts" is = needed.

  When in the ACTIVE = state, the CP starts the envisioned sub-state
=   machines (i.e., the MP state machine and the MC state = machine)
  according to the roles it plays in = the telepresence sessions.  Such
  roles = have been previously declared in the 'options' and
=   'optionsResponse' messages involved in the initiation phase = (see
  OPTIONS sections Section 5.1 and Section = 5.2 for the details).  [...]

My = reading of the initiation phase is that each CP sends only a boolean
indication of whether it supports the MP/MC roles, and so = each party has to
determine on its own whether it will act = as a MP and/or MC; is that
correct?  If so, do we = need to say anything about how the boolean matrix
translates= to activating the respective sub-state machines?

Section 6.1

=             &n= bsp;           'con= figure+ack' messages referring to out-of-
=   date (i.e., having a sequence number equal to or less than = the
  highest seen so far) advertisements MUST = be ignored, i.e., they do
  not trigger any = state transition.  [...]

Is this = really less than or equal or just less than?  Also, is "seen" = the
right verb, since IIUC these are sequence numbers that = the MP has
*generated* in its advertisements?

Section 7

=             &n= bsp;           &nbs= p;            =             &n= bsp;       In other
=   words, in this example, the MP MUST use version 1.4 and = downgrade to
  the lower version. =  [...]

nit: does the phrase "and = downgrade to the lower version" add any value
here? =  The word "downgrade" can have negative connotations in some = other
contexts, so if it's not adding value I'd suggest = avoiding it.

Section 8

  As reported in Figure 13, the values of the = fields of the <extension>
  element = (either new information or new messages) take the following
=   values:
[...]
  o =  the major standard version of the protocol that the extension
     refers to.

The XSL includes a full version (including minor), even = though the
semantics basically only use the major version. =  That said, why is the
'version' element = minOccurs=3D"0" -- what are the semantics when it is
absent?

Section 8.1

  The CLUE data model document = ([I-D.ietf-clue-data-model-schema])
  envisions = the possibility of adding this kind of "extra" information
=   in the description of a video capture by keeping the = compatibility
  with the CLUE data model = schema.  [...]

nit: I don't think this = is grammatical; maybe just "keeping compatibility".

Section 10

This claims to be a = "call flow" example, but the described flows only
contain = a single unidirectional media flow, which is not really consistent
with the normal usage of the word "call".  Buried in the = body text there is
a disclaimer:
=   [...] =             &n= bsp;        For the sake of = simplicity, the following
  call flow focuses = only on the dialogue between MP CP1 and MC CP2.
I would = suggest making the presence of this simplification much clearer
from the start, perhaps "CLUE protocol messages exchanged in = the following
call flow are detailed; only one direction = of media is shown for
simplicity, as the other direction = is precisely symmetric".

  CP2 = acknowledges the second 'advertisement' message with an 'ack'
  message (Section 10.7).

  In a second moment, CP2 changes the requested = media streams from CP1
  by sending to CP1 a = 'configure' message replacing the previously
=   selected video streams with the new composed media streams = advertised
  by CP1 (Section 10.8).

This might be an appropriate place to indicate = that media from the previous
configuration continue to = flow during the reconfiguration process.

It = might also be worth noting again somewhere in here (or a subsection)
that there are three (well, two, since we only show one = direction of media)
distinct sequence number spaces per = sender, and that the discontinuity
between Section 10.2 = and 10.3's numbers is correct.

Section = 11

Thanks for the well-thought-through = security considerations; in combination
with the linked = documents (particularly the framework), they cover all the
considerations (especially privacy considerations) that I had = in mind.

Section 14.2

We appear to be citing both 5117 and 7667, whereas the latter = obsoletes the
former.


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue


= --Apple-Mail=_B216C493-80EB-4851-B9F7-7FC902266DEC-- From nobody Thu Jul 4 05:24:17 2019 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 22C2512061C; Thu, 4 Jul 2019 05:24:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1NK2bmhpQT9l; Thu, 4 Jul 2019 05:24:03 -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 F35CF120698; Thu, 4 Jul 2019 05:23:52 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id x64CNodm029554-x64CNodo029554 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:23:50 +0200 Received: from [10.20.1.250] (iw452509.net.t-com.hr [195.29.56.30]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id x64CNnf8031279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jul 2019 14:23:50 +0200 From: Simon Pietro Romano Message-Id: <9B3D3D3F-2C32-43FF-98E8-E57B35530F60@unina.it> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB19869F-3B26-4305-8516-C6A796484BE3" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 4 Jul 2019 14:23:48 +0200 In-Reply-To: <154268515769.26665.4530527657139603206.idtracker@ietfa.amsl.com> Cc: The IESG , clue-chairs@ietf.org, clue@ietf.org, draft-ietf-clue-protocol@ietf.org To: Ben Campbell References: <154268515769.26665.4530527657139603206.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-protocol-17: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 12:24:08 -0000 --Apple-Mail=_AB19869F-3B26-4305-8516-C6A796484BE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Ben! You=E2=80=99ll find below our hyper-delayed answers (preceded = by [SPR]) to your comments. Thanks once again for your support and advice, Simon & Roberta (Ben Campbell) Discuss Discuss (2018-11-19) [BEN]=20 Thanks for all the work on this over the years. I have a few concerns = that I think require discussion prior to publication: =C2=A75.7: Is the "description" field expected to be human readable? If = so, are there internationalization issues to consider? [SPR] We were not thinking of any internationalization-specific issues = for this field. [BEN] =C2=A76.2, 5th paragraph: This says that if you get an error back for a = configure message, you send a new configure message. This seems likely = to cause an infinite loop unless some guidance is given about escaping = the loop when the endpoints cannot agree on a configuration. [SPR] As per our answer to Kaduk's DISCUSS, generally speaking timeouts = and retransmissions have been completely removed from the current = version of the protocol draft, based on the discussions that we had on = the WG mailing list. The draft has now become "Experimental" just = because of that. Coming to the specific case mentioned above (sending = back a new Configure upon reception of an error message associated with = a previous Configure), our guess is that one might try and modify the = new Configure based on the feedback received in the error message = itself, so to avoid incurring in the exact same situation over and over = again. Obviously, after a number of tries (whose value might depend on = the specific CLUE implementation and logic) the peer in question should = throw in the towel and tear down the session setup process. [BEN] =C2=A77: I=E2=80=99m confused by the versioning mechanisms. This = section requires an endpoint to ignore unknown elements, but it also = requires the peer to downgrade to the highest shared version. These = requirements seem to be at cross purposes. If the peer downgrades, one = should only see unknown elements in the case of implementation errors. = The requirement to ignore unknown elements does not come for free; nor = does the requirement to downgrade. [SPR] Here we were making the difference between the sending and = receiving behaviors, coherently with RFC1122. We do know that = flexibility never comes for free. Do you think we should be remove that = part? [BEN] =C2=A75.1 and =C2=A78: The use of the options message to negotiate = extensions seems underspecified. How does an endpoint compare = extensionType elements? Is a spec required or expected? Is the = extension spec expected to register the URI for schemaRef somewhere? = Does this need to be in IANA? Comment (2018-11-19) [SPR] We clearly state that extensions need to be accompanied by the = following pieces of information: name; external XML Schema defining the = XML information and/or the XML messages representing the extension; = major standard version of the protocol that the extension refers to. = Isn't this enough to guarantee that the mechanism works? Should we add = something else? [BEN] I've got a number of additional comments that do not seem to rise to the = level of a DISCUSS: *** Substantive Comments *** I support Benjamin Kaduk's DISCUSS.=20 [SPR] We tried to address Kaduk's DISCUSS and COMMENTS. [BEN] Additionally, I think there's some missing sub-transaction states, at = least in the state machine in Figure 10. When an endpoint sends a = message and is waiting for a response, shouldn't there be a separate = waiting state (for example, when waiting for optionsResponse)? The MP = and MC state machines include this sort of thing but the initial state = machine does not. Also, I wonder if there are some unhandled cases where = a configure and advertise message cross on the wire. [SPR] Please see our answer to your first DISCUSS comment. In its = current status, the draft does not aim at presenting each and every = possible protocol situation (corner cases included).=20 [BEN] - =C2=A71 ( also =C2=A72, definition of "endpoint"): I'd like to see a few more words about the relationship between this, = the framework draft, the datachannel draft, and SIP. Am I correct to = understand that is the only environment the protocol is ever expected to = operate in? That is, is there room for different signaling protocols, = different transports, etc? This also impacts the security = considerations. For example if this depends on the security properties = of datachannels (over SCTP and DTLS), then it's worth some language to = the effect that it MUST not be used on other transports, or that if it = is used on other transports they must have similar security properties. [SPR] The idea is that it is being specified on top of the mentioned = protocols. Though, I personally don't see any major issue in = implementing the CLUE protocol on top of alternative transports. = Obviously, in those cases the security considerations would differ from = the ones we are making now in the draft. [BEN] =C2=A72, definition of endpoint: Please cite RFC3261 for SIP. (I have = mixed feelings whether this needs to be normative or informational.) [SPR] Done (as informative). [BEN] =C2=A74: - "a lack of interoperability between the protocol implementations. In order to correctly establish a CLUE dialogue, the involved CPs MUST have in common a major version number" That seems like a statement of fact. I suggest reserving the normative = keywords for the actual procedures that require this. [SPR] "MUST" has now become "must". [BEN] =C2=A75: - ClueID: Is this truly optional in the sence of never required under = any circumstances? [SPR] This is what we had in mind. Do you envisage issues with this? [BEN] - sequenceNr: Is the language about incrementing intended to use = normative keywords? (e.g MUST)? [SPR] Yep. They have been capitalized in the new version of the draft. [BEN] Why do implementations need to send errors for unexpected sequence = numbers when using a reliable protocol? That would only happen in the = case of implementation errors, right? [SPR] Right. [BEN] Why is it optional to start with a random sequence number? Is there a = concern about fingerprinting if people choose otherwise? (I guess as the = security considerations mention, there's a lot of other things to = fingerprint.) [SPR] There might obviously be concerns about fingerprinting if the = initial sequence number is not random. We were not thinking of mandating = a random choice, though. Should we modify the document in that sense? [BEN] - Protocol field: Do you envision non-CLUE messages will ever occur on = the same SCTP association? if not, then why require this? If so, then = what should an endpoint do if it gets a message with something other = than "clue" here? [SPR] The idea was exactly not to prevent implementations from = leveraging the same SCTP association for the exchanging of non-CLUE = messages. The management of non-CLUE messages would in such a case be = left to the specific implementation. [BEN] =C2=A75.1: "since minor versions are defined to be both backwards and forwards compatible," Please see related DISCUSS comment. [SPR] See our answer to the DISCUSS comment. [BEN] =C2=A75.7:=20 - What is the reason for defining meaning the "100" response code range = if no codes in that range are defined? Why is this different from the = 500-900 ranges that are merely reserved for future use? (I gather there = was an intent to be consistent with SIP error codes, but why not leave = that to the first spec that defines a 1XX code, assuming that ever = happens? [SPR] We wanted to clearly state that the range in question should be = used, for coherence with companion approaches/protocols, for dealing = with either delayed or incomplete operations. We can remove that = requirement, if you deem it worth. [BEN] - "message. Implementations can (and are encouraged to) include more specific descriptions of the error condition, if possible." Am I correct to assume that implementations should not expect any = particular description text for a given error code? (That used to be a = common interop problem for SIP.) [SPR] Yep. We're not mandating this to happen. [BEN] =C2=A76: - "When the CLUE data channel set up starts ("start channel"), the CP moves from the IDLE state to the CHANNEL SETUP state." What does "set up starts" mean? Is this trigged by SDP signaling? SCTP = connection? Is it different for the SCTP client and server? (I suspect = the data-channel draft answers this, but it should at least be cited = here.) [SPR] See our answer to Kaduk's similar comment about channel initiator = and channel receiver. [BEN] =C2=A76.1: - "Finally, if there are changes in the MP=E2=80=99s telepresence settings ("changed telepresence = settings"), the MP switches to the ADV state." If I understand correctly, the MC can send new configure messages at any = time. What happens if one arrives in the ADV state but before sending = the advertise? [SPR] If I am a MP and my telepresence settings change, I move to the = "ADV" state and prepare a new Advertisement to be sent to the MC. If a = Configure arrives from the MC while I am preparing the new Advertisement = message, I will stay in the ADV state. Once the new Advertisement is = ready I will move to the "WAIT FOR ACK" state. The MC on the other side = of the channel will eventually receive my new Advertisement and prepare = either an Acknowledgement message or a Configure+Acknowledgement = message. [BEN] 6.2, 2nd paragraph:=20 - Is the MC forbidden from sending a configure without the ack field = set prior to sending an ack? [SPR] We're not mandating this explicitly. Though, if I send a Configure = prior to the Acknowledgement message, the other peer will simply = disregard it, since it will be in the "WAIT FOR ACK" state. [BEN] - Is the response code limited to 200, are or other 2XX codes allowed if = defined? [SPR] They are allowed, if defined. [BEN] =C2=A712.3: The mime type isn=E2=80=99t mentioned anywhere else in the = doc? Why is it registered here? What is it used for? [SPR] It is indeed not used elsewhere in the document and might be = removed from the draft with no harm. It would definitely be needed just = in cases like, e.g., CLUE encapsulation inside HTTP. Since the draft is = not proposing that, we can remove the mime type registration section = from the document. Is this what you are proposing? [BEN] =C2=A712.4.1: Why is it necessary to both register these directly in = IANA and define them in a (presumably registered) schema? Am I correct = to assume new message types must also be defined in a schema? [SPR] Are you suggesting to just keep the messages definitions embedded = in the (to-be-registered) schema, while removing from the draft the = request for also registering them inside IANA? You're certainly more = expert than us on this kind of issues, so we'll take your advice. *** Editorial Comments *** [BEN] - General: -- Please proofread for "which" vs "that" usage. [SPR] Wi did that in the new version of the draft. Hope the two terms = are now employed more properly. [BEN] -- Please proofread for null words, especially "obviously" and similar = terms, which some readers might read as condescending. [SPR] Done. [BEN - Abstract: Is CLUE an acronym? If so, what is its expansion? (If the = title is the expansion, it's very obscure.). If not, why all-caps? [SPR] I believe we discussed this extensively on the list. As far as I = can tell, CLUE is "officially" expanded as follows: "ControLling mUltiple streams for tElepresence". We agreed on using = all-caps CLUE in all our documents. [BEN] =C2=A72: Please expand MCU on first mention. [SPR] Done. [BEN] =C2=A74: - "The subset of the extensions that are allowed within the CLUE session is also determined in the = initiation phase, such subset being the one including only the = extensions that are supported by both parties" Convoluted sentence, can it be simplified? [SPR] Done [BEN] - "Hence in a call between two CPs, A and B, there would be two separate dialogs, as follows:" Please define the meaning of "dialog" as used in this document. In = particular, that it is not related to SIP's usage of the term. [SPR] Done. We replaced "dialogs" with "message exchange sequences". = Hope this works. [BEN] =C2=A75: "While the =E2=80=99options=E2=80=99 and =E2=80=99optionsResponse=E2=80=99= messages are exchanged in the initiation phase between the CPs, the other messages are involved in MP-MC dialogues." This also needs a definition of "dialog" for the meaning to be clear. [SPR] Done. [BEN] =C2=A75.5:=20 - "The MC can send a =E2=80=99configure=E2=80=99 after the reception of an = =E2=80=99advertisement=E2=80=99 or each time it wants to request other captures that have been previously advertised by the MP." The use of "can" makes this seem optional. I gather from the state = machine this is not the case. [SPR] Right. This has become a MUST. [BEN] - "It indicates that the =E2=80=99configure=E2=80=99 message also acknowledges with success the referred advertisement (=E2=80=99configure=E2=80=99 + =E2=80=99ack=E2=80=99 message), by = applying in that way a piggybacking mechanism for simultaneously acknowledging and replying to the =E2=80=99advertisement=E2=80=99 message." Convoluted sentence. [SPR] Modified by removing the piggybacking part. [BEN] 5.7: - "200, 300 and 400 codes are considered catch-alls." Please elaborate on what "catch-all" means in context. [SPR] Replaced "catch-alls" with "the most generic ones in their = respective categories." [BEN] - "Further response codes can be either defined in future versions of the protocol (by adding them to the related IANA registry)..." The parenthetical phrase is redundant to the next sentence. [SPR] Removed. [BEN] =C2=A76:=20 - First Paragraph: The first and last sentences are redundant with = earlier text in the draft. Should "MC process" and "MP process" be "MC = role" and "MP role"? [SPR] Modified (replaced process with role). [BEN] =C2=A76.1, 3rd paragrap: The first sentence seems out of place, given = that much of the previous paragraph was about what happens in the WAIT = FOR CONF state. [SPR] Didn't get this one, sorry. [BEN] - 5th paragraph: "If there are changes in the MP=E2=80=99s telepresence settings ("changed telepresence settings"), the MP moves back to the ADV state." Redundant to previous paragraph. [SPR] We are indeed reiterating on that, since the event in question = ("changed telepresence settings) is common to the four states (WAIT FOR = ACK, WAIT FOR CONF, CONF RESPONSE and ESTABLISHED) discussed in the = section. [BEN] =C2=A78.1, 2nd paragraph: The second sentence is redundant to similar = text in =C2=A78. [SPR] Removed. _\\|//_ ( 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > Il giorno 20 nov 2018, alle ore 04:39, Ben Campbell = ha scritto: >=20 > Ben Campbell has entered the following ballot position for > draft-ietf-clue-protocol-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > Thanks for all the work on this over the years. I have a few concerns = that I > think require discussion prior to publication: >=20 > =C2=A75.7: Is the "description" field expected to be human readable? = If so, are > there internationalization issues to consider? >=20 > =C2=A76.2, 5th paragraph: This says that if you get an error back for = a configure > message, you send a new configure message. This seems likely to cause = an > infinite loop unless some guidance is given about escaping the loop = when the > endpoints cannot agree on a configuration. >=20 > =C2=A77: I=E2=80=99m confused by the versioning mechanisms. This = section requires an > endpoint to ignore unknown elements, but it also requires the peer to = downgrade > to the highest shared version. These requirements seem to be at cross = purposes. > If the peer downgrades, one should only see unknown elements in the = case of > implementation errors. The requirement to ignore unknown elements does = not come > for free; nor does the requirement to downgrade. >=20 > =C2=A75.1 and =C2=A78: The use of the options message to negotiate = extensions seems > underspecified. How does an endpoint compare extensionType elements? = Is a spec > required or expected? Is the extension spec expected to register the = URI for > schemaRef somewhere? Does this need to be in IANA? >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > I've got a number of additional comments that do not seem to rise to = the level > of a DISCUSS: >=20 > *** Substantive Comments *** >=20 > I support Benjamin Kaduk's DISCUSS. >=20 > Additionally, I think there's some missing sub-transaction states, at = least in > the state machine in Figure 10. When an endpoint sends a message and = is waiting > for a response, shouldn't there be a separate waiting state (for = example, when > waiting for optionsResponse)? The MP and MC state machines include = this sort of > thing but the initial state machine does not. Also, I wonder if there = are some > unhandled cases where a configure and advertise message cross on the = wire. >=20 > - =C2=A71 ( also =C2=A72, definition of "endpoint"): > I'd like to see a few more words about the relationship between this, = the > framework draft, the datachannel draft, and SIP. Am I correct to = understand > that is the only environment the protocol is ever expected to operate = in? That > is, is there room for different signaling protocols, different = transports, etc? > This also impacts the security considerations. For example if this = depends on > the security properties of datachannels (over SCTP and DTLS), then = it's worth > some language to the effect that it MUST not be used on other = transports, or > that if it is used on other transports they must have similar security > properties. >=20 > =C2=A72, definition of endpoint: Please cite RFC3261 for SIP. (I have = mixed feelings > whether this needs to be normative or informational.) >=20 > =C2=A74: > - "a lack of interoperability between the > protocol implementations. In order to correctly establish a CLUE > dialogue, the involved CPs MUST have in common a major version number" >=20 > That seems like a statement of fact. I suggest reserving the normative = keywords > for the actual procedures that require this. >=20 > =C2=A75: > - ClueID: Is this truly optional in the sence of never required under = any > circumstances? - sequenceNr: Is the language about incrementing = intended to use > normative keywords? (e.g MUST)? Why do implementations need to send = errors for > unexpected sequence numbers when using a reliable protocol? That would = only > happen in the case of implementation errors, right? Why is it optional = to start > with a random sequence number? Is there a concern about fingerprinting = if > people choose otherwise? (I guess as the security considerations = mention, > there's a lot of other things to fingerprint.) >=20 > - Protocol field: Do you envision non-CLUE messages will ever occur on = the same > SCTP association? if not, then why require this? If so, then what = should an > endpoint do if it gets a message with something other than "clue" = here? >=20 > =C2=A75.1: "since minor versions are > defined to be both backwards and forwards compatible," > Please see related DISCUSS comment. >=20 > =C2=A75.7: >=20 > - What is the reason for defining meaning the "100" response code = range if no > codes in that range are defined? Why is this different from the = 500-900 ranges > that are merely reserved for future use? (I gather there was an intent = to be > consistent with SIP error codes, but why not leave that to the first = spec that > defines a 1XX code, assuming that ever happens? >=20 > - "message. Implementations can (and are encouraged to) > include more specific descriptions of the error condition, if > possible." >=20 > Am I correct to assume that implementations should not expect any = particular > description text for a given error code? (That used to be a common = interop > problem for SIP.) >=20 > =C2=A76: > - "When the CLUE data channel set up starts ("start channel"), the CP > moves from the IDLE state to the CHANNEL SETUP state." >=20 > What does "set up starts" mean? Is this trigged by SDP signaling? SCTP > connection? Is it different for the SCTP client and server? (I suspect = the > data-channel draft answers this, but it should at least be cited = here.) >=20 > =C2=A76.1: > - "Finally, if there are changes > in the MP=E2=80=99s telepresence settings ("changed telepresence = settings"), > the MP switches to the ADV state." > If I understand correctly, the MC can send new configure messages at = any time. > What happens if one arrives in the ADV state but before sending the = advertise? >=20 > 6.2, 2nd paragraph: > - Is the MC forbidden from sending a configure without the ack field = set prior > to sending an ack? - Is the response code limited to 200, are or other = 2XX > codes allowed if defined? >=20 > =C2=A712.3: The mime type isn=E2=80=99t mentioned anywhere else in the = doc? Why is it > registered here? What is it used for? >=20 > =C2=A712.4.1: Why is it necessary to both register these directly in = IANA and define > them in a (presumably registered) schema? Am I correct to assume new = message > types must also be defined in a schema? >=20 > *** Editorial Comments *** >=20 > - General: > -- Please proofread for "which" vs "that" usage. > -- Please proofread for null words, especially "obviously" and similar = terms, > which some readers might read as condescending. >=20 > - Abstract: Is CLUE an acronym? If so, what is its expansion? (If the = title is > the expansion, it's very obscure.). If not, why all-caps? >=20 > =C2=A72: Please expand MCU on first mention. >=20 > =C2=A74: > - "The subset of the extensions > that are allowed within the CLUE session is also determined in the = initiation > phase, such subset being the one including only the extensions that = are > supported by both parties" Convoluted sentence, can it be simplified? >=20 > - "Hence in a call between two > CPs, A and B, there would be two separate dialogs, as follows:" > Please define the meaning of "dialog" as used in this document. In = particular, > that it is not related to SIP's usage of the term. >=20 > =C2=A75: > "While the =E2=80=99options=E2=80=99 and =E2=80=99optionsResponse=E2=80=99= messages are exchanged in > the initiation phase between the CPs, the other messages are involved > in MP-MC dialogues." > This also needs a definition of "dialog" for the meaning to be clear. >=20 > =C2=A75.5: >=20 > - "The MC can send a > =E2=80=99configure=E2=80=99 after the reception of an = =E2=80=99advertisement=E2=80=99 or each time it > wants to request other captures that have been previously advertised > by the MP." > The use of "can" makes this seem optional. I gather from the state = machine this > is not the case. >=20 > - "It indicates that the =E2=80=99configure=E2=80=99 > message also acknowledges with success the referred advertisement > (=E2=80=99configure=E2=80=99 + =E2=80=99ack=E2=80=99 message), by = applying in that way a piggybacking > mechanism for simultaneously acknowledging and replying to the > =E2=80=99advertisement=E2=80=99 message." > Convoluted sentence. >=20 > 5.7: > - "200, 300 and 400 codes are considered catch-alls." > Please elaborate on what "catch-all" means in context. >=20 > - "Further response codes can be either defined > in future versions of the protocol (by adding them to the related > IANA registry)..." > The parenthetical phrase is redundant to the next sentence. >=20 > =C2=A76: >=20 > - First Paragraph: The first and last sentences are redundant with = earlier text > in the draft. Should "MC process" and "MP process" be "MC role" and = "MP role"? >=20 > =C2=A76.1, 3rd paragrap: The first sentence seems out of place, given = that much of > the previous paragraph was about what happens in the WAIT FOR CONF = state. >=20 > - 5th paragraph: "If there are > changes in the MP=E2=80=99s telepresence settings ("changed = telepresence > settings"), the MP moves back to the ADV state." > Redundant to previous paragraph. >=20 > =C2=A78.1, 2nd paragraph: The second sentence is redundant to similar = text in =C2=A78. >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --Apple-Mail=_AB19869F-3B26-4305-8516-C6A796484BE3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Ben! You=E2=80=99ll find below our hyper-delayed answers (preceded by = [SPR]) to your comments.

Thanks once again for your support and advice,

Simon & = Roberta

(Ben Campbell)
Discuss
Discuss (2018-11-19)

[BEN] 

Thanks for all the work on this over = the years. I have a few concerns that I think require discussion prior = to publication:

=C2=A75.7: Is the "description" field expected to be = human readable? If so, are there internationalization issues to = consider?

[SPR] We were not thinking of any = internationalization-specific issues for this field.

[BEN]

=C2=A76.2, 5th paragraph: This says that if you get = an error back for a configure message, you send a new configure message. = This seems likely to cause an infinite loop unless some guidance is = given about escaping the loop when the endpoints cannot agree on a = configuration.

[SPR] As per our answer to Kaduk's DISCUSS, = generally speaking timeouts and retransmissions have been completely = removed from the current version of the protocol draft, based on the = discussions that we had on the WG mailing list. The draft has now become = "Experimental" just because of that. Coming to the specific case = mentioned above (sending back a new Configure upon reception of an error = message associated with a previous Configure), our guess is that one = might try and modify the new Configure based on the feedback received in = the error message itself, so to avoid incurring in the exact same = situation over and over again. Obviously, after a number of tries (whose = value might depend on the specific CLUE implementation and logic) the = peer in question should throw in the towel and tear down the session = setup process.

[BEN]

=C2=A77:  I=E2=80=99m confused by = the versioning mechanisms. This section requires an endpoint to = ignore unknown elements, but it also requires the peer to downgrade to the = highest shared version. These requirements seem to be at cross purposes. = If the peer downgrades, one should only see unknown elements in = the case of implementation errors. The requirement to ignore unknown = elements does not come for free; nor does the requirement to downgrade.

[SPR] Here we were = making the difference between the sending and receiving behaviors, = coherently with RFC1122. We do know that flexibility never comes for = free. Do you think we should be remove that part?

[BEN]

=C2=A75.1 and =C2=A78: The use of the options = message to negotiate extensions seems underspecified. How does an endpoint compare = extensionType elements?  Is a spec required or expected? Is the extension = spec = expected to register the URI for schemaRef somewhere? Does this need to = be in IANA?
Comment (2018-11-19)

[SPR] We clearly = state that extensions need to be accompanied by the following pieces of = information: name; external XML Schema defining the XML information = and/or the XML messages representing the extension; major standard = version of the protocol that the extension refers to. Isn't this enough = to guarantee that the mechanism works? Should we add something = else?

[BEN]

I've got a number of additional comments that do not = seem to rise to the level of a DISCUSS:

*** Substantive = Comments ***

I support Benjamin Kaduk's DISCUSS. 

[SPR] We tried to address Kaduk's DISCUSS and = COMMENTS.

[BEN]

Additionally, I think there's some = missing sub-transaction states, at least in the state machine in Figure = 10. When an endpoint sends a message and is waiting for a = response, shouldn't there be a separate waiting state (for example, when = waiting for optionsResponse)? The MP and MC state machines include this = sort of thing but the initial state machine does not. Also, I wonder if = there are some unhandled cases where a configure and advertise = message cross on the wire.

[SPR] Please see our answer to your = first DISCUSS comment. In its current status, the draft does not aim at = presenting each and every possible protocol situation (corner cases = included). 

[BEN]

- =C2=A71 ( also =C2=A72, definition of = "endpoint"):
I'd like to see a few more words about the = relationship between this, the framework draft, the datachannel = draft, and SIP.  Am I correct to understand that is the only = environment the protocol is ever expected to operate in? That is, is = there room for different signaling protocols, different transports, etc? = This also impacts the security considerations. For example if this = depends on the security properties of datachannels (over SCTP and DTLS), then = it's worth some language to the effect that it MUST not be used on other = transports, or that if it is used on other transports they must have = similar security properties.

[SPR] The idea is = that it is being specified on top of the mentioned protocols. Though, I = personally don't see any major issue in implementing the CLUE protocol = on top of alternative transports. Obviously, in those cases the security = considerations would differ from the ones we are making now in the = draft.

[BEN]

=C2=A72, definition of endpoint: Please cite RFC3261 for SIP. (I = have mixed feelings whether this needs to be normative or = informational.)

[SPR] Done (as informative).

[BEN]

=C2=A74:
- "a lack of interoperability between the
protocol = implementations. In order to correctly establish a CLUE
dialogue, the = involved CPs MUST have in common a major version number"

That seems like a statement of fact. I suggest reserving the = normative = keywords for the actual procedures that require this.

[SPR] "MUST" has now become "must".

[BEN]

=C2=A75:
- ClueID: Is this truly optional in the sence of never = required under any circumstances?

[SPR] This is what = we had in mind. Do you envisage issues with this?

[BEN]

- sequenceNr: Is the language about incrementing = intended to use normative keywords? (e.g MUST)?

[SPR] Yep. They have been capitalized in the new version of = the draft.

[BEN]

Why do implementations need to send = errors for unexpected sequence numbers when using a reliable protocol? = That would only happen in the case of implementation errors, = right?

[SPR] Right.

[BEN]

Why is it optional = to start with a random sequence number? Is there a concern about fingerprinting if = people choose otherwise? (I guess as the security considerations = mention, there's a lot of other things to fingerprint.)

[SPR] There might obviously be concerns about fingerprinting if = the initial sequence number is not random. We were not thinking of = mandating a random choice, though. Should we modify the document in that = sense?


[BEN]

- Protocol field: = Do you envision non-CLUE messages will ever occur on the same SCTP = association? if not, then why require this? If so, then what should an = endpoint do = if it gets a message with something other than "clue" here?

[SPR] The idea was exactly not to prevent implementations = from leveraging the same SCTP association for the exchanging of non-CLUE = messages. The management of non-CLUE messages would in such a case be = left to the specific implementation.

[BEN]

=C2=A75.1: "since minor versions are
defined to be both backwards and = forwards compatible,"
Please see related DISCUSS comment.

[SPR] See our answer to the DISCUSS comment.

[BEN]

=C2=A75.7: 

- What is the = reason for defining meaning the "100" response code range if no codes in = that range are defined? Why is this different from the 500-900 ranges = that are merely reserved for future use? (I gather there was an intent = to be consistent with SIP error codes, but why not leave that to the = first spec = that defines a 1XX code, assuming that ever happens?

[SPR] We wanted to clearly state that the range in question = should be used, for coherence with companion approaches/protocols, for = dealing with either delayed or incomplete operations. We can remove that = requirement, if you deem it worth.

[BEN]

- "message. Implementations can (and are encouraged = to)
include more = specific descriptions of the error condition, if
possible."

Am I correct to assume that implementations should not expect = any particular description text for a given error code? (That used to be = a common interop problem for SIP.)

[SPR] Yep. We're not mandating this to happen.

[BEN]

=C2=A76:
- "When the CLUE data channel set up starts ("start = channel"), the CP
moves from the IDLE state to the CHANNEL SETUP = state."

What does "set up starts" mean? Is this trigged by SDP = signaling? SCTP connection? Is it different for the SCTP client and = server? (I suspect the data-channel draft answers this, but it should at = least be cited here.)

[SPR] See our answer to Kaduk's similar = comment about channel initiator and channel receiver.

[BEN]

=C2=A76.1:
- "Finally, if there are changes
in the MP=E2=80=99s = telepresence = settings ("changed telepresence settings"),
the MP switches to the ADV = state."
If I = understand correctly, the MC can send new configure messages at any = time. What happens if one arrives in the ADV state but before sending = the advertise?

[SPR] If I am a MP and my telepresence = settings change, I move to the "ADV" state and prepare a new = Advertisement to be sent to the MC. If a Configure arrives from the MC = while I am preparing the new Advertisement message, I will stay in the = ADV state. Once the new Advertisement is ready I will move to the "WAIT = FOR ACK" state. The MC on the other side of the channel will eventually = receive my new Advertisement and prepare either an Acknowledgement = message or a Configure+Acknowledgement message.

[BEN]

6.2, 2nd paragraph: 
-  Is the MC forbidden from = sending a configure without the ack field set prior to sending an ack?

[SPR] We're not mandating this explicitly. Though, if I send = a Configure prior to the Acknowledgement message, the other peer will = simply disregard it, since it will be in the "WAIT FOR ACK" = state.

[BEN]

- Is the response code limited to 200, are or other = 2XX codes allowed if defined?

[SPR] They are = allowed, if defined.

[BEN]

=C2=A712.3: The = mime type isn=E2=80=99t mentioned anywhere else in the doc? Why is it = registered here? What is it used for?

[SPR] It is indeed = not used elsewhere in the document and might be removed from the draft = with no harm. It would definitely be needed just in cases like, e.g., = CLUE encapsulation inside HTTP. Since the draft is not proposing that, = we can remove the mime type registration section from the document. Is = this what you are proposing?

[BEN]

=C2=A712.4.1: Why is it necessary to both register these = directly in IANA and define them in a (presumably registered) schema? Am = I correct to assume new message types must also be defined in a = schema?

[SPR] Are you suggesting to just keep the messages = definitions embedded in the (to-be-registered) schema, while removing = from the draft the request for also registering them inside IANA? You're = certainly more expert than us on this kind of issues, so we'll take your = advice.

*** Editorial Comments ***

[BEN]

- General:
-- Please proofread for "which" vs "that" usage.

[SPR] Wi did that in the new version of the draft. Hope the = two terms are now employed more properly.

[BEN]

-- Please proofread for null words, especially "obviously" and = similar terms, which some readers might read as condescending.

[SPR] Done.

[BEN

- Abstract: Is = CLUE an acronym? If so, what is its expansion? (If the title is the = expansion, it's very obscure.). If not, why all-caps?

[SPR] I believe we discussed this extensively on the list. As = far as I can tell, CLUE is "officially" expanded as follows:

"ControLling mUltiple streams for tElepresence". We agreed on = using all-caps CLUE in all our documents.

[BEN]

=C2=A72: Please expand MCU on first = mention.

[SPR] Done.

[BEN]

=C2=A74:
- "The subset of the extensions
that are allowed within the CLUE = session is also determined in the initiation phase, such subset being = the one including only the extensions that are supported by both = parties"
Convoluted sentence, can it be simplified?

[SPR] Done

[BEN]

- "Hence in a call = between two
CPs, A and B, there would be two separate dialogs, as = follows:"
Please define the meaning of "dialog" as used in this = document. In particular, that it is not related to SIP's usage of the = term.

[SPR] Done. We replaced "dialogs" with "message exchange = sequences". Hope this works.

[BEN]

=C2=A75:
"While the =E2=80=99options=E2=80=99 and = =E2=80=99optionsResponse=E2=80=99 messages are exchanged in
the initiation = phase between the CPs, the other messages are involved
in MP-MC = dialogues."
This also needs a definition of "dialog" for the meaning to = be clear.

[SPR] Done.

[BEN]

=C2=A75.5: 

- "The MC can send = a
=E2=80=99configure=E2= =80=99 after the reception of an =E2=80=99advertisement=E2=80=99 or each = time it
wants to = request other captures that have been previously advertised
by the = MP."
The use of = "can" makes this seem optional. I gather from the state machine this is = not the case.

[SPR] Right. This has become a MUST.

[BEN]

- "It indicates that the =E2=80=99configure=E2=80=99
message also = acknowledges with success the referred advertisement
(=E2=80=99configure=E2= =80=99 + =E2=80=99ack=E2=80=99 message), by applying in that way a piggybacking
mechanism for simultaneously acknowledging and = replying to the
=E2=80=99advertisement=E2=80=99 message."
Convoluted = sentence.

[SPR] Modified by removing the piggybacking = part.

[BEN]

5.7:
- "200, 300 and 400 codes are considered catch-alls."
Please elaborate = on what "catch-all" means in context.

[SPR] Replaced = "catch-alls" = with "the most generic ones in their respective categories."

[BEN]

- "Further response codes can be either = defined
in future = versions of the protocol (by adding them to the related
IANA = registry)..."
The= parenthetical phrase is redundant to the next sentence.

[SPR] Removed.

[BEN]

=C2=A76: 
=

- First Paragraph: The first and last sentences are redundant = with earlier text in the draft. Should "MC process" and "MP process" be = "MC role" and "MP role"?

[SPR] Modified (replaced process with = role).

[BEN]

=C2=A76.1, 3rd paragrap: The first sentence seems out of = place, given that much of the previous paragraph was about what happens = in the WAIT FOR CONF state.

[SPR] Didn't get = this one, sorry.

[BEN]

- 5th paragraph: "If there = are
changes in = the MP=E2=80=99s telepresence settings ("changed telepresence
settings"), the MP moves back to the ADV = state."
Redundant to = previous paragraph.

[SPR] We are indeed reiterating on = that, since the event in question ("changed telepresence = settings) is common to the four states (WAIT FOR ACK, WAIT FOR CONF, = CONF RESPONSE and ESTABLISHED) discussed in the section.

[BEN]

=C2=A78.1, 2nd paragraph: The second sentence is = redundant to similar text in =C2=A78.

[SPR] = Removed.


      =                 =      =        _\\|//_
      =                     =   =    ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   )
=                 =                   \_) =          ) /
      =                     =                     =                     =      (_/



Il giorno 20 nov 2018, alle ore 04:39, Ben Campbell <ben@nostrum.com> ha = scritto:

Ben Campbell has entered the following ballot position = for
draft-ietf-clue-protocol-17: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.htmlfor more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/<= br class=3D"">


---------------------------------------------------------------= -------
DISCUSS:
---------------------------------------------------------------= -------

Thanks for all the work on this = over the years. I have a few concerns that I
think require = discussion prior to publication:

=C2=A75.7: = Is the "description" field expected to be human readable? If so, are
there internationalization issues to consider?

=C2=A76.2, 5th paragraph: This says that if = you get an error back for a configure
message, you send a = new configure message. This seems likely to cause an
infinite loop unless some guidance is given about escaping = the loop when the
endpoints cannot agree on a = configuration.

=C2=A77:  I=E2=80=99m = confused by the versioning mechanisms. This section requires an
endpoint to ignore unknown elements, but it also requires the = peer to downgrade
to the highest shared version. These = requirements seem to be at cross purposes.
If the peer = downgrades, one should only see unknown elements in the case of
implementation errors. The requirement to ignore unknown = elements does not come
for free; nor does the requirement = to downgrade.

=C2=A75.1 and =C2=A78: The = use of the options message to negotiate extensions seems
underspecified. How does an endpoint compare extensionType = elements?  Is a spec
required or expected? Is the = extension spec expected to register the URI for
schemaRef = somewhere? Does this need to be in IANA?


---------------------------------------------------------------= -------
COMMENT:
---------------------------------------------------------------= -------

I've got a number of additional = comments that do not seem to rise to the level
of a = DISCUSS:

*** Substantive Comments ***

I support Benjamin Kaduk's DISCUSS.

Additionally, I think there's some missing = sub-transaction states, at least in
the state machine in = Figure 10. When an endpoint sends a message and is waiting
for a response, shouldn't there be a separate waiting state = (for example, when
waiting for optionsResponse)? The MP = and MC state machines include this sort of
thing but the = initial state machine does not. Also, I wonder if there are some
unhandled cases where a configure and advertise message cross = on the wire.

- =C2=A71 ( also =C2=A72, = definition of "endpoint"):
I'd like to see a few more = words about the relationship between this, the
framework = draft, the datachannel draft, and SIP.  Am I correct to = understand
that is the only environment the protocol is = ever expected to operate in? That
is, is there room for = different signaling protocols, different transports, etc?
This also impacts the security considerations. For example if = this depends on
the security properties of datachannels = (over SCTP and DTLS), then it's worth
some language to the = effect that it MUST not be used on other transports, or
that= if it is used on other transports they must have similar security
properties.

=C2=A72, definition = of endpoint: Please cite RFC3261 for SIP. (I have mixed feelings
whether this needs to be normative or informational.)

=C2=A74:
- "a lack of = interoperability between the
protocol implementations. In = order to correctly establish a CLUE
dialogue, the involved = CPs MUST have in common a major version number"

That seems like a statement of fact. I suggest reserving the = normative keywords
for the actual procedures that require = this.

=C2=A75:
- ClueID: Is = this truly optional in the sence of never required under any
circumstances? - sequenceNr: Is the language about = incrementing intended to use
normative keywords? (e.g = MUST)? Why do implementations need to send errors for
unexpected sequence numbers when using a reliable protocol? = That would only
happen in the case of implementation = errors, right? Why is it optional to start
with a random = sequence number? Is there a concern about fingerprinting if
people choose otherwise? (I guess as the security = considerations mention,
there's a lot of other things to = fingerprint.)

- Protocol field: Do you = envision non-CLUE messages will ever occur on the same
SCTP = association? if not, then why require this? If so, then what should = an
endpoint do if it gets a message with something other = than "clue" here?

=C2=A75.1: "since minor = versions are
defined to be both backwards and forwards = compatible,"
Please see related DISCUSS comment.

=C2=A75.7:

- What = is the reason for defining meaning the "100" response code range if = no
codes in that range are defined? Why is this different = from the 500-900 ranges
that are merely reserved for = future use? (I gather there was an intent to be
consistent = with SIP error codes, but why not leave that to the first spec that
defines a 1XX code, assuming that ever happens?

- "message. Implementations can (and are = encouraged to)
include more specific descriptions of the = error condition, if
possible."

Am I correct to assume that implementations should not expect = any particular
description text for a given error code? = (That used to be a common interop
problem for SIP.)

=C2=A76:
- "When the CLUE data = channel set up starts ("start channel"), the CP
moves from = the IDLE state to the CHANNEL SETUP state."

What does "set up starts" mean? Is this trigged by SDP = signaling? SCTP
connection? Is it different for the SCTP = client and server? (I suspect the
data-channel draft = answers this, but it should at least be cited here.)

=C2=A76.1:
- "Finally, if there are changes
in the MP=E2=80=99s telepresence settings ("changed = telepresence settings"),
the MP switches to the ADV = state."
If I understand correctly, the MC can send new = configure messages at any time.
What happens if one = arrives in the ADV state but before sending the advertise?

6.2, 2nd paragraph:
-  Is = the MC forbidden from sending a configure without the ack field set = prior
to sending an ack? - Is the response code limited to = 200, are or other 2XX
codes allowed if defined?

=C2=A712.3: The mime type isn=E2=80=99t = mentioned anywhere else in the doc? Why is it
registered = here? What is it used for?

=C2=A712.4.1: = Why is it necessary to both register these directly in IANA and = define
them in a (presumably registered) schema? Am I = correct to assume new message
types must also be defined = in a schema?

*** Editorial Comments ***

- General:
-- Please proofread = for "which" vs "that" usage.
-- Please proofread for null = words, especially "obviously" and similar terms,
which = some readers might read as condescending.

- = Abstract: Is CLUE an acronym? If so, what is its expansion? (If the = title is
the expansion, it's very obscure.). If not, why = all-caps?

=C2=A72: Please expand MCU on = first mention.

=C2=A74:
- = "The subset of the extensions
that are allowed within the = CLUE session is also determined in the initiation
phase, = such subset being the one including only the extensions that are
supported by both parties" Convoluted sentence, can it be = simplified?

- "Hence in a call between = two
CPs, A and B, there would be two separate dialogs, as = follows:"
Please define the meaning of "dialog" as used in = this document. In particular,
that it is not related to = SIP's usage of the term.

=C2=A75:
"While the =E2=80=99options=E2=80=99 and = =E2=80=99optionsResponse=E2=80=99 messages are exchanged in
the initiation phase between the CPs, the other messages are = involved
in MP-MC dialogues."
This also = needs a definition of "dialog" for the meaning to be clear.

=C2=A75.5:

- "The = MC can send a
=E2=80=99configure=E2=80=99 after the = reception of an =E2=80=99advertisement=E2=80=99 or each time it
wants to request other captures that have been previously = advertised
by the MP."
The use of "can" = makes this seem optional. I gather from the state machine this
is not the case.

- "It indicates = that the =E2=80=99configure=E2=80=99
message also = acknowledges with success the referred advertisement
(=E2=80=99configure=E2=80=99 + =E2=80=99ack=E2=80=99 = message), by applying in that way a piggybacking
mechanism = for simultaneously acknowledging and replying to the
=E2=80=99advertisement=E2=80=99 message."
Convoluted sentence.

5.7:
- "200, 300 and 400 codes are considered catch-alls."
Please elaborate on what "catch-all" means in context.

- "Further response codes can be either = defined
in future versions of the protocol (by adding them = to the related
IANA registry)..."
The = parenthetical phrase is redundant to the next sentence.

=C2=A76:

- First Paragraph: The = first and last sentences are redundant with earlier text
in = the draft. Should "MC process" and "MP process" be "MC role" and "MP = role"?

=C2=A76.1, 3rd paragrap: The first = sentence seems out of place, given that much of
the = previous paragraph was about what happens in the WAIT FOR CONF state.

- 5th paragraph: "If there are
changes in the MP=E2=80=99s telepresence settings ("changed = telepresence
settings"), the MP moves back to the ADV = state."
Redundant to previous paragraph.

=C2=A78.1, 2nd paragraph: The second sentence is redundant to = similar text in =C2=A78.


_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

= --Apple-Mail=_AB19869F-3B26-4305-8516-C6A796484BE3-- From nobody Thu Jul 4 05:24:24 2019 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 7E3E012061C; Thu, 4 Jul 2019 05:24:09 -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.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: clue@ietf.org Message-ID: <156224304935.12028.13907670235119807171@ietfa.amsl.com> Date: Thu, 04 Jul 2019 05:24:09 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-protocol-18.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2019 12:24:10 -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 : Protocol for Controlling Multiple Streams for Telepresence (CLUE) Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-18.txt Pages : 68 Date : 2019-07-04 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-18 https://datatracker.ietf.org/doc/html/draft-ietf-clue-protocol-18 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-18 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 Jul 5 06:16:14 2019 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 334A21200B2; Fri, 5 Jul 2019 06:16:12 -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.98.2 Auto-Submitted: auto-generated Precedence: bulk Reply-To: clue@ietf.org Message-ID: <156233257213.21671.802701797499872977@ietfa.amsl.com> Date: Fri, 05 Jul 2019 06:16:12 -0700 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-protocol-19.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.29 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 13:16:13 -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 : Protocol for Controlling Multiple Streams for Telepresence (CLUE) Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-19.txt Pages : 68 Date : 2019-07-05 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-19 https://datatracker.ietf.org/doc/html/draft-ietf-clue-protocol-19 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-19 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/