From nobody Fri Nov 3 13:06:48 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E9B13FF77 for ; Fri, 3 Nov 2017 13:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 WVOHCCj0oDq9 for ; Fri, 3 Nov 2017 13:06:44 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4070213FF76 for ; Fri, 3 Nov 2017 13:06:44 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA3K6f6C055804 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Nov 2017 15:06:43 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Simon Pietro Romano Cc: clue@ietf.org, Roberta Presta References: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> From: Adam Roach Message-ID: Date: Fri, 3 Nov 2017 15:06:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:06:47 -0000 Thanks for your thorough response! I've removed those issues that you've addressed, and included responses to the remaining issues below. IMPORTANT NOTE TO CLUE WORKING GROUP: There is a discussion regarding retransmission timers that you need to have. See the comments below for details. On 10/6/17 1:37 PM, Simon Pietro Romano wrote: > >> Title: The rule of thumb is that all but a small handful of >> well-known acronyms need to be expanded in titles and abstracts. I >> recognize that "CLUE" is a bit tortured, as acronyms go, but the >> title of this document is, broadly speaking, opaque. Please change it >> to something meaningful, such as "Protocol for Controlling Multiple >> Streams for Telepresence (CLUE)” >> > [SPR] Done. I think this got missed. The header of the current version still reads: CLUE Working Group R. Presta Internet-Draft S. P. Romano Intended status: Standards Track University of Napoli Expires: April 9, 2018 October 6, 2017                              CLUE protocol                       draft-ietf-clue-protocol-14 > >> General: There are three instances of excessively long lines in the >> document. >> > [SPR] ??? The reformatting of XML in -14 has fixed this issue. > 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’re not > adding such information to the revised version of the draft, because > we’d 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. 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. > >> Section 5: The XML definition allows zero or more elements >> to appear in a message. If more than one is allowed, the document >> should explain how multiple IDs are handled. If they are not, then >> the schema and/or text needs to prohibit having more than one. >> > [SPR] Actually, the schema states: > > list. >> BLOCKING: The state machines in section 6 and its subsections don't >> have transitions for all possible messages that could arrive in a >> state. This can cause interop issues. Please add text that clearly >> indicates whether such messages do or do not cause a transition. >> (This might be as simple as "messages not shown for a state do not >> cause the state to change," but only if you carefully check that this >> is true -- for example, what should an MP state machine do do if it >> gets a "CONF + ACK" in the state "WAIT FOR CONF"?) >> > [SPR] In the specific case you mention, I would expect that a 302 is > generated (Invalid Parameter), since the incoming CONF should not > contain the element. This said, I see your point related to the > potential lack of some edges in the state machine graph. This point is > obviously also related to the “timeout” issue you raised before. > Different ways of managing timeouts will definitely have different > impacts on the current state machines. > We will defer the modification of the diagrams in question to the next > revision round. In the meanwhile, we’ll give a thought to potential > further unexpected transactions to be taken into account. Based on my analysis above, I think the state machines will get a bit simpler, as they won't have retransmission counts any longer. > >> Section 6.2 describes a state machine that starts in a state called >> "WAIT FOR ADV." This state does not appear to be timer-supervised, >> meaning that implementations of this state machine can stay in this >> state literally forever. Is that the intention? >> > [SPR] The idea would be to open a socket and start listening for > incoming advertisements. Isn’t that OK? At some point, I think you're going to want to conclude that the CLUE data channel isn't going to get set up correctly, and signal that to the application in some way. This is probably on the order of a minute or so. >> Section 8 indicates that extensions need to indicate "the standard >> version of the protocol the extension refers to." Given that there is >> compatibility within a major version of a protocol, I think this >> means to say "the major standard version of the protocol that the >> extension refers to.” >> > [SPR] My extension might be associated with version 3.6 of the > protocol. This means that it will need to be supported by all versions > higher than that (3.7 onwards). Though, this does not entail that > versions 3.5 and lower should understand it. Right? I'm a bit confused. Is the notion here that extensions, once introduced, always become a mandatory-to-implement part of the protocol? If that's the case, it's not clear why you would need to advertise them explicitly, since support would be implied by the version number itself. (This isn't unheard of: it's how NFS has historically handled version numbers, for example.) However, I didn't get the impression that CLUE protocol extensions were handled in such a way. If this is the intention, there needs to be a lot more text that makes this MTI aspect of extensions clear, and a reconsideration of why you're signaling them individually rather than inferring them from the version number. >> Section 8 contains schema that contains a element. It >> should be clarified that this is the *protocol* version, not the >> *extension* version (or, if it's the extension version, that needs to >> be spelled out too, but I think you'll need a new namespace for that...?) >> > [SPR] I thought this was clear from the third bullet point in the list: > > - the standard version of the protocol the extension refers to. > > Isn’t this enough? In such a case, what would you suggest to add? Ah, I see. It wasn't clear that these three bullets corresponded to the elements in the XML. Perhaps make this clearer with something like "The values of the fields of the element take the following values:" (and maybe move it closer to the actual XML). > >> The remainder of this comment is non-blocking: I also find the >> "SHOULD" in this section to be highly perplexing. Can you explain the >> rationale behind requiring schema, but not requiring any description >> of what the schema *means?) >> > [SPR] It is like coding without adding comments/documentation. > Documentation is most welcome, but not mandatory. Don’t you agree? I don't. It seems more like committing a header file without the corresponding implementation file. Just because people know what things are called doesn't mean that they can handle them. For interop, you're going to need some description of what the fields mean and how the messages are handled. >> >> The schema in section 9 contains: >> >> > schemaLocation="data-model-schema-17.xsd"/> >> >> If you do not intend to bake this "-17" into the document (and I >> can't imagine you do), please add an RFC editor note to change it to >> something else upon publication. >> > [SPR] Done. I am not very familiar with RFC editor notes, indeed. Here > is what we added at the beginning of section 9: > > "NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd" > with the right schema location for the CLUE data model schema document > (which is still to be defined at the time of this writing) in this > section prior to publication as an RFC.” > > Does this work for you? That's perfect. Thanks! >> Section 10 in general: While it does consume a lot of space, I don't >> think that defining six rather different message types and then >> showing only *one* type in the examples is very illustrative of the >> protocol. I would *STRONGLY* suggest adding at least a response >> message, and ideally the example section should contain at least one >> example for each of the six message types. >> > [SPR] Will do in the (hopefully final) revision of the document. Let’s > first double check that the proposed modifications are OK. Sounds good. > >> Section 12.1 has a strange double-double quote around the URN name, >> and section 12.3 repeats this for the MIME type. >> > [SPR] I don’t understand this. Can you please clarify? > Replace ""urn:ietf:params:xml:ns:clue-protocol"". with "urn:ietf:params:xml:ns:clue-protocol". And then replace This section registers the ""application/clue+xml"" MIME type. with This section registers the "application/clue+xml" MIME type. Thanks! /a From nobody Fri Nov 3 13:11:50 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F5313FF79 for ; Fri, 3 Nov 2017 13:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 hdIC_ZCgvT5r for ; Fri, 3 Nov 2017 13:11:48 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2433A13FF48 for ; Fri, 3 Nov 2017 13:11:48 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA3KBk3F056340 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Nov 2017 15:11:47 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at From: Adam Roach To: Simon Pietro Romano Cc: clue@ietf.org, Roberta Presta References: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> Message-ID: Date: Fri, 3 Nov 2017 15:11:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 20:11:50 -0000 Ah, I almost forgot -- please replace the RFC2119 boilerplate in section 3 with RFC8174 boilerplate. Thanks! /a On 11/3/17 3:06 PM, Adam Roach wrote: > Thanks for your thorough response! I've removed those issues that > you've addressed, and included responses to the remaining issues below. > > IMPORTANT NOTE TO CLUE WORKING GROUP: There is a discussion regarding > retransmission timers that you need to have. See the comments below > for details. > > > On 10/6/17 1:37 PM, Simon Pietro Romano wrote: >> >>> Title: The rule of thumb is that all but a small handful of >>> well-known acronyms need to be expanded in titles and abstracts. I >>> recognize that "CLUE" is a bit tortured, as acronyms go, but the >>> title of this document is, broadly speaking, opaque. Please change >>> it to something meaningful, such as "Protocol for Controlling >>> Multiple Streams for Telepresence (CLUE)” >>> >> [SPR] Done. > > I think this got missed. The header of the current version still reads: > > CLUE Working Group R. Presta > Internet-Draft S. P. Romano > Intended status: Standards Track University of Napoli > Expires: April 9, 2018 October 6, 2017 > >                              CLUE protocol >                       draft-ietf-clue-protocol-14 > >> >>> General: There are three instances of excessively long lines in the >>> document. >>> >> [SPR] ??? > > The reformatting of XML in -14 has fixed this issue. > >> 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’re not adding such information to the revised version of the >> draft, because we’d 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. > > 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. > >> >>> Section 5: The XML definition allows zero or more elements >>> to appear in a message. If more than one is allowed, the document >>> should explain how multiple IDs are handled. If they are not, then >>> the schema and/or text needs to prohibit having more than one. >>> >> [SPR] Actually, the schema states: >> >> number in the "v" field with a major number higher than it understands > is supposed to close the connection, since it runs a risk of > misinterpreting the contents of messages. So, in your example, if you > sent "v=12.23" to my implementation that only spoke major version 1, I > would reject it, even though you also support major version 1. That's > why I was thinking it should contain the smallest major version being > advertised. > > The minor version is obviously less useful in this context, since > they're defined to be backwards and forwards compatible, but it's more > useful to know the highest minor version supported than some random > minor version, as it indicates the full feature set that is supported. > The reason it's less useful is that the value can be parsed out of the > list. > >>> BLOCKING: The state machines in section 6 and its subsections don't >>> have transitions for all possible messages that could arrive in a >>> state. This can cause interop issues. Please add text that clearly >>> indicates whether such messages do or do not cause a transition. >>> (This might be as simple as "messages not shown for a state do not >>> cause the state to change," but only if you carefully check that >>> this is true -- for example, what should an MP state machine do do >>> if it gets a "CONF + ACK" in the state "WAIT FOR CONF"?) >>> >> [SPR] In the specific case you mention, I would expect that a 302 is >> generated (Invalid Parameter), since the incoming CONF should not >> contain the element. This said, I see your point related to the >> potential lack of some edges in the state machine graph. This point >> is obviously also related to the “timeout” issue you raised before. >> Different ways of managing timeouts will definitely have different >> impacts on the current state machines. >> We will defer the modification of the diagrams in question to the >> next revision round. In the meanwhile, we’ll give a thought to >> potential further unexpected transactions to be taken into account. > > Based on my analysis above, I think the state machines will get a bit > simpler, as they won't have retransmission counts any longer. > >> >>> Section 6.2 describes a state machine that starts in a state called >>> "WAIT FOR ADV." This state does not appear to be timer-supervised, >>> meaning that implementations of this state machine can stay in this >>> state literally forever. Is that the intention? >>> >> [SPR] The idea would be to open a socket and start listening for >> incoming advertisements. Isn’t that OK? > > At some point, I think you're going to want to conclude that the CLUE > data channel isn't going to get set up correctly, and signal that to > the application in some way. This is probably on the order of a minute > or so. > >>> Section 8 indicates that extensions need to indicate "the standard >>> version of the protocol the extension refers to." Given that there >>> is compatibility within a major version of a protocol, I think this >>> means to say "the major standard version of the protocol that the >>> extension refers to.” >>> >> [SPR] My extension might be associated with version 3.6 of the >> protocol. This means that it will need to be supported by all >> versions higher than that (3.7 onwards). Though, this does not entail >> that versions 3.5 and lower should understand it. Right? > > I'm a bit confused. Is the notion here that extensions, once > introduced, always become a mandatory-to-implement part of the > protocol? If that's the case, it's not clear why you would need to > advertise them explicitly, since support would be implied by the > version number itself. (This isn't unheard of: it's how NFS has > historically handled version numbers, for example.) However, I didn't > get the impression that CLUE protocol extensions were handled in such > a way. If this is the intention, there needs to be a lot more text > that makes this MTI aspect of extensions clear, and a reconsideration > of why you're signaling them individually rather than inferring them > from the version number. > >>> Section 8 contains schema that contains a element. It >>> should be clarified that this is the *protocol* version, not the >>> *extension* version (or, if it's the extension version, that needs >>> to be spelled out too, but I think you'll need a new namespace for >>> that...?) >>> >> [SPR] I thought this was clear from the third bullet point in the list: >> >> - the standard version of the protocol the extension refers to. >> >> Isn’t this enough? In such a case, what would you suggest to add? > > Ah, I see. It wasn't clear that these three bullets corresponded to > the elements in the XML. Perhaps make this clearer with something like > "The values of the fields of the element take the > following values:" (and maybe move it closer to the actual XML). > >> >>> The remainder of this comment is non-blocking: I also find the >>> "SHOULD" in this section to be highly perplexing. Can you explain >>> the rationale behind requiring schema, but not requiring any >>> description of what the schema *means?) >>> >> [SPR] It is like coding without adding comments/documentation. >> Documentation is most welcome, but not mandatory. Don’t you agree? > > I don't. It seems more like committing a header file without the > corresponding implementation file. Just because people know what > things are called doesn't mean that they can handle them. For interop, > you're going to need some description of what the fields mean and how > the messages are handled. > >>> >>> The schema in section 9 contains: >>> >>> >> schemaLocation="data-model-schema-17.xsd"/> >>> >>> If you do not intend to bake this "-17" into the document (and I >>> can't imagine you do), please add an RFC editor note to change it to >>> something else upon publication. >>> >> [SPR] Done. I am not very familiar with RFC editor notes, indeed. >> Here is what we added at the beginning of section 9: >> >> "NOTE TO THE RFC-Editor: Please replace "data-model-schema-17.xsd" >> with the right schema location for the CLUE data model schema >> document (which is still to be defined at the time of this writing) >> in this section prior to publication as an RFC.” >> >> Does this work for you? > > That's perfect. Thanks! > >>> Section 10 in general: While it does consume a lot of space, I don't >>> think that defining six rather different message types and then >>> showing only *one* type in the examples is very illustrative of the >>> protocol. I would *STRONGLY* suggest adding at least a response >>> message, and ideally the example section should contain at least one >>> example for each of the six message types. >>> >> [SPR] Will do in the (hopefully final) revision of the document. >> Let’s first double check that the proposed modifications are OK. > > Sounds good. > >> >>> Section 12.1 has a strange double-double quote around the URN name, >>> and section 12.3 repeats this for the MIME type. >>> >> [SPR] I don’t understand this. Can you please clarify? >> > > Replace > >    ""urn:ietf:params:xml:ns:clue-protocol"". > > with > >    "urn:ietf:params:xml:ns:clue-protocol". > > > And then replace > >    This section registers the ""application/clue+xml"" MIME type. > > with > >    This section registers the "application/clue+xml" MIME type. > > > Thanks! > > /a From nobody Fri Nov 3 14:00:22 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17E9713FFBB for ; Fri, 3 Nov 2017 14:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 pFEi7RrChp5l for ; Fri, 3 Nov 2017 14:00:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3AA813FB1C for ; Fri, 3 Nov 2017 14:00:17 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vA3L0Cje061348 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 3 Nov 2017 16:00:13 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at From: Adam Roach To: "Rob Hansen (rohanse2)" , "clue@ietf.org" References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> Message-ID: <3724cc04-6350-d041-6ab3-5439b1af9b26@nostrum.com> Date: Fri, 3 Nov 2017 16:00:12 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 21:00:20 -0000 Rob -- Just a quick ping to check when we might expect to see a revised version of the document. /a On 8/24/17 7:29 PM, Adam Roach wrote: > Thanks! Responses inline. > > On 8/20/17 21:40, Rob Hansen (rohanse2) wrote: >> Section 4.5.4.3: "Note that this is distinct from cases where the >> CLUE protocol negotiation fails, or an error occurs in the CLUE >> protocol; see [I-D.ietf-clue-protocol] for details of media and state >> preservation in this circumstance." -- I carefully scrubbed the CLUE >> protocol document to try to determine what this is referring to. >> Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but >> replacing "X.Y.Z" with the section that provides the details you >> allude to. >> >> [Rob] I believe when I wrote this the plan was that call preservation >> actions in the event of a protocol error/failure would be addressed >> as part of the protocol document, but that this section had not yet >> been written, and that remains the case. Simon, is this something you >> have planned, or can you point me at the relevant section? > > Simon is on vacation for (I think) at least another week or so; but I > agree that this may need some coordination. See also my earlier > response to Roni. > >> BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3: >> >>      Generally, implementations that receive messages for which they >> have >>      incomplete information SHOULD wait until they have the >> corresponding >>      information they lack before sending messages to make changes >> related >>      to that information.  For example, an answerer that receives a new >>      SDP offer with three new "a=sendonly" CLUE "m=" lines for which it >>      has received no CLUE Advertisement providing the corresponding >>      capture information SHOULD include corresponding "a=inactive" lines >>      in its answer, and SHOULD make a new SDP offer with "a=recvonly" >> when >>      and if a new Advertisement arrives with Captures relevant to those >>      Encodings. >> >> With the normative statements in section 4.5.2.2: >> >>      If the initial offer contained "a=recvonly" CLUE-controlled media >>      lines the recipient SHOULD include corresponding "a=sendonly" CLUE- >>      controlled media lines for accepted Encodings >>      ... >>      If the initial offer contained "a=sendonly" CLUE-controlled media >>      lines the recipient MAY include corresponding "a=recvonly" CLUE- >>      controlled media lines >> >> 5.3 says "SHOULD set a=inactive" in the exact same circumstances >> 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected >> behavior and make sure both sections agree. Ideally, you would >> refactor this so that the normative statement is made in only one >> location. >> >> [Rob] I don't think these sections are in conflict - the quoted >> paragraph from section 5.3 is referring to cases where the SDP offer >> includes "a=sendonly" lines, whereas the section in 4.5.2.2 saying >> "SHOULD set a=sendonly" is talking about that the SDP *answer* >> including "a=sendonly" lines in response to the offerer's >> "a=recvonly" lines. It's the paragraph below that corresponds to the >> quoted 5.3 paragraph, which says that the SDP *answer* MAY include >> "a=recvonly" in its response or "MAY" wait, and then references >> section 5.3, which is where the quoted paragraph with recommendation >> that implementations should wait and send a subsequent SDP is >> included. We ended up with this approach because, even though in most >> cases implementations should wait until they receive the information >> about the encodings and their contents via the CLUE channel, there >> are some valid use-cases where implementations will know this >> up-front and hence can avoid the need for multiple SDP exchanges. > > Ah, okay. I see what you're getting at here. I think the problem, > then, is that the language in 5.3 isn't really normative per se (or, > rather, it shouldn't be normative), as much as it is illustrative. > (This is reinforced by the phrasing "For example...") I would propose: > >     For example, an answerer that receives a new >     SDP offer with three new "a=sendonly" CLUE "m=" lines for which it >     has received no CLUE Advertisement providing the corresponding >     capture information would typically include corresponding > "a=inactive" >     lines in its answer, and make a new SDP offer with "a=recvonly" only >     when and if a new Advertisement arrives with Captures relevant to >     those Encodings. > > >> General, but surfaced in section 8: The procedures described in this >> document virtually guarantee that every CLUE call that is established >> will result in glare (response code 491) behavior. This might cause >> the operations folks some heartburn, as it means that their error >> counts will spike once CLUE is deployed. Further, without fairly >> advanced analysis of the callflow, this will make it impossible to >> distinguish "expected" CLUE-induced 491s from the oddball actual >> glare conditions usually signaled by 491. Has any consideration been >> given to avoiding this situation (e.g., by having the called party >> wait on the order of one second before attempting to negotiate its >> encodings)? >> >> [Rob] I definitely agree that glare is much more likely at the start >> of a CLUE call. There was quite a bit of discussion in the group on >> the pros and cons of introducing an asymmetry into the call messaging >> to avoid (or reduce the frequency) of glare, and how best to do so, >> but the final conclusion in the end was not to do so and to rely on >> SIP's mechanisms to resolve it. > > Sure. What I'd like to have positive confirmation on is: did the > working group specifically consider the operational aspects of this > decision? I agree that it works from a protocol perspective. I'm just > worried that it will give operators unnecessary difficulty. > >> Section 10: It is rather unusual to include authors in the >> acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and >> Christian Groves, I suggest removing the individual's name from >> either the Acknowledgements section or from the authors list. >> >> [Rob] The authors list hasn't really been updated since the initial >> stages. Looking at other docs like the framework one I can see >> they've been revised a fair bit. For now I've left the authors as-is >> and removed the duplicate names from the acknowledgements, but will >> reach out to Paul and Roni for guidance here. > > Thanks. Either resolution makes sense to me, and I suspect that the > current author list is correct. > >> Section 8: "In this case Bob is the Channel Initiator..." this isn't >> clear (and, in fact, it's counterintuitive to me) -- perhaps there >> should be some text indicating *why* Bob is the Channel Initiator. >> >> [Rob] I've made explicit that, when the SCTP over DTLS channel is >> negotiated, Bob ends up the client and hence the Channel Initiator. >> However, when I went to double-check that that was how the initiator >> role was assigned, I can't actually find anything in the protocol or >> datachannel document that defines who ends up with the Initiator >> role. That definitely seems like something that we need to fix... >> (unless I've just failing to find it). Simon, is this something >> you're planning to address? > > The reason this seems counter-intuitve to me is that it is backwards > from how RTCWEB (JSEP) works in the general case. To be clear, for > datachannels, the TLS client is selected by the "a=setup" attribute; > and JSEP implementations are required (MUST) to put "a=setup:actpass" > in their offers, and expected (SHOULD) to put "a=setup:active" in > their answers. The rationale here is: the way ICE ends up working, the > answerer will have the first opportunity to send a packet, so this > reduces overall setup time by ~1/2-RTT. > > Of course, CLUE is free to do this however it wants [1]; but doing it > opposite from RTCWEB is likely to confuse people beyond just me. I > think you'd also need a reasonably good rationale, as a naïve analysis > of CLUE is that doing it the way you currently have in your examples > is generally going to impose an additional 1/2-RTT delay on > datachannel establishment. But I freely admit that I haven't spent a > lot of time thinking about the low-level details, and could be > overlooking something. > > /a > > ____ > [1] Subject to the constraints in > , sections > 10 - 11 From nobody Sun Nov 5 02:55:15 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CAE913FC54 for ; Sun, 5 Nov 2017 02:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id St67ysNYQhsQ for ; Sun, 5 Nov 2017 02:55:13 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1AE513FC4F for ; Sun, 5 Nov 2017 02:55:11 -0800 (PST) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSA05684; Sun, 05 Nov 2017 10:55:09 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 5 Nov 2017 10:55:09 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Sun, 5 Nov 2017 18:55:04 +0800 From: Roni Even To: Adam Roach , Simon Pietro Romano CC: "clue@ietf.org" Thread-Topic: [clue] AD Review: draft-ietf-clue-protocol-13 Thread-Index: AQHTVN9OLwWOwIWuoUq2me51TqtVGqMFl9hQ Date: Sun, 5 Nov 2017 10:55:03 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8322F4@DGGEMM506-MBX.china.huawei.com> References: <8D2EDAF8-014E-477A-AECD-79D944EA4503@unina.it> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59FEEE0E.0019, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 76cf52d37ca639633f7cc63015a80425 Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-protocol-13 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 10:55:14 -0000 Pj4gQkxPQ0tFUjogU2VjdGlvbiA1LjE6IFRoZSBkZXNjcmlwdGlvbiBvZiA8c3VwcG9ydGVkVmVy c2lvbnM+IA0KPj4gZGVzY3JpYmVzIGEgc2NoZW1lIGluIHdoaWNoIG11bHRpcGxlIHN1cHBvcnRl ZCB2ZXJzaW9ucyBjYW4gYmUgDQo+PiBsaXN0ZWQ7IGFuZCwgaWYgdGhlIGxpc3QgaXMgb21pdHRl ZCwgaXQgaW1wbGllcyB0aGF0IG9ubHkgdGhlIHZlcnNpb24gDQo+PiBkZXNjcmliZWQgaW4gPHY+ IGlzIHN1cHBvcnRlZC4gVGhpcyB0ZXh0IGRvZXMgbm90IGRlZmluZSAobm9yIGRvZXMgDQo+PiBh bnkgb3RoZXIgdGV4dCB0aGF0IEkgY2FuIGZpbmQpIHdoYXQgPHY+IHNob3VsZCBiZSBzZXQgdG8g d2hlbiANCj4+IDxzdXBwb3J0ZWRWZXJzaW9ucz4gaXMgdXNlZC4gSW50dWl0aXZlbHksIGl0IHNl ZW1zIHRoYXQgPHY+IHNob3VsZCBiZSANCj4+IHNldCB0byB0aGUgbGFyZ2VzdCBtaW5vciB2ZXJz aW9uIG9mIHRoZSBzbWFsbGVzdCBtYWpvciB2ZXJzaW9uIA0KPj4gYWR2ZXJ0aXNlZCBpbiA8c3Vw cG9ydGVkVmVyc2lvbnM+LCBidXQgdGhhdCAob3Igd2hhdGV2ZXIgdGhlIGNvcnJlY3QgDQo+PiBh bnN3ZXIgaXMpIG5lZWRzIHRvIGJlIGNsZWFybHkgc3BlbGxlZCBvdXQuDQo+Pg0KPiBbU1BSXSBJ IGJlbGlldmUgd2Ugd2VyZSBnaXZpbmcgZm9yIGdyYW50ZWQgdGhhdCDigJx24oCdIHNob3VsZCBi ZSwgaW4gc3VjaCANCj4gY2FzZSwgdGhlIGhpZ2hlc3Qgc3VwcG9ydGVkIHZlcnNpb24gKGkuZS4s IGxhcmdlc3QgbWFqb3IgYW5kIGxhcmdlciANCj4gbWlub3IgbnVtYmVycykuIE5vdyB0aGF0IHlv dSBtYWtlIG1lIHRoaW5rIGFyb3VuZCB0aGF0LCBJIHdvdWxkIHNpbXBseSANCj4gc2F5IHRoYXQg dGhlIOKAnHbigJ0gYXR0cmlidXRlIE1VU1QgYmUgc2V0IHRvIG9uZSBvZiB0aGUgdmVyc2lvbnMg dGhhdCB0aGUgDQo+IGVudGl0eSBpbiBxdWVzdGlvbiBzdXBwb3J0cywgYXMgcGVyIHRoZSA8c3Vw cG9ydGVkVmVyc2lvbnM+IGxpc3QuIEkgDQo+IGNhbiwgZS5nLiwgZGVjaWRlIHRoYXQgSSBzZW5k IGFuIOKAmG9wdGlvbnPigJkgd2l0aCDigJx2PTEyLjIz4oCdIGlmIHRoZSANCj4gPHN1cHBvcnRl ZFZlcnNpb25zPiBsaXN0IGlzIGxpa2UgaW4gdGhlIGZvbGxvd2luZzoNCj4NCj4gPHZlcnNpb24+ MzMuNDQ8L3ZlcnNpb24+DQo+IDx2ZXJzaW9uPjI3LjA8L3ZlcnNpb24+DQo+IDx2ZXJzaW9uPjEy LjM0NTwvdmVyc2lvbj4NCj4gPHZlcnNpb24+MS40NDwvdmVyc2lvbj4NCg0KSSB0aGluayB0aGlz IGZvcm11bGF0aW9uIGlzIGEgcHJvYmxlbS4gSSBhc3N1bWUgdGhlIGludGVudGlvbiBiZWhpbmQg dGhlICJ2IiBmaWVsZCBpcyB0aGF0IHNvbWUgaW1wbGVtZW50YXRpb24gdGhhdCByZWNlaXZlcyBh IHZlcnNpb24gbnVtYmVyIGluIHRoZSAidiIgZmllbGQgd2l0aCBhIG1ham9yIG51bWJlciBoaWdo ZXIgdGhhbiBpdCB1bmRlcnN0YW5kcyBpcyBzdXBwb3NlZCB0byBjbG9zZSB0aGUgY29ubmVjdGlv biwgc2luY2UgaXQgcnVucyBhIHJpc2sgb2YgbWlzaW50ZXJwcmV0aW5nIHRoZSBjb250ZW50cyBv ZiBtZXNzYWdlcy4gU28sIGluIHlvdXIgZXhhbXBsZSwgaWYgeW91IHNlbnQgInY9MTIuMjMiIHRv IG15IGltcGxlbWVudGF0aW9uIHRoYXQgb25seSBzcG9rZSBtYWpvciB2ZXJzaW9uIDEsIEkgd291 bGQgcmVqZWN0IGl0LCBldmVuIHRob3VnaCB5b3UgYWxzbyBzdXBwb3J0IG1ham9yIHZlcnNpb24g MS4gVGhhdCdzIHdoeSBJIHdhcyB0aGlua2luZyBpdCBzaG91bGQgY29udGFpbiB0aGUgc21hbGxl c3QgbWFqb3IgdmVyc2lvbiBiZWluZyBhZHZlcnRpc2VkLg0KDQpUaGUgbWlub3IgdmVyc2lvbiBp cyBvYnZpb3VzbHkgbGVzcyB1c2VmdWwgaW4gdGhpcyBjb250ZXh0LCBzaW5jZSB0aGV5J3JlIGRl ZmluZWQgdG8gYmUgYmFja3dhcmRzIGFuZCBmb3J3YXJkcyBjb21wYXRpYmxlLCBidXQgaXQncyBt b3JlIHVzZWZ1bCB0byBrbm93IHRoZSBoaWdoZXN0IG1pbm9yIHZlcnNpb24gc3VwcG9ydGVkIHRo YW4gc29tZSByYW5kb20gbWlub3IgdmVyc2lvbiwgYXMgaXQgaW5kaWNhdGVzIHRoZSBmdWxsIGZl YXR1cmUgc2V0IHRoYXQgaXMgc3VwcG9ydGVkLiANClRoZSByZWFzb24gaXQncyBsZXNzIHVzZWZ1 bCBpcyB0aGF0IHRoZSB2YWx1ZSBjYW4gYmUgcGFyc2VkIG91dCBvZiB0aGUgPHZlcnNpb24+IGxp c3QuDQoNCg0KW1JvbmldIEkgdGhpbmsgdGhhdCBldmVuIHNlbGVjdGluZyB0aGUgbG93ZXIgbWFq b3IgZm9yICJ2IiBkb2VzIG5vdCBzb2x2ZSB0aGUgcHJvYmxlbSBzaW5jZSBpbiB0aGUgZXhhbXBs ZSBhYm92ZSB0aGUgQ2hhbm5lbCBSZWNlaXZlciBtYXkgc3VwcG9ydCBhbnkgb2YgdGhlIGFib3Zl IHZlcnNpb25zIGFuZCB0aGUgY2hhbm5lbCBpbml0aWF0b3IgZG9lcyBub3Qga25vdyB3aGljaC4g SSB0aGluayByZWNvbW1lbmRpbmcgdGhlIGhpZ2hlciB2ZXJzaW9uIGlzIGFsc28gaG93IFJGQzYx MjAgc3BlY2lmeSBpdA0KDQo= From nobody Fri Nov 10 14:00:20 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B131294C8 for ; Fri, 10 Nov 2017 14:00:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 hUHgBT_was28 for ; Fri, 10 Nov 2017 14:00:15 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63461271DF for ; Fri, 10 Nov 2017 14:00:15 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id vAAM09Qg059729 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 10 Nov 2017 16:00:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local From: Adam Roach To: "Rob Hansen (rohanse2)" , "clue@ietf.org" References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> Message-ID: <7f9ac07f-897b-fb42-be56-d7fb9474fd4e@nostrum.com> Date: Fri, 10 Nov 2017 16:00:04 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 22:00:18 -0000 Rob -- Just a quick ping to check when we might expect to see a revised version of the document. /a On 8/24/17 7:29 PM, Adam Roach wrote: > Thanks! Responses inline. > > On 8/20/17 21:40, Rob Hansen (rohanse2) wrote: >> Section 4.5.4.3: "Note that this is distinct from cases where the >> CLUE protocol negotiation fails, or an error occurs in the CLUE >> protocol; see [I-D.ietf-clue-protocol] for details of media and state >> preservation in this circumstance." -- I carefully scrubbed the CLUE >> protocol document to try to determine what this is referring to. >> Please change it to "see [I-D.ietf-clue-protocol] section X.Y.Z", but >> replacing "X.Y.Z" with the section that provides the details you >> allude to. >> >> [Rob] I believe when I wrote this the plan was that call preservation >> actions in the event of a protocol error/failure would be addressed >> as part of the protocol document, but that this section had not yet >> been written, and that remains the case. Simon, is this something you >> have planned, or can you point me at the relevant section? > > Simon is on vacation for (I think) at least another week or so; but I > agree that this may need some coordination. See also my earlier > response to Roni. > >> BLOCKER: Compare the normative statements in paragraph 2 of Section 5.3: >> >>      Generally, implementations that receive messages for which they >> have >>      incomplete information SHOULD wait until they have the >> corresponding >>      information they lack before sending messages to make changes >> related >>      to that information.  For example, an answerer that receives a new >>      SDP offer with three new "a=sendonly" CLUE "m=" lines for which it >>      has received no CLUE Advertisement providing the corresponding >>      capture information SHOULD include corresponding "a=inactive" lines >>      in its answer, and SHOULD make a new SDP offer with "a=recvonly" >> when >>      and if a new Advertisement arrives with Captures relevant to those >>      Encodings. >> >> With the normative statements in section 4.5.2.2: >> >>      If the initial offer contained "a=recvonly" CLUE-controlled media >>      lines the recipient SHOULD include corresponding "a=sendonly" CLUE- >>      controlled media lines for accepted Encodings >>      ... >>      If the initial offer contained "a=sendonly" CLUE-controlled media >>      lines the recipient MAY include corresponding "a=recvonly" CLUE- >>      controlled media lines >> >> 5.3 says "SHOULD set a=inactive" in the exact same circumstances >> 4.5.2.2 says "SHOULD set a=sendonly". Please pick one expected >> behavior and make sure both sections agree. Ideally, you would >> refactor this so that the normative statement is made in only one >> location. >> >> [Rob] I don't think these sections are in conflict - the quoted >> paragraph from section 5.3 is referring to cases where the SDP offer >> includes "a=sendonly" lines, whereas the section in 4.5.2.2 saying >> "SHOULD set a=sendonly" is talking about that the SDP *answer* >> including "a=sendonly" lines in response to the offerer's >> "a=recvonly" lines. It's the paragraph below that corresponds to the >> quoted 5.3 paragraph, which says that the SDP *answer* MAY include >> "a=recvonly" in its response or "MAY" wait, and then references >> section 5.3, which is where the quoted paragraph with recommendation >> that implementations should wait and send a subsequent SDP is >> included. We ended up with this approach because, even though in most >> cases implementations should wait until they receive the information >> about the encodings and their contents via the CLUE channel, there >> are some valid use-cases where implementations will know this >> up-front and hence can avoid the need for multiple SDP exchanges. > > Ah, okay. I see what you're getting at here. I think the problem, > then, is that the language in 5.3 isn't really normative per se (or, > rather, it shouldn't be normative), as much as it is illustrative. > (This is reinforced by the phrasing "For example...") I would propose: > >     For example, an answerer that receives a new >     SDP offer with three new "a=sendonly" CLUE "m=" lines for which it >     has received no CLUE Advertisement providing the corresponding >     capture information would typically include corresponding > "a=inactive" >     lines in its answer, and make a new SDP offer with "a=recvonly" only >     when and if a new Advertisement arrives with Captures relevant to >     those Encodings. > > >> General, but surfaced in section 8: The procedures described in this >> document virtually guarantee that every CLUE call that is established >> will result in glare (response code 491) behavior. This might cause >> the operations folks some heartburn, as it means that their error >> counts will spike once CLUE is deployed. Further, without fairly >> advanced analysis of the callflow, this will make it impossible to >> distinguish "expected" CLUE-induced 491s from the oddball actual >> glare conditions usually signaled by 491. Has any consideration been >> given to avoiding this situation (e.g., by having the called party >> wait on the order of one second before attempting to negotiate its >> encodings)? >> >> [Rob] I definitely agree that glare is much more likely at the start >> of a CLUE call. There was quite a bit of discussion in the group on >> the pros and cons of introducing an asymmetry into the call messaging >> to avoid (or reduce the frequency) of glare, and how best to do so, >> but the final conclusion in the end was not to do so and to rely on >> SIP's mechanisms to resolve it. > > Sure. What I'd like to have positive confirmation on is: did the > working group specifically consider the operational aspects of this > decision? I agree that it works from a protocol perspective. I'm just > worried that it will give operators unnecessary difficulty. > >> Section 10: It is rather unusual to include authors in the >> acknowledgements section. For each of Rob Hansen, Paul Kyzivat, and >> Christian Groves, I suggest removing the individual's name from >> either the Acknowledgements section or from the authors list. >> >> [Rob] The authors list hasn't really been updated since the initial >> stages. Looking at other docs like the framework one I can see >> they've been revised a fair bit. For now I've left the authors as-is >> and removed the duplicate names from the acknowledgements, but will >> reach out to Paul and Roni for guidance here. > > Thanks. Either resolution makes sense to me, and I suspect that the > current author list is correct. > >> Section 8: "In this case Bob is the Channel Initiator..." this isn't >> clear (and, in fact, it's counterintuitive to me) -- perhaps there >> should be some text indicating *why* Bob is the Channel Initiator. >> >> [Rob] I've made explicit that, when the SCTP over DTLS channel is >> negotiated, Bob ends up the client and hence the Channel Initiator. >> However, when I went to double-check that that was how the initiator >> role was assigned, I can't actually find anything in the protocol or >> datachannel document that defines who ends up with the Initiator >> role. That definitely seems like something that we need to fix... >> (unless I've just failing to find it). Simon, is this something >> you're planning to address? > > The reason this seems counter-intuitve to me is that it is backwards > from how RTCWEB (JSEP) works in the general case. To be clear, for > datachannels, the TLS client is selected by the "a=setup" attribute; > and JSEP implementations are required (MUST) to put "a=setup:actpass" > in their offers, and expected (SHOULD) to put "a=setup:active" in > their answers. The rationale here is: the way ICE ends up working, the > answerer will have the first opportunity to send a packet, so this > reduces overall setup time by ~1/2-RTT. > > Of course, CLUE is free to do this however it wants [1]; but doing it > opposite from RTCWEB is likely to confuse people beyond just me. I > think you'd also need a reasonably good rationale, as a naïve analysis > of CLUE is that doing it the way you currently have in your examples > is generally going to impose an additional 1/2-RTT delay on > datachannel establishment. But I freely admit that I haven't spent a > lot of time thinking about the low-level details, and could be > overlooking something. > > /a > > ____ > [1] Subject to the constraints in > , sections > 10 - 11 From nobody Mon Nov 13 14:05:59 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DEB120725 for ; Mon, 13 Nov 2017 14:05:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 9E7s0lI1LjZd for ; Mon, 13 Nov 2017 14:05:56 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30F2120724 for ; Mon, 13 Nov 2017 14:05:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12772; q=dns/txt; s=iport; t=1510610755; x=1511820355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=e+4+iE7aSPMkOH+ZsY7ICK79WF9IhnlPGZdZNGVDlYE=; b=jz8PLQRktR9WpEGoGCA+Kjkj8cXcn2IwepS7RWVhBCNeTs6USyd83CrM MVrfS0gO8y6UnSt0DgnzM5c5azdRx16LzHooMo+QK9T5lj/5mn2gSbLAp I4gC4b+ycaqJY2BQMc1NER7cgPjEfE2FW8mpdNeR6/WitQknJeQVx1Q+h w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CfAADcFQpa/4sNJK1VBhkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDNWRuJweDd4ofjy+BfX6VUhCCAQojhRgCGoRLPxgBAQEBAQE?= =?us-ascii?q?BAQFrKIUeAQEBAQMjEUAFDAQCAQYCEQQBAQECAiMDAgICMBQBCAgCBAENBQiKG?= =?us-ascii?q?hCNZ51ogieLDgEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+CJYIHgz6CdTWEfwq?= =?us-ascii?q?DI4JjAQSBLQGQOpBAAgKHaYNpiSeCHoYIiyWMaIkPAhEZAYE4AR84gXJ6XoERg?= =?us-ascii?q?VOCXByBZ3eHTYERAQEB?= X-IronPort-AV: E=Sophos;i="5.44,389,1505779200"; d="scan'208";a="318321616" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Nov 2017 22:05:54 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id vADM5sh3031689 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Nov 2017 22:05:54 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 13 Nov 2017 16:05:53 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1320.000; Mon, 13 Nov 2017 16:05:53 -0600 From: "Rob Hansen (rohanse2)" To: Adam Roach , "clue@ietf.org" Thread-Topic: AD Review: draft-ietf-clue-signaling-11 Thread-Index: AQHS2/5y7kSFmrH8ikm+frs9dJG8taKOk+JggAZ6ZICAenzYAIAEU9bw Date: Mon, 13 Nov 2017 22:05:53 +0000 Message-ID: References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> <7f9ac07f-897b-fb42-be56-d7fb9474fd4e@nostrum.com> In-Reply-To: <7f9ac07f-897b-fb42-be56-d7fb9474fd4e@nostrum.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.178.203] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 22:05:57 -0000 VW5sZXNzIHNvbWV0aGluZyB1bmV4cGVjdGVkIGNhdGNoZXMgZmlyZSBJJ3ZlIGdvdCBzb21lIHRp bWUgdGhpcyB3ZWVrIHNvIEknbGwgdHJ5IGFuZCBnZXQgYSByZXZpc2lvbiBvdXQgaW4gdGhlIG5l eHQgZmV3IGRheXMuDQoNClJvYg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog QWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dIA0KU2VudDogMTAgTm92ZW1iZXIg MjAxNyAyMjowMA0KVG86IFJvYiBIYW5zZW4gKHJvaGFuc2UyKSA8cm9oYW5zZTJAY2lzY28uY29t PjsgY2x1ZUBpZXRmLm9yZw0KQ2M6IFNpbW9uIFBpZXRybyBSb21hbm8gPHNwcm9tYW5vQHVuaW5h Lml0Pg0KU3ViamVjdDogUmU6IEFEIFJldmlldzogZHJhZnQtaWV0Zi1jbHVlLXNpZ25hbGluZy0x MQ0KDQpSb2IgLS0NCg0KSnVzdCBhIHF1aWNrIHBpbmcgdG8gY2hlY2sgd2hlbiB3ZSBtaWdodCBl eHBlY3QgdG8gc2VlIGEgcmV2aXNlZCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCg0KL2ENCg0K T24gOC8yNC8xNyA3OjI5IFBNLCBBZGFtIFJvYWNoIHdyb3RlOg0KPiBUaGFua3MhIFJlc3BvbnNl cyBpbmxpbmUuDQo+DQo+IE9uIDgvMjAvMTcgMjE6NDAsIFJvYiBIYW5zZW4gKHJvaGFuc2UyKSB3 cm90ZToNCj4+IFNlY3Rpb24gNC41LjQuMzogIk5vdGUgdGhhdCB0aGlzIGlzIGRpc3RpbmN0IGZy b20gY2FzZXMgd2hlcmUgdGhlIA0KPj4gQ0xVRSBwcm90b2NvbCBuZWdvdGlhdGlvbiBmYWlscywg b3IgYW4gZXJyb3Igb2NjdXJzIGluIHRoZSBDTFVFIA0KPj4gcHJvdG9jb2w7IHNlZSBbSS1ELmll dGYtY2x1ZS1wcm90b2NvbF0gZm9yIGRldGFpbHMgb2YgbWVkaWEgYW5kIHN0YXRlIA0KPj4gcHJl c2VydmF0aW9uIGluIHRoaXMgY2lyY3Vtc3RhbmNlLiIgLS0gSSBjYXJlZnVsbHkgc2NydWJiZWQg dGhlIENMVUUgDQo+PiBwcm90b2NvbCBkb2N1bWVudCB0byB0cnkgdG8gZGV0ZXJtaW5lIHdoYXQg dGhpcyBpcyByZWZlcnJpbmcgdG8uDQo+PiBQbGVhc2UgY2hhbmdlIGl0IHRvICJzZWUgW0ktRC5p ZXRmLWNsdWUtcHJvdG9jb2xdIHNlY3Rpb24gWC5ZLloiLCBidXQgDQo+PiByZXBsYWNpbmcgIlgu WS5aIiB3aXRoIHRoZSBzZWN0aW9uIHRoYXQgcHJvdmlkZXMgdGhlIGRldGFpbHMgeW91IA0KPj4g YWxsdWRlIHRvLg0KPj4NCj4+IFtSb2JdIEkgYmVsaWV2ZSB3aGVuIEkgd3JvdGUgdGhpcyB0aGUg cGxhbiB3YXMgdGhhdCBjYWxsIHByZXNlcnZhdGlvbiANCj4+IGFjdGlvbnMgaW4gdGhlIGV2ZW50 IG9mIGEgcHJvdG9jb2wgZXJyb3IvZmFpbHVyZSB3b3VsZCBiZSBhZGRyZXNzZWQgDQo+PiBhcyBw YXJ0IG9mIHRoZSBwcm90b2NvbCBkb2N1bWVudCwgYnV0IHRoYXQgdGhpcyBzZWN0aW9uIGhhZCBu b3QgeWV0IA0KPj4gYmVlbiB3cml0dGVuLCBhbmQgdGhhdCByZW1haW5zIHRoZSBjYXNlLiBTaW1v biwgaXMgdGhpcyBzb21ldGhpbmcgeW91IA0KPj4gaGF2ZSBwbGFubmVkLCBvciBjYW4geW91IHBv aW50IG1lIGF0IHRoZSByZWxldmFudCBzZWN0aW9uPw0KPg0KPiBTaW1vbiBpcyBvbiB2YWNhdGlv biBmb3IgKEkgdGhpbmspIGF0IGxlYXN0IGFub3RoZXIgd2VlayBvciBzbzsgYnV0IEkgDQo+IGFn cmVlIHRoYXQgdGhpcyBtYXkgbmVlZCBzb21lIGNvb3JkaW5hdGlvbi4gU2VlIGFsc28gbXkgZWFy bGllciANCj4gcmVzcG9uc2UgdG8gUm9uaS4NCj4NCj4+IEJMT0NLRVI6IENvbXBhcmUgdGhlIG5v cm1hdGl2ZSBzdGF0ZW1lbnRzIGluIHBhcmFncmFwaCAyIG9mIFNlY3Rpb24gNS4zOg0KPj4NCj4+ IMKgwqDCoMKgIEdlbmVyYWxseSwgaW1wbGVtZW50YXRpb25zIHRoYXQgcmVjZWl2ZSBtZXNzYWdl cyBmb3Igd2hpY2ggdGhleSANCj4+IGhhdmUNCj4+IMKgwqDCoMKgIGluY29tcGxldGUgaW5mb3Jt YXRpb24gU0hPVUxEIHdhaXQgdW50aWwgdGhleSBoYXZlIHRoZSANCj4+IGNvcnJlc3BvbmRpbmcN Cj4+IMKgwqDCoMKgIGluZm9ybWF0aW9uIHRoZXkgbGFjayBiZWZvcmUgc2VuZGluZyBtZXNzYWdl cyB0byBtYWtlIGNoYW5nZXMgDQo+PiByZWxhdGVkDQo+PiDCoMKgwqDCoCB0byB0aGF0IGluZm9y bWF0aW9uLsKgIEZvciBleGFtcGxlLCBhbiBhbnN3ZXJlciB0aGF0IHJlY2VpdmVzIGEgDQo+PiBu ZXcNCj4+IMKgwqDCoMKgIFNEUCBvZmZlciB3aXRoIHRocmVlIG5ldyAiYT1zZW5kb25seSIgQ0xV RSAibT0iIGxpbmVzIGZvciB3aGljaCANCj4+IGl0DQo+PiDCoMKgwqDCoCBoYXMgcmVjZWl2ZWQg bm8gQ0xVRSBBZHZlcnRpc2VtZW50IHByb3ZpZGluZyB0aGUgY29ycmVzcG9uZGluZw0KPj4gwqDC oMKgwqAgY2FwdHVyZSBpbmZvcm1hdGlvbiBTSE9VTEQgaW5jbHVkZSBjb3JyZXNwb25kaW5nICJh PWluYWN0aXZlIiANCj4+IGxpbmVzDQo+PiDCoMKgwqDCoCBpbiBpdHMgYW5zd2VyLCBhbmQgU0hP VUxEIG1ha2UgYSBuZXcgU0RQIG9mZmVyIHdpdGggImE9cmVjdm9ubHkiIA0KPj4gd2hlbg0KPj4g wqDCoMKgwqAgYW5kIGlmIGEgbmV3IEFkdmVydGlzZW1lbnQgYXJyaXZlcyB3aXRoIENhcHR1cmVz IHJlbGV2YW50IHRvIA0KPj4gdGhvc2UNCj4+IMKgwqDCoMKgIEVuY29kaW5ncy4NCj4+DQo+PiBX aXRoIHRoZSBub3JtYXRpdmUgc3RhdGVtZW50cyBpbiBzZWN0aW9uIDQuNS4yLjI6DQo+Pg0KPj4g wqDCoMKgwqAgSWYgdGhlIGluaXRpYWwgb2ZmZXIgY29udGFpbmVkICJhPXJlY3Zvbmx5IiBDTFVF LWNvbnRyb2xsZWQgDQo+PiBtZWRpYQ0KPj4gwqDCoMKgwqAgbGluZXMgdGhlIHJlY2lwaWVudCBT SE9VTEQgaW5jbHVkZSBjb3JyZXNwb25kaW5nICJhPXNlbmRvbmx5IiANCj4+IENMVUUtDQo+PiDC oMKgwqDCoCBjb250cm9sbGVkIG1lZGlhIGxpbmVzIGZvciBhY2NlcHRlZCBFbmNvZGluZ3MNCj4+ IMKgwqDCoMKgIC4uLg0KPj4gwqDCoMKgwqAgSWYgdGhlIGluaXRpYWwgb2ZmZXIgY29udGFpbmVk ICJhPXNlbmRvbmx5IiBDTFVFLWNvbnRyb2xsZWQgDQo+PiBtZWRpYQ0KPj4gwqDCoMKgwqAgbGlu ZXMgdGhlIHJlY2lwaWVudCBNQVkgaW5jbHVkZSBjb3JyZXNwb25kaW5nICJhPXJlY3Zvbmx5IiBD TFVFLQ0KPj4gwqDCoMKgwqAgY29udHJvbGxlZCBtZWRpYSBsaW5lcw0KPj4NCj4+IDUuMyBzYXlz ICJTSE9VTEQgc2V0IGE9aW5hY3RpdmUiIGluIHRoZSBleGFjdCBzYW1lIGNpcmN1bXN0YW5jZXMN Cj4+IDQuNS4yLjIgc2F5cyAiU0hPVUxEIHNldCBhPXNlbmRvbmx5Ii4gUGxlYXNlIHBpY2sgb25l IGV4cGVjdGVkIA0KPj4gYmVoYXZpb3IgYW5kIG1ha2Ugc3VyZSBib3RoIHNlY3Rpb25zIGFncmVl LiBJZGVhbGx5LCB5b3Ugd291bGQgDQo+PiByZWZhY3RvciB0aGlzIHNvIHRoYXQgdGhlIG5vcm1h dGl2ZSBzdGF0ZW1lbnQgaXMgbWFkZSBpbiBvbmx5IG9uZSANCj4+IGxvY2F0aW9uLg0KPj4NCj4+ IFtSb2JdIEkgZG9uJ3QgdGhpbmsgdGhlc2Ugc2VjdGlvbnMgYXJlIGluIGNvbmZsaWN0IC0gdGhl IHF1b3RlZCANCj4+IHBhcmFncmFwaCBmcm9tIHNlY3Rpb24gNS4zIGlzIHJlZmVycmluZyB0byBj YXNlcyB3aGVyZSB0aGUgU0RQIG9mZmVyIA0KPj4gaW5jbHVkZXMgImE9c2VuZG9ubHkiIGxpbmVz LCB3aGVyZWFzIHRoZSBzZWN0aW9uIGluIDQuNS4yLjIgc2F5aW5nIA0KPj4gIlNIT1VMRCBzZXQg YT1zZW5kb25seSIgaXMgdGFsa2luZyBhYm91dCB0aGF0IHRoZSBTRFAgKmFuc3dlciogDQo+PiBp bmNsdWRpbmcgImE9c2VuZG9ubHkiIGxpbmVzIGluIHJlc3BvbnNlIHRvIHRoZSBvZmZlcmVyJ3Mg DQo+PiAiYT1yZWN2b25seSIgbGluZXMuIEl0J3MgdGhlIHBhcmFncmFwaCBiZWxvdyB0aGF0IGNv cnJlc3BvbmRzIHRvIHRoZSANCj4+IHF1b3RlZCA1LjMgcGFyYWdyYXBoLCB3aGljaCBzYXlzIHRo YXQgdGhlIFNEUCAqYW5zd2VyKiBNQVkgaW5jbHVkZSANCj4+ICJhPXJlY3Zvbmx5IiBpbiBpdHMg cmVzcG9uc2Ugb3IgIk1BWSIgd2FpdCwgYW5kIHRoZW4gcmVmZXJlbmNlcyANCj4+IHNlY3Rpb24g NS4zLCB3aGljaCBpcyB3aGVyZSB0aGUgcXVvdGVkIHBhcmFncmFwaCB3aXRoIHJlY29tbWVuZGF0 aW9uIA0KPj4gdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxkIHdhaXQgYW5kIHNlbmQgYSBzdWJz ZXF1ZW50IFNEUCBpcyANCj4+IGluY2x1ZGVkLiBXZSBlbmRlZCB1cCB3aXRoIHRoaXMgYXBwcm9h Y2ggYmVjYXVzZSwgZXZlbiB0aG91Z2ggaW4gbW9zdCANCj4+IGNhc2VzIGltcGxlbWVudGF0aW9u cyBzaG91bGQgd2FpdCB1bnRpbCB0aGV5IHJlY2VpdmUgdGhlIGluZm9ybWF0aW9uIA0KPj4gYWJv dXQgdGhlIGVuY29kaW5ncyBhbmQgdGhlaXIgY29udGVudHMgdmlhIHRoZSBDTFVFIGNoYW5uZWws IHRoZXJlIA0KPj4gYXJlIHNvbWUgdmFsaWQgdXNlLWNhc2VzIHdoZXJlIGltcGxlbWVudGF0aW9u cyB3aWxsIGtub3cgdGhpcyANCj4+IHVwLWZyb250IGFuZCBoZW5jZSBjYW4gYXZvaWQgdGhlIG5l ZWQgZm9yIG11bHRpcGxlIFNEUCBleGNoYW5nZXMuDQo+DQo+IEFoLCBva2F5LiBJIHNlZSB3aGF0 IHlvdSdyZSBnZXR0aW5nIGF0IGhlcmUuIEkgdGhpbmsgdGhlIHByb2JsZW0sIA0KPiB0aGVuLCBp cyB0aGF0IHRoZSBsYW5ndWFnZSBpbiA1LjMgaXNuJ3QgcmVhbGx5IG5vcm1hdGl2ZSBwZXIgc2Ug KG9yLCANCj4gcmF0aGVyLCBpdCBzaG91bGRuJ3QgYmUgbm9ybWF0aXZlKSwgYXMgbXVjaCBhcyBp dCBpcyBpbGx1c3RyYXRpdmUuDQo+IChUaGlzIGlzIHJlaW5mb3JjZWQgYnkgdGhlIHBocmFzaW5n ICJGb3IgZXhhbXBsZS4uLiIpIEkgd291bGQgcHJvcG9zZToNCj4NCj4gwqDCoMKgIEZvciBleGFt cGxlLCBhbiBhbnN3ZXJlciB0aGF0IHJlY2VpdmVzIGEgbmV3DQo+IMKgwqDCoCBTRFAgb2ZmZXIg d2l0aCB0aHJlZSBuZXcgImE9c2VuZG9ubHkiIENMVUUgIm09IiBsaW5lcyBmb3Igd2hpY2ggaXQN Cj4gwqDCoMKgIGhhcyByZWNlaXZlZCBubyBDTFVFIEFkdmVydGlzZW1lbnQgcHJvdmlkaW5nIHRo ZSBjb3JyZXNwb25kaW5nDQo+IMKgwqDCoCBjYXB0dXJlIGluZm9ybWF0aW9uIHdvdWxkIHR5cGlj YWxseSBpbmNsdWRlIGNvcnJlc3BvbmRpbmcgDQo+ICJhPWluYWN0aXZlIg0KPiDCoMKgwqAgbGlu ZXMgaW4gaXRzIGFuc3dlciwgYW5kIG1ha2UgYSBuZXcgU0RQIG9mZmVyIHdpdGggImE9cmVjdm9u bHkiIA0KPiBvbmx5DQo+IMKgwqDCoCB3aGVuIGFuZCBpZiBhIG5ldyBBZHZlcnRpc2VtZW50IGFy cml2ZXMgd2l0aCBDYXB0dXJlcyByZWxldmFudCB0bw0KPiDCoMKgwqAgdGhvc2UgRW5jb2Rpbmdz Lg0KPg0KPg0KPj4gR2VuZXJhbCwgYnV0IHN1cmZhY2VkIGluIHNlY3Rpb24gODogVGhlIHByb2Nl ZHVyZXMgZGVzY3JpYmVkIGluIHRoaXMgDQo+PiBkb2N1bWVudCB2aXJ0dWFsbHkgZ3VhcmFudGVl IHRoYXQgZXZlcnkgQ0xVRSBjYWxsIHRoYXQgaXMgZXN0YWJsaXNoZWQgDQo+PiB3aWxsIHJlc3Vs dCBpbiBnbGFyZSAocmVzcG9uc2UgY29kZSA0OTEpIGJlaGF2aW9yLiBUaGlzIG1pZ2h0IGNhdXNl IA0KPj4gdGhlIG9wZXJhdGlvbnMgZm9sa3Mgc29tZSBoZWFydGJ1cm4sIGFzIGl0IG1lYW5zIHRo YXQgdGhlaXIgZXJyb3IgDQo+PiBjb3VudHMgd2lsbCBzcGlrZSBvbmNlIENMVUUgaXMgZGVwbG95 ZWQuIEZ1cnRoZXIsIHdpdGhvdXQgZmFpcmx5IA0KPj4gYWR2YW5jZWQgYW5hbHlzaXMgb2YgdGhl IGNhbGxmbG93LCB0aGlzIHdpbGwgbWFrZSBpdCBpbXBvc3NpYmxlIHRvIA0KPj4gZGlzdGluZ3Vp c2ggImV4cGVjdGVkIiBDTFVFLWluZHVjZWQgNDkxcyBmcm9tIHRoZSBvZGRiYWxsIGFjdHVhbCAN Cj4+IGdsYXJlIGNvbmRpdGlvbnMgdXN1YWxseSBzaWduYWxlZCBieSA0OTEuIEhhcyBhbnkgY29u c2lkZXJhdGlvbiBiZWVuIA0KPj4gZ2l2ZW4gdG8gYXZvaWRpbmcgdGhpcyBzaXR1YXRpb24gKGUu Zy4sIGJ5IGhhdmluZyB0aGUgY2FsbGVkIHBhcnR5IA0KPj4gd2FpdCBvbiB0aGUgb3JkZXIgb2Yg b25lIHNlY29uZCBiZWZvcmUgYXR0ZW1wdGluZyB0byBuZWdvdGlhdGUgaXRzIA0KPj4gZW5jb2Rp bmdzKT8NCj4+DQo+PiBbUm9iXSBJIGRlZmluaXRlbHkgYWdyZWUgdGhhdCBnbGFyZSBpcyBtdWNo IG1vcmUgbGlrZWx5IGF0IHRoZSBzdGFydCANCj4+IG9mIGEgQ0xVRSBjYWxsLiBUaGVyZSB3YXMg cXVpdGUgYSBiaXQgb2YgZGlzY3Vzc2lvbiBpbiB0aGUgZ3JvdXAgb24gDQo+PiB0aGUgcHJvcyBh bmQgY29ucyBvZiBpbnRyb2R1Y2luZyBhbiBhc3ltbWV0cnkgaW50byB0aGUgY2FsbCBtZXNzYWdp bmcgDQo+PiB0byBhdm9pZCAob3IgcmVkdWNlIHRoZSBmcmVxdWVuY3kpIG9mIGdsYXJlLCBhbmQg aG93IGJlc3QgdG8gZG8gc28sIA0KPj4gYnV0IHRoZSBmaW5hbCBjb25jbHVzaW9uIGluIHRoZSBl bmQgd2FzIG5vdCB0byBkbyBzbyBhbmQgdG8gcmVseSBvbiANCj4+IFNJUCdzIG1lY2hhbmlzbXMg dG8gcmVzb2x2ZSBpdC4NCj4NCj4gU3VyZS4gV2hhdCBJJ2QgbGlrZSB0byBoYXZlIHBvc2l0aXZl IGNvbmZpcm1hdGlvbiBvbiBpczogZGlkIHRoZSANCj4gd29ya2luZyBncm91cCBzcGVjaWZpY2Fs bHkgY29uc2lkZXIgdGhlIG9wZXJhdGlvbmFsIGFzcGVjdHMgb2YgdGhpcyANCj4gZGVjaXNpb24/ IEkgYWdyZWUgdGhhdCBpdCB3b3JrcyBmcm9tIGEgcHJvdG9jb2wgcGVyc3BlY3RpdmUuIEknbSBq dXN0IA0KPiB3b3JyaWVkIHRoYXQgaXQgd2lsbCBnaXZlIG9wZXJhdG9ycyB1bm5lY2Vzc2FyeSBk aWZmaWN1bHR5Lg0KPg0KPj4gU2VjdGlvbiAxMDogSXQgaXMgcmF0aGVyIHVudXN1YWwgdG8gaW5j bHVkZSBhdXRob3JzIGluIHRoZSANCj4+IGFja25vd2xlZGdlbWVudHMgc2VjdGlvbi4gRm9yIGVh Y2ggb2YgUm9iIEhhbnNlbiwgUGF1bCBLeXppdmF0LCBhbmQgDQo+PiBDaHJpc3RpYW4gR3JvdmVz LCBJIHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIGluZGl2aWR1YWwncyBuYW1lIGZyb20gDQo+PiBlaXRo ZXIgdGhlIEFja25vd2xlZGdlbWVudHMgc2VjdGlvbiBvciBmcm9tIHRoZSBhdXRob3JzIGxpc3Qu DQo+Pg0KPj4gW1JvYl0gVGhlIGF1dGhvcnMgbGlzdCBoYXNuJ3QgcmVhbGx5IGJlZW4gdXBkYXRl ZCBzaW5jZSB0aGUgaW5pdGlhbCANCj4+IHN0YWdlcy4gTG9va2luZyBhdCBvdGhlciBkb2NzIGxp a2UgdGhlIGZyYW1ld29yayBvbmUgSSBjYW4gc2VlIA0KPj4gdGhleSd2ZSBiZWVuIHJldmlzZWQg YSBmYWlyIGJpdC4gRm9yIG5vdyBJJ3ZlIGxlZnQgdGhlIGF1dGhvcnMgYXMtaXMgDQo+PiBhbmQg cmVtb3ZlZCB0aGUgZHVwbGljYXRlIG5hbWVzIGZyb20gdGhlIGFja25vd2xlZGdlbWVudHMsIGJ1 dCB3aWxsIA0KPj4gcmVhY2ggb3V0IHRvIFBhdWwgYW5kIFJvbmkgZm9yIGd1aWRhbmNlIGhlcmUu DQo+DQo+IFRoYW5rcy4gRWl0aGVyIHJlc29sdXRpb24gbWFrZXMgc2Vuc2UgdG8gbWUsIGFuZCBJ IHN1c3BlY3QgdGhhdCB0aGUgDQo+IGN1cnJlbnQgYXV0aG9yIGxpc3QgaXMgY29ycmVjdC4NCj4N Cj4+IFNlY3Rpb24gODogIkluIHRoaXMgY2FzZSBCb2IgaXMgdGhlIENoYW5uZWwgSW5pdGlhdG9y Li4uIiB0aGlzIGlzbid0IA0KPj4gY2xlYXIgKGFuZCwgaW4gZmFjdCwgaXQncyBjb3VudGVyaW50 dWl0aXZlIHRvIG1lKSAtLSBwZXJoYXBzIHRoZXJlIA0KPj4gc2hvdWxkIGJlIHNvbWUgdGV4dCBp bmRpY2F0aW5nICp3aHkqIEJvYiBpcyB0aGUgQ2hhbm5lbCBJbml0aWF0b3IuDQo+Pg0KPj4gW1Jv Yl0gSSd2ZSBtYWRlIGV4cGxpY2l0IHRoYXQsIHdoZW4gdGhlIFNDVFAgb3ZlciBEVExTIGNoYW5u ZWwgaXMgDQo+PiBuZWdvdGlhdGVkLCBCb2IgZW5kcyB1cCB0aGUgY2xpZW50IGFuZCBoZW5jZSB0 aGUgQ2hhbm5lbCBJbml0aWF0b3IuDQo+PiBIb3dldmVyLCB3aGVuIEkgd2VudCB0byBkb3VibGUt Y2hlY2sgdGhhdCB0aGF0IHdhcyBob3cgdGhlIGluaXRpYXRvciANCj4+IHJvbGUgd2FzIGFzc2ln bmVkLCBJIGNhbid0IGFjdHVhbGx5IGZpbmQgYW55dGhpbmcgaW4gdGhlIHByb3RvY29sIG9yIA0K Pj4gZGF0YWNoYW5uZWwgZG9jdW1lbnQgdGhhdCBkZWZpbmVzIHdobyBlbmRzIHVwIHdpdGggdGhl IEluaXRpYXRvciANCj4+IHJvbGUuIFRoYXQgZGVmaW5pdGVseSBzZWVtcyBsaWtlIHNvbWV0aGlu ZyB0aGF0IHdlIG5lZWQgdG8gZml4Li4uDQo+PiAodW5sZXNzIEkndmUganVzdCBmYWlsaW5nIHRv IGZpbmQgaXQpLiBTaW1vbiwgaXMgdGhpcyBzb21ldGhpbmcgDQo+PiB5b3UncmUgcGxhbm5pbmcg dG8gYWRkcmVzcz8NCj4NCj4gVGhlIHJlYXNvbiB0aGlzIHNlZW1zIGNvdW50ZXItaW50dWl0dmUg dG8gbWUgaXMgdGhhdCBpdCBpcyBiYWNrd2FyZHMgDQo+IGZyb20gaG93IFJUQ1dFQiAoSlNFUCkg d29ya3MgaW4gdGhlIGdlbmVyYWwgY2FzZS4gVG8gYmUgY2xlYXIsIGZvciANCj4gZGF0YWNoYW5u ZWxzLCB0aGUgVExTIGNsaWVudCBpcyBzZWxlY3RlZCBieSB0aGUgImE9c2V0dXAiIGF0dHJpYnV0 ZTsgDQo+IGFuZCBKU0VQIGltcGxlbWVudGF0aW9ucyBhcmUgcmVxdWlyZWQgKE1VU1QpIHRvIHB1 dCAiYT1zZXR1cDphY3RwYXNzIg0KPiBpbiB0aGVpciBvZmZlcnMsIGFuZCBleHBlY3RlZCAoU0hP VUxEKSB0byBwdXQgImE9c2V0dXA6YWN0aXZlIiBpbiANCj4gdGhlaXIgYW5zd2Vycy4gVGhlIHJh dGlvbmFsZSBoZXJlIGlzOiB0aGUgd2F5IElDRSBlbmRzIHVwIHdvcmtpbmcsIHRoZSANCj4gYW5z d2VyZXIgd2lsbCBoYXZlIHRoZSBmaXJzdCBvcHBvcnR1bml0eSB0byBzZW5kIGEgcGFja2V0LCBz byB0aGlzIA0KPiByZWR1Y2VzIG92ZXJhbGwgc2V0dXAgdGltZSBieSB+MS8yLVJUVC4NCj4NCj4g T2YgY291cnNlLCBDTFVFIGlzIGZyZWUgdG8gZG8gdGhpcyBob3dldmVyIGl0IHdhbnRzIFsxXTsg YnV0IGRvaW5nIGl0IA0KPiBvcHBvc2l0ZSBmcm9tIFJUQ1dFQiBpcyBsaWtlbHkgdG8gY29uZnVz ZSBwZW9wbGUgYmV5b25kIGp1c3QgbWUuIEkgDQo+IHRoaW5rIHlvdSdkIGFsc28gbmVlZCBhIHJl YXNvbmFibHkgZ29vZCByYXRpb25hbGUsIGFzIGEgbmHDr3ZlIGFuYWx5c2lzIA0KPiBvZiBDTFVF IGlzIHRoYXQgZG9pbmcgaXQgdGhlIHdheSB5b3UgY3VycmVudGx5IGhhdmUgaW4geW91ciBleGFt cGxlcyANCj4gaXMgZ2VuZXJhbGx5IGdvaW5nIHRvIGltcG9zZSBhbiBhZGRpdGlvbmFsIDEvMi1S VFQgZGVsYXkgb24gDQo+IGRhdGFjaGFubmVsIGVzdGFibGlzaG1lbnQuIEJ1dCBJIGZyZWVseSBh ZG1pdCB0aGF0IEkgaGF2ZW4ndCBzcGVudCBhIA0KPiBsb3Qgb2YgdGltZSB0aGlua2luZyBhYm91 dCB0aGUgbG93LWxldmVsIGRldGFpbHMsIGFuZCBjb3VsZCBiZSANCj4gb3Zlcmxvb2tpbmcgc29t ZXRoaW5nLg0KPg0KPiAvYQ0KPg0KPiBfX19fDQo+IFsxXSBTdWJqZWN0IHRvIHRoZSBjb25zdHJh aW50cyBpbg0KPiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtbW11c2lj LXNjdHAtc2RwLTExPiwgc2VjdGlvbnMNCj4gMTAgLSAxMQ0KDQoNCg== From nobody Mon Nov 13 15:59:37 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C90D1200B9 for ; Mon, 13 Nov 2017 15:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nMBWipMoLARG for ; Mon, 13 Nov 2017 15:59:32 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5A6127BA3 for ; Mon, 13 Nov 2017 15:59:32 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A50F996307612 for ; Mon, 13 Nov 2017 23:59:29 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 13 Nov 2017 23:59:30 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 07:59:27 +0800 From: Roni Even To: "Rob Hansen (rohanse2)" , Adam Roach , "clue@ietf.org" Thread-Topic: AD Review: draft-ietf-clue-signaling-11 Thread-Index: AQHS2/5y7kSFmrH8ikm+frs9dJG8taKOk+JggAZ6ZICAenzYAIAEU9bwgAAfvTA= Date: Mon, 13 Nov 2017 23:59:26 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836873@DGGEMM506-MBX.china.huawei.com> References: <0b69d2f1-11e1-8fd1-d4a1-2faacc0a8528@nostrum.com> <7f9ac07f-897b-fb42-be56-d7fb9474fd4e@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.36.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [clue] AD Review: draft-ietf-clue-signaling-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 23:59:35 -0000 SGkgUm9iLA0KVGhhbmtzLCBrZWVwIHRoZSBmaXJlIGV4dGluZ3Vpc2hlciBuZWFyYnkgOi0pDQpS b25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2x1ZSBbbWFpbHRv OmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYiBIYW5zZW4NCj4gKHJvaGFu c2UyKQ0KPiBTZW50OiDXmdeV153CoNeSIDE0INeg15XXkdee15HXqCAyMDE3IDAwOjA2DQo+IFRv OiBBZGFtIFJvYWNoOyBjbHVlQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbY2x1ZV0gQUQgUmV2 aWV3OiBkcmFmdC1pZXRmLWNsdWUtc2lnbmFsaW5nLTExDQo+IA0KPiBVbmxlc3Mgc29tZXRoaW5n IHVuZXhwZWN0ZWQgY2F0Y2hlcyBmaXJlIEkndmUgZ290IHNvbWUgdGltZSB0aGlzIHdlZWsgc28g SSdsbA0KPiB0cnkgYW5kIGdldCBhIHJldmlzaW9uIG91dCBpbiB0aGUgbmV4dCBmZXcgZGF5cy4N Cj4gDQo+IFJvYg0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQWRh bSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQo+IFNlbnQ6IDEwIE5vdmVtYmVyIDIw MTcgMjI6MDANCj4gVG86IFJvYiBIYW5zZW4gKHJvaGFuc2UyKSA8cm9oYW5zZTJAY2lzY28uY29t PjsgY2x1ZUBpZXRmLm9yZw0KPiBDYzogU2ltb24gUGlldHJvIFJvbWFubyA8c3Byb21hbm9AdW5p bmEuaXQ+DQo+IFN1YmplY3Q6IFJlOiBBRCBSZXZpZXc6IGRyYWZ0LWlldGYtY2x1ZS1zaWduYWxp bmctMTENCj4gDQo+IFJvYiAtLQ0KPiANCj4gSnVzdCBhIHF1aWNrIHBpbmcgdG8gY2hlY2sgd2hl biB3ZSBtaWdodCBleHBlY3QgdG8gc2VlIGEgcmV2aXNlZCB2ZXJzaW9uIG9mDQo+IHRoZSBkb2N1 bWVudC4NCj4gDQo+IC9hDQo+IA0KPiBPbiA4LzI0LzE3IDc6MjkgUE0sIEFkYW0gUm9hY2ggd3Jv dGU6DQo+ID4gVGhhbmtzISBSZXNwb25zZXMgaW5saW5lLg0KPiA+DQo+ID4gT24gOC8yMC8xNyAy MTo0MCwgUm9iIEhhbnNlbiAocm9oYW5zZTIpIHdyb3RlOg0KPiA+PiBTZWN0aW9uIDQuNS40LjM6 ICJOb3RlIHRoYXQgdGhpcyBpcyBkaXN0aW5jdCBmcm9tIGNhc2VzIHdoZXJlIHRoZQ0KPiA+PiBD TFVFIHByb3RvY29sIG5lZ290aWF0aW9uIGZhaWxzLCBvciBhbiBlcnJvciBvY2N1cnMgaW4gdGhl IENMVUUNCj4gPj4gcHJvdG9jb2w7IHNlZSBbSS1ELmlldGYtY2x1ZS1wcm90b2NvbF0gZm9yIGRl dGFpbHMgb2YgbWVkaWEgYW5kIHN0YXRlDQo+ID4+IHByZXNlcnZhdGlvbiBpbiB0aGlzIGNpcmN1 bXN0YW5jZS4iIC0tIEkgY2FyZWZ1bGx5IHNjcnViYmVkIHRoZSBDTFVFDQo+ID4+IHByb3RvY29s IGRvY3VtZW50IHRvIHRyeSB0byBkZXRlcm1pbmUgd2hhdCB0aGlzIGlzIHJlZmVycmluZyB0by4N Cj4gPj4gUGxlYXNlIGNoYW5nZSBpdCB0byAic2VlIFtJLUQuaWV0Zi1jbHVlLXByb3RvY29sXSBz ZWN0aW9uIFguWS5aIiwgYnV0DQo+ID4+IHJlcGxhY2luZyAiWC5ZLloiIHdpdGggdGhlIHNlY3Rp b24gdGhhdCBwcm92aWRlcyB0aGUgZGV0YWlscyB5b3UNCj4gPj4gYWxsdWRlIHRvLg0KPiA+Pg0K PiA+PiBbUm9iXSBJIGJlbGlldmUgd2hlbiBJIHdyb3RlIHRoaXMgdGhlIHBsYW4gd2FzIHRoYXQg Y2FsbCBwcmVzZXJ2YXRpb24NCj4gPj4gYWN0aW9ucyBpbiB0aGUgZXZlbnQgb2YgYSBwcm90b2Nv bCBlcnJvci9mYWlsdXJlIHdvdWxkIGJlIGFkZHJlc3NlZA0KPiA+PiBhcyBwYXJ0IG9mIHRoZSBw cm90b2NvbCBkb2N1bWVudCwgYnV0IHRoYXQgdGhpcyBzZWN0aW9uIGhhZCBub3QgeWV0DQo+ID4+ IGJlZW4gd3JpdHRlbiwgYW5kIHRoYXQgcmVtYWlucyB0aGUgY2FzZS4gU2ltb24sIGlzIHRoaXMg c29tZXRoaW5nIHlvdQ0KPiA+PiBoYXZlIHBsYW5uZWQsIG9yIGNhbiB5b3UgcG9pbnQgbWUgYXQg dGhlIHJlbGV2YW50IHNlY3Rpb24/DQo+ID4NCj4gPiBTaW1vbiBpcyBvbiB2YWNhdGlvbiBmb3Ig KEkgdGhpbmspIGF0IGxlYXN0IGFub3RoZXIgd2VlayBvciBzbzsgYnV0IEkNCj4gPiBhZ3JlZSB0 aGF0IHRoaXMgbWF5IG5lZWQgc29tZSBjb29yZGluYXRpb24uIFNlZSBhbHNvIG15IGVhcmxpZXIN Cj4gPiByZXNwb25zZSB0byBSb25pLg0KPiA+DQo+ID4+IEJMT0NLRVI6IENvbXBhcmUgdGhlIG5v cm1hdGl2ZSBzdGF0ZW1lbnRzIGluIHBhcmFncmFwaCAyIG9mIFNlY3Rpb24NCj4gNS4zOg0KPiA+ Pg0KPiA+PiDCoMKgwqDCoCBHZW5lcmFsbHksIGltcGxlbWVudGF0aW9ucyB0aGF0IHJlY2VpdmUg bWVzc2FnZXMgZm9yIHdoaWNoIHRoZXkNCj4gPj4gaGF2ZQ0KPiA+PiDCoMKgwqDCoCBpbmNvbXBs ZXRlIGluZm9ybWF0aW9uIFNIT1VMRCB3YWl0IHVudGlsIHRoZXkgaGF2ZSB0aGUNCj4gPj4gY29y cmVzcG9uZGluZw0KPiA+PiDCoMKgwqDCoCBpbmZvcm1hdGlvbiB0aGV5IGxhY2sgYmVmb3JlIHNl bmRpbmcgbWVzc2FnZXMgdG8gbWFrZSBjaGFuZ2VzDQo+ID4+IHJlbGF0ZWQNCj4gPj4gwqDCoMKg wqAgdG8gdGhhdCBpbmZvcm1hdGlvbi7CoCBGb3IgZXhhbXBsZSwgYW4gYW5zd2VyZXIgdGhhdCBy ZWNlaXZlcyBhDQo+ID4+IG5ldw0KPiA+PiDCoMKgwqDCoCBTRFAgb2ZmZXIgd2l0aCB0aHJlZSBu ZXcgImE9c2VuZG9ubHkiIENMVUUgIm09IiBsaW5lcyBmb3Igd2hpY2gNCj4gPj4gaXQNCj4gPj4g wqDCoMKgwqAgaGFzIHJlY2VpdmVkIG5vIENMVUUgQWR2ZXJ0aXNlbWVudCBwcm92aWRpbmcgdGhl IGNvcnJlc3BvbmRpbmcNCj4gPj4gwqDCoMKgwqAgY2FwdHVyZSBpbmZvcm1hdGlvbiBTSE9VTEQg aW5jbHVkZSBjb3JyZXNwb25kaW5nICJhPWluYWN0aXZlIg0KPiA+PiBsaW5lcw0KPiA+PiDCoMKg wqDCoCBpbiBpdHMgYW5zd2VyLCBhbmQgU0hPVUxEIG1ha2UgYSBuZXcgU0RQIG9mZmVyIHdpdGgg ImE9cmVjdm9ubHkiDQo+ID4+IHdoZW4NCj4gPj4gwqDCoMKgwqAgYW5kIGlmIGEgbmV3IEFkdmVy dGlzZW1lbnQgYXJyaXZlcyB3aXRoIENhcHR1cmVzIHJlbGV2YW50IHRvDQo+ID4+IHRob3NlDQo+ ID4+IMKgwqDCoMKgIEVuY29kaW5ncy4NCj4gPj4NCj4gPj4gV2l0aCB0aGUgbm9ybWF0aXZlIHN0 YXRlbWVudHMgaW4gc2VjdGlvbiA0LjUuMi4yOg0KPiA+Pg0KPiA+PiDCoMKgwqDCoCBJZiB0aGUg aW5pdGlhbCBvZmZlciBjb250YWluZWQgImE9cmVjdm9ubHkiIENMVUUtY29udHJvbGxlZA0KPiA+ PiBtZWRpYQ0KPiA+PiDCoMKgwqDCoCBsaW5lcyB0aGUgcmVjaXBpZW50IFNIT1VMRCBpbmNsdWRl IGNvcnJlc3BvbmRpbmcgImE9c2VuZG9ubHkiDQo+ID4+IENMVUUtDQo+ID4+IMKgwqDCoMKgIGNv bnRyb2xsZWQgbWVkaWEgbGluZXMgZm9yIGFjY2VwdGVkIEVuY29kaW5ncw0KPiA+PiDCoMKgwqDC oCAuLi4NCj4gPj4gwqDCoMKgwqAgSWYgdGhlIGluaXRpYWwgb2ZmZXIgY29udGFpbmVkICJhPXNl bmRvbmx5IiBDTFVFLWNvbnRyb2xsZWQNCj4gPj4gbWVkaWENCj4gPj4gwqDCoMKgwqAgbGluZXMg dGhlIHJlY2lwaWVudCBNQVkgaW5jbHVkZSBjb3JyZXNwb25kaW5nICJhPXJlY3Zvbmx5IiBDTFVF LQ0KPiA+PiDCoMKgwqDCoCBjb250cm9sbGVkIG1lZGlhIGxpbmVzDQo+ID4+DQo+ID4+IDUuMyBz YXlzICJTSE9VTEQgc2V0IGE9aW5hY3RpdmUiIGluIHRoZSBleGFjdCBzYW1lIGNpcmN1bXN0YW5j ZXMNCj4gPj4gNC41LjIuMiBzYXlzICJTSE9VTEQgc2V0IGE9c2VuZG9ubHkiLiBQbGVhc2UgcGlj ayBvbmUgZXhwZWN0ZWQNCj4gPj4gYmVoYXZpb3IgYW5kIG1ha2Ugc3VyZSBib3RoIHNlY3Rpb25z IGFncmVlLiBJZGVhbGx5LCB5b3Ugd291bGQNCj4gPj4gcmVmYWN0b3IgdGhpcyBzbyB0aGF0IHRo ZSBub3JtYXRpdmUgc3RhdGVtZW50IGlzIG1hZGUgaW4gb25seSBvbmUNCj4gPj4gbG9jYXRpb24u DQo+ID4+DQo+ID4+IFtSb2JdIEkgZG9uJ3QgdGhpbmsgdGhlc2Ugc2VjdGlvbnMgYXJlIGluIGNv bmZsaWN0IC0gdGhlIHF1b3RlZA0KPiA+PiBwYXJhZ3JhcGggZnJvbSBzZWN0aW9uIDUuMyBpcyBy ZWZlcnJpbmcgdG8gY2FzZXMgd2hlcmUgdGhlIFNEUCBvZmZlcg0KPiA+PiBpbmNsdWRlcyAiYT1z ZW5kb25seSIgbGluZXMsIHdoZXJlYXMgdGhlIHNlY3Rpb24gaW4gNC41LjIuMiBzYXlpbmcNCj4g Pj4gIlNIT1VMRCBzZXQgYT1zZW5kb25seSIgaXMgdGFsa2luZyBhYm91dCB0aGF0IHRoZSBTRFAg KmFuc3dlcioNCj4gPj4gaW5jbHVkaW5nICJhPXNlbmRvbmx5IiBsaW5lcyBpbiByZXNwb25zZSB0 byB0aGUgb2ZmZXJlcidzDQo+ID4+ICJhPXJlY3Zvbmx5IiBsaW5lcy4gSXQncyB0aGUgcGFyYWdy YXBoIGJlbG93IHRoYXQgY29ycmVzcG9uZHMgdG8gdGhlDQo+ID4+IHF1b3RlZCA1LjMgcGFyYWdy YXBoLCB3aGljaCBzYXlzIHRoYXQgdGhlIFNEUCAqYW5zd2VyKiBNQVkgaW5jbHVkZQ0KPiA+PiAi YT1yZWN2b25seSIgaW4gaXRzIHJlc3BvbnNlIG9yICJNQVkiIHdhaXQsIGFuZCB0aGVuIHJlZmVy ZW5jZXMNCj4gPj4gc2VjdGlvbiA1LjMsIHdoaWNoIGlzIHdoZXJlIHRoZSBxdW90ZWQgcGFyYWdy YXBoIHdpdGggcmVjb21tZW5kYXRpb24NCj4gPj4gdGhhdCBpbXBsZW1lbnRhdGlvbnMgc2hvdWxk IHdhaXQgYW5kIHNlbmQgYSBzdWJzZXF1ZW50IFNEUCBpcw0KPiA+PiBpbmNsdWRlZC4gV2UgZW5k ZWQgdXAgd2l0aCB0aGlzIGFwcHJvYWNoIGJlY2F1c2UsIGV2ZW4gdGhvdWdoIGluIG1vc3QNCj4g Pj4gY2FzZXMgaW1wbGVtZW50YXRpb25zIHNob3VsZCB3YWl0IHVudGlsIHRoZXkgcmVjZWl2ZSB0 aGUgaW5mb3JtYXRpb24NCj4gPj4gYWJvdXQgdGhlIGVuY29kaW5ncyBhbmQgdGhlaXIgY29udGVu dHMgdmlhIHRoZSBDTFVFIGNoYW5uZWwsIHRoZXJlDQo+ID4+IGFyZSBzb21lIHZhbGlkIHVzZS1j YXNlcyB3aGVyZSBpbXBsZW1lbnRhdGlvbnMgd2lsbCBrbm93IHRoaXMNCj4gPj4gdXAtZnJvbnQg YW5kIGhlbmNlIGNhbiBhdm9pZCB0aGUgbmVlZCBmb3IgbXVsdGlwbGUgU0RQIGV4Y2hhbmdlcy4N Cj4gPg0KPiA+IEFoLCBva2F5LiBJIHNlZSB3aGF0IHlvdSdyZSBnZXR0aW5nIGF0IGhlcmUuIEkg dGhpbmsgdGhlIHByb2JsZW0sDQo+ID4gdGhlbiwgaXMgdGhhdCB0aGUgbGFuZ3VhZ2UgaW4gNS4z IGlzbid0IHJlYWxseSBub3JtYXRpdmUgcGVyIHNlIChvciwNCj4gPiByYXRoZXIsIGl0IHNob3Vs ZG4ndCBiZSBub3JtYXRpdmUpLCBhcyBtdWNoIGFzIGl0IGlzIGlsbHVzdHJhdGl2ZS4NCj4gPiAo VGhpcyBpcyByZWluZm9yY2VkIGJ5IHRoZSBwaHJhc2luZyAiRm9yIGV4YW1wbGUuLi4iKSBJIHdv dWxkIHByb3Bvc2U6DQo+ID4NCj4gPiDCoMKgwqAgRm9yIGV4YW1wbGUsIGFuIGFuc3dlcmVyIHRo YXQgcmVjZWl2ZXMgYSBuZXcNCj4gPiDCoMKgwqAgU0RQIG9mZmVyIHdpdGggdGhyZWUgbmV3ICJh PXNlbmRvbmx5IiBDTFVFICJtPSIgbGluZXMgZm9yIHdoaWNoIGl0DQo+ID4gwqDCoMKgIGhhcyBy ZWNlaXZlZCBubyBDTFVFIEFkdmVydGlzZW1lbnQgcHJvdmlkaW5nIHRoZSBjb3JyZXNwb25kaW5n DQo+ID4gwqDCoMKgIGNhcHR1cmUgaW5mb3JtYXRpb24gd291bGQgdHlwaWNhbGx5IGluY2x1ZGUg Y29ycmVzcG9uZGluZw0KPiA+ICJhPWluYWN0aXZlIg0KPiA+IMKgwqDCoCBsaW5lcyBpbiBpdHMg YW5zd2VyLCBhbmQgbWFrZSBhIG5ldyBTRFAgb2ZmZXIgd2l0aCAiYT1yZWN2b25seSINCj4gPiBv bmx5DQo+ID4gwqDCoMKgIHdoZW4gYW5kIGlmIGEgbmV3IEFkdmVydGlzZW1lbnQgYXJyaXZlcyB3 aXRoIENhcHR1cmVzIHJlbGV2YW50IHRvDQo+ID4gwqDCoMKgIHRob3NlIEVuY29kaW5ncy4NCj4g Pg0KPiA+DQo+ID4+IEdlbmVyYWwsIGJ1dCBzdXJmYWNlZCBpbiBzZWN0aW9uIDg6IFRoZSBwcm9j ZWR1cmVzIGRlc2NyaWJlZCBpbiB0aGlzDQo+ID4+IGRvY3VtZW50IHZpcnR1YWxseSBndWFyYW50 ZWUgdGhhdCBldmVyeSBDTFVFIGNhbGwgdGhhdCBpcyBlc3RhYmxpc2hlZA0KPiA+PiB3aWxsIHJl c3VsdCBpbiBnbGFyZSAocmVzcG9uc2UgY29kZSA0OTEpIGJlaGF2aW9yLiBUaGlzIG1pZ2h0IGNh dXNlDQo+ID4+IHRoZSBvcGVyYXRpb25zIGZvbGtzIHNvbWUgaGVhcnRidXJuLCBhcyBpdCBtZWFu cyB0aGF0IHRoZWlyIGVycm9yDQo+ID4+IGNvdW50cyB3aWxsIHNwaWtlIG9uY2UgQ0xVRSBpcyBk ZXBsb3llZC4gRnVydGhlciwgd2l0aG91dCBmYWlybHkNCj4gPj4gYWR2YW5jZWQgYW5hbHlzaXMg b2YgdGhlIGNhbGxmbG93LCB0aGlzIHdpbGwgbWFrZSBpdCBpbXBvc3NpYmxlIHRvDQo+ID4+IGRp c3Rpbmd1aXNoICJleHBlY3RlZCIgQ0xVRS1pbmR1Y2VkIDQ5MXMgZnJvbSB0aGUgb2RkYmFsbCBh Y3R1YWwNCj4gPj4gZ2xhcmUgY29uZGl0aW9ucyB1c3VhbGx5IHNpZ25hbGVkIGJ5IDQ5MS4gSGFz IGFueSBjb25zaWRlcmF0aW9uIGJlZW4NCj4gPj4gZ2l2ZW4gdG8gYXZvaWRpbmcgdGhpcyBzaXR1 YXRpb24gKGUuZy4sIGJ5IGhhdmluZyB0aGUgY2FsbGVkIHBhcnR5DQo+ID4+IHdhaXQgb24gdGhl IG9yZGVyIG9mIG9uZSBzZWNvbmQgYmVmb3JlIGF0dGVtcHRpbmcgdG8gbmVnb3RpYXRlIGl0cw0K PiA+PiBlbmNvZGluZ3MpPw0KPiA+Pg0KPiA+PiBbUm9iXSBJIGRlZmluaXRlbHkgYWdyZWUgdGhh dCBnbGFyZSBpcyBtdWNoIG1vcmUgbGlrZWx5IGF0IHRoZSBzdGFydA0KPiA+PiBvZiBhIENMVUUg Y2FsbC4gVGhlcmUgd2FzIHF1aXRlIGEgYml0IG9mIGRpc2N1c3Npb24gaW4gdGhlIGdyb3VwIG9u DQo+ID4+IHRoZSBwcm9zIGFuZCBjb25zIG9mIGludHJvZHVjaW5nIGFuIGFzeW1tZXRyeSBpbnRv IHRoZSBjYWxsIG1lc3NhZ2luZw0KPiA+PiB0byBhdm9pZCAob3IgcmVkdWNlIHRoZSBmcmVxdWVu Y3kpIG9mIGdsYXJlLCBhbmQgaG93IGJlc3QgdG8gZG8gc28sDQo+ID4+IGJ1dCB0aGUgZmluYWwg Y29uY2x1c2lvbiBpbiB0aGUgZW5kIHdhcyBub3QgdG8gZG8gc28gYW5kIHRvIHJlbHkgb24NCj4g Pj4gU0lQJ3MgbWVjaGFuaXNtcyB0byByZXNvbHZlIGl0Lg0KPiA+DQo+ID4gU3VyZS4gV2hhdCBJ J2QgbGlrZSB0byBoYXZlIHBvc2l0aXZlIGNvbmZpcm1hdGlvbiBvbiBpczogZGlkIHRoZQ0KPiA+ IHdvcmtpbmcgZ3JvdXAgc3BlY2lmaWNhbGx5IGNvbnNpZGVyIHRoZSBvcGVyYXRpb25hbCBhc3Bl Y3RzIG9mIHRoaXMNCj4gPiBkZWNpc2lvbj8gSSBhZ3JlZSB0aGF0IGl0IHdvcmtzIGZyb20gYSBw cm90b2NvbCBwZXJzcGVjdGl2ZS4gSSdtIGp1c3QNCj4gPiB3b3JyaWVkIHRoYXQgaXQgd2lsbCBn aXZlIG9wZXJhdG9ycyB1bm5lY2Vzc2FyeSBkaWZmaWN1bHR5Lg0KPiA+DQo+ID4+IFNlY3Rpb24g MTA6IEl0IGlzIHJhdGhlciB1bnVzdWFsIHRvIGluY2x1ZGUgYXV0aG9ycyBpbiB0aGUNCj4gPj4g YWNrbm93bGVkZ2VtZW50cyBzZWN0aW9uLiBGb3IgZWFjaCBvZiBSb2IgSGFuc2VuLCBQYXVsIEt5 eml2YXQsIGFuZA0KPiA+PiBDaHJpc3RpYW4gR3JvdmVzLCBJIHN1Z2dlc3QgcmVtb3ZpbmcgdGhl IGluZGl2aWR1YWwncyBuYW1lIGZyb20NCj4gPj4gZWl0aGVyIHRoZSBBY2tub3dsZWRnZW1lbnRz IHNlY3Rpb24gb3IgZnJvbSB0aGUgYXV0aG9ycyBsaXN0Lg0KPiA+Pg0KPiA+PiBbUm9iXSBUaGUg YXV0aG9ycyBsaXN0IGhhc24ndCByZWFsbHkgYmVlbiB1cGRhdGVkIHNpbmNlIHRoZSBpbml0aWFs DQo+ID4+IHN0YWdlcy4gTG9va2luZyBhdCBvdGhlciBkb2NzIGxpa2UgdGhlIGZyYW1ld29yayBv bmUgSSBjYW4gc2VlDQo+ID4+IHRoZXkndmUgYmVlbiByZXZpc2VkIGEgZmFpciBiaXQuIEZvciBu b3cgSSd2ZSBsZWZ0IHRoZSBhdXRob3JzIGFzLWlzDQo+ID4+IGFuZCByZW1vdmVkIHRoZSBkdXBs aWNhdGUgbmFtZXMgZnJvbSB0aGUgYWNrbm93bGVkZ2VtZW50cywgYnV0IHdpbGwNCj4gPj4gcmVh Y2ggb3V0IHRvIFBhdWwgYW5kIFJvbmkgZm9yIGd1aWRhbmNlIGhlcmUuDQo+ID4NCj4gPiBUaGFu a3MuIEVpdGhlciByZXNvbHV0aW9uIG1ha2VzIHNlbnNlIHRvIG1lLCBhbmQgSSBzdXNwZWN0IHRo YXQgdGhlDQo+ID4gY3VycmVudCBhdXRob3IgbGlzdCBpcyBjb3JyZWN0Lg0KPiA+DQo+ID4+IFNl Y3Rpb24gODogIkluIHRoaXMgY2FzZSBCb2IgaXMgdGhlIENoYW5uZWwgSW5pdGlhdG9yLi4uIiB0 aGlzIGlzbid0DQo+ID4+IGNsZWFyIChhbmQsIGluIGZhY3QsIGl0J3MgY291bnRlcmludHVpdGl2 ZSB0byBtZSkgLS0gcGVyaGFwcyB0aGVyZQ0KPiA+PiBzaG91bGQgYmUgc29tZSB0ZXh0IGluZGlj YXRpbmcgKndoeSogQm9iIGlzIHRoZSBDaGFubmVsIEluaXRpYXRvci4NCj4gPj4NCj4gPj4gW1Jv Yl0gSSd2ZSBtYWRlIGV4cGxpY2l0IHRoYXQsIHdoZW4gdGhlIFNDVFAgb3ZlciBEVExTIGNoYW5u ZWwgaXMNCj4gPj4gbmVnb3RpYXRlZCwgQm9iIGVuZHMgdXAgdGhlIGNsaWVudCBhbmQgaGVuY2Ug dGhlIENoYW5uZWwgSW5pdGlhdG9yLg0KPiA+PiBIb3dldmVyLCB3aGVuIEkgd2VudCB0byBkb3Vi bGUtY2hlY2sgdGhhdCB0aGF0IHdhcyBob3cgdGhlIGluaXRpYXRvcg0KPiA+PiByb2xlIHdhcyBh c3NpZ25lZCwgSSBjYW4ndCBhY3R1YWxseSBmaW5kIGFueXRoaW5nIGluIHRoZSBwcm90b2NvbCBv cg0KPiA+PiBkYXRhY2hhbm5lbCBkb2N1bWVudCB0aGF0IGRlZmluZXMgd2hvIGVuZHMgdXAgd2l0 aCB0aGUgSW5pdGlhdG9yDQo+ID4+IHJvbGUuIFRoYXQgZGVmaW5pdGVseSBzZWVtcyBsaWtlIHNv bWV0aGluZyB0aGF0IHdlIG5lZWQgdG8gZml4Li4uDQo+ID4+ICh1bmxlc3MgSSd2ZSBqdXN0IGZh aWxpbmcgdG8gZmluZCBpdCkuIFNpbW9uLCBpcyB0aGlzIHNvbWV0aGluZw0KPiA+PiB5b3UncmUg cGxhbm5pbmcgdG8gYWRkcmVzcz8NCj4gPg0KPiA+IFRoZSByZWFzb24gdGhpcyBzZWVtcyBjb3Vu dGVyLWludHVpdHZlIHRvIG1lIGlzIHRoYXQgaXQgaXMgYmFja3dhcmRzDQo+ID4gZnJvbSBob3cg UlRDV0VCIChKU0VQKSB3b3JrcyBpbiB0aGUgZ2VuZXJhbCBjYXNlLiBUbyBiZSBjbGVhciwgZm9y DQo+ID4gZGF0YWNoYW5uZWxzLCB0aGUgVExTIGNsaWVudCBpcyBzZWxlY3RlZCBieSB0aGUgImE9 c2V0dXAiIGF0dHJpYnV0ZTsNCj4gPiBhbmQgSlNFUCBpbXBsZW1lbnRhdGlvbnMgYXJlIHJlcXVp cmVkIChNVVNUKSB0byBwdXQgImE9c2V0dXA6YWN0cGFzcyINCj4gPiBpbiB0aGVpciBvZmZlcnMs IGFuZCBleHBlY3RlZCAoU0hPVUxEKSB0byBwdXQgImE9c2V0dXA6YWN0aXZlIiBpbg0KPiA+IHRo ZWlyIGFuc3dlcnMuIFRoZSByYXRpb25hbGUgaGVyZSBpczogdGhlIHdheSBJQ0UgZW5kcyB1cCB3 b3JraW5nLCB0aGUNCj4gPiBhbnN3ZXJlciB3aWxsIGhhdmUgdGhlIGZpcnN0IG9wcG9ydHVuaXR5 IHRvIHNlbmQgYSBwYWNrZXQsIHNvIHRoaXMNCj4gPiByZWR1Y2VzIG92ZXJhbGwgc2V0dXAgdGlt ZSBieSB+MS8yLVJUVC4NCj4gPg0KPiA+IE9mIGNvdXJzZSwgQ0xVRSBpcyBmcmVlIHRvIGRvIHRo aXMgaG93ZXZlciBpdCB3YW50cyBbMV07IGJ1dCBkb2luZyBpdA0KPiA+IG9wcG9zaXRlIGZyb20g UlRDV0VCIGlzIGxpa2VseSB0byBjb25mdXNlIHBlb3BsZSBiZXlvbmQganVzdCBtZS4gSQ0KPiA+ IHRoaW5rIHlvdSdkIGFsc28gbmVlZCBhIHJlYXNvbmFibHkgZ29vZCByYXRpb25hbGUsIGFzIGEg bmHDr3ZlIGFuYWx5c2lzDQo+ID4gb2YgQ0xVRSBpcyB0aGF0IGRvaW5nIGl0IHRoZSB3YXkgeW91 IGN1cnJlbnRseSBoYXZlIGluIHlvdXIgZXhhbXBsZXMNCj4gPiBpcyBnZW5lcmFsbHkgZ29pbmcg dG8gaW1wb3NlIGFuIGFkZGl0aW9uYWwgMS8yLVJUVCBkZWxheSBvbg0KPiA+IGRhdGFjaGFubmVs IGVzdGFibGlzaG1lbnQuIEJ1dCBJIGZyZWVseSBhZG1pdCB0aGF0IEkgaGF2ZW4ndCBzcGVudCBh DQo+ID4gbG90IG9mIHRpbWUgdGhpbmtpbmcgYWJvdXQgdGhlIGxvdy1sZXZlbCBkZXRhaWxzLCBh bmQgY291bGQgYmUNCj4gPiBvdmVybG9va2luZyBzb21ldGhpbmcuDQo+ID4NCj4gPiAvYQ0KPiA+ DQo+ID4gX19fXw0KPiA+IFsxXSBTdWJqZWN0IHRvIHRoZSBjb25zdHJhaW50cyBpbg0KPiA+IDxo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1tbXVzaWMtc2N0cC1zZHAtMTE+ LCBzZWN0aW9ucw0KPiA+IDEwIC0gMTENCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBjbHVlIG1haWxpbmcgbGlzdA0KPiBjbHVlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0K From nobody Mon Nov 20 06:11:12 2017 Return-Path: X-Original-To: clue@ietf.org Delivered-To: clue@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E231E126B7F; Mon, 20 Nov 2017 06:11:10 -0800 (PST) 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.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151118707088.21986.12411609151332421549@ietfa.amsl.com> Date: Mon, 20 Nov 2017 06:11:10 -0800 Archived-At: Subject: [clue] I-D Action: draft-ietf-clue-signaling-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 14:11:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence WG of the IETF. Title : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) Authors : Robert Hansen Paul Kyzivat Lennard Xiao Christian Groves Filename : draft-ietf-clue-signaling-13.txt Pages : 41 Date : 2017-11-20 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-13 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-13 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 Mon Nov 20 06:27:30 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B81126C0F for ; Mon, 20 Nov 2017 06:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 ZRLM9-UimLAf for ; Mon, 20 Nov 2017 06:27:26 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46247129AA3 for ; Mon, 20 Nov 2017 06:27:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3811; q=dns/txt; s=iport; t=1511188046; x=1512397646; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Xci7vzJU3J6krbjyoWVVD19znVi1XslFlHhPtIL8XP0=; b=WjnlYJyD7wpQWdbfcXefcIsIqsg+zT57EBFO+16f8XoQOG/HuLas1ICB jiDitPrmpft3i8ZTWwN0wJV1IC985oV8jTEuWYtQhxFYN1GDVbPf0ixH1 3m3zAJIzB+EP4WoMMPrv3ESgfWyvfxVs/TvNkvudy9HHKnNEE7phhE4pC Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DYAADd5RJa/40NJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOLmZuJweOF48ogX2WYoIRChgNhRYChH0/GAEBAQEBAQEBAWs?= =?us-ascii?q?dC4UeAQEBAQMBATg0FwQCAQgRBAEBHwkHJwsUCQgCBBMIih0Qqn+KdAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2DNIIHgz6DK4NFh04FgS0BoQ4CAodwjRGCH2KFKos?= =?us-ascii?q?qjHKJEwIRGQGBOQEfOYF0ejQqgRGBUwmCUxyBZ3cBAQGKOYEUAQEB?= X-IronPort-AV: E=Sophos;i="5.44,427,1505779200"; d="scan'208";a="33917425" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Nov 2017 14:27:25 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id vAKERPCX003110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 20 Nov 2017 14:27:25 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 20 Nov 2017 08:27:24 -0600 Received: from xch-rcd-016.cisco.com ([173.37.102.26]) by XCH-RCD-016.cisco.com ([173.37.102.26]) with mapi id 15.00.1320.000; Mon, 20 Nov 2017 08:27:24 -0600 From: "Rob Hansen (rohanse2)" To: "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-13.txt Thread-Index: AQHTYglvQleWbXYScUyBDcWxXVkPk6MdUSkQ Date: Mon, 20 Nov 2017 14:27:24 +0000 Message-ID: <8b2568b889674d31a931ea2610cb6c31@XCH-RCD-016.cisco.com> References: <151118707088.21986.12411609151332421549@ietfa.amsl.com> In-Reply-To: <151118707088.21986.12411609151332421549@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.230.72.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 14:27:28 -0000 Hi all, was hoping to get this out last week, but inevitably a few things d= id catch fire.=20 Not a huge number of changes since -12; changelog is at https://tools.ietf.= org/html/draft-ietf-clue-signaling-13#section-13 The major change is adding a section on the actions to take in the event of= a failure of the protocol (either due to loss of the transport or an error= on the channel). Originally I thought this should go in the protocol docum= ent, but since it involves interactions between the protocol, SIP and media= I figure the signalling document is actually probably a better place for i= t. It can be found at https://tools.ietf.org/html/draft-ietf-clue-signaling= -13#section-4.5.4.4 , and currently reads: " 4.5.4.4. CLUE protocol failure mid-call In contrast to the specific disablement of the use of CLUE described above, the CLUE channel may fail unexpectedly. Two circumstances where this can occur are: o The CLUE data channel terminates, either gracefully or ungracefully, without any corresponding SDP renegotiation. o The CLUE protocol enters an unrecoverable error state as defined in Section 6. of [I-D.ietf-clue-protocol], either the 'MP- TERMINATED' state for the Media Provider or 'MC-TERMINATED' for the Media Consumer. In this circumstance implementations MUST continue to transmit and receive CLUE-controlled media on the basis of the last negotiated CLUE messages, until the CLUE protocol is disabled mid-call by an SDP exchange as defined in Section 4.5.4.3. Implementations MAY choose to send such an SDP request to disable CLUE immediately or MAY continue on in a call-preservation mode. " Hopefully this reflects people's understanding of what should be done here.= Not sure if the final sentence is strictly necessary, but figured it was m= ore helpful to state it explicitly. Rob -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 20 November 2017 14:11 To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-13.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tEleprese= nce WG of the IETF. Title : Session Signaling for Controlling Multiple Stream= s for Telepresence (CLUE) Authors : Robert Hansen Paul Kyzivat Lennard Xiao Christian Groves Filename : draft-ietf-clue-signaling-13.txt Pages : 41 Date : 2017-11-20 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol and the CLUE data channel are used in conjunction with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-13 https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-13 Please note that it may take a couple of minutes from the time of submissio= n 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/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Mon Nov 20 09:50:05 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBFF12DDD2 for ; Mon, 20 Nov 2017 09:50:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vyOXpsdo-JKt for ; Mon, 20 Nov 2017 09:50:00 -0800 (PST) Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF07129D9D for ; Mon, 20 Nov 2017 09:50:00 -0800 (PST) X-AuditID: 12074413-3a3ff70000007929-e1-5a1315c79341 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id DD.C9.31017.7C5131A5; Mon, 20 Nov 2017 12:49:59 -0500 (EST) Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id vAKHnwwt031510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Nov 2017 12:49:59 -0500 To: clue@ietf.org References: <151118707088.21986.12411609151332421549@ietfa.amsl.com> <8b2568b889674d31a931ea2610cb6c31@XCH-RCD-016.cisco.com> From: Paul Kyzivat Message-ID: <036a855b-aa42-e48e-0565-b139b0c16aaa@alum.mit.edu> Date: Mon, 20 Nov 2017 12:49:58 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8b2568b889674d31a931ea2610cb6c31@XCH-RCD-016.cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrIIsWRmVeSWpSXmKPExsUixO6iqHtcVDjKYH+rksX+U5eZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcXPeFpaC+woVD9pPMzYw7pTsYuTkkBAwkZh28xRzFyMXh5DA DiaJ9u+PWSGcr0wS16+uZOxi5OAQFnCQuD+9EsQUERCUeHlFEKRXSKBeYk33FiYQm01AS2LO of8sICW8AvYSZ686g5gsAqoSf5ckgVSICqRJ3JnxEKyaF2jIyZlPWEBsTgFXiTuTjjOD2MwC ZhLzNj+EssUlbj2ZzwRhy0tsfzuHeQIj/ywk7bOQtMxC0jILScsCRpZVjHKJOaW5urmJmTnF qcm6xcmJeXmpRbrmermZJXqpKaWbGCHhKLyDcddJuUOMAhyMSjy8H3iEooRYE8uKK3MPMUpy MCmJ8q76DRTiS8pPqcxILM6ILyrNSS0+xCjBwawkwqsWBZTjTUmsrEotyodJSXOwKInzqi1R 9xMSSE8sSc1OTS1ILYLJynBwKEnw3hQRjhISLEpNT61Iy8wpQUgzcXCCDOcBGp4JUsNbXJCY W5yZDpE/xWjM0dNz4w8Tx7OZrxuYhVjy8vNSpcR5HYBJQUgApDSjNA9uGiylvGIUB3pOmJcD pIoHmI7g5r0CWsUEtMrlAj/IqpJEhJRUA6PT8pnuS/uZhOI37oruv+16x2Bt+441e80vZ9Sd Ofc3PttqY2LgEY6c0ILj9kJTD7v5OfuGvp6wM6Rw19rqjB7xpJDUc98MLJT6LlXY6M+93b3D t/j6LHbLbQwNrmciJ8Ry/lt25tqRWb3F4Wq86lGV5TY/bOSmVhzWy8mSmH99ntiqWdUVfEos xRmJhlrMRcWJAM4dViUEAwAA Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-13.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:50:02 -0000 On 11/20/17 9:27 AM, Rob Hansen (rohanse2) wrote: > Hi all, was hoping to get this out last week, but inevitably a few things did catch fire. > > Not a huge number of changes since -12; changelog is at https://tools.ietf.org/html/draft-ietf-clue-signaling-13#section-13 > > The major change is adding a section on the actions to take in the event of a failure of the protocol (either due to loss of the transport or an error on the channel). Originally I thought this should go in the protocol document, but since it involves interactions between the protocol, SIP and media I figure the signalling document is actually probably a better place for it. It can be found at https://tools.ietf.org/html/draft-ietf-clue-signaling-13#section-4.5.4.4 , and currently reads: > > " > 4.5.4.4. CLUE protocol failure mid-call > > In contrast to the specific disablement of the use of CLUE described > above, the CLUE channel may fail unexpectedly. Two circumstances > where this can occur are: > > o The CLUE data channel terminates, either gracefully or > ungracefully, without any corresponding SDP renegotiation. > > o The CLUE protocol enters an unrecoverable error state as defined > in Section 6. of [I-D.ietf-clue-protocol], either the 'MP- > TERMINATED' state for the Media Provider or 'MC-TERMINATED' for > the Media Consumer. > > In this circumstance implementations MUST continue to transmit and > receive CLUE-controlled media on the basis of the last negotiated > CLUE messages, until the CLUE protocol is disabled mid-call by an SDP > exchange as defined in Section 4.5.4.3. Implementations MAY choose > to send such an SDP request to disable CLUE immediately or MAY > continue on in a call-preservation mode. > " > > Hopefully this reflects people's understanding of what should be done here. Not sure if the final sentence is strictly necessary, but figured it was more helpful to state it explicitly. This sounds just right to me. Thanks, Paul > Rob > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: 20 November 2017 14:11 > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-signaling-13.txt > > > 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 : Session Signaling for Controlling Multiple Streams for Telepresence (CLUE) > Authors : Robert Hansen > Paul Kyzivat > Lennard Xiao > Christian Groves > Filename : draft-ietf-clue-signaling-13.txt > Pages : 41 > Date : 2017-11-20 > > Abstract: > This document specifies how CLUE-specific signaling such as the CLUE > protocol and the CLUE data channel are used in conjunction with each > other and with existing signaling mechanisms such as SIP and SDP to > produce a telepresence call. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-clue-signaling-13 > https://datatracker.ietf.org/doc/html/draft-ietf-clue-signaling-13 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-13 > > > 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/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >