From nobody Mon Jan 2 08:15:26 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 6A3DE129699; Mon, 2 Jan 2017 08:15:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148337372543.21869.11741316152883827300.idtracker@ietfa.amsl.com> Date: Mon, 02 Jan 2017 08:15:25 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-11.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 16:15:25 -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 of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-11.txt Pages : 60 Date : 2017-01-02 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-11 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 Jan 2 08:19:03 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 39D031296BA for ; Mon, 2 Jan 2017 08:19:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 FCx5GTMs1ZNy for ; Mon, 2 Jan 2017 08:18:59 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B88F1296AF for ; Mon, 2 Jan 2017 08:18:59 -0800 (PST) X-ASG-Debug-ID: 1483373936-05f2757d451acba0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id MLD6m0LO34bWnq2a (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 02 Jan 2017 17:18:56 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from 10-21-48-222.0200.sob.it.iosda.org ([193.206.114.71]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v02GIsMS021700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2017 17:18:55 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] WGLC for draft-ietf-clue-protocol-10 In-Reply-To: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> Date: Mon, 2 Jan 2017 17:18:54 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> To: Christian Groves X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1483373936 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 193.206.114.71 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35523 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 16:19:02 -0000 Dear Christian, thanks a lot for your review. Please find in-line our answers. Cheers, Simon & Roberta > Here are my comments: >=20 > Cl.1 bullet 1: Change "envisioned" to "defined". The information isn't = some future thing. Fixed. > Cl.1 para 2: Change "upon" to "over". There's other instances in the = draft also. Fixed. > Cl.1 para 3: The section says "Participant state machines" whereas the = referred to section 6 is called "Protocol state machines=E2=80=9D. Fixed. > Cl.2 Endpoint: "...and exactly one [RFC4353 = ] Participant (which, in turn, = includes exactly one SIP User Agent)." Can we make the SIP aspect more = as an example? E.g. A WebRTC endpoint doesn't include a SIP user agent. = How about something like "...and exactly one participant (e.g. a = [RFC4353] paricipant).=E2=80=9D Fixed. > Cl.4 para 1: change "...we are not able..." -> "...it is not = possible=E2=80=A6" Fixed. > Cl.4 para 1: change "Such information is designed...." -> "Such = information is contained=E2=80=A6" Fixed. > Cl.4 para 2: "Three main communication layers" would it be better to = say "phases" instead of "layers=E2=80=9D? Fixed. > Cl.4 bullet 2: "The version and options negotiation can be performed = once and only at this stage." clarification "... can be performed once = during the CLUE session and =E2=80=A6." Fixed. > Cl.4 para 3: "is is", delete one. Fixed. > Cl.4 para 4:"After that negotiation..." -> "After the negotiation=E2=80=A6= " Fixed. > Cl.4 para last: "Such messages will be..." -> "Such messages are=E2=80=A6= " Fixed. > Cl.5: "The basic structure determines the mandatory information that = is > carried within each CLUE message. Such an information is made by:" = can this be simplified to say "The mandatory information contained in = each CLUE message is:=E2=80=9D? Fixed. > Cl.5 last bullet: "Allowed values are of this kind: "1.3", "2.4", = etc." change to "E.g. "1.3", "2.4" etc." Otherwise it sounds like the = values are normative. Fixed. > General: The document talks about extensions and options. Are they = different? if not should we use one term. The difference is indeed a subtle one. The idea should be that an option = is a predefined capability of the protocol that is not mandatory, = whereas an extension is a brand new feature one might be interested in = defining for their own purpose. Technically speaking, they look exactly = the same, as section 8 clearly illustrates.=20 > Cl.5.2: "RESPONSE contains mandatorily..." -> "RESPONSE contains a = mandatory=E2=80=A6" Fixed. > Cl.5.2: Is there a reason why we indicated that both the response code = AND string are mandatory? It seems like an unnecessary duplication. Its = not clear that text other than what has be defined may be sent. OK. We made the "reasonString=E2=80=9D element become optional in = version-11 of the schema (minOccurs=3D=E2=80=9C0=E2=80=9D). > Cl.5.2: The XML doesn't match the XML in section 9. E.g. responseCode = is of type "xs:short" in section 9 its type "type=3D"responseCodeType=E2=80= =9D. Fixed. > Cl.5.2 last paragraph: Can the paragraph be simplified to say "Upon = reception of the OPTIONS RESPONSE the version to be used is provided in = the tag of the message.=E2=80=9D? Done. > Cl.5.2 last paragraph: "the CLUE dialogue will be those" -> "the CLUE = dialogue are those=E2=80=9D Fixed. > Cl.5.3 para 1: "The MP sends to the MC an ADV as soon " -> "The MP = sends an ADV to the MC as soon=E2=80=A6" Fixed. > Cl.5.3 para 1: "its media CLUE telepresence capabilities change" -> = "its CLUE telepresence media capabilities change=E2=80=9D Fixed. > Cl.5.3 para 1: Rather than use "invalidates" would "replaces" be = better? Fixed. > Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth = harmonising how each message section describes this. We replaced =E2=80=9Cpicture=E2=80=9D with =E2=80=9Cschema excerpt=E2=80=9D= . Does this look ok? > Cl.5.4: The XML doesn't match the XML in section 9. E.g. responseCode = is of type "xs:short" in section 9 its type "type=3D"responseCodeType=E2=80= =9D. Fixed. > Cl.5.6: The XML doesn't match the XML in section 9. E.g. responseCode = is of type "xs:short" in section 9 its type "type=3D"responseCodeType=E2=80= =9D. Fixed. > Cl.5.6/General: Do we need some text indicating that there's no = partial execution of commands. E.g. If a MP is able to understand all = the selected capture encodings bar one. The whole command fails and = nothing is instantiated. We added the following sentence at the end of the section: "We remark that there is no partial execution of commands. As an = example, if a MP is able to understand all the selected capture = encodings except one, then the whole command fails and nothing is = instantiated." > Cl.5.7: It says future protocol version can introduce error codes? How = about options? It seems like an option could introduce a specific error = code. Based on the discussion in section 8, a new response code might indeed = be added through the =E2=80=9Cextension=E2=80=9D mechanism. Though, the = =E2=80=9Ccleanest=E2=80=9D way for achieving such a task in a formal way = is by adding the new response code to the list of codes published in the dedicated = IANA registry (see section 12.4.2 fo the draft). In the mentioned = section, we refer to future versions of the standard.=20 > Cl.5.7: Error code 302 is duplicated. The 2nd one should be 303. Fixed. > Cl.6 para 5: "Otherwise ("channel error")=E2=80=A6" Should we add an "if" between =E2=80=9COtherwise=E2=80=9D and the = parenthesis? Please advise on that. > Cl.6 para 1: "the MP is preparing" -> "the MP prepares=E2=80=9D Fixed. > Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates = to the transport (e.g. SCTP) rather than application level = timers/counters? I'm a bit confused about the descriptions in the draft = as we have a reliable transport. Namely, we state that the CLUE (application layer) protocol relies on = timeouts and retransmissions. Our interpretation is that we do need = timeouts and retransmissions for application-layer errors. > Cl.6.2 para 1: "Otherwise the MC is stuck in..." -> "Otherwise the MC = stays in=E2=80=A6" Fixed. > Cl.6.2 para 3: "If the ADV elaboration..." -> "If the ADV = processing=E2=80=A6" Fixed. > Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, = missing XML elements, etc.), and the number of times this has happened = is under the retry treshold," I don't understand why the retry threshold = comes in here? Wouldn't the MC simply send a NACK is there's an error. = It wouldn't wait for multiple instances of the erroneous message. The idea here is that the MC avoids entering a loop where the MP keeps = on sending an erroneous ADV hence forcing the MC to respond with a NACK. = If this situation iterates for a while (# of retries), the MC terminates = the ongoing CLUE =E2=80=9Csession=E2=80=9D. >=20 > Cl.6.2 para 3: "the MC sends a NACK message (i.e., an ACK with an > error response code) to the MP describing the problem via a proper > reason phrase." Isn't the reason code enough? Yep. Based on your suggestion, we made the reason phrase optional. > Cl.6.2 para 4: "the MC is preparing" -> "the MC prepares=E2=80=9D. Fixed. > Cl.6.2 para 5: "the MC is waiting" -> "the MC waits=E2=80=9D. Fixed. > Cl.7 para 3: "The version of the XML schema contained in the standard = document deriving from this draft will be 1.0." -> "This document = defines XML schema version 1.0=E2=80=9D. Fixed. > Cl.8 bullet 1: "...we may want to add more fields" -> "... more fields = may be added=E2=80=9D Fixed. > Cl.8 I think it would be very helpful to include an example syntax = showing the definition of a new capture attribute that could be used by = future people as a template. Its still not clear if there's any = distinction between "option" and "extension=E2=80=9D. See our answer above regarding extensions vs options. If we all agree = that they are practically the same thing, we can properly re-word things = in the document. About the example, a new capture attribute could be defined in a = separate schema to further describe, e.g., a video capture. Indeed, looking at the data model XML definition of a video capture, it = is possible to see that there is an element allowing for the = introduction of a new XML field in the XML description of the capture, = by keeping the compatibility with the CLUE data model schema: That means that a video capture might have, after the set of the generic = media capture attributes, a set of new attributes defined elsewhere, = i.e., in an XML schema defining an extension. Such a schema might look like the following: The video capture could be further described in the advertisement using = the element containing two extra information = ( and ) besides using the = attributes envisioned for a generic media capture.=20 As stated in this document, both the CP must be aware of the extension = schema and related semantics to use such an extension and negotiate it = via the OPTIONS and OPTIONS RESPONSE mechanism. > Cl.9: schemaLocation=3D"data-model-schema-12.xsd"/> Should this be "17" = instead of "12" to match the version number? Yes. Fixed. > Does this get updated to the relevant RFC number? This looks reasonable to me.=20 >=20 > Cl.10.1: "The associated Media Provider's telepresence capabilities = are > described in [I-D.ietf-clue-data-model-schema], Section "Sample XML > file"." I'm a bit confused because the example in 10.1 doesn't match = the one specified in cl.27/draft-ietf-clue-data-model-schema-17. Many of = the attribute values are different. Some of the syntax has different = names. e.g. capturePoint->captureOrigin. Fixed (the excerpt from the data model was not up to date). > Cl.10.1/10.2: protocol=3D"CLUE" v=3D"0.4" should this be "1.0" given = this is going for WGLC? Fixed. > Cl.12. Do we need to establish IANA registry for clue = options/extensions to manage the option names? Again, options/extensions probably deserve a further (final) thought. We = would like to hear feedback from the group. > Regards, Christian Thanks 1k for your precious review! From nobody Mon Jan 2 08:21:32 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 011AD1296BE for ; Mon, 2 Jan 2017 08:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1, 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 zb9sIosIACJb for ; Mon, 2 Jan 2017 08:21:28 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD43E1296BB for ; Mon, 2 Jan 2017 08:21:27 -0800 (PST) X-ASG-Debug-ID: 1483374085-05f2757d441acd00001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id 5AJMV6eMo8DyA56m (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 02 Jan 2017 17:21:25 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from 10-21-48-222.0200.sob.it.iosda.org ([193.206.114.71]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v02GLO7H021988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jan 2017 17:21:24 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_F9482085-C87F-4E8F-8ED6-9C4DF5DC7641" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Mark's WGLC comments on protocol-10 In-Reply-To: Date: Mon, 2 Jan 2017 17:21:25 +0100 Message-Id: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> References: To: Mark.Duckworth@polycom.com X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1483374085 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 193.206.114.71 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35523 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: clue@ietf.org Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 16:21:31 -0000 --Apple-Mail=_F9482085-C87F-4E8F-8ED6-9C4DF5DC7641 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Mark, thanks a lot for your review. Please find in-line our answers. Cheers, Simon & Roberta > 4. "three main communication layers" - I agree with Christian these = are phases, not layers. Fixed. > 5. clueId - it still isn't clear to me what is the use of this = element. It seems wasteful to include this element in every message. > Simon previously said "In my view, it is just a name for the CP". But = what is it used for? Can we delete clueId if it has no purpose? > Or if it has a purpose and is meant to be static, can we make it part = of the options message exchange rather than every message? And explain = what the purpose is? If we just look at the CLUE protocol level dialogue, the clueId provides = a means for properly identifying the interacting parties. What is wrong = with this? > "Each CP MUST be able to manage up to three (independent) streams of > sequence numbers" - sounds to me like it is really six streams of = sequence numbers. Because each of the three "streams" described actually = has separate independent sequence numbers for each direction. > - initiation phase send > - initiation phase receive > - MP send > - MP receive > - MC send > - MC receive > It also is misleading because it is not required to be both an MC and = an MP, so possibly only one of those applies. So it could be either four = streams of sequence numbers, or six streams. Got it. When we say =E2=80=9Cmanage=E2=80=9D we actually mean =E2=80=9Cbei= ng responsible for the creation and the update=E2=80=9D. So, we were = looking at the three roles mentioned above, but by focusing just on the = =E2=80=9Csending=E2=80=9D perspective. Would you like us to reword that = sentence?=20 > 5.2 "copied in the the" remove a =E2=80=9Cthe" Done. > 5.3 "an MP may send new ADV messages to replace the previously = advertised options" - this could be misunderstood as relating to the = options messages in the initiation phase. How about "an MP may send new = ADV messages to replace the previous advertisement=E2=80=9D Done. > Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout = and retry relates to the transport (e.g. SCTP) rather than application = level timers/counters? I'm a bit confused about the descriptions in the = draft as we have a reliable transport" > I thought the timeout and retry stuff was application level, not to = account for transport errors but rather to account for application = behavior such as an application not responding for whatever reason. So I = think it does need to be clarified if Christian and I interpreted it = differently. This is inline with our interpretation. See also our answer to = Christian=E2=80=99s point in the related e-mail. > Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is = unsuccessful (bad syntax, missing XML elements, etc.), and the number of = times this has happened is under the retry treshold," I don't understand = why the retry threshold comes in here? Wouldn't the MC simply send a = NACK is there's an error. It wouldn't wait for multiple instances of the = erroneous message." > My understanding is it gives the MP an opportunity to send a different = advertisement after it receives a nack. It doesn't have to send another = copy of the same advertisement. Agreed. As per above, see also our answer to Christian=E2=80=99s point = in the related e-mail. > 10.1 simple ADV - I suggest updating this to be consistent with the = sample XML file in the data model. We already fixed some problems with = that sample XML. I see problems, probably the same ones we already = fixed, here in the simple ADV example. For example captureID AC0 is a = video capture but the description says "main audio from the room". And = on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I = think we've done a good review of the XML in the data model, so let's = just use that as much as possible to avoid new mistakes in this = document. Done. Thank you for pointing this out. > 10.2 - same comment, I suggest using the already reviewed XML from = the data model, and show it here in the protocol message envelope. Done. > =20 > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue = --Apple-Mail=_F9482085-C87F-4E8F-8ED6-9C4DF5DC7641 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear Mark,

thanks a = lot for your review. Please find in-line our answers.

Cheers,

Simon = & Roberta

4. "three main communication = layers" - I agree with Christian these are phases, not = layers.

Fixed.

 5. = clueId - it still isn't clear to me what is the use of this element. It = seems wasteful to include this element in every = message.
Simon = previously said "In my view, it is just a name for the CP". But what is = it used for? Can we delete clueId if it has no purpose?
Or if it = has a purpose and is meant to be static, can we make it part of the = options message exchange rather than every message? And explain what the = purpose is?

If we = just look at the CLUE protocol level dialogue, the clueId provides a = means for properly identifying the interacting parties. What is wrong = with this?

 "Each = CP MUST be able to manage up to three (independent) streams = of
sequence = numbers" - sounds to me like it is really six streams of sequence = numbers. Because each of the three "streams" described actually has = separate independent sequence numbers for each direction.
- = initiation phase send
- initiation phase receive
- MP send
- MP receive
- MC = send
- MC = receive
It also is misleading because it is not required to be both = an MC and an MP, so possibly only one of those applies. So it could be = either four streams of sequence numbers, or six = streams.

Got it. When = we say =E2=80=9Cmanage=E2=80=9D we actually mean =E2=80=9Cbeing = responsible for the creation and the update=E2=80=9D. So, we were = looking at the three roles mentioned above, but by focusing just on the = =E2=80=9Csending=E2=80=9D perspective. Would you like us to reword that = sentence? 

 5.2 "copied in the the" remove = a =E2=80=9C= the"

Done.

 5.3 "an MP may send new ADV messages to replace the = previously advertised options" - this could be misunderstood as relating = to the options messages in the initiation phase. How about "an MP may = send new ADV messages to replace the previous advertisement=E2=80=9D

Done.

 Christian wrote: "Cl.6.1&6.2: Do we need to indicate that = the timeout and retry relates to the transport (e.g. SCTP) rather than = application level timers/counters? I'm a bit confused about the = descriptions in the draft as we have a reliable = transport"
I thought = the timeout and retry stuff was application level, not to account for = transport errors but rather to account for application behavior such as = an application not responding for whatever reason. So I think it does = need to be clarified if Christian and I interpreted it = differently.

This is = inline with our interpretation. See also our answer to Christian=E2=80=99s= point in the related e-mail.


 Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is = unsuccessful (bad syntax, missing XML elements, etc.), and the number of = times this has happened is under the retry treshold," I don't understand = why the retry threshold comes in here? Wouldn't the MC simply send a = NACK is there's an error. It wouldn't wait for multiple instances of the = erroneous message."
My = understanding is it gives the MP an opportunity to send a different = advertisement after it receives a nack. It doesn't have to send another = copy of the same advertisement.

Agreed. As per above, see also our answer to = Christian=E2=80=99s point in the related e-mail.

10.1 simple ADV - I suggest = updating this to be consistent with the sample XML file in the data = model. We already fixed some problems with that sample XML. I see = problems, probably the same ones we already fixed, here in the simple = ADV example. For example captureID AC0 is a video capture but the = description says "main audio from the room". And on page 36 sceneView = SE3 and SE4 are the same, so that is a mistake. I think we've done a = good review of the XML in the data model, so let's just use that as much = as possible to avoid new mistakes in this = document.

Done. = Thank you for pointing this out.

 10.2 - same comment, I suggest using the already reviewed XML = from the data model, and show it here in the protocol message = envelope.

Done.


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

= --Apple-Mail=_F9482085-C87F-4E8F-8ED6-9C4DF5DC7641-- From nobody Mon Jan 2 09:05:47 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 AF3A31296CF for ; Mon, 2 Jan 2017 09:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 uKDSVD_5iatA for ; Mon, 2 Jan 2017 09:05:44 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BFE01296CA for ; Mon, 2 Jan 2017 09:05:44 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-03v.sys.comcast.net with SMTP id O631cnLsxcKypO63KcBpPr; Mon, 02 Jan 2017 17:05:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483376742; bh=ZVpVdWm3WSUrFFBnxPmFR5XxFkwiAw2J6Wp/YR6XMnc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=g913KQQYkRfHEWnDXQloVeIf5JHVonXndaOM8unHJ6GMwyyUgsUi69luWWS+iStUd d+D7gkZbcVaDK3QwQ03ktmtOzZN4t6DclFS7CPW1ARk7qqC6X3P0uV2gfba+k+tWHn zrj0ekfZWF27vNUDlkqdTYBubkLYng538YGTpZZgWjJH/yXF7HlAmr6JzGy5Tk5l7f 6yuHKrADv/QisTMaMQY7PyuCWdLd8bOwvc3NsvVPQZW40Agwfti1SYxkIsslEDGaFn F/+4oj6kEpPGpV6C7YqIyNDjbHMSo2LsxpT9PvonYsC+6pEse405ln8MOKgdrW4UKC ns5Dz92GUq+WQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-15v.sys.comcast.net with SMTP id O63Jcs618W0VBO63KcDsSm; Mon, 02 Jan 2017 17:05:42 +0000 References: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> To: Mark Duckworth From: Paul Kyzivat X-Forwarded-Message-Id: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> Message-ID: <363f32ad-918f-b451-ec5b-dd073c99574c@comcast.net> Date: Mon, 2 Jan 2017 12:05:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> Content-Type: multipart/mixed; boundary="------------5583671185B0A17F073477CB" X-CMAE-Envelope: MS4wfLlMsL30PVM7Ki+vACgLJmcpUvU7T6VPMLFUMJWaMXnlZg+DpgSr8y+Axr8ETRhAQ0oCfR14jzWvcLCfR/eECQbh87gHsQtszUYSpqLZlqrTynger8jI WwDQexCPiTwjXnpQvkMtk2lMgB1MpDJUnNAN2UCd78/ZHPYvMCjJDgeurXtQvDf7fCht7Wql3jBbpnhYmS0DTfM/B4Yett1mi9w= Archived-At: Cc: CLUE Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 02 Jan 2017 17:05:45 -0000 This is a multi-part message in MIME format. --------------5583671185B0A17F073477CB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Forwarding this to Mark's new email address. -------- Forwarded Message -------- Subject: Re: [clue] Mark's WGLC comments on protocol-10 Date: Mon, 2 Jan 2017 17:21:25 +0100 From: Simon Pietro Romano To: Mark.Duckworth@polycom.com CC: clue@ietf.org Dear Mark, thanks a lot for your review. Please find in-line our answers. Cheers, Simon & Roberta > 4. "three main communication layers" - I agree with Christian these > are phases, not layers. Fixed. > 5. clueId - it still isn't clear to me what is the use of this > element. It seems wasteful to include this element in every message. > Simon previously said "In my view, it is just a name for the CP". But > what is it used for? Can we delete clueId if it has no purpose? > Or if it has a purpose and is meant to be static, can we make it part > of the options message exchange rather than every message? And explain > what the purpose is? If we just look at the CLUE protocol level dialogue, the clueId provides a means for properly identifying the interacting parties. What is wrong with this? > "Each CP MUST be able to manage up to three (independent) streams of > sequence numbers" - sounds to me like it is really six streams of > sequence numbers. Because each of the three "streams" described > actually has separate independent sequence numbers for each direction. > - initiation phase send > - initiation phase receive > - MP send > - MP receive > - MC send > - MC receive > It also is misleading because it is not required to be both an MC and > an MP, so possibly only one of those applies. So it could be either > four streams of sequence numbers, or six streams. Got it. When we say “manage” we actually mean “being responsible for the creation and the update”. So, we were looking at the three roles mentioned above, but by focusing just on the “sending” perspective. Would you like us to reword that sentence? > 5.2 "copied in the the" remove a “the" Done. > 5.3 "an MP may send new ADV messages to replace the previously > advertised options" - this could be misunderstood as relating to the > options messages in the initiation phase. How about "an MP may send > new ADV messages to replace the previous advertisement” Done. > Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout > and retry relates to the transport (e.g. SCTP) rather than application > level timers/counters? I'm a bit confused about the descriptions in > the draft as we have a reliable transport" > I thought the timeout and retry stuff was application level, not to > account for transport errors but rather to account for application > behavior such as an application not responding for whatever reason. So > I think it does need to be clarified if Christian and I interpreted it > differently. This is inline with our interpretation. See also our answer to Christian’s point in the related e-mail. > Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is > unsuccessful (bad syntax, missing XML elements, etc.), and the number > of times this has happened is under the retry treshold," I don't > understand why the retry threshold comes in here? Wouldn't the MC > simply send a NACK is there's an error. It wouldn't wait for multiple > instances of the erroneous message." > My understanding is it gives the MP an opportunity to send a different > advertisement after it receives a nack. It doesn't have to send > another copy of the same advertisement. Agreed. As per above, see also our answer to Christian’s point in the related e-mail. > 10.1 simple ADV - I suggest updating this to be consistent with the > sample XML file in the data model. We already fixed some problems with > that sample XML. I see problems, probably the same ones we already > fixed, here in the simple ADV example. For example captureID AC0 is a > video capture but the description says "main audio from the room". And > on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I > think we've done a good review of the XML in the data model, so let's > just use that as much as possible to avoid new mistakes in this document. Done. Thank you for pointing this out. > 10.2 - same comment, I suggest using the already reviewed XML from the > data model, and show it here in the protocol message envelope. Done. > Mark > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------5583671185B0A17F073477CB Content-Type: text/plain; charset=UTF-8; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KY2x1ZSBt YWlsaW5nIGxpc3QKY2x1ZUBpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2NsdWUKCg== --------------5583671185B0A17F073477CB-- From nobody Mon Jan 2 22:22:49 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 D2E321294B1 for ; Mon, 2 Jan 2017 22:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.32 X-Spam-Level: X-Spam-Status: No, score=-7.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 sK23DrimmaY7 for ; Mon, 2 Jan 2017 22:22:46 -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 655F9129481 for ; Mon, 2 Jan 2017 22:22:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYD39900; Tue, 03 Jan 2017 06:22:23 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 3 Jan 2017 06:22:23 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Tue, 3 Jan 2017 14:21:09 +0800 From: Roni Even To: "rohanse2@cisco.com" Thread-Topic: status of draft-ietf-clue-signaling Thread-Index: AdJliRLdDtQUMmRJQKOu4hCeYoOi2w== Date: Tue, 3 Jan 2017 06:21:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76B199@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.117.5] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76B199DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.586B4332.006E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 21a1bb7bbd1a989722cce9336653583b Archived-At: Cc: "clue@ietf.org" Subject: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 06:22:48 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD76B199DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rob, I am sorry to keep pinging you but can you let us know if and when are you = going to finish editing the document so that we can do a WGLC and publish i= t. We want very much to conclude the work and close the WG Thanks and happy new year Roni Even CLUE WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD76B199DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Rob,

I am sorry to keep pinging you but can you let us kn= ow if and when are you going to finish editing the document so that we can = do a WGLC and publish it.

We want very much to conclude the work and close the= WG

Thanks and happy new year

Roni Even

CLUE WG co-chair

--_000_6E58094ECC8D8344914996DAD28F1CCD76B199DGGEMM506MBXchina_-- From nobody Tue Jan 3 10:30:18 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 1AD00129AA3 for ; Tue, 3 Jan 2017 10:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-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 Da5fc8Uu4PRG for ; Tue, 3 Jan 2017 10:30:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59832129AA1 for ; Tue, 3 Jan 2017 10:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5130; q=dns/txt; s=iport; t=1483468213; x=1484677813; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=yW3tZjs+6WHBuQDB3zF2q6mfzcOC7EQFU9BJBU+Z5mk=; b=iIu4t3AdabtYvJfloIcO12xfl2rLrAJzgblaCFlfS5KgirZ/sPMyUJ8Q FpK4iINaGrCJBwKsNp42a2JK0mrXLePdsmKSHGs6lY+LuQg+c3yHK4jNA Vfl+/7eP0mHjhvChV1kMYfS1OWDGLbf+2Ki1mZgjArKpIlK+raGA4Yq73 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQCU7GtY/4UNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnE5DQEBAQEBH1+BDAeNUJRGj3OFKIIIhiICgUw/FAECAQEBAQE?= =?us-ascii?q?BAWIohGgBAQEELUwQAgEIEQQBASgHMhQJCAEBBA4FCIhosVSKJwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2LJoR8hSsFgSUBmVUCAZE0kF6SPAEfOIIrhQpyhzGBDQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.33,456,1477958400"; d="scan'208,217";a="189816447" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 03 Jan 2017 18:30:12 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v03IUCEG007329 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 3 Jan 2017 18:30:12 GMT Received: from xch-rcd-016.cisco.com (173.37.102.26) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 3 Jan 2017 12:30:11 -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.1210.000; Tue, 3 Jan 2017 12:30:11 -0600 From: "Rob Hansen (rohanse2)" To: Roni Even Thread-Topic: status of draft-ietf-clue-signaling Thread-Index: AdJliRLdDtQUMmRJQKOu4hCeYoOi2wAZjIvA Date: Tue, 3 Jan 2017 18:30:11 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD76B199@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76B199@DGGEMM506-MBX.china.huawei.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.65] Content-Type: multipart/alternative; boundary="_000_ac9ca2eba52546cc8d72920c3510ab78XCHRCD016ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] status of draft-ietf-clue-signaling X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 18:30:17 -0000 --_000_ac9ca2eba52546cc8d72920c3510ab78XCHRCD016ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, Was just reviewing the new version of the protocol document to make sure th= ere's nothing new that desynchronises them - uploading now. Rob From: Roni Even [mailto:roni.even@huawei.com] Sent: 03 January 2017 06:21 To: Rob Hansen (rohanse2) Cc: clue@ietf.org; pkyzivat@alum.mit.edu; Christian.Groves@nteczone.com; Xi= aojing (Lennard) Subject: status of draft-ietf-clue-signaling Hi Rob, I am sorry to keep pinging you but can you let us know if and when are you = going to finish editing the document so that we can do a WGLC and publish i= t. We want very much to conclude the work and close the WG Thanks and happy new year Roni Even CLUE WG co-chair --_000_ac9ca2eba52546cc8d72920c3510ab78XCHRCD016ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Roni,

 

Was just reviewing the= new version of the protocol document to make sure there’s nothing ne= w that desynchronises them – uploading now.

 

Rob

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: 03 January 2017 06:21
To: Rob Hansen (rohanse2) <rohanse2@cisco.com>
Cc: clue@ietf.org; pkyzivat@alum.mit.edu; Christian.Groves@nteczone.= com; Xiaojing (Lennard) <lennard.xiao@huawei.com>
Subject: status of draft-ietf-clue-signaling

 

Hi Rob,

I am sorry to keep pinging you = but can you let us know if and when are you going to finish editing the doc= ument so that we can do a WGLC and publish it.

We want very much to conclude t= he work and close the WG

Thanks and happy new year<= /o:p>

Roni Even

CLUE WG co-chair

--_000_ac9ca2eba52546cc8d72920c3510ab78XCHRCD016ciscocom_-- From nobody Tue Jan 3 10:41:23 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 BF6AD1295DE; Tue, 3 Jan 2017 10:41:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148346888177.28010.16706185492878151723.idtracker@ietfa.amsl.com> Date: Tue, 03 Jan 2017 10:41:21 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-10.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 18:41:21 -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 of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-10.txt Pages : 37 Date : 2017-01-03 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used 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's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-signaling-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-10 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 Thu Jan 5 13:45:36 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 6D0E512940F for ; Thu, 5 Jan 2017 13:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 wE0ibkCIf18w for ; Thu, 5 Jan 2017 13:45:31 -0800 (PST) Received: from COL004-OMC2S6.hotmail.com (col004-omc2s6.hotmail.com [65.55.34.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BFA129428 for ; Thu, 5 Jan 2017 13:45:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.34.71]) by COL004-OMC2S6.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 5 Jan 2017 13:45:31 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pYzGnLWO3W3+ymiW28NIrzXufrAbyMSvCSivgOmAiQI=; b=oJjETQ7qwlKMUgYf5n7oiw/kGKLueCih+96jJKTMMOg5WdsN0//wAGWiRqioOGQvwiIhkSyqFgTq/VuqfjZeT1qnGT9G55KNs+jO/ZJhxVi3klFjKCJRyEtl0dGAl20xz/q47xaLaLGqq4JjAuT99+GJ44vNdMaR/yz6+mCb/9Ub+mD8Pe4Bu7aTuYOsGfH8g3k6Icx9uzIEIoVNRMQoL6tLklqNMbO3Hwr5u+ra3VlddJ09m3gWyIZxD94mjwwM55iCR3oAS/TRntw8D8USzjvdMhGiJ677vQ0TuUaruODsMud9OA+oHupkSfh9RCyBIqObEoEkYIpKFiixt9T8Ew== Received: from CY1NAM02FT055.eop-nam02.prod.protection.outlook.com (10.152.74.56) by CY1NAM02HT193.eop-nam02.prod.protection.outlook.com (10.152.75.120) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8; Thu, 5 Jan 2017 21:45:29 +0000 Received: from BLUPR06MB196.namprd06.prod.outlook.com (10.152.74.51) by CY1NAM02FT055.mail.protection.outlook.com (10.152.74.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8 via Frontend Transport; Thu, 5 Jan 2017 21:45:29 +0000 Received: from BLUPR06MB196.namprd06.prod.outlook.com ([169.254.6.250]) by BLUPR06MB196.namprd06.prod.outlook.com ([169.254.6.250]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 21:45:29 +0000 From: Mark Duckworth To: Simon Pietro Romano , "Mark.Duckworth@polycom.com" Thread-Topic: [clue] Mark's WGLC comments on protocol-10 Thread-Index: AQHSZRRKixNb1xXFgk6cb7meUSaXBqEqZS6d Date: Thu, 5 Jan 2017 21:45:29 +0000 Message-ID: References: , <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> In-Reply-To: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:B51D57C65371EDA2981094C5C8F1FD2BF1504EBAD7662352D7131C60D7F47E38; UpperCasedChecksum:B626D6A52493BBBA750632A91588A51C16EF24E22B833C6F72A947F0F7DFC696; SizeAsReceived:7734; Count:39 x-tmn: [g5SPtfJGONpOcXTg9DsBRxsGl7Q2Mo7M] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CY1NAM02HT193; 7:+zSK/hvrPkCQjrmQOBh0mikT9UFBz0aPmZO1jd4X021nCUEIKu7IL2n9IlyrGvdoXeX+si6nSoGjOhgtHDBJiQPaceH2qI9r+IyjBKUYTeDDTB8pip5s1/gwa++Zpx4C81J+03u8GG2uqehCsIASXbSKvVF7SDUPI1JQObUaudg2vOVimyYuNR6geQhUWBGkeNha3jnsVhq5OtOHo017kpQ2LI7MFmu3zXWB2L0vukMdu4j1FYl4LImM+EdyQuUY/OjDPRiWhlx01myR7SfRf6da2xi80jNpuSnNaVtvfMTAa2ufuePcNczvnVq3HbIHr9VaWIyZmCW0j7VUexoYd/unvKihqf2Vq7whcIJCSJhFGSb2GCgTactWSM6FGWVTA0bSOVA78UD8cQRuAj9oX8jyav1ym4gjyYgEfo9LXWXe/4+LcXQJLObcQKD4TdWs8XLfSg69l2mMxa54/Fj4wg== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1NAM02HT193; H:BLUPR06MB196.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 075753e0-5081-4261-96ed-08d435b42ab3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:CY1NAM02HT193; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(444112120)(432015012)(82015046); SRVR:CY1NAM02HT193; BCL:0; PCL:0; RULEID:; SRVR:CY1NAM02HT193; x-forefront-prvs: 0178184651 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR06MB1962A66114E82B6FDDF80E4A7600BLUPR06MB196namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 21:45:29.0290 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1NAM02HT193 X-OriginalArrivalTime: 05 Jan 2017 21:45:31.0010 (UTC) FILETIME=[09435620:01D2679D] Archived-At: Cc: "clue@ietf.org" Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 21:45:34 -0000 --_000_BLUPR06MB1962A66114E82B6FDDF80E4A7600BLUPR06MB196namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Simon and Roberta, About the clueId element - I guess my main point is I don't understand what= this is for or how to use it. As an implementer, I wouldn't know what to d= o with it. As a sender, can I populate this field with any random string? C= an I send a different value for this element for every message? If I send r= andom values, or empty string, will it cause a problem? As a receiver, what= should I do with this element? Can I safely ignore it? Should I check it f= or some type of validity, and possibly send a nack if it is invalid? Is it = permissible to display the value to a human user? It seems to me the docume= nt isn't clear enough about how to use this element, so my interpretation i= s that this clueId element is useless because there are absolutely no rules= about what to do with it. It says the clueId is "identifier (in the form o= f a generic string) of the CP within the telepresence system". But what is = the "identifier"? I don't think this is defined anywhere. If it is okay for an implementation to send an empty string for clueId, and= to ignore any value it receives, then can we add this clarification to the= document? If it is not okay, then can you please add an explanation why, a= nd what the additional rules are? About "Each CP MUST be able to manage up to three (independent) streams of = sequence numbers" - okay, now I understand you are talking about the sendin= g side only. But this statement still isn't strictly correct, because a CP = doesn't have to be both a mediaProvider and a mediaConsumer, so it doesn't = necessarily have to manage three streams. How about this instead, to replac= e the current paragraph: "Each CP is responsible for creating and updating up to three independent s= treams of sequence numbers in messages it sends: (i) one for the messages s= ent in the initiation phase, (ii) one for the messages sent as MP (if it is= acting as a MP), and (iii) one for the messages sent as MC (if it is actin= g as a MC)." Mark ________________________________ From: clue on behalf of Simon Pietro Romano Sent: Monday, January 02, 2017 11:21 AM To: Mark.Duckworth@polycom.com Cc: clue@ietf.org Subject: Re: [clue] Mark's WGLC comments on protocol-10 Dear Mark, thanks a lot for your review. Please find in-line our answers. Cheers, Simon & Roberta 4. "three main communication layers" - I agree with Christian these are pha= ses, not layers. Fixed. 5. clueId - it still isn't clear to me what is the use of this element. It= seems wasteful to include this element in every message. Simon previously said "In my view, it is just a name for the CP". But what = is it used for? Can we delete clueId if it has no purpose? Or if it has a purpose and is meant to be static, can we make it part of th= e options message exchange rather than every message? And explain what the = purpose is? If we just look at the CLUE protocol level dialogue, the clueId provides a = means for properly identifying the interacting parties. What is wrong with = this? "Each CP MUST be able to manage up to three (independent) streams of sequence numbers" - sounds to me like it is really six streams of sequence = numbers. Because each of the three "streams" described actually has separat= e independent sequence numbers for each direction. - initiation phase send - initiation phase receive - MP send - MP receive - MC send - MC receive It also is misleading because it is not required to be both an MC and an MP= , so possibly only one of those applies. So it could be either four streams= of sequence numbers, or six streams. Got it. When we say =93manage=94 we actually mean =93being responsible for = the creation and the update=94. So, we were looking at the three roles ment= ioned above, but by focusing just on the =93sending=94 perspective. Would y= ou like us to reword that sentence? 5.2 "copied in the the" remove a =93the" Done. 5.3 "an MP may send new ADV messages to replace the previously advertised = options" - this could be misunderstood as relating to the options messages = in the initiation phase. How about "an MP may send new ADV messages to repl= ace the previous advertisement=94 Done. Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and = retry relates to the transport (e.g. SCTP) rather than application level ti= mers/counters? I'm a bit confused about the descriptions in the draft as we= have a reliable transport" I thought the timeout and retry stuff was application level, not to account= for transport errors but rather to account for application behavior such a= s an application not responding for whatever reason. So I think it does nee= d to be clarified if Christian and I interpreted it differently. This is inline with our interpretation. See also our answer to Christian=92= s point in the related e-mail. Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (= bad syntax, missing XML elements, etc.), and the number of times this has h= appened is under the retry treshold," I don't understand why the retry thre= shold comes in here? Wouldn't the MC simply send a NACK is there's an error= . It wouldn't wait for multiple instances of the erroneous message." My understanding is it gives the MP an opportunity to send a different adve= rtisement after it receives a nack. It doesn't have to send another copy of= the same advertisement. Agreed. As per above, see also our answer to Christian=92s point in the rel= ated e-mail. 10.1 simple ADV - I suggest updating this to be consistent with the sample = XML file in the data model. We already fixed some problems with that sample= XML. I see problems, probably the same ones we already fixed, here in the = simple ADV example. For example captureID AC0 is a video capture but the de= scription says "main audio from the room". And on page 36 sceneView SE3 and= SE4 are the same, so that is a mistake. I think we've done a good review o= f the XML in the data model, so let's just use that as much as possible to = avoid new mistakes in this document. Done. Thank you for pointing this out. 10.2 - same comment, I suggest using the already reviewed XML from the dat= a model, and show it here in the protocol message envelope. Done. Mark _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_BLUPR06MB1962A66114E82B6FDDF80E4A7600BLUPR06MB196namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Simon and Roberta,

About the clueId element - I guess my main point is I don't understand w= hat this is for or how to use it. As an implementer, I wouldn't know what t= o do with it. As a sender, can I populate this field with any random string= ? Can I send a different value for this element for every message? If I send random values, or empty string, = will it cause a problem? As a receiver, what should I do with this ele= ment? Can I safely ignore it? Should I check it for some type of validity, = and possibly send a nack if it is invalid? Is it permissible to display the value to a human user? It seems to me the= document isn't clear enough about how to use this element, so my interpret= ation is that this clueId element is useless because there are absolutely n= o rules about what to do with it. It says the clueId is "identifier (in the form of a generic stri= ng) of the CP within the telepresence system". But what is the = "identifier"? I don't think this is defined anywhere.


If it is okay for an implementation to send an empty string for clueId, = and to ignore any value it receives, then can we add this clarification to = the document? If it is not okay, then can you please add an explanation&nbs= p;why, and what the additional rules are?


About "Each CP MUST be able to manage up to three (independent) s= treams of sequence numbers" - okay, now I understand you are talking about the sending side only. But this statement still isn'= t strictly correct, because a CP doesn't have to be both a mediaProvider an= d a mediaConsumer, so it doesn't necessarily have to manage three streams. = How about this instead, to replace the current paragraph:


"= ;Each CP is responsible for creating and updating up to three independ= ent streams of sequence numbers in messages it sends: (i) one for the = messages sent in the initiation phase, (ii) one for the messages sent as MP (if it is acting as a MP), and (iii) one for = the messages sent as MC (if it is acting as a MC)."

Mark

From: clue <clue-bounces= @ietf.org> on behalf of Simon Pietro Romano <spromano@unina.it> Sent: Monday, January 02, 2017 11:21 AM
To: Mark.Duckworth@polycom.com
Cc: clue@ietf.org
Subject: Re: [clue] Mark's WGLC comments on protocol-10
 
Dear Mark,

thanks a lot for your review. Please find in-line our answers.

Cheers,

Simon & Roberta

4. "three main communication layers" - I agree wit= h Christian these are phases, not layers.

Fixed.

 5. clueId - it still isn't = clear to me what is the use of this element. It seems wasteful to include t= his element in every message.
Simon previously said "In my view, it is just a name for the CP".= But what is it used for? Can we delete clueId if it has no purpose?
Or if it has a purpose and is meant to be static, can we make it part of th= e options message exchange rather than every message? And explain what the = purpose is?

If we just look at the CLUE protocol level dialogue, the clueId provid= es a means for properly identifying the interacting parties. What is wrong = with this?

 "Each CP MUST be able = to manage up to three (independent) streams of
sequence numbers" - sounds to me like it is really six streams of sequ= ence numbers. Because each of the three "streams" described actua= lly has separate independent sequence numbers for each direction.
- initiation phase send
- initiation phase receive
- MP send
- MP receive
- MC send
- MC receive
It also is misleading because it is not required to be both an MC and an MP= , so possibly only one of those applies. So it could be either four streams= of sequence numbers, or six streams.

Got it. When we say =93manage=94 we actually mean =93being responsible for = the creation and the update=94. So, we were looking at the three roles ment= ioned above, but by focusing just on the =93sending=94 perspective. Would y= ou like us to reword that sentence? 

 5.2 &q= uot;copied in the the" remove a =93the&quo= t;

Done.

 5.3 "an MP may send new ADV messages to replace the previously advertised options" - this= could be misunderstood as relating to the options messages in the initiati= on phase. How about "an MP may send new ADV messages to replace the pr= evious advertisement=94

Done.

 Christian wrote: "Cl.6= .1&6.2: Do we need to indicate that the timeout and retry relates to th= e transport (e.g. SCTP) rather than application level timers/counters? I'm = a bit confused about the descriptions in the draft as we have a reliable transport"
I thought the timeout and retry stuff was application level, not to account= for transport errors but rather to account for application behavior such a= s an application not responding for whatever reason. So I think it does nee= d to be clarified if Christian and I interpreted it differently.

This is inline with our interpretation. See also our answer to Christian=92= s point in the related e-mail.


 Christian wrote: "Cl.6= .2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missin= g XML elements, etc.), and the number of times this has happened is under t= he retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an = error. It wouldn't wait for multiple instances of the erroneous message.&qu= ot;
My understanding is it gives the MP an opportunity to send a different adve= rtisement after it receives a nack. It doesn't have to send another copy of= the same advertisement.

Agreed. As per above, see also our answer to Christian=92s point in the rel= ated e-mail.

10.1 simple ADV - I suggest updat= ing this to be consistent with the sample XML file in the data model. We al= ready fixed some problems with that sample XML. I see problems, probably th= e same ones we already fixed, here in the simple ADV example. For example captureID AC0 is a video capture but t= he description says "main audio from the room". And on page 36 sc= eneView SE3 and SE4 are the same, so that is a mistake. I think we've done = a good review of the XML in the data model, so let's just use that as much as possible to avoid new mistakes in this d= ocument.

Done. Thank you for pointing this out.

 10.2 - same comment, I sugg= est using the already reviewed XML from the data model, and show it here in= the protocol message envelope.

Done.


 
Mark
______________= _________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org/mailman= /listinfo/clue

--_000_BLUPR06MB1962A66114E82B6FDDF80E4A7600BLUPR06MB196namprd_-- From nobody Fri Jan 6 04:59:09 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 C1284128AC9 for ; Fri, 6 Jan 2017 04:59:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 xM2AORVbV6h7 for ; Fri, 6 Jan 2017 04:59:05 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02088129B03 for ; Fri, 6 Jan 2017 04:59:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FoN9xXV3z8+d0OKB05Xo8GLkkgW6zhbiHMPZxbxs3fQ=; b=CK4tvGJwdPuur7gZJ8sW4j9lA9 CE5N2v3Kwqs54CLamK+CClLa7JU0tJZwdc/Geu9qedrKQXdF5Rb2PtrFPH+MicVdjZZNCgGajMB+V WTbeTDc7/b9IOMNT6IIfkxx1in3uBfNs+ZyPl2pxdeWAAlRHW5y6ZjzGhKi71X1ETLZXi+oxZBiL5 eqC0qqs0i1rcWxtfhGAenaKhBDdRJdiZGyMUZNcO+ZJWHSbDtALqAEiZjRbNoJ8g69mASD9i+jN5P PdrYoFmHDbIKwc2hLoBLPlL7+s+rS3BJ4kn1A/O1Qwy23/H0WQ/Fa6+djz8WD9gO0i1DNDVWQsNcA D3nS6dcg==; Received: from [116.6.65.160] (port=56478 helo=[172.31.1.51]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cPU6Z-003twW-5C; Fri, 06 Jan 2017 23:58:47 +1100 To: Simon Pietro Romano References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> From: Christian Groves Message-ID: Date: Fri, 6 Jan 2017 23:58:06 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: clue@ietf.org Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 12:59:07 -0000 Hello Simon, Sorry about the slow response. I've been travelling. Please see my responses below. Regards, Christian ..snip >> General: The document talks about extensions and options. Are they different? if not should we use one term. > The difference is indeed a subtle one. The idea should be that an option is a predefined capability of the protocol that is not mandatory, whereas an extension is a brand new feature one might be interested in defining for their own purpose. Technically speaking, they look exactly the same, as section 8 clearly illustrates. [CNG]I think we need to separate whether something is an optional capability or not from extending the protocol/data model. Extensions I see are additions to the protocol. ..snip > >> Cl.5.2: Is there a reason why we indicated that both the response code AND string are mandatory? It seems like an unnecessary duplication. Its not clear that text other than what has be defined may be sent. > OK. We made the "reasonString” element become optional in version-11 of the schema (minOccurs=“0”). [CNG] OK ..snip > Cl.5.3 para 2: "Picture" -> "Syntax" or "Schema". Its worth harmonising how each message section describes this. > We replaced “picture” with “schema excerpt”. Does this look ok? [CNG] OK ..snip > Cl.5.6/General: Do we need some text indicating that there's no partial execution of commands. E.g. If a MP is able to understand all the selected capture encodings bar one. The whole command fails and nothing is instantiated. > We added the following sentence at the end of the section: > > "We remark that there is no partial execution of commands. As an example, if a MP is able to understand all the selected capture encodings except one, then the whole command fails and nothing is instantiated." [CNG] That's OK except that i'd remove "We remark that..." and just keep it at "There is no....". > >> Cl.5.7: It says future protocol version can introduce error codes? How about options? It seems like an option could introduce a specific error code. > Based on the discussion in section 8, a new response code might indeed be added through the “extension” mechanism. Though, the “cleanest” way for achieving such a task in a formal way is by adding > the new response code to the list of codes published in the dedicated IANA registry (see section 12.4.2 fo the draft). In the mentioned section, we refer to future versions of the standard. [CNG] By saying that error codes can be designed in future versions seems to preclude them being defined by extensions. (BTW 5.7 uses "designed", I think "defined" would be better). I agree one could simply update the IANA registry with the new code but I was thinking more of how an end point would know that it would be used. That's where registering an extension would make sense. Of course if you made a new version you wouldn't need an extension. ..snip > Cl.6 para 5: "Otherwise ("channel error")…" > Should we add an "if" between “Otherwise” and the parenthesis? Please advise on that. [CNG] If doesn't need to be in parentheses just "Otherwise if ..." ..snip > Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport. > Namely, we state that the CLUE (application layer) protocol relies on timeouts and retransmissions. Our interpretation is that we do need timeouts and retransmissions for application-layer errors. [CNG] OK. > Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message. > The idea here is that the MC avoids entering a loop where the MP keeps on sending an erroneous ADV hence forcing the MC to respond with a NACK. If this situation iterates for a while (# of retries), the MC terminates the ongoing CLUE “session”. [CNG] OK that makes sense. ..snip > Cl.8 I think it would be very helpful to include an example syntax showing the definition of a new capture attribute that could be used by future people as a template. Its still not clear if there's any distinction between "option" and "extension”. > See our answer above regarding extensions vs options. If we all agree that they are practically the same thing, we can properly re-word things in the document. > > About the example, a new capture attribute could be defined in a separate schema to further describe, e.g., a video capture. > Indeed, looking at the data model XML definition of a video capture, it is possible to see that there is an element allowing for the introduction of a new XML field in the XML description of the capture, by keeping the compatibility with the CLUE data model schema: > > > > > > > maxOccurs="unbounded"/> > > > > > > > > That means that a video capture might have, after the set of the generic media capture attributes, a set of new attributes defined elsewhere, i.e., in an XML schema defining an extension. > Such a schema might look like the following: > > > version="1.0" > targetNamespace="clue-info-extension-myVideoExtensions" > xmlns:xs="http://www.w3.org/2001/XMLSchema" > xmlns="clue-info-extension-myVideoExtensions" > elementFormDefault="qualified" > attributeFormDefault="unqualified"> > > > > > > > > > > > > > > > > > > > > > The video capture could be further described in the advertisement using the element containing two extra information ( and ) besides using the attributes envisioned for a generic media capture. > As stated in this document, both the CP must be aware of the extension schema and related semantics to use such an extension and negotiate it via the OPTIONS and OPTIONS RESPONSE mechanism. [CNG] I think its valuable to have such an example on extending the clue-info and clue-protocol schemas. ..snip > Thanks 1k for your precious review! [CNG] No problem. > > From nobody Wed Jan 11 00:06:14 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 31728129A69; Wed, 11 Jan 2017 00:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 B6kLyM9kUk70; Wed, 11 Jan 2017 00:06:05 -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 87F98129A65; Wed, 11 Jan 2017 00:06:04 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEF33104; Wed, 11 Jan 2017 08:06:00 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 11 Jan 2017 08:05:59 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Wed, 11 Jan 2017 16:05:53 +0800 From: Roni Even To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjQGll?= =?utf-8?B?dGZhLmFtc2wuY29t?= <=?utf-8?b?SsO8cmdlbiBTY2jDtm53w6RsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFj?=@ietfa.amsl.com>, "ops-dir@ietf.org" Thread-Topic: Review of draft-ietf-clue-rtp-mapping-10 Thread-Index: AQHSZbeSRJ3tnTYULkWp18M9pC35/qEy8E8Q Date: Wed, 11 Jan 2017 08:05:52 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76C149@DGGEMM506-MBX.china.huawei.com> References: <148344421561.28040.10199222017103675571.idtracker@ietfa.amsl.com> In-Reply-To: <148344421561.28040.10199222017103675571.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.242] 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.0A0B0206.5875E769.0327, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 27f2b505fe16ab95670489090cf3ec13 Archived-At: Cc: "clue@ietf.org" , "ietf@ietf.org" , "draft-ietf-clue-rtp-mapping.all@ietf.org" Subject: Re: [clue] Review of draft-ietf-clue-rtp-mapping-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:06:07 -0000 SGksDQpUaGFua3MgZm9yIHRoZSByZXZpZXcNCklubGluZQ0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206ID0/dXRmLQ0KPiA4P2I/U3NPOGNtZGxiaUJUWTJqRHRt NTN3NlJzWkdWeUlEeHFMbk5qYUc5bGJuZGhaV3hrWlhKQWFtRmo/PQ0KPiBAaWV0ZmEuYW1zbC5j b20gW21haWx0bzo9P3V0Zi0NCj4gOD9iP1NzTzhjbWRsYmlCVFkyakR0bTUzdzZSc1pHVnlJRHhx TG5OamFHOWxibmRoWld4a1pYSkFhbUZqPz0NCj4gQGlldGZhLmFtc2wuY29tXQ0KPiBTZW50OiDX mdeV153CoNeSIDAzINeZ16DXldeQ16ggMjAxNyAxMzo1MA0KPiBUbzogb3BzLWRpckBpZXRmLm9y Zw0KPiBDYzogY2x1ZUBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jbHVlLXJ0 cC1tYXBwaW5nLmFsbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1j bHVlLXJ0cC1tYXBwaW5nLTEwDQo+IA0KPiBSZXZpZXdlcjogSsO8cmdlbiBTY2jDtm53w6RsZGVy DQo+IFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQo+IA0KPiBJIGRvIG5vdCBzZWUgYW55IG1ham9y IE9QUyByZWxhdGVkIGlzc3Vlcy4gV2hpbGUgcmVhZGluZyB0aGUgZG9jdW1lbnQsIEkNCj4gZm91 bmQgYSBudW1iZXIgb2YgdGhpbmdzIHRoZSBhdXRob3JzIHNob3VsZCBsb29rIGludG86DQo+IA0K PiAtIENvbnNpZGVyIHRvIGV4cGFuZCBTRFAgYW5kIHBlcmhhcHMgQ0xVRSBpbiB0aGUgYWJzdHJh Y3QNCltSb25pIEV2ZW5dIE9LDQo+IA0KPiAtIEhhdmluZyBib3RoIENhcHR1cmVJZCBhbmQgQ2Fw dHVyZUlEIGluIDUuMSBpcyBhIGJpdCBjb25mdXNpbmcgKHNpbmNlDQo+ICAgdGhlIHR3byBpZGVu dGlmaWVycyBvbmx5IGRpZmZlciBieSB0aGUgY2FwaXRhbGl6YXRpb24gb2YgdGhlIGxhc3QNCj4g ICBjaGFyYWN0ZXIpDQpbUm9uaSBFdmVuXSBJIHdpbGwgY2hhbmdlIGl0DQo+IA0KPiAtIEJvdGgg blhNTCBtb2RlIGluIGVtYWNzIGFuZCB4bWxpbnQgaW5kaWNhdGUgdGhhdCB0aGUgeG1sIGluIHNl Y3Rpb24NCj4gICA2IGlzIGludmFsaWQuIFBsZWFzZSBjaGVjay4gKEl0IGNvdWxkIGFsc28gYmUg YW4gaXNzdWUgd2l0aCBteSB0b29scw0KPiAgIGFuZCB0aGUgbmFtZXNwYWNlcyBidXQgdGhlbiBh bHNvIHRoZSBpbmRlbnRhdGlvbiBsb29rcyBhdCBsZWFzdA0KPiAgIHNvbWV3aGF0IHN1cnByaXNp bmcuDQpbUm9uaSBFdmVuXSBUaGlzIGFyZSBwYXJ0aWFsIGV4YW1wbGVzIGZyb20gdGhlIGNsdWUg ZGF0YSBtb2RlbCBkb2N1bWVudCBqdXN0IHRvIHNob3cgdGhlIHJlbGV2YW50IHBhcnQuIFRoZXkg d2VyZSBub3QgbWVhbnQgdG8gYmUgdmFsaWQgeG1sICwgSSBjYW4gYWRkIHRleHQgdG8gZXhwbGFp biB0aGlzDQo+IA0KPiAtIElzIHRoZSBSRkMgZWRpdG9yIGV4cGVjdGVkIHRvCXJlcGxhY2UgWFgg aW4gdGhlIGRyYXdpbmcgaW4gc2VjdGlvbg0KPiAgIDUuMSB3aXRoIHRoZSB2YWx1ZSBhc3NpZ25l ZCBmb3IgVEJBPyBJZiBzbywgSSB0aGluayB0aGlzIG5lZWRzIHRvIGJlDQo+ICAgZG9jdW1lbnRl ZCBzb21ld2hlcmUuDQpbUm9uaSBFdmVuXSBPSw0KPiANCj4gLSBJcyAncm9uaS5ldmVuQG1haWww MS5odWF3ZWkuY29tJyBpcyBhIGxvbmcgdGVybSBzdGFibGUgaWRlbnRpZmllcg0KPiAgIGZvciB0 aGUgJ0NvbnRhY3QnIGZpZWxkIG9mIHRoZSBSVFAgU0RFUyBDb21wYWN0IEhlYWRlciBFeHRlbnNp b25zDQo+ICAgc3VicmVnaXN0cnk/DQpbUm9uaSBFdmVuXSBJIHdpbGwgcHJvdmlkZSBhIGJldHRl ciBlbWFpbCBhZGRyZXNzDQo+IA0KPiAtIFNlY3VyaXR5IGNvbnNpZGVyYXRpb25zLCBsYXN0CXBh cmFncmFwaDogV2hhdAlpcyAnYSBsb3Qgb2YgdHJ1c3QnPw0KPiAgIFdoeSBpcyB0aGUgU0hPVUxE IG5vdAlhIE1VU1Q/DQpbUm9uaSBFdmVuXSBJIGFncmVlLCBpdCBpcyBhbHNvIGEgcGFzc2l2ZSBs YW5ndWFnZQ0KT2xkIHRleHQNCiJJbiBtdWx0aS1wYXJ0eSBjb21tdW5pY2F0aW9uIHNjZW5hcmlv cyB1c2luZyBSVFAgTWlkZGxlYm94ZXMsIGEgbG90IG9mIHRydXN0IGlzIHBsYWNlZCBvbiB0aGVz ZSBtaWRkbGVib3hlcyB0byBwcmVzZXJ2ZSB0aGUgc2Vzc2lvbnMgc2VjdXJpdHkiDQpOZXcgdGV4 dA0KIkluIG11bHRpLXBhcnR5IGNvbW11bmljYXRpb24gc2NlbmFyaW9zIHVzaW5nIFJUUCBNaWRk bGVib3hlczsgdGhlc2UgbWlkZGxlYm94ZXMgYXJlIHRydXN0ZWQgdG8gcHJlc2VydmUgdGhlIHNl c3Npb25zIHNlY3VyaXR5Ig0KDQpBcyBmb3IgdGhlICJTSE9VTEQgbWFpbnRhaW4iIGl0IG1heSBk ZXBlbmQgb24gYXBwbGljYXRpb24gcG9saWNpZXMgKGZvciBleGFtcGxlIGFsbG93aW5nIHVzZXJz IHdpdGggZGlmZmVyZW50IHNlY3VyaXR5IGxldmVscyBpbnRvIGEgbXVsdGlwb2ludCBjb25mZXJl bmNlKQ0KDQo+IA0KPiAtIHMvQ2FwdHVyZUlEaXMvQ2FwdHVyZUlEIGlzL2cNCltSb25pIEV2ZW5d IE9LDQo+IA0KPiAtIEFjY29yZGluZyB0byBpZG5pdHMsIHRoZXJlIGFyZSBSRkNzIGxpc3RlZCBp biB0aGUgcmVmZXJlbmNlcyB0aGF0DQo+ICAgYXJlIG5vdCBjaXRlZCBpbiB0aGUgdGV4dDsgcGxl YXNlIHBheSBhdHRlbnRpb24gdG8gaWRuaXRzIHJlcG9ydHMNCltSb25pIEV2ZW5dIE9LDQo+IA0K DQo= From nobody Wed Jan 11 22:30:26 2017 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74DF012949B for ; Wed, 11 Jan 2017 22:30:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 nfDK1a_-pU8t for ; Wed, 11 Jan 2017 22:30:23 -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 39CA4129498 for ; Wed, 11 Jan 2017 22:30:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYQ71671; Thu, 12 Jan 2017 06:30:20 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 06:29:58 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 12 Jan 2017 14:29:14 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: WGLC on draft-ietf-clue-signaling-10 Thread-Index: AdJsnHB3E0Nl/o0sSIChD7jBnBRieQ== Date: Thu, 12 Jan 2017 06:29:13 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76C6CF@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.119.125] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76C6CFDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0207.5877227D.010A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: b5b90fc3ccadffe92482daad1309ef10 Archived-At: Subject: [clue] WGLC on draft-ietf-clue-signaling-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 06:30:25 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD76C6CFDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We had a WGLC on draft-ietf-clue-signaling-06 on October 2015. Since then = there were updates to the documents based on the reviews and the documents = should be ready now for publication. I would like to have a second WGLC allowing the WG to review the document b= efore sending it to publication. The WGLC will end February 2nd to allow for enough time for reviews. Please use this time and review the document and send comments to the list = including "I read and have no comments" Thanks Roni Even CLUE WG co-chair --_000_6E58094ECC8D8344914996DAD28F1CCD76C6CFDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Hi,

We had a WGLC on draft-i= etf-clue-signaling-06 on October 2015.  Since then there were updates = to the documents based on the reviews and the documents should be ready now= for publication.

 =

I would like to have a s= econd WGLC allowing the WG to review the document before  sending it t= o publication.

The WGLC will end Februa= ry 2nd  to allow for enough time for reviews.

 =

Please use this time and= review the document and send comments to the list including “I read = and have no comments”

 =

Thanks=

Roni Even

CLUE WG co-chair

 =

 =

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD76C6CFDGGEMM506MBXchina_-- From nobody Thu Jan 12 02:51:08 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 DD2DD129573 for ; Thu, 12 Jan 2017 02:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 1BhH2TvsKWAN for ; Thu, 12 Jan 2017 02:51:05 -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 2DC15129547 for ; Thu, 12 Jan 2017 02:51:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYR09350; Thu, 12 Jan 2017 10:51:02 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 10:51:02 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Thu, 12 Jan 2017 18:50:14 +0800 From: Roni Even To: Roni Even , "clue@ietf.org" Thread-Topic: WGLC on draft-ietf-clue-signaling-10 - my review Thread-Index: AdJsv1aKhhXy5WIlRX+JEuF5W00s1Q== Date: Thu, 12 Jan 2017 10:50:14 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76C7C2@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.119.125] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76C7C2DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.58775F97.012E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 00bed032fe028189a0cafe2261704b50 Archived-At: Subject: Re: [clue] WGLC on draft-ietf-clue-signaling-10 - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:51:08 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD76C7C2DGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, As individual, I reviewed the document some comments 1. The idnits shows error, please address idnits issues 2. In the introduction first paragraph suggest reference for SDP 3. In section 3 =93The "sip.clue" media feature tag indicates support= for CLUE=94 add =93in SIP[RFC3261] calls=94 4. In section 4.1 second paragraph =93A device MUST NOT include more = than one CLUE group in its SDP=94 add =93SDP offer[RFC3264]=94 5. In section 4.2 first paragraph =93must=94 to =93MUST=94 6. In section 4.2 first paragraph =93a CLUE group in the SDP=94 add = =93SDP offer=94 7. In section 6.1 last part what is the difference between the first = and the fourth bullet? 8. In section 8 last SDP example for =93m=3Dvideo 0 RTP/AVP 96=94 add= a line with =93a=3Dmid:6=94 this is relevant to the group usage. I was als= o wondering if we remove mid 6 from the CLUE group? 9. In section 9 in the drawing need Alice and Bob instead of EP1 and = EP2 10. In section 13 add a note to the RFC editor to remove this section Thanks Roni Even As individual From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even Sent: =E9=E5=ED =E4 12 =E9=F0=E5=E0=F8 2017 08:29 To: clue@ietf.org Subject: [clue] WGLC on draft-ietf-clue-signaling-10 Hi, We had a WGLC on draft-ietf-clue-signaling-06 on October 2015. Since then = there were updates to the documents based on the reviews and the documents = should be ready now for publication. I would like to have a second WGLC allowing the WG to review the document b= efore sending it to publication. The WGLC will end February 2nd to allow for enough time for reviews. Please use this time and review the document and send comments to the list = including =93I read and have no comments=94 Thanks Roni Even CLUE WG co-chair ________________________________ --_000_6E58094ECC8D8344914996DAD28F1CCD76C7C2DGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

As individual, I revie= wed the document some comments

 

1.&= nbsp;      The idnits shows error, please address idnits issues<= /span>

2.&= nbsp;      In the introduction first paragraph suggest reference for SDP

3.     &= nbsp; In section 3 =93The "sip.clue" media feature tag indic= ates support for CLUE=94 add =93in SIP[RFC3261] calls=94

4.     &= nbsp; In section 4.1 second paragraph =93A device MUST NOT include mor= e than one CLUE group in its SDP=94 add =93SDP offer[RFC3264]=94=

5.     &= nbsp; In section 4.2 first paragraph =93must=94 to =93MUST=94

6.     &= nbsp; In section 4.2 first paragraph =93a CLUE group in the SDP=94 add= =93SDP offer=94

7.     &= nbsp; In section 6.1 last part what is the difference between the first and t= he fourth bullet?

8.     &= nbsp; In section 8 last SDP example for =93m=3Dvideo 0 RTP/AVP 96=94 a= dd a line with =93a=3Dmid:6=94 this is relevant to the group usage. I was a= lso  wondering if we remove mid 6 from the CLUE group?

9.     &= nbsp; In section 9 in the drawing need Alice and Bob instead of EP1 and EP2

10.   In section 13 add a note t= o the RFC editor to remove this section

 

Thanks

Roni Even

As individual

 

 

 

From: clue [ma= ilto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: =E9=E5=ED =E4 12 =E9=F0=E5=E0=F8 2017 08:29
To: clue@ietf.org
Subject: [clue] WGLC on draft-ietf-clue-signaling-10

 

 

Hi,

We had a WGLC on draft-i= etf-clue-signaling-06 on October 2015.  Since then there were updates = to the documents based on the reviews and the documents should be ready now= for publication.

 =

I would like to have a s= econd WGLC allowing the WG to review the document before  sending it t= o publication.

The WGLC will end Februa= ry 2nd  to allow for enough time for reviews.

 =

Please use this time and= review the document and send comments to the list including =93I read and = have no comments=94

 =

Thanks=

Roni Even

CLUE WG co-chair

 =

 =

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD76C7C2DGGEMM506MBXchina_-- From nobody Thu Jan 12 02:54:56 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 D303112957E for ; Thu, 12 Jan 2017 02:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-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 BTCDatZiZf2T for ; Thu, 12 Jan 2017 02:54:53 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84CF71293F8 for ; Thu, 12 Jan 2017 02:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20234; q=dns/txt; s=iport; t=1484218492; x=1485428092; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=+yHHOctqwjUY8T+efTc4oIiKrW4k1ngtJto4Dwm1G20=; b=RMTu8x6PIluYhOgmuFjmhPjPv2DE3YS2iwKE/3ThkMVpMWhSRsg4tOt2 Hh5tznOJOtcPml0qudi4b86UOFCH8EN0nFOuWKh0mCzLxDXTWDunGuwfL 6qIk7AVErlvco0I6pw2iq2IapKCvKBlYq0l0ePnLRRCYga7KjnITCnOoh 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQDgX3dY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnJKAQEBAQF+A4EDg1CKCHKPfwaBHZUrgg0fAQqFeAKCTRQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAEBIQpBGwkCEQICAQEBIAcDAgInHwkIEwYCAQGIbw0Ok?= =?us-ascii?q?lydToIlK4lnAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQ0ChXKCRgiCV4QXNAMuglC?= =?us-ascii?q?CXgWBKwGHSpI0AoZbinuBd4UOgyojhhiSZB84Nl8SHU9bg1kcgV8+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="648715750" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 10:54:48 +0000 Received: from [10.47.200.26] ([10.47.200.26]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v0CAslwr022449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 12 Jan 2017 10:54:48 GMT To: clue@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD76C7C2@DGGEMM506-MBX.china.huawei.com> From: Robert Hansen Message-ID: <876a2955-7201-13a9-1847-621083b99198@cisco.com> Date: Thu, 12 Jan 2017 10:54:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76C7C2@DGGEMM506-MBX.china.huawei.com> Content-Type: multipart/alternative; boundary="------------F77F57F672FEE50C484A8FF7" X-Authenticated-User: rohanse2 Archived-At: Subject: Re: [clue] WGLC on draft-ietf-clue-signaling-10 - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:54:55 -0000 This is a multi-part message in MIME format. --------------F77F57F672FEE50C484A8FF7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Thanks for the review Roni, will incorporate the comments into the next version. Rob On 12/01/17 10:50, Roni Even wrote: > > Hi, > > As individual, I reviewed the document some comments > > 1.The idnits shows error, please address idnits issues > > 2.In the introduction first paragraph suggest reference for SDP > > 3.In section 3 “The "sip.clue" media feature tag indicates support for > CLUE” add “in SIP[RFC3261] calls” > > 4.In section 4.1 second paragraph “A device MUST NOT include more than > one CLUE group in its SDP” add “SDP offer[RFC3264]” > > 5.In section 4.2 first paragraph “must” to “MUST” > > 6.In section 4.2 first paragraph “a CLUE group in the SDP” add “SDP offer” > > 7.In section 6.1 last part what is the difference between the first > and the fourth bullet? > > 8.In section 8 last SDP example for “m=video 0 RTP/AVP 96” add a line > with “a=mid:6” this is relevant to the group usage. I was also > wondering if we remove mid 6 from the CLUE group? > > 9.In section 9 in the drawing need Alice and Bob instead of EP1 and EP2 > > 10.In section 13 add a note to the RFC editor to remove this section > > Thanks > > Roni Even > > As individual > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Roni Even > *Sent:* יוםה12 ינואר2017 08:29 > *To:* clue@ietf.org > *Subject:* [clue] WGLC on draft-ietf-clue-signaling-10 > > Hi, > > We had a WGLC on draft-ietf-clue-signaling-06 on October 2015. Since > then there were updates to the documents based on the reviews and the > documents should be ready now for publication. > > I would like to have a second WGLC allowing the WG to review the > document before sending it to publication. > > The WGLC will end February 2^nd to allow for enough time for reviews. > > Please use this time and review the document and send comments to the > list including “I read and have no comments” > > Thanks > > Roni Even > > CLUE WG co-chair > > ------------------------------------------------------------------------ > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------F77F57F672FEE50C484A8FF7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Thanks for the review Roni, will incorporate the comments into the next version.

Rob

On 12/01/17 10:50, Roni Even wrote:

Hi,

As individual, I reviewed the document some comments

 

1.       The idnits shows error, please address idnits issues

2.       In the introduction first paragraph suggest reference for SDP

3.       In section 3 “The "sip.clue" media feature tag indicates support for CLUE” add “in SIP[RFC3261] calls”

4.       In section 4.1 second paragraph “A device MUST NOT include more than one CLUE group in its SDP” add “SDP offer[RFC3264]”

5.       In section 4.2 first paragraph “must” to “MUST”

6.       In section 4.2 first paragraph “a CLUE group in the SDP” add “SDP offer”

7.       In section 6.1 last part what is the difference between the first and the fourth bullet?

8.       In section 8 last SDP example for “m=video 0 RTP/AVP 96” add a line with “a=mid:6” this is relevant to the group usage. I was also  wondering if we remove mid 6 from the CLUE group?

9.       In section 9 in the drawing need Alice and Bob instead of EP1 and EP2

10.   In section 13 add a note to the RFC editor to remove this section

 

Thanks

Roni Even

As individual

 

 

 

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even
Sent: יום ה 12 ינואר 2017 08:29
To: clue@ietf.org
Subject: [clue] WGLC on draft-ietf-clue-signaling-10

 

 

Hi,

We had a WGLC on draft-ietf-clue-signaling-06 on October 2015.  Since then there were updates to the documents based on the reviews and the documents should be ready now for publication.

 

I would like to have a second WGLC allowing the WG to review the document before  sending it to publication.

The WGLC will end February 2nd  to allow for enough time for reviews.

 

Please use this time and review the document and send comments to the list including “I read and have no comments”

 

Thanks

Roni Even

CLUE WG co-chair

 

 

 

 



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

--------------F77F57F672FEE50C484A8FF7-- From nobody Thu Jan 12 09:53:49 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 DE6DB129421 for ; Thu, 12 Jan 2017 09:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 M4TAMwIW7CLv for ; Thu, 12 Jan 2017 09:53:46 -0800 (PST) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A9601293FC for ; Thu, 12 Jan 2017 09:53:46 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-10v.sys.comcast.net with SMTP id RjZGcFWvFkJTyRjZJcgoPu; Thu, 12 Jan 2017 17:53:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484243625; bh=0MzxbpIlLEDKPFRZ1W62jht2v+TzdfxPqx5bUg4tqX0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=bscs9vTjFO+s1ilJBg14Tghv3ok30DhTNK4lADtuy13CvmoeLr4EwAfT1QI6Hh+uC UNYarI15YphBMxCSJKWsIdRZneXQcq5MjQjZFrdSuwHeLUXiIfChuGM+tDh3McQFU7 Pa618YVmOwOT9PKKWO6g/RoYTKwm/+m8w4+zPN/kLigxLXI5nsx4gAYjS85A7VnJvW 6saTKvt5bxEOo2Vdp8O10ZaPQn4CNWqG6o+1vjK3wd40a/O6wVGH677r67VPVal4N6 7xVRHSF1SlW/xI3CLgcxfTvTmpOX7QH/nz2U5O0BSwepeX5KRmAR9FIXxMnyPt/ytw G5Bv1qH5AUcuw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-05v.sys.comcast.net with SMTP id RjZHcVFjXmBhGRjZIc1KbN; Thu, 12 Jan 2017 17:53:45 +0000 To: clue@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD76C6CF@DGGEMM506-MBX.china.huawei.com> From: Paul Kyzivat Message-ID: Date: Thu, 12 Jan 2017 12:53:43 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76C6CF@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [clue] WGLC on draft-ietf-clue-signaling-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:53:48 -0000 On 1/12/17 1:29 AM, Roni Even wrote: > We had a WGLC on draft-ietf-clue-signaling-06 on October 2015. Since > then there were updates to the documents based on the reviews and the > documents should be ready now for publication. > > I would like to have a second WGLC allowing the WG to review the > document before sending it to publication. > > The WGLC will end February 2^nd to allow for enough time for reviews. > > Please use this time and review the document and send comments to the > list including I read and have no comments I'm one of the authors, so perhaps it goes without saying, but I've read all the versions and I'm good with it as it is now. Thanks, Paul From nobody Fri Jan 13 04:22:54 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 B16F5129B5C; Fri, 13 Jan 2017 04:22:47 -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 qpxvQOG3Hrnr; Fri, 13 Jan 2017 04:22:45 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 042C9129B5D; Fri, 13 Jan 2017 04:22:41 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-73-5878c68f1e9f Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id BD.C2.17130.F86C8785; Fri, 13 Jan 2017 13:22:39 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.319.2; Fri, 13 Jan 2017 13:22:21 +0100 To: References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> From: Magnus Westerlund Message-ID: Date: Fri, 13 Jan 2017 13:22:21 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2K7tG7/sYoIg4nbrS2+TlrCZrH/1GVm i6cT/7FYPNs4n8VixYYDrA6sHn/ff2DyWLLkJ1MAUxSXTUpqTmZZapG+XQJXxoEFn5gKtihU 7Fin0sDYJ9XFyMEhIWAi0fZRu4uRi0NIYB2jxLxp81kgnOWMEidv/GUHcYQFGhglNn84zdTF yMkhIiAsceTRP3aQbiEBP4mOmcEgYWaBaomZc24yg9hsAhYSN380soHYvAL2Eo03jrCD2CwC qhIPN6xhBbFFBWIk3q5fzg5RIyhxcuYTFhCbU8BfYsLXg2wg45mBeh9sLYMYLy/RvHU22Hgh AW2JhqYO1gmMArOQdM9C6JiFpGMBI/MqRtHi1OKk3HQjY73Uoszk4uL8PL281JJNjMBwPbjl t+oOxstvHA8xCnAwKvHwFnBVRAixJpYVV+YeYpTgYFYS4S0/CBTiTUmsrEotyo8vKs1JLT7E KM3BoiTOa7byfriQQHpiSWp2ampBahFMlomDU6qBMTrdzMz6spKX+QPBrmtpuulX0x/d7q3Y Ntkz5EpczZU1adsl2qonBZUeKrj23FNlQ1tALmP19Zxzf78emXy6snT/5Kd5R/L+rJLWmnb5 Y5XU6ep/E3xObjgwIedW11ZhS6YVp54KKYaZnXcNNfrBGc1s4MRjKMC8RdR8v4/mxgw79iMf i7XZlViKMxINtZiLihMByEwp5VMCAAA= Archived-At: Cc: draft-ietf-clue-rtp-mapping@ietf.org, clue-chairs@ietf.org, clue@ietf.org Subject: Re: [clue] Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 12:22:48 -0000 Hi, As one of IANA's expert reviewers for the two registries that this document attempts to register in, I want to provide some feedback on individual basis and directly. The SDES item registration of the CaptureID is fine with the exception that it isn't clear on the security consideration for the CaptureID field as SDES item. I fail to find any limitations or even recommendations for how the value is created by the implementation. Nor does the security considerations discuss the potential risk that the capture ID is privacy sensitive, like "Adrian's Mic" rather than AC0 as in the example in the data model document. The data model document is fairly clear on the need for confidentiality and authorization for the whole data model document. However, this thinking has not been raised and clarified in this specific move of the information into the RTP protocol. So, I would recommend a discussion in general if the field should have anonymous labels, that do not contain privacy information. Then one needs to be clear on what requirements that puts on transporting this field in RTP. And that depends on how certain one can be that it is anonymous or that it may contain sensitive information and therefore should be confidentiality protected. In all cases this field needs integrity and source authentication. Which should be made explicit in the security consideration. The clue mapping require implementation of SRTP with DTLS-SRTP keying, however, it fails to be specific on which protection profiles that are to be supported, both for the SRTP as well as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I can't be certain if the CaptureID will be confidentiality protected or not even in RTCP. When it comes to the RTP Header Extension case, the RFC 7941 is very explicit about the requirement on doing this security consideration. And I note that with the above analysis of what requirements to put, one can ensure that the right requirements on the CLUE system to protect any RTP header extension with the CaptureID is done. I do note that if confidentiality protection is needed, this means additional implementation requirement. Such needs to be defined in this or referenced document if that is the case. This should be fairly straight forward to fix, but needs to be done. Cheers Magnus Den 2016-12-22 kl. 22:18, skrev The IESG: > > The IESG has received a request from the ControLling mUltiple streams for > tElepresence WG (clue) to consider the following document: > - 'Mapping RTP streams to CLUE Media Captures' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document describes how the Real Time transport Protocol (RTP) is > used in the context of the CLUE protocol. It also describes the > mechanisms and recommended practice for mapping RTP media streams > defined in SDP to CLUE Media Captures. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri Jan 13 12:27:53 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 82939129E0B; Fri, 13 Jan 2017 12:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 afCLI89LfKww; Fri, 13 Jan 2017 12:27:49 -0800 (PST) Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id 62784129E08; Fri, 13 Jan 2017 12:27:49 -0800 (PST) X-AuditID: 12074412-5ddff700000009b5-6d-58793844658c Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id E5.E6.02485.44839785; Fri, 13 Jan 2017 15:27:48 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0DKRk6k008407 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Jan 2017 15:27:47 -0500 To: Magnus Westerlund References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <1957e1a2-6f79-82e3-451e-f78500950108@alum.mit.edu> Date: Fri, 13 Jan 2017 15:27:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixO6iqOtiURlhsPGKisXXSUvYLPafusxs 8XTiPxaLS+vvMTmwePz6epXNY8mSn0wBTFFcNimpOZllqUX6dglcGd+XmxU8la04tPEsSwPj H/EuRk4OCQETiR8fDjJ1MXJxCAlcZpSYv+4SG4RznUli168udhBHWKCBUWLzh9NMIC0iAmYS Dyfsh6pqYZSY/Ps4G0iCWcBXYsPmKawgNpuAlsScQ/9ZQGxeAXuJ5v0LGbsYOThYBFQltiwQ BQmLCqRJPDi5lRGiRFDi5MwnYOWcAg4S505/ZIIYaStxZ+5uZghbXmL72znMExj5ZyFpmYWk bBaSsgWMzKsY5RJzSnN1cxMzc4pTk3WLkxPz8lKLdM30cjNL9FJTSjcxQsJUaAfj+pNyhxgF OBiVeHgDpCojhFgTy4orcw8xSnIwKYnyfletiBDiS8pPqcxILM6ILyrNSS0+xCjBwawkwvve AKicNyWxsiq1KB8mJc3BoiTO+3Oxup+QQHpiSWp2ampBahFMVoaDQ0mCN84cqFGwKDU9tSIt M6cEIc3EwQkynAdoeJMZyPDigsTc4sx0iPwpRkUpcV51kGYBkERGaR5cLyyNvGIUB3pFmLcA pIoHmILgul8BDWYCGnzRphxkcEkiQkqqgXHDttIXe/zDVi9YXfl2ms2/lgeiEe0n4rpLFgpp r5N+dvuoU9009U2/vIp3bbj+vou7QkjH+WnU96uvGDbyrdD6ZPmKO8T1YLXTthkH1lmx/tnV YnNnie6lzX+ye04XlJ2V/PuQP7DuwVa+F/YdzhXfv3Da7V3vbfDlURWLQNaRI8821HpwnzZU YinOSDTUYi4qTgQAhL5Ftf4CAAA= Archived-At: Cc: draft-ietf-clue-rtp-mapping@ietf.org, clue-chairs@ietf.org, clue@ietf.org Subject: Re: [clue] Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 20:27:51 -0000 Roni? On 1/13/17 7:22 AM, Magnus Westerlund wrote: > Hi, > > As one of IANA's expert reviewers for the two registries that this > document attempts to register in, I want to provide some feedback on > individual basis and directly. > > The SDES item registration of the CaptureID is fine with the exception > that it isn't clear on the security consideration for the CaptureID > field as SDES item. I fail to find any limitations or even > recommendations for how the value is created by the implementation. Nor > does the security considerations discuss the potential risk that the > capture ID is privacy sensitive, like "Adrian's Mic" rather than AC0 as > in the example in the data model document. The data model document is > fairly clear on the need for confidentiality and authorization for the > whole data model document. However, this thinking has not been raised > and clarified in this specific move of the information into the RTP > protocol. > > So, I would recommend a discussion in general if the field should have > anonymous labels, that do not contain privacy information. Then one > needs to be clear on what requirements that puts on transporting this > field in RTP. And that depends on how certain one can be that it is > anonymous or that it may contain sensitive information and therefore > should be confidentiality protected. In all cases this field needs > integrity and source authentication. Which should be made explicit in > the security consideration. The clue mapping require implementation of > SRTP with DTLS-SRTP keying, however, it fails to be specific on which > protection profiles that are to be supported, both for the SRTP as well > as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I > can't be certain if the CaptureID will be confidentiality protected or > not even in RTCP. > > When it comes to the RTP Header Extension case, the RFC 7941 is very > explicit about the requirement on doing this security consideration. And > I note that with the above analysis of what requirements to put, one can > ensure that the right requirements on the CLUE system to protect any RTP > header extension with the CaptureID is done. I do note that if > confidentiality protection is needed, this means additional > implementation requirement. Such needs to be defined in this or > referenced document if that is the case. > > This should be fairly straight forward to fix, but needs to be done. > > Cheers > > Magnus > > Den 2016-12-22 kl. 22:18, skrev The IESG: >> >> The IESG has received a request from the ControLling mUltiple streams for >> tElepresence WG (clue) to consider the following document: >> - 'Mapping RTP streams to CLUE Media Captures' >> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final comments on this action. Please send substantive comments to the >> ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document describes how the Real Time transport Protocol (RTP) is >> used in the context of the CLUE protocol. It also describes the >> mechanisms and recommended practice for mapping RTP media streams >> defined in SDP to CLUE Media Captures. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> >> >> > > From nobody Fri Jan 13 14:23:43 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 ACBAF129721 for ; Fri, 13 Jan 2017 14:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 asLn9K7t0r4S for ; Fri, 13 Jan 2017 14:23:41 -0800 (PST) Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id EC746129EAE for ; Fri, 13 Jan 2017 14:23:40 -0800 (PST) X-AuditID: 12074414-773ff70000004a85-d3-5879536b96fd Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 1E.D6.19077.B6359785; Fri, 13 Jan 2017 17:23:40 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0DMNbni014677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 13 Jan 2017 17:23:38 -0500 To: Mark Duckworth , Christian Groves , Simon Pietro Romano From: Paul Kyzivat Message-ID: <29895908-43c2-d434-a269-b319a9bca64c@alum.mit.edu> Date: Fri, 13 Jan 2017 17:23:37 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixO6iqJsTXBlhcK5fzOLL+0YWi/2nLjNb fO+9ymixre0GswOLx5IlP5k8VpyfyeKx+fULZo8fW54yBbBEcdmkpOZklqUW6dslcGUs/nOQ vWAPS8XFOWuZGhgPMHcxcnJICJhINLVPYOxi5OIQErjMKPH36WkmCOc6k8S535PYQBwRgemM EgeXdYG1sAloScw59J8FxBYWUJHYuPwaI4jNLCAhcfviPCYQm1fAXuLi0olgcRYBVYkrDb/A 4qICaRIPTm5lhKgRlDg58wkLRK+ZxLzND5khbHmJ7W/nME9g5J2FpGwWkrJZSMoWMDKvYpRL zCnN1c1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSndxAgJRpEdjEdOyh1iFOBgVOLh/SFeGSHE mlhWXJl7iFGSg0lJlPe7akWEEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe54FA5bwpiZVVqUX5 MClpDhYlcd5vi9X9hATSE0tSs1NTC1KLYLIyHBxKErzPgoAaBYtS01Mr0jJzShDSTBycIMN5 gIabgtTwFhck5hZnpkPkTzHqcpz6dOElkxBLXn5eqpQ472mQCwRAijJK8+DmwJLIK0ZxoLeE eYVBRvEAExDcpFdAS5iAlly0KQdZUpKIkJJqYGTyni24Lr/DfaqKpnua74cat9LbSaLrbpqE b+SvKjn5u/RA1P8JDnEtro9tvh+8FcO+51D2ltyWY3zbNsQKR3MGeT1rEJh5R9trkZza/C1P bEz+i6reOL78+slsD8/5iZsv29zVELjxJ6Tk0ua20hrurdz34nebPJ3N3XhM1OpjSN+d9y1/ ZZRYijMSDbWYi4oTAVhjkuH9AgAA Archived-At: Cc: CLUE Subject: [clue] draft-ietf-clue-protocol-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 13 Jan 2017 22:23:43 -0000 Mark, Christian, Simon, and other clueful, On Jan 2 Simon responded to outstanding comments from Mark and Christian. He also published -11 reflecting his response to those comments. On Jan 5 & 6 Mark and Christian replied to Simon. The subject line continued to refer to -10. I am not sure if those comments were directed specifically in the context of -11 or still -10. I *think* there are still a few small loose ends to clear up. Can the three of you please try to come to convergence? We are *almost* done! Thank you all for your efforts! Paul From nobody Sat Jan 14 21:44:57 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 90EB01289C4; Sat, 14 Jan 2017 21:44:55 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148445909555.24171.16959374231971197789.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 21:44:55 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-11.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 05:44:55 -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 of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-11.txt Pages : 12 Date : 2017-01-14 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-11 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 Sat Jan 14 22:05:31 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 5AC691289C4; Sat, 14 Jan 2017 22:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f0tkCCDLtLbN; Sat, 14 Jan 2017 22:05:28 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (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 8E447127076; Sat, 14 Jan 2017 22:05:28 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id c85so22111047wmi.1; Sat, 14 Jan 2017 22:05:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=xkrEAQ2uQGhuSN6upJYoqwzb4ZMUX/KWNLTwXmKib14=; b=CGZKcz+CQpowEA4d7RGgiBxYhCEHn+uUTEoIpVs4w3PreBWjXim+/4fxsME82W8xK4 gZm8XBptG9nDKojRBD6k5eTh1rszLwGmfbr9Q+ryB+/WDwYhmEP3Gd8V+BtjrNbBtXtS FBX+CxQEoCtrC+r11BaZL9z1lP/WKCGZFJWr/72Je5R9QJDncI+lWWi7J230KeHE35IL TE2ZpvesQEVYSJnb20Lp/UvMs9dtIkPMB5mAJ6rYh/vxT8lOsTF2PyT5Bf2q7DtxRs6d /VfsrdScWh6StJ8NUh6upjE2PxS+Es9x8fv3yHCCy2wixWrLpgDIJsKoz0d1ttm7LsgK vypg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=xkrEAQ2uQGhuSN6upJYoqwzb4ZMUX/KWNLTwXmKib14=; b=iij48BwFVuP2452/JL8KQvi1kPIDmzr9tbniJf2UbhquHPZneJyQcIeacCOY+Si79f Hy7rSEkLt4Js2DWGs9XAMNLwkcDhcXJgVCAkmoXQEkhylVqnYvWzYbVAm7iyTUFfr2Xw aFSKJwjPKfBRMSDff9S5F3VUBsvUTeQzJKtgECh1Hd3tvP1CKLzrDn5CK6Uw0/BzGCnj tnfoSQaL+MR4onumcX1JHWVlPJFG6sCG2IZ0Z6C7mtFHqNMaJG+1Wr9glSLTerYvbcy7 PyBB2Zdm6+GHz3+H8KN4VJuv8VwqFHHf8yHv5/N8J6YjEeIskRww8XMoKz0OmHvfVlOT uQHA== X-Gm-Message-State: AIkVDXLOm4RURP/hs01fHae+oIY/haeea35/D2JBnLqovcbc1wU9LfC37It5evltMPjkGA== X-Received: by 10.223.130.204 with SMTP id 70mr18382305wrc.128.1484460326869; Sat, 14 Jan 2017 22:05:26 -0800 (PST) Received: from RoniPC ([2.53.141.242]) by smtp.gmail.com with ESMTPSA id s20sm18224936wmb.9.2017.01.14.22.05.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 14 Jan 2017 22:05:24 -0800 (PST) From: "Roni Even" To: "'Magnus Westerlund'" , References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 15 Jan 2017 08:05:22 +0200 Message-ID: <001901d26ef5$5c91af20$15b50d60$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIponXJa9st+OXyo8A7i9lppNYssAHLDuQ3oHxKP1A= Content-Language: he Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: Re: [clue] Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 15 Jan 2017 06:05:30 -0000 Hi Magnus, CaptureID here is just conveying the value defined in the CLUE data = model and CLUE protocol defines the security consideration for conveying the adertized and configured values. So any security on creating is done in the protocol document As for the header extension, I will add some text Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Magnus = Westerlund > Sent: Friday, January 13, 2017 2:22 PM > To: ietf@ietf.org > Cc: draft-ietf-clue-rtp-mapping@ietf.org; clue-chairs@ietf.org; clue@ietf.org > Subject: Re: [clue] Last Call: (Mapping RTP > streams to CLUE Media Captures) to Proposed Standard >=20 > Hi, >=20 > As one of IANA's expert reviewers for the two registries that this document > attempts to register in, I want to provide some feedback on individual basis and > directly. >=20 > The SDES item registration of the CaptureID is fine with the exception that it isn't > clear on the security consideration for the CaptureID field as SDES = item. I fail to > find any limitations or even recommendations for how the value is = created by > the implementation. Nor does the security considerations discuss the potential > risk that the capture ID is privacy sensitive, like "Adrian's Mic" = rather than AC0 > as in the example in the data model document. The data model document = is > fairly clear on the need for confidentiality and authorization for the whole data > model document. However, this thinking has not been raised and = clarified in this > specific move of the information into the RTP protocol. >=20 > So, I would recommend a discussion in general if the field should have > anonymous labels, that do not contain privacy information. Then one = needs to > be clear on what requirements that puts on transporting this field in = RTP. And > that depends on how certain one can be that it is anonymous or that it = may > contain sensitive information and therefore should be confidentiality protected. > In all cases this field needs integrity and source authentication. = Which should be > made explicit in the security consideration. The clue mapping require > implementation of SRTP with DTLS-SRTP keying, however, it fails to be specific > on which protection profiles that are to be supported, both for the = SRTP as well > as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I = can't be > certain if the CaptureID will be confidentiality protected or not even = in RTCP. >=20 > When it comes to the RTP Header Extension case, the RFC 7941 is very explicit > about the requirement on doing this security consideration. And I note that with > the above analysis of what requirements to put, one can ensure that = the right > requirements on the CLUE system to protect any RTP header extension = with the > CaptureID is done. I do note that if confidentiality protection is = needed, this > means additional implementation requirement. Such needs to be defined = in this > or referenced document if that is the case. >=20 > This should be fairly straight forward to fix, but needs to be done. >=20 > Cheers >=20 > Magnus >=20 > Den 2016-12-22 kl. 22:18, skrev The IESG: > > > > The IESG has received a request from the ControLling mUltiple = streams > > for tElepresence WG (clue) to consider the following document: > > - 'Mapping RTP streams to CLUE Media Captures' > > as Proposed Standard > > > > The IESG plans to make a decision in the next few weeks, and = solicits > > final comments on this action. Please send substantive comments to = the > > ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments = may > > be sent to iesg@ietf.org instead. In either case, please retain the > > beginning of the Subject line to allow automated sorting. > > > > Abstract > > > > > > This document describes how the Real Time transport Protocol = (RTP) is > > used in the context of the CLUE protocol. It also describes the > > mechanisms and recommended practice for mapping RTP media streams > > defined in SDP to CLUE Media Captures. > > > > > > > > > > The file can be obtained via > > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > > > IESG discussion can be tracked via > > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ > > > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > > > > > >=20 >=20 > -- >=20 > Magnus Westerlund >=20 > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sat Jan 14 22:41:05 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 6A0A8127076; Sat, 14 Jan 2017 22:41:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148446246442.24167.11183332125428592480.idtracker@ietfa.amsl.com> Date: Sat, 14 Jan 2017 22:41:04 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 06:41:04 -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 of the IETF. Title : Mapping RTP streams to CLUE Media Captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-12.txt Pages : 12 Date : 2017-01-14 Abstract: This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol. It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-12 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 Sun Jan 15 17:37:03 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 933E1127058 for ; Sun, 15 Jan 2017 17:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 212h_JLBXzYj for ; Sun, 15 Jan 2017 17:37:00 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE00128824 for ; Sun, 15 Jan 2017 17:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wI82h4f2ERTA9wjSWfoBFtZixTxwjrHinzW8aJweXlk=; b=wJoDPBQKPSWESeYbtera2atzi4 5Yt9UJpTyLGb0cJmi1EyT4cljL0F5MNiA/s1Cc3u9OJwwStxjKPchqW1HHz/hUyN4d58BX9GJ0Vf+ KjwwEPIXFN+kD6pGOyyUlz7fkgdaeUkWLYYISpD9cXJhklg4wIr9RF4DYeBmWqWuugTKhZi/DL+6P QW7hhmQIjIW8WT/SzVuQTsq7JSypG07+s4TnNpaPI+hb6U0q+HEyDaDBLEzCjwBT/nlCQVV6nMhVD tAYDJr6r50UvSsBYutUdyANfHu4rau8z7l3iVyqo7rZZF2M6wb8ifRlH1hKKwDt4cQUmj/NcAtX83 X9eIqW3w==; Received: from ppp118-209-145-28.lns20.mel8.internode.on.net ([118.209.145.28]:57808 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cSwEA-002Nwv-VK; Mon, 16 Jan 2017 12:36:55 +1100 To: Paul Kyzivat , Mark Duckworth , Simon Pietro Romano References: <29895908-43c2-d434-a269-b319a9bca64c@alum.mit.edu> From: Christian Groves Message-ID: <71798e61-fc28-734c-e989-343d18f5c74f@nteczone.com> Date: Mon, 16 Jan 2017 12:36:51 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <29895908-43c2-d434-a269-b319a9bca64c@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 01:37:01 -0000 Hello Paul, My comments were on Simon's answers which were incorporated in -11. Several of my comments would have to be incorporated in a v12. Regards, Christian On 14/01/2017 9:23 AM, Paul Kyzivat wrote: > Mark, Christian, Simon, and other clueful, > > On Jan 2 Simon responded to outstanding comments from Mark and > Christian. He also published -11 reflecting his response to those > comments. > > On Jan 5 & 6 Mark and Christian replied to Simon. The subject line > continued to refer to -10. I am not sure if those comments were > directed specifically in the context of -11 or still -10. > > I *think* there are still a few small loose ends to clear up. Can the > three of you please try to come to convergence? We are *almost* done! > > Thank you all for your efforts! > Paul > From nobody Sun Jan 15 17:44:21 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 1F87C128824 for ; Sun, 15 Jan 2017 17:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.91 X-Spam-Level: X-Spam-Status: No, score=0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 Ix4sm7z6Sf0c for ; Sun, 15 Jan 2017 17:44:20 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23A80127058 for ; Sun, 15 Jan 2017 17:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=O5owVWcNarOcL+0m2o45TuEt+eUPjO2BMQg6VoQ16WM=; b=hzsTTGYrJ1xD6IpjXcEjThn5G+ v9G82oiYZxs/wOBBWW89RxX88dNjUeu8ePPtkgAaOnCVvYHdW8feQfI+FbsQN/WJaA9GR9wd6rTis 0kAXCWE2dajZNRfCL3z4bTSvAkU7I3RCSwHMAiAG/sMCWfriwGcwXDKx8jOqz51/Da8+XCbjWuQC4 W8x9WXyU3qQLlv20KDXNAtqYbJvsIqLlPZXci/orsZNtPkCpbfvierbq4g9F3VnRaX9bmhQDkskEV C4qOfM4I6r9lwTxWIyhwF8+c1S2RylVAKVQpm7a/dLbS6hW5fZm4h1eJhweu8hHzbKQlG1U/B3rci M2Y9y9Zg==; Received: from ppp118-209-145-28.lns20.mel8.internode.on.net ([118.209.145.28]:58118 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cSwLK-002ObB-Et for clue@ietf.org; Mon, 16 Jan 2017 12:44:18 +1100 To: clue@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD76C6CF@DGGEMM506-MBX.china.huawei.com> From: Christian Groves Message-ID: Date: Mon, 16 Jan 2017 12:44:16 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC on draft-ietf-clue-signaling-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 01:44:21 -0000 +1 from me. A couple of the references need updated versions e.g. draft-ietf-mmusic-data-channel-sdpneg but these are moving targets and can be picked up later. Regards, Christian On 13/01/2017 4:53 AM, Paul Kyzivat wrote: > On 1/12/17 1:29 AM, Roni Even wrote: > >> We had a WGLC on draft-ietf-clue-signaling-06 on October 2015. Since >> then there were updates to the documents based on the reviews and the >> documents should be ready now for publication. >> >> I would like to have a second WGLC allowing the WG to review the >> document before sending it to publication. >> >> The WGLC will end February 2^nd to allow for enough time for reviews. >> >> Please use this time and review the document and send comments to the >> list including I read and have no comments > > I'm one of the authors, so perhaps it goes without saying, but I've > read all the versions and I'm good with it as it is now. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jan 15 22:40: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 D1827129428 for ; Sun, 15 Jan 2017 22:40:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.7 X-Spam-Level: X-Spam-Status: No, score=-3.7 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 7mrHnJtdcHcu for ; Sun, 15 Jan 2017 22:40:46 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB52126D73 for ; Sun, 15 Jan 2017 22:40:46 -0800 (PST) X-ASG-Debug-ID: 1484548841-05f27556cb2a2f40001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id UZikpkqZyhHVJ6PP (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2017 07:40:41 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [1.176.243.99] ([91.253.249.140]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v0G6edl0011429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Jan 2017 07:40:40 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: draft-ietf-clue-protocol-11 X-Mailer: iPhone Mail (14C92) In-Reply-To: <71798e61-fc28-734c-e989-343d18f5c74f@nteczone.com> Date: Mon, 16 Jan 2017 07:38:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7739D509-D0F5-4076-8790-9F6F68549289@unina.it> References: <29895908-43c2-d434-a269-b319a9bca64c@alum.mit.edu> <71798e61-fc28-734c-e989-343d18f5c74f@nteczone.com> To: Christian Groves X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1484548841 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 1.176.243.99 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, BSF_SPF_SOFTFAIL, MIME_QP_LONG_LINE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35827 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: Cc: CLUE Subject: Re: [clue] draft-ietf-clue-protocol-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 06:40:49 -0000 Hello guys, we're working on them. Version 12 will be ready soon. Cheers, Simon Inviato da iPhone > Il giorno 16 gen 2017, alle ore 02:36, Christian Groves ha scritto: >=20 > Hello Paul, >=20 > My comments were on Simon's answers which were incorporated in -11. Severa= l of my comments would have to be incorporated in a v12. >=20 > Regards, Christian >=20 >=20 >> On 14/01/2017 9:23 AM, Paul Kyzivat wrote: >> Mark, Christian, Simon, and other clueful, >>=20 >> On Jan 2 Simon responded to outstanding comments from Mark and Christian.= He also published -11 reflecting his response to those comments. >>=20 >> On Jan 5 & 6 Mark and Christian replied to Simon. The subject line contin= ued to refer to -10. I am not sure if those comments were directed specifica= lly in the context of -11 or still -10. >>=20 >> I *think* there are still a few small loose ends to clear up. Can the thr= ee of you please try to come to convergence? We are *almost* done! >>=20 >> Thank you all for your efforts! >> Paul >>=20 >=20 >=20 From nobody Mon Jan 16 05:20:07 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 C56AB129406 for ; Mon, 16 Jan 2017 05:20:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 ApS6abuqwhb9 for ; Mon, 16 Jan 2017 05:20:03 -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 33FEF1293F5 for ; Mon, 16 Jan 2017 05:20:03 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEN84997; Mon, 16 Jan 2017 13:20:00 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 16 Jan 2017 13:19:58 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0301.000; Mon, 16 Jan 2017 21:19:52 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AdJv7ZUuiNGS7gCVTiuOvOx9KcHY1AADXJpA Date: Mon, 16 Jan 2017 13:19:52 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76DBC1@DGGEMM506-MBX.china.huawei.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.201.115.198] Content-Type: multipart/mixed; boundary="_004_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.587CC880.035A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: c85cfc3ea124f9711242602149ffce4b Archived-At: Subject: [clue] FW: WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 13:20:06 -0000 --_004_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_ Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_" --_000_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, This WGLC is also important to CLUE so if you can review and send comments = to MMUSIC list it will be helpful Roni Even CLUE WG co-chair From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: =E9=E5=ED =E1 16 =E9=F0=E5=E0=F8 2017 13:45 To: mmusic (mmusic@ietf.org) Cc: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org Subject: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sdpneg-11 MMUSIC, This email starts a one week WG last call on version -11 of this draft that= ends on January 23, 2017. There was a previous WG last call on version -09 that resulted in some mino= r document updates. The intended status of this document is standards track (Proposed Standard)= . Please review and provide any comments you may have on the document. Commen= ts should be sent to the document authors and the MMUSIC WG list. If you re= view the document but do not have any comments, please send a note to that = effect as well. Please also forward this WGLC to any other interested parties who may be ab= le to review the draft, asking them to also direct their comments to the au= thors and the list as above. The document can be retrieved here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/ Thank you! Bo Burman (MMUSIC co-chair) --_000_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

This WGLC is also impo= rtant to CLUE so if you can review and send comments to MMUSIC list it will= be helpful

Roni Even

CLUE WG co-chair<= /o:p>

 

From: mmusic [= mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: =E9=E5=ED =E1 16 =E9=F0=E5=E0=F8 2017 13:45
To: mmusic (mmusic@ietf.org)
Cc: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org
Subject: [MMUSIC] WG Last Call for draft-ietf-mmusic-data-channel-sd= pneg-11

 

MMUSIC,

 

This email starts a one week WG last call on version= -11 of this draft that ends on January 23, 2017.

There was a previous WG last call on version -09 tha= t resulted in some minor document updates.


The intended status of this document is standards track (Proposed Standard)= .

Please review and provide any comments you may have on the document. Commen= ts should be sent to the document authors and the MMUSIC WG list. If you re= view the document but do not have any comments, please send a note to that = effect as well.

 

Please also forward this WGLC to any other intere= sted parties who may be able to review the draft, asking them to also direc= t their comments to the authors and the list as above.

 

The document can be retrieved here:

https://datatracker.ietf.org/doc/draft-ietf= -mmusic-data-channel-sdpneg/

 

Thank you!

 

        Bo Bur= man (MMUSIC co-chair)

 

--_000_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_-- --_004_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 16 Jan 2017 12:06:20 GMT"; modification-date="Mon, 16 Jan 2017 12:06:20 GMT" Content-ID: Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_6E58094ECC8D8344914996DAD28F1CCD76DBC1DGGEMM506MBXchina_-- From nobody Mon Jan 16 05:56:54 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 4782F129470; Mon, 16 Jan 2017 05:56:50 -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 IfQldTWofuHF; Mon, 16 Jan 2017 05:56:48 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61E012943D; Mon, 16 Jan 2017 05:56:47 -0800 (PST) X-AuditID: c1b4fb30-3136f98000003c8a-0f-587cd11d6d6c Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 7A.B5.15498.D11DC785; Mon, 16 Jan 2017 14:56:45 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.319.2; Mon, 16 Jan 2017 14:56:43 +0100 To: Roni Even , References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> <001901d26ef5$5c91af20$15b50d60$@gmail.com> From: Magnus Westerlund Message-ID: <18e96e7e-51f4-2a38-a267-110f7f60f9aa@ericsson.com> Date: Mon, 16 Jan 2017 14:56:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <001901d26ef5$5c91af20$15b50d60$@gmail.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM2K7ma7sxZoIg0MLLS2+TlrCZrH/1GVm i6cT/7FYPNs4n8XibzuzA6vHzll32T2WLPnJFMAUxWWTkpqTWZZapG+XwJWx7cY0toIpJhUb jp5hbGCcq9XFyMEhIWAisWqudBcjF4eQwDpGiZ9TV7FBOMsZJa4daGQBcYQF2hklTn45yArS ISJgLrFqPR9E0SZGiXcn5gN1cHIwC4RKXPnwgR3EZhOwkLj5oxEszitgL/Ft4lRGEJtFQFXi 5oU7TCC2qECMxNv1y9khagQlTs58wgIynxOo985GfRCTGaj1wdYyiOnyEs1bZzOD2EIC2hIN TR2sExgFZiFpnoXQMQtJxwJG5lWMosWpxUm56UZGeqlFmcnFxfl5enmpJZsYgeF6cMtvgx2M L587HmIU4GBU4uHdcKw6Qog1say4MvcQowQHs5IIr+SZmggh3pTEyqrUovz4otKc1OJDjNIc LErivGYr74cLCaQnlqRmp6YWpBbBZJk4OKUaGLf/k1+/3fn8ggOStcF3ugTXCqz/tcpBv0rI TkrMu2pi6so5h1+5+z2/qi7SJrTwwbuG7X+SJrRnlxy+XH7W9i+HF2P/y8t/vf/msi0wP9Hv YTolN+q26+rdKnYB+RFLPomsXfjYg+3jCfGkqcGhB6dJHudhvZ5ia2u3Raf137PyRL9a/fQj ZUosxRmJhlrMRcWJAHpAUhhTAgAA Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: Re: [clue] Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 13:56:50 -0000 Den 2017-01-15 kl. 07:05, skrev Roni Even: > Hi Magnus, > CaptureID here is just conveying the value defined in the CLUE data model > and CLUE protocol defines the security consideration for conveying the > adertized and configured values. > So any security on creating is done in the protocol document Yes, it is containing a value. And the data model and protocol documents defines the protocol level security requirements and solution. However, as the CaptureID is taken out of the context of the CLUE protocol, and put into RTP/RTCP there needs to be consideration for the implications of that action. As I don't find any recommendation for how an implementation generates CaptureIDs I could not determine the security sensitivity of the field. That is why I am asking about that aspect. Please provide an analysis of what it may contain, i.e. worst case, and the appropriate recommendation for appropriately securing that field. > > As for the header extension, I will add some text And I think this is relevant also for SDES items in general, not only for the header extension. The security risks and fundamental requirements are shared anyway. Cheers Magnus > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Magnus Westerlund >> Sent: Friday, January 13, 2017 2:22 PM >> To: ietf@ietf.org >> Cc: draft-ietf-clue-rtp-mapping@ietf.org; clue-chairs@ietf.org; > clue@ietf.org >> Subject: Re: [clue] Last Call: > (Mapping RTP >> streams to CLUE Media Captures) to Proposed Standard >> >> Hi, >> >> As one of IANA's expert reviewers for the two registries that this > document >> attempts to register in, I want to provide some feedback on individual > basis and >> directly. >> >> The SDES item registration of the CaptureID is fine with the exception > that it isn't >> clear on the security consideration for the CaptureID field as SDES item. > I fail to >> find any limitations or even recommendations for how the value is created > by >> the implementation. Nor does the security considerations discuss the > potential >> risk that the capture ID is privacy sensitive, like "Adrian's Mic" rather > than AC0 >> as in the example in the data model document. The data model document is >> fairly clear on the need for confidentiality and authorization for the > whole data >> model document. However, this thinking has not been raised and clarified > in this >> specific move of the information into the RTP protocol. >> >> So, I would recommend a discussion in general if the field should have >> anonymous labels, that do not contain privacy information. Then one needs > to >> be clear on what requirements that puts on transporting this field in RTP. > And >> that depends on how certain one can be that it is anonymous or that it may >> contain sensitive information and therefore should be confidentiality > protected. >> In all cases this field needs integrity and source authentication. Which > should be >> made explicit in the security consideration. The clue mapping require >> implementation of SRTP with DTLS-SRTP keying, however, it fails to be > specific >> on which protection profiles that are to be supported, both for the SRTP > as well >> as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I can't > be >> certain if the CaptureID will be confidentiality protected or not even in > RTCP. >> >> When it comes to the RTP Header Extension case, the RFC 7941 is very > explicit >> about the requirement on doing this security consideration. And I note > that with >> the above analysis of what requirements to put, one can ensure that the > right >> requirements on the CLUE system to protect any RTP header extension with > the >> CaptureID is done. I do note that if confidentiality protection is needed, > this >> means additional implementation requirement. Such needs to be defined in > this >> or referenced document if that is the case. >> >> This should be fairly straight forward to fix, but needs to be done. >> >> Cheers >> >> Magnus >> >> Den 2016-12-22 kl. 22:18, skrev The IESG: >>> >>> The IESG has received a request from the ControLling mUltiple streams >>> for tElepresence WG (clue) to consider the following document: >>> - 'Mapping RTP streams to CLUE Media Captures' >>> as Proposed Standard >>> >>> The IESG plans to make a decision in the next few weeks, and solicits >>> final comments on this action. Please send substantive comments to the >>> ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may >>> be sent to iesg@ietf.org instead. In either case, please retain the >>> beginning of the Subject line to allow automated sorting. >>> >>> Abstract >>> >>> >>> This document describes how the Real Time transport Protocol (RTP) is >>> used in the context of the CLUE protocol. It also describes the >>> mechanisms and recommended practice for mapping RTP media streams >>> defined in SDP to CLUE Media Captures. >>> >>> >>> >>> >>> The file can be obtained via >>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >>> >>> IESG discussion can be tracked via >>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ >>> >>> >>> No IPR declarations have been submitted directly on this I-D. >>> >>> >>> >>> >>> >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Frgatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 16 06:57: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 65A7512955C for ; Mon, 16 Jan 2017 06:57: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 m7XBREXmCSlB for ; Mon, 16 Jan 2017 06:57:12 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874E1129556 for ; Mon, 16 Jan 2017 06:57:12 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-be-587cdf46fc31 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 84.2C.25710.64FDC785; Mon, 16 Jan 2017 15:57:10 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.89) with Microsoft SMTP Server id 14.3.319.2; Mon, 16 Jan 2017 15:57:04 +0100 References: <148446246442.24167.11183332125428592480.idtracker@ietfa.amsl.com> From: Magnus Westerlund To: Message-ID: <7d5f732c-e7a7-739c-ae8f-7521bfddc7f9@ericsson.com> Date: Mon, 16 Jan 2017 15:57:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148446246442.24167.11183332125428592480.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLLMWRmVeSWpSXmKPExsUyM2J7uK7b/ZoIg1t9Ghb7T11mdmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr6uvewF/6Qq3nYuZm9gvCDaxcjJISFgIjFp1m7GLkYuDiGB dYwSk+9MZIVwljNK/H98nAmkSljASWLjngfMILaQgJ/ErhfN7CA2m4CFxM0fjWwgtoiAsMSE Y/vBangF7CXWb94L1ssioCqx4e9BsLioQIzE2/XL2SFqBCVOznzCAmJzCvhLPLpwCaieg4MZ qPfB1jKQMLOAvETz1tlQa7UlGpo6WCcw8s9C0j0LoWMWko4FjMyrGEWLU4uLc9ONjPVSizKT i4vz8/TyUks2MQID7eCW37o7GFe/djzEKMDBqMTDu+FYdYQQa2JZcWXuIUYJDmYlEV7DWzUR QrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgtgskycXBKNTBGcC/59GzV 5PPHmlMP57onPzpzLmZfzbvEON+Lhj25E6Z+XHx74fQ5/+3ebZ5zStfCg/8fp6rqjsmCLlM+ G8zd68tsvE8hVm3ha+WM3106z84EHVjOv2Bp7tHdX2+w3vaavs5OyoF77pNZ0gvEnq5we30s SXpDRUDuwpm7d204yhD64NaMFRWx7UosxRmJhlrMRcWJAMP4hMowAgAA Archived-At: Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 14:57:14 -0000 Hi, Looking at the update in the draft-12: > The CaptureID is created as part of the CLUE protocol. The CaptId > SDES item is used to convey the same CaptureID value in the SDES > item. When sending the SDES item the security considertion specied > in the security section of [RFC7941] are applicable and this SDES > item MUST use similar security as the CLUE protocol messages carried > in the CLUE data channel. I don't find this sufficient. First of all, there is no clarify of what the security treats to the CaptureId are. Secondly, the similar security here is far from trivial as the SCTPoDTLS data channel uses DTLS while RTP/RTCP security is the combination of the DTLS-SRTP and SRTP mechanisms in use. Note that from part of the security aspects DTLS-SRTP and DTLS is actually quite different. I will note that I still haven't found the equivalent the RTCWeb security architecture document. Which actually discusses what protection profiles to support. CLUE-Framework: In addition, the media MUST be secured. DTLS/SRTP MUST be supported and SHOULD be used unless the media, which is based on RTP, is secured by other means (see [RFC7201] [RFC7202]). Media security is also discussed in [I-D.ietf-clue-signaling] and [I-D.ietf-clue- rtp-mapping]. In signalling this is also not specified: All CLUE- controlled RTP "m" lines must be secured and implemented using mechanisms such as SRTP [RFC3711]; no specific security mechanisms are made mandatory to use due to the issues addressed in [RFC7202]. I would note, that the point of RFC 7202, is that "solutions" like CLUE is the one that shall make mandatory to implement choices. So that CLUE WG attempts to dodge that aspect is very worrying. Then RTP-mapping: The Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback [RFC5124] (RTP/SAVPF) provides handling of fundamental issues by offering confidentiality, integrity and partial source authentication. CLUE endpoints MUST support RTP/ SAVPF and DTLS-SRTP keying [RFC5764]. This part is actually good, but it needs additional sentences saying which DTLS algorithms and which DTLS-SRTP protection profiles that needs to be supported. And then we arrive back at the question. Does this document needs to mandate implementation of RFC6904? And does that actually provide equivalent security. Which all comes back to what may the CaptureID value contain. Is that privacy sensitive? I am sorry press you about the security aspects and the need for analysis and understanding of what choices implies. Yes, choosing the right things are difficult. The RTCWeb Security Architecture document (https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12) still has a rather large number of issues: https://github.com/rtcweb-wg/security-arch/issues Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon Jan 16 12:11:27 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 A9C27129610 for ; Mon, 16 Jan 2017 12:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 rkesT4xWIgEX for ; Mon, 16 Jan 2017 12:11:25 -0800 (PST) Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02093129640 for ; Mon, 16 Jan 2017 12:01:30 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-09v.sys.comcast.net with SMTP id TDRqcA0DJ5lLvTDT8chD6I; Mon, 16 Jan 2017 20:01:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484596890; bh=vC6k8jtUkqrvlsTb+ep6k6LG2OF3YVr9S0oiGSc/RrY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=OYZkPbHnlu4uBbpXqroVQ+uDh4fPGuiF3a32QhuPZhaxxwlvyz/K65mmrAACTtG/h mtV6qbrluDJmQUBgZNLP4shYAenI10015cJBNJpoFwC+36JOp/LBm8cqQnUESOTJxC WB5q9w5sT7DJ0tOdpy3ZuIbx9n/lyaKT451IDNIn1X5bH5VPzEJ6RgyviLKGQtmJWC 6JJduN912PbgiPh4UDK3HvntAlvyapFYdW7BAOHByPQ9666UFmFiXg9sf/so6XtllW KSPHxMVDMA0XwG3DvP5K7udRXPx+QeEx+hf3RETKM35wYf2CmkcijhwPaBE+goUjr+ llyhIf9wK3gVg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-03v.sys.comcast.net with SMTP id TDT7c6dq3wJd1TDT7cKk2C; Mon, 16 Jan 2017 20:01:30 +0000 To: Magnus Westerlund , Roni Even , ietf@ietf.org References: <148244150608.26135.13003140554574277685.idtracker@ietfa.amsl.com> <001901d26ef5$5c91af20$15b50d60$@gmail.com> <18e96e7e-51f4-2a38-a267-110f7f60f9aa@ericsson.com> From: Paul Kyzivat Message-ID: <6c1e7532-d4aa-8529-efa7-57c809afe63d@comcast.net> Date: Mon, 16 Jan 2017 15:01:29 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <18e96e7e-51f4-2a38-a267-110f7f60f9aa@ericsson.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: Re: [clue] Last Call: (Mapping RTP streams to CLUE Media Captures) to Proposed Standard X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 16 Jan 2017 20:11:27 -0000 On 1/16/17 8:56 AM, Magnus Westerlund wrote: > Den 2017-01-15 kl. 07:05, skrev Roni Even: >> Hi Magnus, >> CaptureID here is just conveying the value defined in the CLUE data model >> and CLUE protocol defines the security consideration for conveying the >> adertized and configured values. >> So any security on creating is done in the protocol document > > Yes, it is containing a value. And the data model and protocol documents > defines the protocol level security requirements and solution. However, > as the CaptureID is taken out of the context of the CLUE protocol, and > put into RTP/RTCP there needs to be consideration for the implications > of that action. Good point. When used within the CLUE protocol the captureID is protected by DTLS. RTP/RTCP presents new concerns. Thanks, Paul > As I don't find any recommendation for how an implementation generates > CaptureIDs I could not determine the security sensitivity of the field. > That is why I am asking about that aspect. Please provide an analysis of > what it may contain, i.e. worst case, and the appropriate recommendation > for appropriately securing that field. > >> >> As for the header extension, I will add some text > > And I think this is relevant also for SDES items in general, not only > for the header extension. The security risks and fundamental > requirements are shared anyway. > > Cheers > > Magnus > >> Roni >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Magnus Westerlund >>> Sent: Friday, January 13, 2017 2:22 PM >>> To: ietf@ietf.org >>> Cc: draft-ietf-clue-rtp-mapping@ietf.org; clue-chairs@ietf.org; >> clue@ietf.org >>> Subject: Re: [clue] Last Call: >> (Mapping RTP >>> streams to CLUE Media Captures) to Proposed Standard >>> >>> Hi, >>> >>> As one of IANA's expert reviewers for the two registries that this >> document >>> attempts to register in, I want to provide some feedback on individual >> basis and >>> directly. >>> >>> The SDES item registration of the CaptureID is fine with the exception >> that it isn't >>> clear on the security consideration for the CaptureID field as SDES >>> item. >> I fail to >>> find any limitations or even recommendations for how the value is >>> created >> by >>> the implementation. Nor does the security considerations discuss the >> potential >>> risk that the capture ID is privacy sensitive, like "Adrian's Mic" >>> rather >> than AC0 >>> as in the example in the data model document. The data model document is >>> fairly clear on the need for confidentiality and authorization for the >> whole data >>> model document. However, this thinking has not been raised and clarified >> in this >>> specific move of the information into the RTP protocol. >>> >>> So, I would recommend a discussion in general if the field should have >>> anonymous labels, that do not contain privacy information. Then one >>> needs >> to >>> be clear on what requirements that puts on transporting this field in >>> RTP. >> And >>> that depends on how certain one can be that it is anonymous or that >>> it may >>> contain sensitive information and therefore should be confidentiality >> protected. >>> In all cases this field needs integrity and source authentication. Which >> should be >>> made explicit in the security consideration. The clue mapping require >>> implementation of SRTP with DTLS-SRTP keying, however, it fails to be >> specific >>> on which protection profiles that are to be supported, both for the SRTP >> as well >>> as the crypto functions for the key handshakes in DTLS-SRTP. Thus, I >>> can't >> be >>> certain if the CaptureID will be confidentiality protected or not >>> even in >> RTCP. >>> >>> When it comes to the RTP Header Extension case, the RFC 7941 is very >> explicit >>> about the requirement on doing this security consideration. And I note >> that with >>> the above analysis of what requirements to put, one can ensure that the >> right >>> requirements on the CLUE system to protect any RTP header extension with >> the >>> CaptureID is done. I do note that if confidentiality protection is >>> needed, >> this >>> means additional implementation requirement. Such needs to be defined in >> this >>> or referenced document if that is the case. >>> >>> This should be fairly straight forward to fix, but needs to be done. >>> >>> Cheers >>> >>> Magnus >>> >>> Den 2016-12-22 kl. 22:18, skrev The IESG: >>>> >>>> The IESG has received a request from the ControLling mUltiple streams >>>> for tElepresence WG (clue) to consider the following document: >>>> - 'Mapping RTP streams to CLUE Media Captures' >>>> as Proposed Standard >>>> >>>> The IESG plans to make a decision in the next few weeks, and solicits >>>> final comments on this action. Please send substantive comments to the >>>> ietf@ietf.org mailing lists by 2017-01-12. Exceptionally, comments may >>>> be sent to iesg@ietf.org instead. In either case, please retain the >>>> beginning of the Subject line to allow automated sorting. >>>> >>>> Abstract >>>> >>>> >>>> This document describes how the Real Time transport Protocol >>>> (RTP) is >>>> used in the context of the CLUE protocol. It also describes the >>>> mechanisms and recommended practice for mapping RTP media streams >>>> defined in SDP to CLUE Media Captures. >>>> >>>> >>>> >>>> >>>> The file can be obtained via >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ >>>> >>>> IESG discussion can be tracked via >>>> https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ballot/ >>>> >>>> >>>> No IPR declarations have been submitted directly on this I-D. >>>> >>>> >>>> >>>> >>>> >>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>> Ericsson AB | Phone +46 10 7148287 >>> Frgatan 6 | Mobile +46 73 0949079 >>> SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> > > From nobody Tue Jan 17 06:22:39 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 AF6801294A2; Tue, 17 Jan 2017 06:22:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148466294170.31991.12817544859466420542.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 06:22:21 -0800 Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: [clue] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-clue-rtp-mapping-12=3A_=28with_COMMENT=29?= X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 14:22:22 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-clue-rtp-mapping-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - I find the following sentence in the abstract rather confusing: „This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol.“ I would just start with the second sentence directly and potentially also mention that this doc defines a new RTP Header Extension for the mapping. - There is still some redundancy in this document that could be removed for more clarity. From nobody Tue Jan 17 16:05:01 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 7CCCF12940F; Tue, 17 Jan 2017 16:04:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148469789646.32039.13785089955571943651.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2017 16:04:56 -0800 Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: [clue] Stephen Farrell's No Objection on draft-ietf-clue-rtp-mapping-12: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 00:04:56 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-clue-rtp-mapping-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - abstract: expanding CLUE (or avoiding the acronym) in the abstract would be better (some abstract readers won't have heard of CLUE before). - section 9: I think the paragraph about RFC6562 should be reduced to the first sentence only. The rest, if it were correct (and I'm not sure), ought be part of an update to 6562. That's not just process-crap - I would expect the state of the art to change here and when it does then the right place to deal with that will be in an update to 6562. (And hey, it's been 5 years already since we did that, so maybe it'd be timely if someone re-checked the state of the art here?) This could have been, but is not a DISCUSS ballot, on the basis that if we do update 6562 then we could have that formally UPDATE this RFC, but requiring that we remember to do that seems worse than just leaving it to a putative 6562bis. (And again, could we find someone to re-check 6562 and perhaps consider if a BCP on the topic would be a worthwhile thing?) - Section 9 says: "In multi-party communication scenarios using RTP Middleboxes; this middleboxes are trusted to preserve the sessions' security." That is just wrong. The middleboxes may or may not be trusted (or even known to exist) by the parties to the call. What you should be saying is that those middleboxes are REQUIRED, by this protocol/spec, to not weaken security. (And this one is not a DISCUSS because the rest of the para mitigates the horrible first sentence;-) From nobody Wed Jan 18 00:34:14 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 68A731294A8 for ; Wed, 18 Jan 2017 00:34:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, 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 VsYZt-Yzdx7e for ; Wed, 18 Jan 2017 00:34:10 -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 1EF64120727 for ; Wed, 18 Jan 2017 00:34:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DET09918; Wed, 18 Jan 2017 08:34:05 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 08:34:03 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 16:33:26 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: Comments on CaptureID and security Thread-Index: AdJxYyu3dvmMy6+lR4Sf9Fep5IDFDA== Date: Wed, 18 Jan 2017 08:33:26 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.112.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD76DEFFDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.587F287E.00C0, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: bd2cee618da927d6ce9f243526e0fd1f Archived-At: Cc: Jonathan Lennox Subject: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 08:34:13 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD76DEFFDGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We got the following comments from Magnus when he reviewed the registration= , he also had similar comments during IETF LC "This registration is fine with the exception that it isn't clear on the se= curity consideration for the CaptureID field as SDES item. I fail to find a= ny limitations or even recommendations for how the value is created by the = implementation. Nor does the security considerations discuss the potential = risk that the capture ID is privacy sensetive, like "Adrian's Mic" rather t= han AC0 as in the example in the data model document. The data model docume= nt is fairly clear on the need for confidentiality and authorization for th= e whole data model document. However, this thinking has not been raised and clarified in this specific m= ove of the information into the RTP protocol. So, I would recommend a discussion in general that the field should have an= onymous labels, that do not contain privacy information. Then one should be= clear on what requirements one put on transporting these fields in RTP. An= d that depends on how certain one can be that it is anonymous or that it ma= y contain sensitive information and therefore should be confidentiality pro= tected. In all cases this field needs integrity and source authentication. = The clue mapping require implementation of SRTP with DTLS-SRTP keying, howe= ver, it fails to be specific on which protection profiles that are to be su= pported, both for the SRTP as well as the crypto functions for the key hand= shakes in DTLS-SRTP. I recommended that registration is hold off for the RTP header extension pa= rts (IANA review request #944570), where this gets even worse by the fact t= hat even if RTP and RTCP is confidentiality protected, the RTP header exten= sion is not per default confidentiality protected, and there is a additiona= l protection mechanism that needs to be implemented." The major point are: 1. We need to specify the considerations for creating CaptureID, the = data model talks in general about securing the CLUE message, the CLUE proto= col and framework are silent about this parameter. Any suggestions? Also sh= ould this be specified in the RTP mapping or in the CLUE protocol? 2. What do we want to say about supported security profile? For examp= le does the following directive from https://tools.ietf.org/html/draft-ietf= -rtcweb-security-arch-12#section-5.5 looks good for CLUE? "Implementations MUST implement SRTP [RFC3711]. Implementations MUST implement DTLS [RFC4347] and DTLS-S= RTP [RFC5763][RFC5764] for SRTP keying. Implementations MUST implement [I-D.ietf-tsvwg-sctp-dtls-encaps]. All media channels MUST be secured via SRTP. Media traffic MUST NOT be sent over plain (unencrypted) RTP; that is, implementations MUST NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP MUST be offered for every media channel. All data channels MUST be secured via DTLS. All implementations MUST implement DTLS 1.0, with the cipher suite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve [FIPS186]. The DTLS-SRTP protection profile SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. Implementations SHOULD implement DTLS 1.2 with the TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. Implementations MUST favor cipher suites which support PFS over non- PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. " Thanks Roni --_000_6E58094ECC8D8344914996DAD28F1CCD76DEFFDGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We got the following comments from Magnus when he re= viewed the registration, he also had similar comments during IETF LC

 

“This registration is fine with the excepti= on that it isn't clear on the security consideration for the CaptureID fiel= d as SDES item. I fail to find any limitations or even recommendations for = how the value is created by the implementation. Nor does the security considerations discuss the potential risk that the c= apture ID is privacy sensetive, like "Adrian's Mic" rather than A= C0 as in the example in the data model document. The data model document is= fairly clear on the need for confidentiality and authorization for the whole data model document.

However, this thinking has not been raised and cl= arified in this specific move of the information into the RTP protocol.

 

So, I would recommend a discussion in general tha= t the field should have anonymous labels, that do not contain privacy infor= mation. Then one should be clear on what requirements one put on transporti= ng these fields in RTP. And that depends on how certain one can be that it is anonymous or that it may contain sens= itive information and therefore should be confidentiality protected. In all= cases this field needs integrity and source authentication. The clue mappi= ng require implementation of SRTP with DTLS-SRTP keying, however, it fails to be specific on which protectio= n profiles that are to be supported, both for the SRTP as well as the crypt= o functions for the key handshakes in DTLS-SRTP.

 

I recommended that registration is hold off for t= he RTP header extension parts (IANA review request #944570), where this get= s even worse by the fact that even if RTP and RTCP is confidentiality prote= cted, the RTP header extension is not per default confidentiality protected, and there is a additional prote= ction mechanism that needs to be implemented.”

 

 

The major point are:

 

1.       We need to specify the con= siderations for creating CaptureID, the data model talks in general about s= ecuring the CLUE message, the CLUE protocol and framework are silent about = this parameter. Any suggestions? Also should this be specified in the RTP mapping or in the CLUE protocol? =

2.       What do we want to say abo= ut supported security profile? For example does the following directive fro= m https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5<= /a> looks good for CLUE?

 

“Implementation= s MUST implement SRTP [RFC3711].  Implementations MUST

   implement DTLS [RFC4347] and DTLS-SRTP [RFC5763][RFC5764] for SRTP

   keying.  Implementations=
 MUST implement


   [I-D.ietf-tsvwg-sctp-dtls-encaps].


 


   All media channels MUST be se=
cured via SRTP.  Media traffic MUST NOT


   be sent over plain (unencrypt=
ed) RTP; that is, implementations MUST


   NOT negotiate cipher suites w=
ith NULL encryption modes.  DTLS-SRTP


   MUST be offered for every med=
ia channel.  


 


   All data channels MUST be sec=
ured via DTLS.


 


   All implementations MUST impl=
ement DTLS 1.0, with the cipher suite


   TLS_ECDHE_ECDSA_WITH_AES_128_=
CBC_SHA with the the P-256 curve


   [FIPS186].  The DTLS-SRTP pr=
otection profile


   SRTP_AES128_CM_HMAC_SHA1_80 M=
UST be supported for SRTP.


   Implementations SHOULD implem=
ent DTLS 1.2 with the


   TLS_ECDHE_ECDSA_WITH_AES_128_=
GCM_SHA256 cipher suite.


   Implementations MUST favor ci=
pher suites which support PFS over non-


   PFS cipher suites and SHOULD =
favor AEAD over non-AEAD cipher suites.


“


 


Thanks


Roni
--_000_6E58094ECC8D8344914996DAD28F1CCD76DEFFDGGEMM506MBXchina_-- From nobody Wed Jan 18 00:45: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 57B11129411 for ; Wed, 18 Jan 2017 00:45:13 -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 hgXhCFSHxtjm for ; Wed, 18 Jan 2017 00:45:11 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B28F128B44 for ; Wed, 18 Jan 2017 00:45:11 -0800 (PST) X-AuditID: c1b4fb2d-db0c19800000646e-ce-587f2b15c189 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id F6.9E.25710.51B2F785; Wed, 18 Jan 2017 09:45:09 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.319.2; Wed, 18 Jan 2017 09:44:57 +0100 To: Roni Even , "clue@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> Date: Wed, 18 Jan 2017 09:44:56 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM2K7uq6odn2EwfTNuhb7T11mtti/+Dyz xadj51kcmD1ajrxl9Viy5CeTR9uzO+wBzFFcNimpOZllqUX6dglcGZ+f3mUpaJOs2PzsNWMD 4yKRLkZODgkBE4knu/eydTFycQgJrGOUeNbYwgzhLGeU+H9xKwtIlbCAvsTqZXPYQWwRAVeJ Iwv2gdlCAsES76/3sHYxcnAwC2hINE2IAAmzCVhI3PzRyAZi8wrYSzSsec0KYrMIqEoc/D2D EcQWFYiReLt+OTtEjaDEyZlPwFZxCoRI9C45yQIx0l7iwdYykDCzgLxE89bZzBBbtSUamjpY JzAKzELSPQuhYxaSjgWMzKsYRYtTi4tz042M9VKLMpOLi/Pz9PJSSzYxAsP04JbfujsYV792 PMQowMGoxMNbYFgXIcSaWFZcmXuIUYKDWUmEV02tPkKINyWxsiq1KD++qDQntfgQozQHi5I4 r9nK++FCAumJJanZqakFqUUwWSYOTqkGxub3K17oSs47LR3c7TU3/oqyxAV2YbMiKQfhH4fm NZUWvmjK03ix56+zzvKNErzdUtf4Dsk8FzfeoC7o271tt+HfBvGjp5140ny8X6y6ey9B0nN5 /j2u6fvX/plT0rxV+hL3BRVb66eXS92n1nmH7r0wcduqO7u+qh8O8ets9jubOK9hS6/PWSWW 4oxEQy3mouJEAOtjBeJPAgAA Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 08:45:13 -0000 Hi, A comment about the below. I have an issue raised against the below quoted text from the rtcweb-security-architecture in the RTCWeb WG, as it fails to specify if RTCP encryption is mandatory to use or not. There are protection profiles that only have confidentiality protection for RTP, and not for RTCP. I would recommend requiring confidentiality protection also of RTCP. The second note on the below is that depending on the outcome of the security requirements for the CaptureID RTP header extension, you might in addition have to require RFC 6904, implementation and usage for the CaptureId header extension field. Or rather if you write nothing it will by default be required if you encrypt RTCP, due to RFC 7941. But, I really recommend that you are explicit on this matter. It comes down to what security risks the field entails. What information will it leak to a third party viewer of the RTP/RTCP stream they can capture. Cheers Magnus Den 2017-01-18 kl. 09:33, skrev Roni Even: > 2. What do we want to say about supported security profile? For > example does the following directive from > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5 > looks good for CLUE? > > > > Implementations MUST implement SRTP [RFC3711 > ]. Implementations MUST > > implement DTLS [RFC4347 ] and > DTLS-SRTP [RFC5763 ][RFC5764] for SRTP > > keying. Implementations MUST implement > > [I-D.ietf-tsvwg-sctp-dtls-encaps > ]. > > > > All media channels MUST be secured via SRTP. Media traffic MUST NOT > > be sent over plain (unencrypted) RTP; that is, implementations MUST > > NOT negotiate cipher suites with NULL encryption modes. DTLS-SRTP > > MUST be offered for every media channel. > > > > All data channels MUST be secured via DTLS. > > > > All implementations MUST implement DTLS 1.0, with the cipher suite > > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve > > [FIPS186 > ]. > The DTLS-SRTP protection profile > > SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. > > Implementations SHOULD implement DTLS 1.2 with the > > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. > > Implementations MUST favor cipher suites which support PFS over non- > > PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher suites. > > -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Frgatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jan 18 01:44:51 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 7D3E912969B for ; Wed, 18 Jan 2017 01:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 vr9gveBRs5TN for ; Wed, 18 Jan 2017 01:44:48 -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 74A17126BF7 for ; Wed, 18 Jan 2017 01:44:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DET23919; Wed, 18 Jan 2017 09:44:23 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 09:44:22 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 17:44:19 +0800 From: Roni Even To: Magnus Westerlund , "clue@ietf.org" Thread-Topic: Comments on CaptureID and security Thread-Index: AdJxYyu3dvmMy6+lR4Sf9Fep5IDFDP//gdUA//9w7oA= Date: Wed, 18 Jan 2017 09:44:18 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> In-Reply-To: <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.112.60] 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.0A020204.587F390C.034D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 37c3681b66ab832cd4f59909e82edb2b Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 09:44:50 -0000 SGksDQpUaGUgdGV4dCBJIGFkZGVkIHRvIHRoZSAtMTEgdmVyc2lvbiANCiJUaGUgQ2FwdHVyZUlE IGlzIGNyZWF0ZWQgYXMgcGFydCBvZiB0aGUgQ0xVRSBwcm90b2NvbC4gIFRoZSBDYXB0SWQNCiAg IFNERVMgaXRlbSBpcyB1c2VkIHRvIGNvbnZleSB0aGUgc2FtZSBDYXB0dXJlSUQgdmFsdWUgaW4g dGhlIFNERVMNCiAgIGl0ZW0uICBXaGVuIHNlbmRpbmcgdGhlIFNERVMgaXRlbSB0aGUgc2VjdXJp dHkgY29uc2lkZXJ0aW9uIHNwZWNpZWQNCiAgIGluIHRoZSBzZWN1cml0eSBzZWN0aW9uIG9mIFtS RkM3OTQxXSBhcmUgYXBwbGljYWJsZSBhbmQgdGhpcyBTREVTDQogICBpdGVtIE1VU1QgdXNlIHNp bWlsYXIgc2VjdXJpdHkgYXMgdGhlIENMVUUgcHJvdG9jb2wgbWVzc2FnZXMgY2FycmllZA0KICAg aW4gdGhlIENMVUUgZGF0YSBjaGFubmVsLiINCg0KU2F5IHRoYXQgICIgdGhpcyBTREVTIGl0ZW0g TVVTVCB1c2Ugc2ltaWxhciBzZWN1cml0eSBhcyB0aGUgQ0xVRSBwcm90b2NvbCBtZXNzYWdlcyBj YXJyaWVkIGluIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4iDQpUaGUgQ0xVRSBkYXRhIGNoYW5uZWwg ZG9jdW1lbnQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1ZS1kYXRh Y2hhbm5lbC0xNCNzZWN0aW9uLTQgcG9pbnQgYXQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcnRjd2ViLWRhdGEtY2hhbm5lbC0xMyNzZWN0aW9uLTcgcG9pbnRpbmcgdG8g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFy Y2gtMTAgDQoNClNvIHdlIGNhbiByZWZlcmVuY2UgdGhlIHJ0Y3dlYiBzZWN1cml0eSBhcmNoaXRl Y3R1cmUgb3IgdXNlIHRoZSB0ZXh0IEkgY29waWVkIGZyb20gdGhlcmUgdG8gZGVmaW5lIGEgc2Vj dXJpdHkgcHJvZmlsZQ0KDQpBcyBmb3IgdGhlIHNlY29uZCBpdGVtIEkgYWdyZWUgdGhhdCBpZiB3 ZSBlbmNyeXB0IHRoZSBjb250ZW50IGluIHRoZSBDTFVFIGRhdGEgY2hhbm5lbCB0aGF0IGluY2x1 ZGVzIHRoZSBjYXB0dXJlSUQsIHdlIG5lZWQgYWxzbyB0byBlbmNyeXB0IFJUQ1Agd2l0aCB0aGUg Y2FwdHVyZUlEIFNERVMgaXRlbSBhbmQgaXQgZG9lcyBub3QgbWF0dGVyIGhvdyB3ZSBjcmVhdGUg dGhlIGNhcHR1cmVJRCB2YWx1ZSwgc28gbWF5YmUgaWYgd2UgbWFuZGF0ZSBlbmNyeXB0aW5nIHRo ZSBTREVTIGl0ZW0gdGhlcmUgaXMgbm8gc3Ryb25nIG5lZWQgZm9yIHNwZWNpZnlpbmcgaG93IHRv IGNyZWF0ZSBDYXB0dXJlSUQgLiBOb3RlIHRoYXQgdGhlIENhcHR1cmVJRCBpcyBub3QgdXNlIHRv IHByb3ZpZGUgaHVtYW4tcmVhZGFibGUgdGV4dHVhbCBpbmZvcm1hdGlvbiB3aGljaCBpcyBpbiB0 aGUgZGVzY3JpcHRpb24gYXR0cmlidXRlLg0KDQpSb25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2VzdGVy bHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6INeZ15XXncKg15MgMTgg15nXoNeV15DXqCAyMDE3 IDEwOjQ1DQo+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4gQ2M6IEpvbmF0aGFuIExl bm5veA0KPiBTdWJqZWN0OiBSZTogQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0eQ0K PiANCj4gSGksDQo+IA0KPiBBIGNvbW1lbnQgYWJvdXQgdGhlIGJlbG93LiBJIGhhdmUgYW4gaXNz dWUgcmFpc2VkIGFnYWluc3QgdGhlIGJlbG93IHF1b3RlZA0KPiB0ZXh0IGZyb20gdGhlIHJ0Y3dl Yi1zZWN1cml0eS1hcmNoaXRlY3R1cmUgaW4gdGhlIFJUQ1dlYiBXRywgYXMgaXQgZmFpbHMgdG8N Cj4gc3BlY2lmeSBpZiBSVENQIGVuY3J5cHRpb24gaXMgbWFuZGF0b3J5IHRvIHVzZSBvciBub3Qu IFRoZXJlIGFyZSBwcm90ZWN0aW9uDQo+IHByb2ZpbGVzIHRoYXQgb25seSBoYXZlIGNvbmZpZGVu dGlhbGl0eSBwcm90ZWN0aW9uIGZvciBSVFAsIGFuZCBub3QgZm9yIFJUQ1AuIEkNCj4gd291bGQg cmVjb21tZW5kIHJlcXVpcmluZyBjb25maWRlbnRpYWxpdHkgcHJvdGVjdGlvbiBhbHNvIG9mIFJU Q1AuDQo+IA0KPiBUaGUgc2Vjb25kIG5vdGUgb24gdGhlIGJlbG93IGlzIHRoYXQgZGVwZW5kaW5n IG9uIHRoZSBvdXRjb21lIG9mIHRoZQ0KPiBzZWN1cml0eSByZXF1aXJlbWVudHMgZm9yIHRoZSBD YXB0dXJlSUQgUlRQIGhlYWRlciBleHRlbnNpb24sIHlvdSBtaWdodCBpbg0KPiBhZGRpdGlvbiBo YXZlIHRvIHJlcXVpcmUgUkZDIDY5MDQsIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZSBmb3IgdGhl DQo+IENhcHR1cmVJZCBoZWFkZXIgZXh0ZW5zaW9uIGZpZWxkLiBPciByYXRoZXIgaWYgeW91IHdy aXRlIG5vdGhpbmcgaXQgd2lsbCBieQ0KPiBkZWZhdWx0IGJlIHJlcXVpcmVkIGlmIHlvdSBlbmNy eXB0IFJUQ1AsIGR1ZSB0byBSRkMgNzk0MS4gQnV0LCBJIHJlYWxseQ0KPiByZWNvbW1lbmQgdGhh dCB5b3UgYXJlIGV4cGxpY2l0IG9uIHRoaXMgbWF0dGVyLiBJdCBjb21lcyBkb3duIHRvIHdoYXQN Cj4gc2VjdXJpdHkgcmlza3MgdGhlIGZpZWxkIGVudGFpbHMuIFdoYXQgaW5mb3JtYXRpb24gd2ls bCBpdCBsZWFrIHRvIGEgdGhpcmQgcGFydHkNCj4gdmlld2VyIG9mIHRoZSBSVFAvUlRDUCBzdHJl YW0gdGhleSBjYW4gY2FwdHVyZS4NCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVzDQo+IA0KPiBE ZW4gMjAxNy0wMS0xOCBrbC4gMDk6MzMsIHNrcmV2IFJvbmkgRXZlbjoNCj4gPiAyLiAgICAgICBX aGF0IGRvIHdlIHdhbnQgdG8gc2F5IGFib3V0IHN1cHBvcnRlZCBzZWN1cml0eSBwcm9maWxlPyBG b3INCj4gPiBleGFtcGxlIGRvZXMgdGhlIGZvbGxvd2luZyBkaXJlY3RpdmUgZnJvbQ0KPiA+IGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNo LTEyI3NlY3Rpb24tNS41DQo+ID4gbG9va3MgZ29vZCBmb3IgQ0xVRT8NCj4gPg0KPiA+DQo+ID4N Cj4gPiDigJxJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1lbnQgU1JUUCBbUkZDMzcxMQ0KPiA+ IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzcxMT5dLiAgSW1wbGVtZW50YXRpb25z IE1VU1QNCj4gPg0KPiA+ICAgIGltcGxlbWVudCBEVExTIFtSRkM0MzQ3IDxodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNDM0Nz5dIGFuZA0KPiA+IERUTFMtU1JUUCBbUkZDNTc2MyA8aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU3NjM+XVtSRkM1NzY0XSBmb3INCj4gU1JUUA0K PiA+DQo+ID4gICAga2V5aW5nLiAgSW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50DQo+ID4N Cj4gPiAgICBbSS1ELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcw0KPiA+IDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xMiNyZWYt SS0NCj4gRC5pZXRmLXRzdndnLXNjdHAtZHRscy1lbmNhcHM+XS4NCj4gPg0KPiA+DQo+ID4NCj4g PiAgICBBbGwgbWVkaWEgY2hhbm5lbHMgTVVTVCBiZSBzZWN1cmVkIHZpYSBTUlRQLiAgTWVkaWEg dHJhZmZpYyBNVVNUIE5PVA0KPiA+DQo+ID4gICAgYmUgc2VudCBvdmVyIHBsYWluICh1bmVuY3J5 cHRlZCkgUlRQOyB0aGF0IGlzLCBpbXBsZW1lbnRhdGlvbnMgTVVTVA0KPiA+DQo+ID4gICAgTk9U IG5lZ290aWF0ZSBjaXBoZXIgc3VpdGVzIHdpdGggTlVMTCBlbmNyeXB0aW9uIG1vZGVzLiAgRFRM Uy1TUlRQDQo+ID4NCj4gPiAgICBNVVNUIGJlIG9mZmVyZWQgZm9yIGV2ZXJ5IG1lZGlhIGNoYW5u ZWwuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgQWxsIGRhdGEgY2hhbm5lbHMgTVVTVCBiZSBzZWN1 cmVkIHZpYSBEVExTLg0KPiA+DQo+ID4NCj4gPg0KPiA+ICAgIEFsbCBpbXBsZW1lbnRhdGlvbnMg TVVTVCBpbXBsZW1lbnQgRFRMUyAxLjAsIHdpdGggdGhlIGNpcGhlciBzdWl0ZQ0KPiA+DQo+ID4g ICAgVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIHdpdGggdGhlIHRoZSBQLTI1 NiBjdXJ2ZQ0KPiA+DQo+ID4gICAgW0ZJUFMxODYNCj4gPiA8aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTIjcmVmLQ0KPiBGSVBTMTg2 Pl0uDQo+ID4gVGhlIERUTFMtU1JUUCBwcm90ZWN0aW9uIHByb2ZpbGUNCj4gPg0KPiA+ICAgIFNS VFBfQUVTMTI4X0NNX0hNQUNfU0hBMV84MCBNVVNUIGJlIHN1cHBvcnRlZCBmb3IgU1JUUC4NCj4g Pg0KPiA+ICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBpbXBsZW1lbnQgRFRMUyAxLjIgd2l0aCB0 aGUNCj4gPg0KPiA+ICAgIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiBj aXBoZXIgc3VpdGUuDQo+ID4NCj4gPiAgICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBmYXZvciBjaXBo ZXIgc3VpdGVzIHdoaWNoIHN1cHBvcnQgUEZTIG92ZXIgbm9uLQ0KPiA+DQo+ID4gICAgUEZTIGNp cGhlciBzdWl0ZXMgYW5kIFNIT1VMRCBmYXZvciBBRUFEIG92ZXIgbm9uLUFFQUQgY2lwaGVyIHN1 aXRlcy4NCj4gPg0KPiA+IOKAnA0KPiANCj4gDQo+IC0tDQo+IA0KPiBNYWdudXMgV2VzdGVybHVu ZA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVh dHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBFcmlj c3NvbiBBQiAgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gRsOkcsO2 Z2F0YW4gNiAgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4gU0UtMTY0 IDgwIFN0b2NraG9sbSwgU3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQo= From nobody Wed Jan 18 03:54:07 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 538B91295D5 for ; Wed, 18 Jan 2017 03:54:06 -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 mYy9W3_D8cL2 for ; Wed, 18 Jan 2017 03:54:04 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A597129599 for ; Wed, 18 Jan 2017 03:54:04 -0800 (PST) X-AuditID: c1b4fb3a-5878998000002f76-eb-587f575af19a Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id D6.55.12150.A575F785; Wed, 18 Jan 2017 12:54:02 +0100 (CET) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.319.2; Wed, 18 Jan 2017 12:53:05 +0100 To: Roni Even , "clue@ietf.org" References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> From: Magnus Westerlund Message-ID: <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> Date: Wed, 18 Jan 2017 12:53:05 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7lm5UeH2EwffnZhb7T11mtti/+Dyz xadj51kcmD1ajrxl9Viy5CeTR9uzO+wBzFFcNimpOZllqUX6dglcGYf+b2cumGReseTbO9YG xlbdLkZODgkBE4nPCxtYQWwhgXWMElv6M7sYuYDs5YwS3y/dB0sIC+hLrF42hx3EFhFwlTiy YB87RNFlRolX/9axdTFycDALaEg0TYgAqWETsJC4+aORDcTmFbCXOHFoGROIzSKgKvF//y5G EFtUIEbi7frl7BA1ghInZz5hAbE5BUIkltz8CtbLDDRn5vzzjBC2vETz1tnMEIdqSzQ0dbBO YBSYhaR9FpKWWUhaFjAyr2IULU4tLs5NNzLSSy3KTC4uzs/Ty0st2cQIDNWDW35b7WA8+Nzx EKMAB6MSD2+BYV2EEGtiWXFl7iFGCQ5mJRHezcH1EUK8KYmVValF+fFFpTmpxYcYpTlYlMR5 zVbeDxcSSE8sSc1OTS1ILYLJMnFwSjUwukY3ntFtufOo5dOfvc0hVgsn7fs4g92s/Wx9/NFi FoGpMyW4DqlpiZzrfybw4HVwb9tHH/42Bm+/ePHb7Ve+xRsXrpcMPvUv/s8MztLnH66nZd1c 5RwvtlRTbFPavLmRFtPvLLlZMu3Dbk/O3HQVT2feKJeb7dJuX45VyNp8bZ0o0v75PMtnJZbi jERDLeai4kQAuUUgdlECAAA= Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 11:54:06 -0000 Hi, Yes, I think encrypting the CaptureID avoids the negative impacts that bad construction can have that I can think of. Thus, I support going in that direction. When it comes to the security solution I would recommend copying the text and then make the edits. There is at least two additions, the MUST encrypt RTCP, and the MUST implement RFC 6904 and use it to encrypt the CaptureID header extension. Please be explicit and clear in the CLUE level document on what security solutions that needs to be implemented and use. Reasons for copying the text, is that there are differences between RTCWeb and CLUE, and in addition I think the implementation considerations and potential needs to later revise the specification are different. I am not certain CLUE will want to be required to follow any changes that RTCWeb does in the future. I would also note that I think you need at least to put in a short paragraph about the CaptureID value. Something like this. The construction of the CaptureID value is implementation dependent and is not tightly restricted. Therefore there exist a risk that the CaptureID contains privacy sensitive information or otherwise revealing information about the communication session to third parties. Therefore confidentiality protection is always applied to avoid this risk. Cheers Magnus Den 2017-01-18 kl. 10:44, skrev Roni Even: > Hi, The text I added to the -11 version "The CaptureID is created as > part of the CLUE protocol. The CaptId SDES item is used to convey > the same CaptureID value in the SDES item. When sending the SDES > item the security considertion specied in the security section of > [RFC7941] are applicable and this SDES item MUST use similar security > as the CLUE protocol messages carried in the CLUE data channel." > > Say that " this SDES item MUST use similar security as the CLUE > protocol messages carried in the CLUE data channel." The CLUE data > channel document > https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4 > point at > https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-7 > pointing to > https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 > > So we can reference the rtcweb security architecture or use the text > I copied from there to define a security profile > > As for the second item I agree that if we encrypt the content in the > CLUE data channel that includes the captureID, we need also to > encrypt RTCP with the captureID SDES item and it does not matter how > we create the captureID value, so maybe if we mandate encrypting the > SDES item there is no strong need for specifying how to create > CaptureID . Note that the CaptureID is not use to provide > human-readable textual information which is in the description > attribute. > > Roni > >> -----Original Message----- From: Magnus Westerlund >> [mailto:magnus.westerlund@ericsson.com] Sent: יום ד 18 ינואר 2017 >> 10:45 To: Roni Even; clue@ietf.org Cc: Jonathan Lennox Subject: Re: >> Comments on CaptureID and security >> >> Hi, >> >> A comment about the below. I have an issue raised against the below >> quoted text from the rtcweb-security-architecture in the RTCWeb WG, >> as it fails to specify if RTCP encryption is mandatory to use or >> not. There are protection profiles that only have confidentiality >> protection for RTP, and not for RTCP. I would recommend requiring >> confidentiality protection also of RTCP. >> >> The second note on the below is that depending on the outcome of >> the security requirements for the CaptureID RTP header extension, >> you might in addition have to require RFC 6904, implementation and >> usage for the CaptureId header extension field. Or rather if you >> write nothing it will by default be required if you encrypt RTCP, >> due to RFC 7941. But, I really recommend that you are explicit on >> this matter. It comes down to what security risks the field >> entails. What information will it leak to a third party viewer of >> the RTP/RTCP stream they can capture. >> >> Cheers >> >> Magnus >> >> Den 2017-01-18 kl. 09:33, skrev Roni Even: >>> 2. What do we want to say about supported security profile? >>> For example does the following directive from >>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5 >>> >>> looks good for CLUE? >>> >>> >>> >>> “Implementations MUST implement SRTP [RFC3711 >>> ]. Implementations MUST >>> >>> implement DTLS [RFC4347 ] >>> and DTLS-SRTP [RFC5763 >>> ][RFC5764] for >> SRTP >>> >>> keying. Implementations MUST implement >>> >>> [I-D.ietf-tsvwg-sctp-dtls-encaps >>> > >>> D.ietf-tsvwg-sctp-dtls-encaps>]. >>> >>> >>> >>> All media channels MUST be secured via SRTP. Media traffic MUST >>> NOT >>> >>> be sent over plain (unencrypted) RTP; that is, implementations >>> MUST >>> >>> NOT negotiate cipher suites with NULL encryption modes. >>> DTLS-SRTP >>> >>> MUST be offered for every media channel. >>> >>> >>> >>> All data channels MUST be secured via DTLS. >>> >>> >>> >>> All implementations MUST implement DTLS 1.0, with the cipher >>> suite >>> >>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve >>> >>> [FIPS186 >>> > >>> FIPS186>]. >>> The DTLS-SRTP protection profile >>> >>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. >>> >>> Implementations SHOULD implement DTLS 1.2 with the >>> >>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. >>> >>> Implementations MUST favor cipher suites which support PFS over >>> non- >>> >>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher >>> suites. >>> >>> “ >> >> >> -- >> >> Magnus Westerlund >> >> ---------------------------------------------------------------------- >> >> Services, Media and Network features, Ericsson Research EAB/TXM >> ---------------------------------------------------------------------- >> >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- > >> -- Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Wed Jan 18 04:21:19 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 3833E1295DE for ; Wed, 18 Jan 2017 04:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 lTHcpSd1gLzQ for ; Wed, 18 Jan 2017 04:21:16 -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 30E0A1295DD for ; Wed, 18 Jan 2017 04:21:15 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DET50542; Wed, 18 Jan 2017 12:21:10 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 18 Jan 2017 12:20:44 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Wed, 18 Jan 2017 20:20:39 +0800 From: Roni Even To: Magnus Westerlund , "clue@ietf.org" Thread-Topic: Comments on CaptureID and security Thread-Index: AQHScYH0r5NcLRRjNUS7Z54RehkMCKE+IVMQ Date: Wed, 18 Jan 2017 12:20:39 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76DFC4@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> In-Reply-To: <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.112.60] 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.0A020205.587F5DB7.0246, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 37c3681b66ab832cd4f59909e82edb2b Archived-At: Cc: Jonathan Lennox Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 12:21:18 -0000 SGkgTWFnbnVzLA0KSSB3YW50IHRvIHNlZSBpZiBvdGhlcnMgaW52b2x2ZWQgaW4gIENMVUUgIHdv cmsgYXJlIE9LIHdpdGggUlRDUCBhbmQgUlRQIGhlYWRlciBlbmNyeXB0aW9uIG9mIHRoZSBDYXB0 dXJlSUQgb3IgZGVmaW5lIGhvdyB0byBjcmVhdGUgQ2FwdHVyZUlEIHdlIGNhbiBzYXkgZm9yIGV4 YW1wbGU6DQoNCiIgVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgQ2FwdHVyZUlEIHZhbHVlIGlzIGlt cGxlbWVudGF0aW9uIGRlcGVuZGVudC4gVGhlcmVmb3JlIHRoZXJlIGV4aXN0IGEgcmlzayB0aGF0 IHRoZSBDYXB0dXJlSUQgY29udGFpbnMgcHJpdmFjeSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gb3Ig b3RoZXJ3aXNlIHJldmVhbGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tbXVuaWNhdGlvbiBz ZXNzaW9uIHRvIHRoaXJkIHBhcnRpZXMuIFNpbmNlIHRoZSBDYXB0dXJlSUQgZG9lcyBub3QgbmVl ZCB0byBiZSBodW1hbiByZWFkYWJsZSBhbiBhcmJpdHJhcnkgdmFsdWUgdGhhdCBpcyBub3QgcmVs YXRlZCB0byB0aGUgQ0xVRSBzZXNzaW9uIE1VU1QgYmUgdXNlZCwgZS5nLiB1c2UgQUMwIGFuZCBu b3QgQm9iJ3MgbWljcm9waG9uZS4gQ29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gc2hvdWxkIGJl IGFwcGxpZWQgdG8gYXZvaWQgdGhpcyByaXNrLiAiDQoNCk9yDQoNCiIgVGhlIGNvbnN0cnVjdGlv biBvZiB0aGUgQ2FwdHVyZUlEIHZhbHVlIGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudC4gVGhl cmVmb3JlIHRoZXJlIGV4aXN0IGEgcmlzayB0aGF0IHRoZSBDYXB0dXJlSUQgY29udGFpbnMgcHJp dmFjeSBzZW5zaXRpdmUgaW5mb3JtYXRpb24gb3Igb3RoZXJ3aXNlIHJldmVhbGluZyBpbmZvcm1h dGlvbiBhYm91dCB0aGUgY29tbXVuaWNhdGlvbiBzZXNzaW9uIHRvIHRoaXJkIHBhcnRpZXMuIFNp bmNlIHRoZSBDYXB0dXJlSUQgZG9lcyBub3QgbmVlZCB0byBiZSBodW1hbiByZWFkYWJsZSBhbiBh cmJpdHJhcnkgdmFsdWUgdGhhdCBpcyBub3QgcmVsYXRlZCB0byB0aGUgQ0xVRSBzZXNzaW9uIE1V U1QgYmUgdXNlZCwgZS5nLiB1c2UgQUMwIGFuZCBub3QgQm9iJ3MgbWljcm9waG9uZS4gVGhlcmVm b3JlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIGlzIGFsd2F5cyBhcHBsaWVkIHRvIGF2b2lk IHRoaXMgcmlzay4gIg0KDQpMb29raW5nIGZvciBmZWVkYmFjayBmcm9tIHRoZSBXRyBhYm91dCB0 aGUgU1JUUCBwcm9maWxlcyB0byBpbXBsZW1lbnRlZC9zdXBwb3J0DQoNCkkgc3VnZ2VzdGVkIHRo ZSBmb2xsb3dpbmcgdGV4dCBiYXNlZCBvbiBSVENXRUIgc2VjdXJpdHkgYXJjaGl0ZWN0dXJlOg0K DQoiQWxsIGltcGxlbWVudGF0aW9ucyBNVVNUIGltcGxlbWVudCBEVExTIDEuMCwgd2l0aCB0aGUg Y2lwaGVyIHN1aXRlIFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfQ0JDX1NIQSB3aXRoIHRo ZSB0aGUgUC0yNTYgY3VydmVbRklQUzE4Nl0uIA0KVGhlIERUTFMtU1JUUCBwcm90ZWN0aW9uIHBy b2ZpbGUgIFNSVFBfQUVTMTI4X0NNX0hNQUNfU0hBMV84MCBNVVNUIGJlIHN1cHBvcnRlZCBmb3Ig U1JUUC4NCkltcGxlbWVudGF0aW9ucyBTSE9VTEQgaW1wbGVtZW50IERUTFMgMS4yIHdpdGggdGhl IFRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FFU18xMjhfR0NNX1NIQTI1NiBjaXBoZXIgc3VpdGUuDQog SW1wbGVtZW50YXRpb25zIE1VU1QgZmF2b3IgY2lwaGVyIHN1aXRlcyB3aGljaCBzdXBwb3J0IFBG UyBvdmVyIG5vbi1QRlMgY2lwaGVyIHN1aXRlcyBhbmQgU0hPVUxEIGZhdm9yIEFFQUQgb3ZlciBu b24tQUVBRCBjaXBoZXIgc3VpdGVzLiINCg0KUm9uaSBFdmVuDQoNCj4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgW21haWx0bzptYWdudXMud2Vz dGVybHVuZEBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6INeZ15XXncKg15MgMTgg15nXoNeV15DXqCAy MDE3IDEzOjUzDQo+IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcNCj4gQ2M6IEpvbmF0aGFu IExlbm5veA0KPiBTdWJqZWN0OiBSZTogQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0 eQ0KPiANCj4gSGksDQo+IA0KPiBZZXMsIEkgdGhpbmsgZW5jcnlwdGluZyB0aGUgQ2FwdHVyZUlE IGF2b2lkcyB0aGUgbmVnYXRpdmUgaW1wYWN0cyB0aGF0IGJhZA0KPiBjb25zdHJ1Y3Rpb24gY2Fu IGhhdmUgdGhhdCBJIGNhbiB0aGluayBvZi4gVGh1cywgSSBzdXBwb3J0IGdvaW5nIGluIHRoYXQN Cj4gZGlyZWN0aW9uLg0KPiANCj4gV2hlbiBpdCBjb21lcyB0byB0aGUgc2VjdXJpdHkgc29sdXRp b24gSSB3b3VsZCByZWNvbW1lbmQgY29weWluZyB0aGUgdGV4dA0KPiBhbmQgdGhlbiBtYWtlIHRo ZSBlZGl0cy4gVGhlcmUgaXMgYXQgbGVhc3QgdHdvIGFkZGl0aW9ucywgdGhlIE1VU1QgZW5jcnlw dA0KPiBSVENQLCBhbmQgdGhlIE1VU1QgaW1wbGVtZW50IFJGQyA2OTA0IGFuZCB1c2UgaXQgdG8g ZW5jcnlwdCB0aGUgQ2FwdHVyZUlEDQo+IGhlYWRlciBleHRlbnNpb24uIFBsZWFzZSBiZSBleHBs aWNpdCBhbmQgY2xlYXIgaW4gdGhlIENMVUUgbGV2ZWwgZG9jdW1lbnQgb24NCj4gd2hhdCBzZWN1 cml0eSBzb2x1dGlvbnMgdGhhdCBuZWVkcyB0byBiZSBpbXBsZW1lbnRlZCBhbmQgdXNlLg0KPiAN Cj4gUmVhc29ucyBmb3IgY29weWluZyB0aGUgdGV4dCwgaXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVy ZW5jZXMgYmV0d2VlbiBSVENXZWINCj4gYW5kIENMVUUsIGFuZCBpbiBhZGRpdGlvbiBJIHRoaW5r IHRoZSBpbXBsZW1lbnRhdGlvbiBjb25zaWRlcmF0aW9ucyBhbmQNCj4gcG90ZW50aWFsIG5lZWRz IHRvIGxhdGVyIHJldmlzZSB0aGUgc3BlY2lmaWNhdGlvbiBhcmUgZGlmZmVyZW50LiBJIGFtIG5v dCBjZXJ0YWluDQo+IENMVUUgd2lsbCB3YW50IHRvIGJlIHJlcXVpcmVkIHRvIGZvbGxvdyBhbnkg Y2hhbmdlcyB0aGF0IFJUQ1dlYiBkb2VzIGluIHRoZQ0KPiBmdXR1cmUuDQo+IA0KPiBJIHdvdWxk IGFsc28gbm90ZSB0aGF0IEkgdGhpbmsgeW91IG5lZWQgYXQgbGVhc3QgdG8gcHV0IGluIGEgc2hv cnQgcGFyYWdyYXBoDQo+IGFib3V0IHRoZSBDYXB0dXJlSUQgdmFsdWUuIFNvbWV0aGluZyBsaWtl IHRoaXMuDQo+IA0KPiBUaGUgY29uc3RydWN0aW9uIG9mIHRoZSBDYXB0dXJlSUQgdmFsdWUgaXMg aW1wbGVtZW50YXRpb24gZGVwZW5kZW50IGFuZCBpcw0KPiBub3QgdGlnaHRseSByZXN0cmljdGVk LiBUaGVyZWZvcmUgdGhlcmUgZXhpc3QgYSByaXNrIHRoYXQgdGhlIENhcHR1cmVJRCBjb250YWlu cw0KPiBwcml2YWN5IHNlbnNpdGl2ZSBpbmZvcm1hdGlvbiBvciBvdGhlcndpc2UgcmV2ZWFsaW5n IGluZm9ybWF0aW9uIGFib3V0IHRoZQ0KPiBjb21tdW5pY2F0aW9uIHNlc3Npb24gdG8gdGhpcmQg cGFydGllcy4gVGhlcmVmb3JlIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uDQo+IGlzIGFsd2F5 cyBhcHBsaWVkIHRvIGF2b2lkIHRoaXMgcmlzay4NCj4gDQo+IENoZWVycw0KPiANCj4gTWFnbnVz DQo+IA0KPiBEZW4gMjAxNy0wMS0xOCBrbC4gMTA6NDQsIHNrcmV2IFJvbmkgRXZlbjoNCj4gPiBI aSwgVGhlIHRleHQgSSBhZGRlZCB0byB0aGUgLTExIHZlcnNpb24gIlRoZSBDYXB0dXJlSUQgaXMg Y3JlYXRlZCBhcw0KPiA+IHBhcnQgb2YgdGhlIENMVUUgcHJvdG9jb2wuICBUaGUgQ2FwdElkIFNE RVMgaXRlbSBpcyB1c2VkIHRvIGNvbnZleSB0aGUNCj4gPiBzYW1lIENhcHR1cmVJRCB2YWx1ZSBp biB0aGUgU0RFUyBpdGVtLiAgV2hlbiBzZW5kaW5nIHRoZSBTREVTIGl0ZW0gdGhlDQo+ID4gc2Vj dXJpdHkgY29uc2lkZXJ0aW9uIHNwZWNpZWQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YgW1JG Qzc5NDFdIGFyZQ0KPiA+IGFwcGxpY2FibGUgYW5kIHRoaXMgU0RFUyBpdGVtIE1VU1QgdXNlIHNp bWlsYXIgc2VjdXJpdHkgYXMgdGhlIENMVUUNCj4gPiBwcm90b2NvbCBtZXNzYWdlcyBjYXJyaWVk IGluIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4iDQo+ID4NCj4gPiBTYXkgdGhhdCAgIiB0aGlzIFNE RVMgaXRlbSBNVVNUIHVzZSBzaW1pbGFyIHNlY3VyaXR5IGFzIHRoZSBDTFVFDQo+ID4gcHJvdG9j b2wgbWVzc2FnZXMgY2FycmllZCBpbiB0aGUgQ0xVRSBkYXRhIGNoYW5uZWwuIiBUaGUgQ0xVRSBk YXRhDQo+ID4gY2hhbm5lbCBkb2N1bWVudA0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWNsdWUtZGF0YWNoYW5uZWwtMTQjc2VjdGlvbi00DQo+ID4gcG9pbnQgYXQN Cj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1j aGFubmVsLTEzI3NlY3Rpb24tDQo+ID4gNw0KPiA+IHBvaW50aW5nIHRvDQo+ID4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTANCj4g Pg0KPiA+IFNvIHdlIGNhbiByZWZlcmVuY2UgdGhlIHJ0Y3dlYiBzZWN1cml0eSBhcmNoaXRlY3R1 cmUgb3IgdXNlIHRoZSB0ZXh0IEkNCj4gPiBjb3BpZWQgZnJvbSB0aGVyZSB0byBkZWZpbmUgYSBz ZWN1cml0eSBwcm9maWxlDQo+ID4NCj4gPiBBcyBmb3IgdGhlIHNlY29uZCBpdGVtIEkgYWdyZWUg dGhhdCBpZiB3ZSBlbmNyeXB0IHRoZSBjb250ZW50IGluIHRoZQ0KPiA+IENMVUUgZGF0YSBjaGFu bmVsIHRoYXQgaW5jbHVkZXMgdGhlIGNhcHR1cmVJRCwgd2UgbmVlZCBhbHNvIHRvIGVuY3J5cHQN Cj4gPiBSVENQIHdpdGggdGhlIGNhcHR1cmVJRCBTREVTIGl0ZW0gYW5kIGl0IGRvZXMgbm90IG1h dHRlciBob3cgd2UgY3JlYXRlDQo+ID4gdGhlIGNhcHR1cmVJRCB2YWx1ZSwgc28gbWF5YmUgaWYg d2UgbWFuZGF0ZSBlbmNyeXB0aW5nIHRoZSBTREVTIGl0ZW0NCj4gPiB0aGVyZSBpcyBubyBzdHJv bmcgbmVlZCBmb3Igc3BlY2lmeWluZyBob3cgdG8gY3JlYXRlIENhcHR1cmVJRCAuIE5vdGUNCj4g PiB0aGF0IHRoZSBDYXB0dXJlSUQgaXMgbm90IHVzZSB0byBwcm92aWRlIGh1bWFuLXJlYWRhYmxl IHRleHR1YWwNCj4gPiBpbmZvcm1hdGlvbiB3aGljaCBpcyBpbiB0aGUgZGVzY3JpcHRpb24gYXR0 cmlidXRlLg0KPiA+DQo+ID4gUm9uaQ0KPiA+DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tIEZyb206IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4+IFttYWlsdG86bWFnbnVzLndlc3Rlcmx1 bmRAZXJpY3Nzb24uY29tXSBTZW50OiDXmdeV150g15MgMTgg15nXoNeV15DXqCAyMDE3DQo+ID4+ IDEwOjQ1IFRvOiBSb25pIEV2ZW47IGNsdWVAaWV0Zi5vcmcgQ2M6IEpvbmF0aGFuIExlbm5veCBT dWJqZWN0OiBSZToNCj4gPj4gQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0eQ0KPiA+ Pg0KPiA+PiBIaSwNCj4gPj4NCj4gPj4gQSBjb21tZW50IGFib3V0IHRoZSBiZWxvdy4gSSBoYXZl IGFuIGlzc3VlIHJhaXNlZCBhZ2FpbnN0IHRoZSBiZWxvdw0KPiA+PiBxdW90ZWQgdGV4dCBmcm9t IHRoZSBydGN3ZWItc2VjdXJpdHktYXJjaGl0ZWN0dXJlIGluIHRoZSBSVENXZWIgV0csDQo+ID4+ IGFzIGl0IGZhaWxzIHRvIHNwZWNpZnkgaWYgUlRDUCBlbmNyeXB0aW9uIGlzIG1hbmRhdG9yeSB0 byB1c2Ugb3Igbm90Lg0KPiA+PiBUaGVyZSBhcmUgcHJvdGVjdGlvbiBwcm9maWxlcyB0aGF0IG9u bHkgaGF2ZSBjb25maWRlbnRpYWxpdHkNCj4gPj4gcHJvdGVjdGlvbiBmb3IgUlRQLCBhbmQgbm90 IGZvciBSVENQLiBJIHdvdWxkIHJlY29tbWVuZCByZXF1aXJpbmcNCj4gPj4gY29uZmlkZW50aWFs aXR5IHByb3RlY3Rpb24gYWxzbyBvZiBSVENQLg0KPiA+Pg0KPiA+PiBUaGUgc2Vjb25kIG5vdGUg b24gdGhlIGJlbG93IGlzIHRoYXQgZGVwZW5kaW5nIG9uIHRoZSBvdXRjb21lIG9mIHRoZQ0KPiA+ PiBzZWN1cml0eSByZXF1aXJlbWVudHMgZm9yIHRoZSBDYXB0dXJlSUQgUlRQIGhlYWRlciBleHRl bnNpb24sIHlvdQ0KPiA+PiBtaWdodCBpbiBhZGRpdGlvbiBoYXZlIHRvIHJlcXVpcmUgUkZDIDY5 MDQsIGltcGxlbWVudGF0aW9uIGFuZCB1c2FnZQ0KPiA+PiBmb3IgdGhlIENhcHR1cmVJZCBoZWFk ZXIgZXh0ZW5zaW9uIGZpZWxkLiBPciByYXRoZXIgaWYgeW91IHdyaXRlDQo+ID4+IG5vdGhpbmcg aXQgd2lsbCBieSBkZWZhdWx0IGJlIHJlcXVpcmVkIGlmIHlvdSBlbmNyeXB0IFJUQ1AsIGR1ZSB0 bw0KPiA+PiBSRkMgNzk0MS4gQnV0LCBJIHJlYWxseSByZWNvbW1lbmQgdGhhdCB5b3UgYXJlIGV4 cGxpY2l0IG9uIHRoaXMNCj4gPj4gbWF0dGVyLiBJdCBjb21lcyBkb3duIHRvIHdoYXQgc2VjdXJp dHkgcmlza3MgdGhlIGZpZWxkIGVudGFpbHMuIFdoYXQNCj4gPj4gaW5mb3JtYXRpb24gd2lsbCBp dCBsZWFrIHRvIGEgdGhpcmQgcGFydHkgdmlld2VyIG9mIHRoZSBSVFAvUlRDUA0KPiA+PiBzdHJl YW0gdGhleSBjYW4gY2FwdHVyZS4NCj4gPj4NCj4gPj4gQ2hlZXJzDQo+ID4+DQo+ID4+IE1hZ251 cw0KPiA+Pg0KPiA+PiBEZW4gMjAxNy0wMS0xOCBrbC4gMDk6MzMsIHNrcmV2IFJvbmkgRXZlbjoN Cj4gPj4+IDIuICAgICAgIFdoYXQgZG8gd2Ugd2FudCB0byBzYXkgYWJvdXQgc3VwcG9ydGVkIHNl Y3VyaXR5IHByb2ZpbGU/DQo+ID4+PiBGb3IgZXhhbXBsZSBkb2VzIHRoZSBmb2xsb3dpbmcgZGly ZWN0aXZlIGZyb20NCj4gPj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTEyI3NlY3RpDQo+ID4+PiBvbi01LjUNCj4gPj4+DQo+ID4+ Pg0KPiBsb29rcyBnb29kIGZvciBDTFVFPw0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4g4oCc SW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50IFNSVFAgW1JGQzM3MTENCj4gPj4+IDxodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjMzcxMT5dLiAgSW1wbGVtZW50YXRpb25zIE1VU1QN Cj4gPj4+DQo+ID4+PiBpbXBsZW1lbnQgRFRMUyBbUkZDNDM0NyA8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzQzNDc+XQ0KPiA+Pj4gYW5kIERUTFMtU1JUUCBbUkZDNTc2Mw0KPiA+Pj4g PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1NzYzPl1bUkZDNTc2NF0gZm9yDQo+ID4+ IFNSVFANCj4gPj4+DQo+ID4+PiBrZXlpbmcuICBJbXBsZW1lbnRhdGlvbnMgTVVTVCBpbXBsZW1l bnQNCj4gPj4+DQo+ID4+PiBbSS1ELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcw0KPiA+Pj4g PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1h cmNoLTEyI3JlZi0NCj4gPj4+IEktDQo+ID4+DQo+ID4+Pg0KPiBELmlldGYtdHN2d2ctc2N0cC1k dGxzLWVuY2Fwcz5dLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWxsIG1lZGlhIGNoYW5u ZWxzIE1VU1QgYmUgc2VjdXJlZCB2aWEgU1JUUC4gIE1lZGlhIHRyYWZmaWMgTVVTVCBOT1QNCj4g Pj4+DQo+ID4+PiBiZSBzZW50IG92ZXIgcGxhaW4gKHVuZW5jcnlwdGVkKSBSVFA7IHRoYXQgaXMs IGltcGxlbWVudGF0aW9ucyBNVVNUDQo+ID4+Pg0KPiA+Pj4gTk9UIG5lZ290aWF0ZSBjaXBoZXIg c3VpdGVzIHdpdGggTlVMTCBlbmNyeXB0aW9uIG1vZGVzLg0KPiA+Pj4gRFRMUy1TUlRQDQo+ID4+ Pg0KPiA+Pj4gTVVTVCBiZSBvZmZlcmVkIGZvciBldmVyeSBtZWRpYSBjaGFubmVsLg0KPiA+Pj4N Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWxsIGRhdGEgY2hhbm5lbHMgTVVTVCBiZSBzZWN1cmVkIHZp YSBEVExTLg0KPiA+Pj4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gQWxsIGltcGxlbWVudGF0aW9ucyBN VVNUIGltcGxlbWVudCBEVExTIDEuMCwgd2l0aCB0aGUgY2lwaGVyIHN1aXRlDQo+ID4+Pg0KPiA+ Pj4gVExTX0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9DQkNfU0hBIHdpdGggdGhlIHRoZSBQLTI1 NiBjdXJ2ZQ0KPiA+Pj4NCj4gPj4+IFtGSVBTMTg2DQo+ID4+PiA8aHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTIjcmVmLQ0KPiA+Pg0K PiA+Pj4NCj4gRklQUzE4Nj5dLg0KPiA+Pj4gVGhlIERUTFMtU1JUUCBwcm90ZWN0aW9uIHByb2Zp bGUNCj4gPj4+DQo+ID4+PiBTUlRQX0FFUzEyOF9DTV9ITUFDX1NIQTFfODAgTVVTVCBiZSBzdXBw b3J0ZWQgZm9yIFNSVFAuDQo+ID4+Pg0KPiA+Pj4gSW1wbGVtZW50YXRpb25zIFNIT1VMRCBpbXBs ZW1lbnQgRFRMUyAxLjIgd2l0aCB0aGUNCj4gPj4+DQo+ID4+PiBUTFNfRUNESEVfRUNEU0FfV0lU SF9BRVNfMTI4X0dDTV9TSEEyNTYgY2lwaGVyIHN1aXRlLg0KPiA+Pj4NCj4gPj4+IEltcGxlbWVu dGF0aW9ucyBNVVNUIGZhdm9yIGNpcGhlciBzdWl0ZXMgd2hpY2ggc3VwcG9ydCBQRlMgb3Zlcg0K PiA+Pj4gbm9uLQ0KPiA+Pj4NCj4gPj4+IFBGUyBjaXBoZXIgc3VpdGVzIGFuZCBTSE9VTEQgZmF2 b3IgQUVBRCBvdmVyIG5vbi1BRUFEIGNpcGhlciBzdWl0ZXMuDQo+ID4+Pg0KPiA+Pj4g4oCcDQo+ ID4+DQo+ID4+DQo+ID4+IC0tDQo+ID4+DQo+ID4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4+DQo+ ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiA+PiAtDQo+ID4+DQo+ID4+DQo+IFNlcnZpY2VzLCBNZWRpYSBh bmQgTmV0d29yayBmZWF0dXJlcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RYTQ0KPiA+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPj4gLQ0KPiA+Pg0KPiA+Pg0KPiBFcmljc3NvbiBBQiAgICAgICAgICAgICAg ICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcNCj4gPj4gRsOkcsO2Z2F0YW4gNiAgICAgICAgICAg ICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkgU0UtMTY0IDgwDQo+ID4+IFN0b2NraG9sbSwg U3dlZGVuIHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gPj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4+IC0NCj4gPg0KPiA+Pg0KPiAtLQ0KPiANCj4gTWFnbnVzIFdlc3Rlcmx1 bmQNCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gU2VydmljZXMsIE1lZGlhIGFuZCBOZXR3b3JrIGZl YXR1cmVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFhNDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRXJp Y3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+IEbDpHLD tmdhdGFuIDYgICAgICAgICAgICAgICAgIHwgTW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+IFNFLTE2 NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nz b24uY29tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Wed Jan 18 08:25:54 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 1424F1294D0 for ; Wed, 18 Jan 2017 08:25:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, 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 33sL9act7BMj for ; Wed, 18 Jan 2017 08:25:51 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEB912947D for ; Wed, 18 Jan 2017 08:25:51 -0800 (PST) X-AuditID: 1207440d-97fff70000000a35-61-587f970ecfd2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id E4.2E.02613.E079F785; Wed, 18 Jan 2017 11:25:50 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0IGPn4Z032576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 18 Jan 2017 11:25:49 -0500 To: clue@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> From: Paul Kyzivat Message-ID: <208e2d66-b7bf-8167-7c3d-6841df84192e@alum.mit.edu> Date: Wed, 18 Jan 2017 11:25:49 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixO6iqMs3vT7C4OlxU4v9py4zOzB6LFny kymAMYrLJiU1J7MstUjfLoEr48CkVYwFh8wr5p41a2DcoNvFyMkhIWAi8WP5ZMYuRi4OIYHL jBJ/lv5jgXBeM0lc2XSAHaRKWMBM4vTW5UA2B4eIgKDEyyuCEDWdTBL7HnSzgtSwCWhJzDn0 nwWkhlfAXmLDEjWQMIuAqsTFZbeYQWxRgTSJBye3MoLYvEBjTs58wgJicwo4SDS+fsEGYjMD rZq3+SEzhC0v0bx1NvMERr5ZSFpmISmbhaRsASPzKka5xJzSXN3cxMyc4tRk3eLkxLy81CJd I73czBK91JTSTYyQEOPdwfh/ncwhRgEORiUe3o6i+ggh1sSy4srcQ4ySHExKorwuPUAhvqT8 lMqMxOKM+KLSnNTiQ4wSHMxKIrzBk4ByvCmJlVWpRfkwKWkOFiVxXrUl6n5CAumJJanZqakF qUUwWRkODiUJ3r9TgRoFi1LTUyvSMnNKENJMHJwgw3mAhqtOAxleXJCYW5yZDpE/xagoJc67 E6RZACSRUZoH1wtLAa8YxYFeEeZNA2nnAaYPuO5XQIOZgAZbKYMNLklESEk1MCYpVkUYdhxb p3NlSek1Zr6J854/PHtZOrcspCRv1cpAViHX83ObCpW2CAb6fb2xLiY2Xs/+V73dMbenAt2n ylMFLm2NaXrc/OmE5QfJ5iNdvkr2usevXLV692az19cP4XyBIt3FTZ2ztm3Pvtp+SmCXzGoh p2sffNVXyc/c0uSyxOvNyhwRRSWW4oxEQy3mouJEAE5r93XcAgAA Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 16:25:53 -0000 I have a side question on this: if RTCP is being multiplexed with RTP, and the RTP is being encrypted, is the RTCP also implicitly encrypted, or is it still an independently negotiated feature? (Yes, I realize that doesn't solve the general problem for CLUE.) Thanks, Paul On 1/18/17 6:53 AM, Magnus Westerlund wrote: > Hi, > > Yes, I think encrypting the CaptureID avoids the negative impacts that > bad construction can have that I can think of. Thus, I support going in > that direction. > > When it comes to the security solution I would recommend copying the > text and then make the edits. There is at least two additions, the MUST > encrypt RTCP, and the MUST implement RFC 6904 and use it to encrypt the > CaptureID header extension. Please be explicit and clear in the CLUE > level document on what security solutions that needs to be implemented > and use. > > Reasons for copying the text, is that there are differences between > RTCWeb and CLUE, and in addition I think the implementation > considerations and potential needs to later revise the specification are > different. I am not certain CLUE will want to be required to follow any > changes that RTCWeb does in the future. > > I would also note that I think you need at least to put in a short > paragraph about the CaptureID value. Something like this. > > The construction of the CaptureID value is implementation dependent and > is not tightly restricted. Therefore there exist a risk that the > CaptureID contains privacy sensitive information or otherwise revealing > information about the communication session to third parties. Therefore > confidentiality protection is always applied to avoid this risk. > > Cheers > > Magnus > > Den 2017-01-18 kl. 10:44, skrev Roni Even: >> Hi, The text I added to the -11 version "The CaptureID is created as >> part of the CLUE protocol. The CaptId SDES item is used to convey >> the same CaptureID value in the SDES item. When sending the SDES >> item the security considertion specied in the security section of >> [RFC7941] are applicable and this SDES item MUST use similar security >> as the CLUE protocol messages carried in the CLUE data channel." >> >> Say that " this SDES item MUST use similar security as the CLUE >> protocol messages carried in the CLUE data channel." The CLUE data >> channel document >> https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4 >> point at >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-7 >> pointing to >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 >> >> So we can reference the rtcweb security architecture or use the text >> I copied from there to define a security profile >> >> As for the second item I agree that if we encrypt the content in the >> CLUE data channel that includes the captureID, we need also to >> encrypt RTCP with the captureID SDES item and it does not matter how >> we create the captureID value, so maybe if we mandate encrypting the >> SDES item there is no strong need for specifying how to create >> CaptureID . Note that the CaptureID is not use to provide >> human-readable textual information which is in the description >> attribute. >> >> Roni >> >>> -----Original Message----- From: Magnus Westerlund >>> [mailto:magnus.westerlund@ericsson.com] Sent: יום ד 18 ינואר 2017 >>> 10:45 To: Roni Even; clue@ietf.org Cc: Jonathan Lennox Subject: Re: >>> Comments on CaptureID and security >>> >>> Hi, >>> >>> A comment about the below. I have an issue raised against the below >>> quoted text from the rtcweb-security-architecture in the RTCWeb WG, >>> as it fails to specify if RTCP encryption is mandatory to use or >>> not. There are protection profiles that only have confidentiality >>> protection for RTP, and not for RTCP. I would recommend requiring >>> confidentiality protection also of RTCP. >>> >>> The second note on the below is that depending on the outcome of >>> the security requirements for the CaptureID RTP header extension, >>> you might in addition have to require RFC 6904, implementation and >>> usage for the CaptureId header extension field. Or rather if you >>> write nothing it will by default be required if you encrypt RTCP, >>> due to RFC 7941. But, I really recommend that you are explicit on >>> this matter. It comes down to what security risks the field >>> entails. What information will it leak to a third party viewer of >>> the RTP/RTCP stream they can capture. >>> >>> Cheers >>> >>> Magnus >>> >>> Den 2017-01-18 kl. 09:33, skrev Roni Even: >>>> 2. What do we want to say about supported security profile? >>>> For example does the following directive from >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5 >>>> >>>> >>>> > looks good for CLUE? >>>> >>>> >>>> >>>> “Implementations MUST implement SRTP [RFC3711 >>>> ]. Implementations MUST >>>> >>>> implement DTLS [RFC4347 ] >>>> and DTLS-SRTP [RFC5763 >>>> ][RFC5764] for >>> SRTP >>>> >>>> keying. Implementations MUST implement >>>> >>>> [I-D.ietf-tsvwg-sctp-dtls-encaps >>>> >> >>>> > D.ietf-tsvwg-sctp-dtls-encaps>]. >>>> >>>> >>>> >>>> All media channels MUST be secured via SRTP. Media traffic MUST >>>> NOT >>>> >>>> be sent over plain (unencrypted) RTP; that is, implementations >>>> MUST >>>> >>>> NOT negotiate cipher suites with NULL encryption modes. >>>> DTLS-SRTP >>>> >>>> MUST be offered for every media channel. >>>> >>>> >>>> >>>> All data channels MUST be secured via DTLS. >>>> >>>> >>>> >>>> All implementations MUST implement DTLS 1.0, with the cipher >>>> suite >>>> >>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve >>>> >>>> [FIPS186 >>>> >> >>>> > FIPS186>]. >>>> The DTLS-SRTP protection profile >>>> >>>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. >>>> >>>> Implementations SHOULD implement DTLS 1.2 with the >>>> >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. >>>> >>>> Implementations MUST favor cipher suites which support PFS over >>>> non- >>>> >>>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher >>>> suites. >>>> >>>> “ >>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> >>> > Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>> >>> > Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >> >>> From nobody Wed Jan 18 12:48:04 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 5E8B6128E18; Wed, 18 Jan 2017 12:48:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148477248127.2230.11179332810356559654.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 12:48:01 -0800 Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: [clue] Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:48:01 -0000 Ben Campbell has entered the following ballot position for draft-ietf-clue-rtp-mapping-12: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I plan to ballot "yes" for this, but there's an issue in section 9 that I think needs to be fixed first: In the second paragraph, the draft says "CLUE endpoints MUST support RTP/ SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft goes further by saying that media MUST be secured, and that DTLS-SRTP SHOULD be used unless the media is secured by some other mechanism. I think that readers will expect the mapping spec to be authoritative about that sort of thing. It's likely to be misleading to have it mention the requirement to support RTP/SAVPF and DTLS-SRTP without also mentioning the MUST be secured, SHOULD be used requirements. This can easily be fixed by mentioning the additional requirements and citing the framework. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Substantive: -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes on to discuss the first two, but doesn't mention the last two. -5, paragraph 4: "When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC." Does MUST send mean MUST send both in the RTP header and as an RTCP SDES item, as in the previous sentence? -5, paragraph 5: It would be helpful to add a sentence or two clarifying the difference between an MCC that carries multiple MCs at the same time, and one that switch between MCs, but only carry one at a time. Editorial: - 1, 2nd paragraph: Please expand SSRC on first use. -3, 2nd paragraph: Please expand SDES on first use. -- "specified in CLUE use case [RFC7205]" should that say "specified in the CLUE use case document [RFC7205]"? -- "described using MCC." missing article ("using an MCC." -3, third paragraph: "If needed by CLUE endpoint," Missing article. -4, 2nd paragraph: s/"slide video"/"side video" -6, first paragraph: s/"made by"/"made up of" ; or "comprises" -9, 2nd paragraph: Please don't use 2119 to describe requirements from other documents, unless in a direct quote (in quotation marks.) From nobody Wed Jan 18 13:09:14 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 D44D1129485; Wed, 18 Jan 2017 13:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 5sEXgTRyh_rl; Wed, 18 Jan 2017 13:09:12 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 577541294C9; Wed, 18 Jan 2017 13:09:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 75EF62CD02; Wed, 18 Jan 2017 23:09:11 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tv5hoWmpQKAf; Wed, 18 Jan 2017 23:09:11 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id C600B2CCAF; Wed, 18 Jan 2017 23:09:10 +0200 (EET) (envelope-from jari.arkko@piuha.net) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0F0988AB-5144-44D0-BA3B-41B29D790748"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Jari Arkko In-Reply-To: <148250596603.16864.2431028787834430981.idtracker@ietfa.amsl.com> Date: Wed, 18 Jan 2017 23:09:09 +0200 Message-Id: <54842316-2154-4E39-A2C4-255709AE9BFB@piuha.net> References: <148250596603.16864.2431028787834430981.idtracker@ietfa.amsl.com> To: Vijay Gurbani X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "gen-art@ietf.org Review Team" , clue@ietf.org, draft-ietf-clue-rtp-mapping.all@ietf.org, IETF Discussion Subject: Re: [clue] Review of draft-ietf-clue-rtp-mapping-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:09:14 -0000 --Apple-Mail=_0F0988AB-5144-44D0-BA3B-41B29D790748 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > Summary: Ready with nits. >=20 > Major issues: 0 >=20 > Minor issues: 0 >=20 > Nits/editorial comments: > - S1: s/source of Media, such as from one or more Capture > Devices./source of Media from one or more Capture Devices./ > - S1: s/SIP offer answer/SIP Offer/Answer model/ > - S1: s/recommendations, for the CLUE architecture, about > how/recommendations for the CLUE architecture on how/ > - S4: s/have main and slides video sources can/have a primary video > source and a slide video source can/ > - S5: s/CaptureIDis/CaptureID is/ Thanks for your review, Vijay! Authors, I didn=92t see changes related to these observations in the new document versions=85 were the comments missed? While they were small editorial comments, they all made sense to me at least ;-) I have balloted no-objection for this document on tomorrow=92s IESG telechat. Jari --Apple-Mail=_0F0988AB-5144-44D0-BA3B-41B29D790748 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYf9l1AAoJEM80gCTQU46qLywQAIfniupDhNH7ODwJc16dyEcL qVUJtTJXauFeE2BvnI4he7HEBZeCAxY402ExGq+2NVYjUol7aMVADhXLL7+nfCvj Y5+qGesgs0eXUBx1ibwd8cfshQ28VDv0adRhlIHOtS1LQeoLk2sJde4dW/MNxMRX rlmLGlvBkBiZR3jUNtsFFJ908oOoTyBtBmVu43bmLxs1TbljDVgO1K/ck0zawfwG H+3VJgHvkWJlB8nnTpTg2nVSsaO5BSonDXPNAV0K6/9YfGBxdv/gvAUJnkQxudjn BMkrQKmd+/5a2oHz78ZLr79vdh9x1vSZR9mx6cJYcfQmV0345ipgg23SgWZSIQtm 5S2FSyVWEXAvbUnCbdCorkmwKnyAyIgN3CfZgUEHGdCpc3XlZL6+a78VwZa28eHn QLdKXbn+MjeYiaDXofsrEtl0FkrvsM7r8LLzYFoveP6k4YCfgRXOugU6dtqwjx9X r22PcWYmgz53ybCwaHzPH+VwWiROiqygQ++6KxAqwyK6V2dc00CY76wnPI6YTvbI DQScJDDfnDu7d5fLqL7myLNRNuPs4ukX7U81gsPEQlumqG9tZJhs0gzno7WdGQx3 Fi93GdyQycWjI4IS0EuGlriiprjVcrTptPQCQywi+lT6zDLXgfEcXmc1Udh0umUE Q1f9nCQftv/U0fjv75Wm =ZMaJ -----END PGP SIGNATURE----- --Apple-Mail=_0F0988AB-5144-44D0-BA3B-41B29D790748-- From nobody Wed Jan 18 22:51:43 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 00175127058; Wed, 18 Jan 2017 22:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 BsO30Uryz-Tc; Wed, 18 Jan 2017 22:51:39 -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 1B5A112940E; Wed, 18 Jan 2017 22:51:37 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZC48909; Thu, 19 Jan 2017 06:51:35 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 06:51:34 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0301.000; Thu, 19 Jan 2017 14:51:29 +0800 From: Roni Even To: Ben Campbell , The IESG Thread-Topic: Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) Thread-Index: AQHSccwvGwMpD2dAOkOswdZl7Gjoo6E/S9/Q Date: Thu, 19 Jan 2017 06:51:28 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76E261@DGGEMM506-MBX.china.huawei.com> References: <148477248127.2230.11179332810356559654.idtracker@ietfa.amsl.com> In-Reply-To: <148477248127.2230.11179332810356559654.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.115.163] 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.0A090202.588061F7.0123, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 3b29ddc1ce8ef5e4c3c2103ce8d3ed10 Archived-At: Cc: "clue@ietf.org" , "clue-chairs@ietf.org" , "draft-ietf-clue-rtp-mapping@ietf.org" Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 06:51:40 -0000 SGkgQmVuLA0KU2VlIGlubGluZQ0KUm9uaQ0KDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gRElTQ1VTUzoN Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gSSBwbGFuIHRvIGJhbGxvdCAieWVzIiBmb3IgdGhpcywg YnV0IHRoZXJlJ3MgYW4gaXNzdWUgaW4gc2VjdGlvbiA5IHRoYXQgSSB0aGluaw0KPiBuZWVkcyB0 byBiZSBmaXhlZCBmaXJzdDoNCj4gDQo+IEluIHRoZSBzZWNvbmQgcGFyYWdyYXBoLCB0aGUgZHJh ZnQgc2F5cyAiQ0xVRSBlbmRwb2ludHMgTVVTVCBzdXBwb3J0IFJUUC8NCj4gU0FWUEYgYW5kIERU TFMtU1JUUCBrZXlpbmcgW1JGQzU3NjRdLiIgQnV0IHRoZSBmcmFtZXdvcmsgZHJhZnQgZ29lcw0K PiBmdXJ0aGVyIGJ5IHNheWluZyB0aGF0IG1lZGlhIE1VU1QgYmUgc2VjdXJlZCwgYW5kIHRoYXQg RFRMUy1TUlRQIFNIT1VMRA0KPiBiZSB1c2VkIHVubGVzcyB0aGUgbWVkaWEgaXMgc2VjdXJlZCBi eSBzb21lIG90aGVyIG1lY2hhbmlzbS4gSSB0aGluayB0aGF0DQo+IHJlYWRlcnMgd2lsbCBleHBl Y3QgdGhlIG1hcHBpbmcgc3BlYyB0byBiZSBhdXRob3JpdGF0aXZlIGFib3V0IHRoYXQgc29ydCBv Zg0KPiB0aGluZy4gSXQncyBsaWtlbHkgdG8gYmUgbWlzbGVhZGluZyB0byBoYXZlIGl0IG1lbnRp b24gdGhlIHJlcXVpcmVtZW50IHRvDQo+IHN1cHBvcnQgUlRQL1NBVlBGIGFuZCBEVExTLVNSVFAg d2l0aG91dCBhbHNvIG1lbnRpb25pbmcgdGhlIE1VU1QgYmUNCj4gc2VjdXJlZCwgU0hPVUxEIGJl IHVzZWQgcmVxdWlyZW1lbnRzLiBUaGlzIGNhbiBlYXNpbHkgYmUgZml4ZWQgYnkNCj4gbWVudGlv bmluZyB0aGUgYWRkaXRpb25hbCByZXF1aXJlbWVudHMgYW5kIGNpdGluZyB0aGUgZnJhbWV3b3Jr Lg0KW1JvbmkgRXZlbl0gWW91IGFyZSByaWdodCwgSSB3aWxsIHVzZSB0aGUgdGV4dCBmcm9tIHRo ZSBmcmFtZXdvcmsgd2hpY2ggaXMgdGhlIGNvcnJlY3QgdGV4dA0KPiANCj4gDQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCj4gQ09NTUVOVDoNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiANCj4gU3Vic3RhbnRpdmU6DQo+ IA0KPiAtMzogVGhlIG9wZW5pbmcgcGFyYWdyYXBoIG1lbnRpb25zICJQb2ludC10by1Qb2ludCwg YXMgd2VsbCBhcyBNZWRpYS1NaXhpbmcNCj4gICAgbWl4ZXJzLCBNZWRpYS0gU3dpdGNoaW5nIG1p eGVycywgYW5kIFNlbGVjdGl2ZSBGb3J3YXJkaW5nIE1pZGRsZWJveHMuIg0KPiBUaGUgc2VjdGlv biBnb2VzIG9uIHRvIGRpc2N1c3MgdGhlIGZpcnN0IHR3bywgYnV0IGRvZXNuJ3QgbWVudGlvbiB0 aGUgbGFzdA0KPiB0d28uDQpbUm9uaSBFdmVuXSBUaGVyZSB3YXMgc29tZSB0ZXh0IGluIHByZXZp b3VzIHJldmlzaW9uIGJ1dCB0aGUgZmVlZGJhY2sgZnJvbSB0aGUgV0cgd2FzIHRvIHJlbW92ZSBp dCBzaW5jZSBpdCB3YXMganVzdCByZXBlYXRpbmcgdGV4dCBmcm9tIHRoZSB0b3BvbG9neSBkcmFm dCAoUkZDNzY2NykNCj4gDQo+IC01LCBwYXJhZ3JhcGggNDogIldoZW4gdGhlIG1lZGlhIHByb3Zp ZGVyDQo+ICAgIHN3aXRjaGVzIHRoZSBNQyBpdCBzZW5kcyB3aXRoaW4gYW4gTUNDLCBpdCBNVVNU IHNlbmQgdGhlIGNhcHR1cmVJRA0KPiAgICB2YWx1ZSBmb3IgdGhlIE1DIGp1c3Qgc3dpdGNoZWQg aW50byB0aGUgTUNDLiINCj4gDQo+IERvZXMgTVVTVCBzZW5kIG1lYW4gTVVTVCBzZW5kIGJvdGgg aW4gdGhlIFJUUCBoZWFkZXIgYW5kIGFzIGFuIFJUQ1ANCj4gU0RFUyBpdGVtLCBhcyBpbiB0aGUg cHJldmlvdXMgc2VudGVuY2U/DQpbUm9uaSBFdmVuXSBZZXMsIGZvciBjbGFyaWZpY2F0aW9uIEkg Y2FuIGFkZCB0byB0aGUgcHJldmlvdXMgc2VudGVuY2UgImFzIHNwZWNpZmllZCBpbiBbUkZDNzk0 MV0iDQo+IA0KPiAtNSwgcGFyYWdyYXBoIDU6DQo+IEl0IHdvdWxkIGJlIGhlbHBmdWwgdG8gYWRk IGEgc2VudGVuY2Ugb3IgdHdvIGNsYXJpZnlpbmcgdGhlIGRpZmZlcmVuY2UNCj4gYmV0d2VlbiBh biBNQ0MgdGhhdCBjYXJyaWVzIG11bHRpcGxlIE1DcyBhdCB0aGUgc2FtZSB0aW1lLCBhbmQgb25l IHRoYXQNCj4gc3dpdGNoIGJldHdlZW4gTUNzLCBidXQgb25seSBjYXJyeSBvbmUgYXQgYSB0aW1l Lg0KW1JvbmkgRXZlbl0gSSB0aGluayB0aGF0IGl0IGlzIGNsZWFyLCBpdCBpcyBub3QgY2Fycnlp bmcgbXVsdGlwbGUgTUNzIGl0ICJzZW5kcyBhIGNvbXBvc2VkIHN0cmVhbSBvZiBtdWx0aXBsZSBN Q3MiLiBUaGlzIGRvY3VtZW50IGRvZXMgbm90IGRlZmluZSB3aGF0IGlzIGFuIE1DQyBzbyBpZiB5 b3UgZG8gbm90IGtub3cgd2hhdCBpcyBhbiBNQ0MgeW91IG5lZWQgdG8gcmVhZCB0aGUgZnJhbWV3 b3JrIGRvY3VtZW50IHdoaWNoIGlzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZS4gDQo+IA0KPiANCj4g RWRpdG9yaWFsOg0KPiANCj4gLSAxLCAybmQgcGFyYWdyYXBoOiBQbGVhc2UgZXhwYW5kIFNTUkMg b24gZmlyc3QgdXNlLg0KW1JvbmkgRXZlbl0gT0sNCj4gDQo+IC0zLCAybmQgcGFyYWdyYXBoOiBQ bGVhc2UgZXhwYW5kIFNERVMgb24gZmlyc3QgdXNlLg0KPiAtLSAic3BlY2lmaWVkIGluIENMVUUg dXNlIGNhc2UgW1JGQzcyMDVdIg0KPiBzaG91bGQgdGhhdCBzYXkgInNwZWNpZmllZCBpbiB0aGUg Q0xVRSB1c2UgY2FzZSBkb2N1bWVudCBbUkZDNzIwNV0iPw0KPiAtLSAiZGVzY3JpYmVkIHVzaW5n IE1DQy4iDQo+IG1pc3NpbmcgYXJ0aWNsZSAoInVzaW5nIGFuIE1DQy4iDQpbUm9uaSBFdmVuXSBP Sw0KPiANCj4gLTMsIHRoaXJkIHBhcmFncmFwaDogIklmIG5lZWRlZCBieSBDTFVFDQo+ICAgIGVu ZHBvaW50LCINCj4gTWlzc2luZyBhcnRpY2xlLg0KW1JvbmkgRXZlbl0gT0sNCj4gDQo+IC00LCAy bmQgcGFyYWdyYXBoOiBzLyJzbGlkZSB2aWRlbyIvInNpZGUgdmlkZW8iDQpbUm9uaSBFdmVuXSBJ dCBpcyBzbGlkZSBzZWUgUkZDNDc5NiAtIGJ1dCB0aGUgY2hhbmdlIGlzIHRvICJzbGlkZXMiDQo+ IA0KPiAtNiwgZmlyc3QgcGFyYWdyYXBoOiBzLyJtYWRlIGJ5Ii8ibWFkZSB1cCBvZiIgIDsgb3Ig ImNvbXByaXNlcyINCltSb25pIEV2ZW5dIE9LDQo+IA0KPiAtOSwgMm5kIHBhcmFncmFwaDogUGxl YXNlIGRvbid0IHVzZSAyMTE5IHRvIGRlc2NyaWJlIHJlcXVpcmVtZW50cyBmcm9tDQo+IG90aGVy IGRvY3VtZW50cywgdW5sZXNzIGluIGEgZGlyZWN0IHF1b3RlIChpbiBxdW90YXRpb24gbWFya3Mu KQ0KW1JvbmkgRXZlbl0gSSBhbSBub3Qgc3VyZSB3aGF0IHRvIGRvLCBJIGFzc3VtZSBpdCBpcyBh Ym91dCAiQ0xVRSBlbmRwb2ludHMgTVVTVCBzdXBwb3J0IFJUUC8NCiAgIFNBVlBGIGFuZCBEVExT LVNSVFAga2V5aW5nIFtSRkM1NzY0XS4iLiBXZSB3YW50IHRvIHNheSB0aGF0IHRoZXkgTVVTVCBz dXBwb3J0IFNBVlBGIGFuZCBEVExTLVNSVFAga2V5aW5nIC4gYnV0IEkgdGhpbmsgdGhhdCB0aGlz IHRleHQgd2lsbCBjaGFuZ2UgYmFzZWQgb24gTWFnbnVzIHJlcXVlc3QgdG8gcHJvdmlkZSBzcGVj aWZpYyBzZWN1cml0eSBwcm9maWxlDQoNCj4gDQoNCg== From nobody Thu Jan 19 07:06: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 0D00A1293F2; Thu, 19 Jan 2017 07:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] 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 FLP8GCBe6QbX; Thu, 19 Jan 2017 07:06:34 -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 12F5C1270B4; Thu, 19 Jan 2017 07:06:34 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0JF6LrF094295 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 19 Jan 2017 09:06:22 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Roni Even" Date: Thu, 19 Jan 2017 09:06:09 -0600 Message-ID: <9BC2A817-5D7F-4AA9-B737-2FB45D2D3DE6@nostrum.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD76E261@DGGEMM506-MBX.china.huawei.com> References: <148477248127.2230.11179332810356559654.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD76E261@DGGEMM506-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: "clue@ietf.org" , "clue-chairs@ietf.org" , "draft-ietf-clue-rtp-mapping@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:06:36 -0000 Hi Roni, thanks for the response. See comments below. I removed sections that I think are resolved. On 19 Jan 2017, at 0:51, Roni Even wrote: > Hi Ben, > See inline > Roni > >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I plan to ballot "yes" for this, but there's an issue in section 9 >> that I think >> needs to be fixed first: >> >> In the second paragraph, the draft says "CLUE endpoints MUST support >> RTP/ >> SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft goes >> further by saying that media MUST be secured, and that DTLS-SRTP >> SHOULD >> be used unless the media is secured by some other mechanism. I think >> that >> readers will expect the mapping spec to be authoritative about that >> sort of >> thing. It's likely to be misleading to have it mention the >> requirement to >> support RTP/SAVPF and DTLS-SRTP without also mentioning the MUST be >> secured, SHOULD be used requirements. This can easily be fixed by >> mentioning the additional requirements and citing the framework. > [Roni Even] You are right, I will use the text from the framework > which is the correct text >> Thanks. I will clear the discuss now, since this is a simple enough fix. >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Substantive: >> >> -3: The opening paragraph mentions "Point-to-Point, as well as >> Media-Mixing >> mixers, Media- Switching mixers, and Selective Forwarding >> Middleboxs." >> The section goes on to discuss the first two, but doesn't mention the >> last >> two. > [Roni Even] There was some text in previous revision but the feedback > from the WG was to remove it since it was just repeating text from the > topology draft (RFC7667) Okay. Something to the effect that "Media-switching mixers and Selective Forwarding Middleboxes behave as described in [RFC7677]" towards the end of the section would help balance things--but it's not critical one way or the other. [...] >> >> -5, paragraph 5: >> It would be helpful to add a sentence or two clarifying the >> difference >> between an MCC that carries multiple MCs at the same time, and one >> that >> switch between MCs, but only carry one at a time. > [Roni Even] I think that it is clear, it is not carrying multiple MCs > it "sends a composed stream of multiple MCs". This document does not > define what is an MCC so if you do not know what is an MCC you need to > read the framework document which is a normative reference. Your call on this one. I am not sure that people will realize that "composed stream of multiple MCs" means one at a time. [...] >> >> -9, 2nd paragraph: Please don't use 2119 to describe requirements >> from >> other documents, unless in a direct quote (in quotation marks.) > [Roni Even] I am not sure what to do, I assume it is about "CLUE > endpoints MUST support RTP/ > SAVPF and DTLS-SRTP keying [RFC5764].". We want to say that they > MUST support SAVPF and DTLS-SRTP keying . but I think that this text > will change based on Magnus request to provide specific security > profile You can always say that "[RFCXXXX] requires endpoints to..." From nobody Thu Jan 19 07:08:08 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 F2A291293DF; Thu, 19 Jan 2017 07:08:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148483848396.10377.6405277360457606468.idtracker@ietfa.amsl.com> Date: Thu, 19 Jan 2017 07:08:03 -0800 Archived-At: Cc: clue@ietf.org, clue-chairs@ietf.org, draft-ietf-clue-rtp-mapping@ietf.org Subject: [clue] Ben Campbell's Yes on draft-ietf-clue-rtp-mapping-12: (with COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:08:04 -0000 Ben Campbell has entered the following ballot position for draft-ietf-clue-rtp-mapping-12: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS point. I'm leaving the other comments below for posterity; I think most of them have been resolved. Substantive: -3: The opening paragraph mentions "Point-to-Point, as well as Media-Mixing mixers, Media- Switching mixers, and Selective Forwarding Middleboxs." The section goes on to discuss the first two, but doesn't mention the last two. -5, paragraph 4: "When the media provider switches the MC it sends within an MCC, it MUST send the captureID value for the MC just switched into the MCC." Does MUST send mean MUST send both in the RTP header and as an RTCP SDES item, as in the previous sentence? -5, paragraph 5: It would be helpful to add a sentence or two clarifying the difference between an MCC that carries multiple MCs at the same time, and one that switch between MCs, but only carry one at a time. Editorial: - 1, 2nd paragraph: Please expand SSRC on first use. -3, 2nd paragraph: Please expand SDES on first use. -- "specified in CLUE use case [RFC7205]" should that say "specified in the CLUE use case document [RFC7205]"? -- "described using MCC." missing article ("using an MCC." -3, third paragraph: "If needed by CLUE endpoint," Missing article. -4, 2nd paragraph: s/"slide video"/"side video" -6, first paragraph: s/"made by"/"made up of" ; or "comprises" -9, 2nd paragraph: Please don't use 2119 to describe requirements from other documents, unless in a direct quote (in quotation marks.) From nobody Thu Jan 19 22:28:24 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 8392C1299AA for ; Thu, 19 Jan 2017 22:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 AkzSio8HDFGA for ; Thu, 19 Jan 2017 22:28:20 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E71129997 for ; Thu, 19 Jan 2017 22:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SxrtL0gIzTtZD3KgTMeBOKMCPvt7uJMvSVTQlzx/xF0=; b=A/M3KGbDFZVjWx+9X647I0GkyS /74cSBHmUPTdfUFcHpLpcJIWqPEWwe1rGpx0jjBdnHqt9gaH0twsGsNldzrYMweicwFO5I7TutpBQ 0lvN8gavtykPLp8wgybaxixHnuUblbxmAXJgpciBzd7MAWJApaqmM/EIxCJc9+7wIuAQ1fC8JwFN6 pXFvNzRL28GoHsf7BA3GPzsCtkFdiqQA+AJ5qe6DaKmaaBzWVLMrQMs6e5GyBVxDtaGN7pDf9RfkT YjpWTt2U3ElcK3UUY9bEa/7LlvaquGMek1OPW83kEBFRjnkLtTGKbT/5VFs2ld/7O9oGO/9wnu1hS 8VMVWeFQ==; Received: from ppp118-209-171-56.lns20.mel8.internode.on.net ([118.209.171.56]:65530 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cUSgK-001BEq-Jr for clue@ietf.org; Fri, 20 Jan 2017 17:28:16 +1100 To: clue@ietf.org References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> From: Christian Groves Message-ID: Date: Fri, 20 Jan 2017 17:28:09 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 20 Jan 2017 06:28:22 -0000 Do we need to consider PERC when making that recommendation? An MDF would need access to the CaptureID in order to making switching decisions in CLUE is used. Regards, Christian On 18/01/2017 10:53 PM, Magnus Westerlund wrote: > Hi, > > Yes, I think encrypting the CaptureID avoids the negative impacts that > bad construction can have that I can think of. Thus, I support going > in that direction. > > When it comes to the security solution I would recommend copying the > text and then make the edits. There is at least two additions, the > MUST encrypt RTCP, and the MUST implement RFC 6904 and use it to > encrypt the CaptureID header extension. Please be explicit and clear > in the CLUE level document on what security solutions that needs to be > implemented and use. > > Reasons for copying the text, is that there are differences between > RTCWeb and CLUE, and in addition I think the implementation > considerations and potential needs to later revise the specification > are different. I am not certain CLUE will want to be required to > follow any changes that RTCWeb does in the future. > > I would also note that I think you need at least to put in a short > paragraph about the CaptureID value. Something like this. > > The construction of the CaptureID value is implementation dependent > and is not tightly restricted. Therefore there exist a risk that the > CaptureID contains privacy sensitive information or otherwise > revealing information about the communication session to third > parties. Therefore confidentiality protection is always applied to > avoid this risk. > > Cheers > > Magnus > > Den 2017-01-18 kl. 10:44, skrev Roni Even: >> Hi, The text I added to the -11 version "The CaptureID is created as >> part of the CLUE protocol. The CaptId SDES item is used to convey >> the same CaptureID value in the SDES item. When sending the SDES >> item the security considertion specied in the security section of >> [RFC7941] are applicable and this SDES item MUST use similar security >> as the CLUE protocol messages carried in the CLUE data channel." >> >> Say that " this SDES item MUST use similar security as the CLUE >> protocol messages carried in the CLUE data channel." The CLUE data >> channel document >> https://tools.ietf.org/html/draft-ietf-clue-datachannel-14#section-4 >> point at >> https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-7 >> pointing to >> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-10 >> >> So we can reference the rtcweb security architecture or use the text >> I copied from there to define a security profile >> >> As for the second item I agree that if we encrypt the content in the >> CLUE data channel that includes the captureID, we need also to >> encrypt RTCP with the captureID SDES item and it does not matter how >> we create the captureID value, so maybe if we mandate encrypting the >> SDES item there is no strong need for specifying how to create >> CaptureID . Note that the CaptureID is not use to provide >> human-readable textual information which is in the description >> attribute. >> >> Roni >> >>> -----Original Message----- From: Magnus Westerlund >>> [mailto:magnus.westerlund@ericsson.com] Sent: יום ד 18 ינואר 2017 >>> 10:45 To: Roni Even; clue@ietf.org Cc: Jonathan Lennox Subject: Re: >>> Comments on CaptureID and security >>> >>> Hi, >>> >>> A comment about the below. I have an issue raised against the below >>> quoted text from the rtcweb-security-architecture in the RTCWeb WG, >>> as it fails to specify if RTCP encryption is mandatory to use or >>> not. There are protection profiles that only have confidentiality >>> protection for RTP, and not for RTCP. I would recommend requiring >>> confidentiality protection also of RTCP. >>> >>> The second note on the below is that depending on the outcome of >>> the security requirements for the CaptureID RTP header extension, >>> you might in addition have to require RFC 6904, implementation and >>> usage for the CaptureId header extension field. Or rather if you >>> write nothing it will by default be required if you encrypt RTCP, >>> due to RFC 7941. But, I really recommend that you are explicit on >>> this matter. It comes down to what security risks the field >>> entails. What information will it leak to a third party viewer of >>> the RTP/RTCP stream they can capture. >>> >>> Cheers >>> >>> Magnus >>> >>> Den 2017-01-18 kl. 09:33, skrev Roni Even: >>>> 2. What do we want to say about supported security profile? >>>> For example does the following directive from >>>> https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-12#section-5.5 >>>> >>>> >>>> > looks good for CLUE? >>>> >>>> >>>> >>>> “Implementations MUST implement SRTP [RFC3711 >>>> ]. Implementations MUST >>>> >>>> implement DTLS [RFC4347 ] >>>> and DTLS-SRTP [RFC5763 >>>> ][RFC5764] for >>> SRTP >>>> >>>> keying. Implementations MUST implement >>>> >>>> [I-D.ietf-tsvwg-sctp-dtls-encaps >>>> >> >>>> > D.ietf-tsvwg-sctp-dtls-encaps>]. >>>> >>>> >>>> >>>> All media channels MUST be secured via SRTP. Media traffic MUST >>>> NOT >>>> >>>> be sent over plain (unencrypted) RTP; that is, implementations >>>> MUST >>>> >>>> NOT negotiate cipher suites with NULL encryption modes. >>>> DTLS-SRTP >>>> >>>> MUST be offered for every media channel. >>>> >>>> >>>> >>>> All data channels MUST be secured via DTLS. >>>> >>>> >>>> >>>> All implementations MUST implement DTLS 1.0, with the cipher >>>> suite >>>> >>>> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA with the the P-256 curve >>>> >>>> [FIPS186 >>>> >> >>>> > FIPS186>]. >>>> The DTLS-SRTP protection profile >>>> >>>> SRTP_AES128_CM_HMAC_SHA1_80 MUST be supported for SRTP. >>>> >>>> Implementations SHOULD implement DTLS 1.2 with the >>>> >>>> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 cipher suite. >>>> >>>> Implementations MUST favor cipher suites which support PFS over >>>> non- >>>> >>>> PFS cipher suites and SHOULD favor AEAD over non-AEAD cipher >>>> suites. >>>> >>>> “ >>> >>> >>> -- >>> >>> Magnus Westerlund >>> >>> ---------------------------------------------------------------------- >>> >>> > Services, Media and Network features, Ericsson Research EAB/TXM >>> ---------------------------------------------------------------------- >>> >>> > Ericsson AB | Phone +46 10 7148287 >>> Färögatan 6 | Mobile +46 73 0949079 SE-164 80 >>> Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com >>> ---------------------------------------------------------------------- >> >>> From nobody Sat Jan 21 21:10:25 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 B6B6B1295BC for ; Sat, 21 Jan 2017 21:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 sPokM_CA2vfL for ; Sat, 21 Jan 2017 21:10:22 -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 90BBB1295A5 for ; Sat, 21 Jan 2017 21:10:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZG34066; Sun, 22 Jan 2017 05:10:19 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 22 Jan 2017 05:10:18 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Sun, 22 Jan 2017 13:10:11 +0800 From: Roni Even To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Comments on CaptureID and security Thread-Index: AQHScuZudDFZmzcLYEO2lSU6qAFVp6FD9TBA Date: Sun, 22 Jan 2017 05:10:10 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76E7AC@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD76DEFF@DGGEMM506-MBX.china.huawei.com> <5eb63eb7-0a07-cae4-cf7d-e4ff00fc7118@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD76DF3C@DGGEMM506-MBX.china.huawei.com> <74afe259-a7cd-c55b-ed4a-bea29ede012f@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] 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.0A020204.58843EBB.0151, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 98a7b41afac6edef6b4b1affb1275325 Archived-At: Subject: Re: [clue] Comments on CaptureID and security X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jan 2017 05:10:24 -0000 SGkgQ2hyaXN0aWFuLA0KSSBhbSBub3Qgc3VyZSBpZiBpdCBpcyBuZWVkZWQgZm9yIHN3aXRjaGlu ZyBidXQgaWYgaXQgZG9lcyB0aGlzIGlzIHNvbWV0aGluZyBmb3IgUEVSQyB0byBzYXkgdGhhdCBp dCBuZWVkcyB0byBiZSBzZWN1cmVkIHVzaW5nIHRoZSBob3AgYnkgaG9wIGtleQ0KUm9uaQ0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNsdWUgW21haWx0bzpjbHVlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDaHJpc3RpYW4gR3JvdmVzDQo+IFNlbnQ6INeZ 15XXncKg15UgMjAg15nXoNeV15DXqCAyMDE3IDA4OjI4DQo+IFRvOiBjbHVlQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbY2x1ZV0gQ29tbWVudHMgb24gQ2FwdHVyZUlEIGFuZCBzZWN1cml0eQ0K PiANCj4gRG8gd2UgbmVlZCB0byBjb25zaWRlciBQRVJDIHdoZW4gbWFraW5nIHRoYXQgcmVjb21t ZW5kYXRpb24/IEFuIE1ERg0KPiB3b3VsZCBuZWVkIGFjY2VzcyB0byB0aGUgQ2FwdHVyZUlEIGlu IG9yZGVyIHRvIG1ha2luZyBzd2l0Y2hpbmcgZGVjaXNpb25zIGluDQo+IENMVUUgaXMgdXNlZC4N Cj4gDQo+IFJlZ2FyZHMsIENocmlzdGlhbg0KPiANCj4gDQo+IE9uIDE4LzAxLzIwMTcgMTA6NTMg UE0sIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gWWVzLCBJIHRo aW5rIGVuY3J5cHRpbmcgdGhlIENhcHR1cmVJRCBhdm9pZHMgdGhlIG5lZ2F0aXZlIGltcGFjdHMg dGhhdA0KPiA+IGJhZCBjb25zdHJ1Y3Rpb24gY2FuIGhhdmUgdGhhdCBJIGNhbiB0aGluayBvZi4g VGh1cywgSSBzdXBwb3J0IGdvaW5nDQo+ID4gaW4gdGhhdCBkaXJlY3Rpb24uDQo+ID4NCj4gPiBX aGVuIGl0IGNvbWVzIHRvIHRoZSBzZWN1cml0eSBzb2x1dGlvbiBJIHdvdWxkIHJlY29tbWVuZCBj b3B5aW5nIHRoZQ0KPiA+IHRleHQgYW5kIHRoZW4gbWFrZSB0aGUgZWRpdHMuIFRoZXJlIGlzIGF0 IGxlYXN0IHR3byBhZGRpdGlvbnMsIHRoZQ0KPiA+IE1VU1QgZW5jcnlwdCBSVENQLCBhbmQgdGhl IE1VU1QgaW1wbGVtZW50IFJGQyA2OTA0IGFuZCB1c2UgaXQgdG8NCj4gPiBlbmNyeXB0IHRoZSBD YXB0dXJlSUQgaGVhZGVyIGV4dGVuc2lvbi4gUGxlYXNlIGJlIGV4cGxpY2l0IGFuZCBjbGVhcg0K PiA+IGluIHRoZSBDTFVFIGxldmVsIGRvY3VtZW50IG9uIHdoYXQgc2VjdXJpdHkgc29sdXRpb25z IHRoYXQgbmVlZHMgdG8gYmUNCj4gPiBpbXBsZW1lbnRlZCBhbmQgdXNlLg0KPiA+DQo+ID4gUmVh c29ucyBmb3IgY29weWluZyB0aGUgdGV4dCwgaXMgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW5jZXMg YmV0d2Vlbg0KPiA+IFJUQ1dlYiBhbmQgQ0xVRSwgYW5kIGluIGFkZGl0aW9uIEkgdGhpbmsgdGhl IGltcGxlbWVudGF0aW9uDQo+ID4gY29uc2lkZXJhdGlvbnMgYW5kIHBvdGVudGlhbCBuZWVkcyB0 byBsYXRlciByZXZpc2UgdGhlIHNwZWNpZmljYXRpb24NCj4gPiBhcmUgZGlmZmVyZW50LiBJIGFt IG5vdCBjZXJ0YWluIENMVUUgd2lsbCB3YW50IHRvIGJlIHJlcXVpcmVkIHRvDQo+ID4gZm9sbG93 IGFueSBjaGFuZ2VzIHRoYXQgUlRDV2ViIGRvZXMgaW4gdGhlIGZ1dHVyZS4NCj4gPg0KPiA+IEkg d291bGQgYWxzbyBub3RlIHRoYXQgSSB0aGluayB5b3UgbmVlZCBhdCBsZWFzdCB0byBwdXQgaW4g YSBzaG9ydA0KPiA+IHBhcmFncmFwaCBhYm91dCB0aGUgQ2FwdHVyZUlEIHZhbHVlLiBTb21ldGhp bmcgbGlrZSB0aGlzLg0KPiA+DQo+ID4gVGhlIGNvbnN0cnVjdGlvbiBvZiB0aGUgQ2FwdHVyZUlE IHZhbHVlIGlzIGltcGxlbWVudGF0aW9uIGRlcGVuZGVudA0KPiA+IGFuZCBpcyBub3QgdGlnaHRs eSByZXN0cmljdGVkLiBUaGVyZWZvcmUgdGhlcmUgZXhpc3QgYSByaXNrIHRoYXQgdGhlDQo+ID4g Q2FwdHVyZUlEIGNvbnRhaW5zIHByaXZhY3kgc2Vuc2l0aXZlIGluZm9ybWF0aW9uIG9yIG90aGVy d2lzZQ0KPiA+IHJldmVhbGluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgY29tbXVuaWNhdGlvbiBz ZXNzaW9uIHRvIHRoaXJkDQo+ID4gcGFydGllcy4gVGhlcmVmb3JlIGNvbmZpZGVudGlhbGl0eSBw cm90ZWN0aW9uIGlzIGFsd2F5cyBhcHBsaWVkIHRvDQo+ID4gYXZvaWQgdGhpcyByaXNrLg0KPiA+ DQo+ID4gQ2hlZXJzDQo+ID4NCj4gPiBNYWdudXMNCj4gPg0KPiA+IERlbiAyMDE3LTAxLTE4IGts LiAxMDo0NCwgc2tyZXYgUm9uaSBFdmVuOg0KPiA+PiBIaSwgVGhlIHRleHQgSSBhZGRlZCB0byB0 aGUgLTExIHZlcnNpb24gIlRoZSBDYXB0dXJlSUQgaXMgY3JlYXRlZCBhcw0KPiA+PiBwYXJ0IG9m IHRoZSBDTFVFIHByb3RvY29sLiAgVGhlIENhcHRJZCBTREVTIGl0ZW0gaXMgdXNlZCB0byBjb252 ZXkNCj4gPj4gdGhlIHNhbWUgQ2FwdHVyZUlEIHZhbHVlIGluIHRoZSBTREVTIGl0ZW0uICBXaGVu IHNlbmRpbmcgdGhlIFNERVMNCj4gPj4gaXRlbSB0aGUgc2VjdXJpdHkgY29uc2lkZXJ0aW9uIHNw ZWNpZWQgaW4gdGhlIHNlY3VyaXR5IHNlY3Rpb24gb2YNCj4gPj4gW1JGQzc5NDFdIGFyZSBhcHBs aWNhYmxlIGFuZCB0aGlzIFNERVMgaXRlbSBNVVNUIHVzZSBzaW1pbGFyIHNlY3VyaXR5DQo+ID4+ IGFzIHRoZSBDTFVFIHByb3RvY29sIG1lc3NhZ2VzIGNhcnJpZWQgaW4gdGhlIENMVUUgZGF0YSBj aGFubmVsLiINCj4gPj4NCj4gPj4gU2F5IHRoYXQgICIgdGhpcyBTREVTIGl0ZW0gTVVTVCB1c2Ug c2ltaWxhciBzZWN1cml0eSBhcyB0aGUgQ0xVRQ0KPiA+PiBwcm90b2NvbCBtZXNzYWdlcyBjYXJy aWVkIGluIHRoZSBDTFVFIGRhdGEgY2hhbm5lbC4iIFRoZSBDTFVFIGRhdGENCj4gPj4gY2hhbm5l bCBkb2N1bWVudA0KPiA+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1j bHVlLWRhdGFjaGFubmVsLTE0I3NlY3Rpb24tNA0KPiA+PiBwb2ludCBhdA0KPiA+PiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItZGF0YS1jaGFubmVsLTEzI3Nl Y3Rpb24NCj4gPj4gLTcNCj4gPj4gcG9pbnRpbmcgdG8NCj4gPj4gaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2ViLXNlY3VyaXR5LWFyY2gtMTANCj4gPj4NCj4gPj4g U28gd2UgY2FuIHJlZmVyZW5jZSB0aGUgcnRjd2ViIHNlY3VyaXR5IGFyY2hpdGVjdHVyZSBvciB1 c2UgdGhlIHRleHQNCj4gPj4gSSBjb3BpZWQgZnJvbSB0aGVyZSB0byBkZWZpbmUgYSBzZWN1cml0 eSBwcm9maWxlDQo+ID4+DQo+ID4+IEFzIGZvciB0aGUgc2Vjb25kIGl0ZW0gSSBhZ3JlZSB0aGF0 IGlmIHdlIGVuY3J5cHQgdGhlIGNvbnRlbnQgaW4gdGhlDQo+ID4+IENMVUUgZGF0YSBjaGFubmVs IHRoYXQgaW5jbHVkZXMgdGhlIGNhcHR1cmVJRCwgd2UgbmVlZCBhbHNvIHRvDQo+ID4+IGVuY3J5 cHQgUlRDUCB3aXRoIHRoZSBjYXB0dXJlSUQgU0RFUyBpdGVtIGFuZCBpdCBkb2VzIG5vdCBtYXR0 ZXIgaG93DQo+ID4+IHdlIGNyZWF0ZSB0aGUgY2FwdHVyZUlEIHZhbHVlLCBzbyBtYXliZSBpZiB3 ZSBtYW5kYXRlIGVuY3J5cHRpbmcgdGhlDQo+ID4+IFNERVMgaXRlbSB0aGVyZSBpcyBubyBzdHJv bmcgbmVlZCBmb3Igc3BlY2lmeWluZyBob3cgdG8gY3JlYXRlDQo+ID4+IENhcHR1cmVJRCAuIE5v dGUgdGhhdCB0aGUgQ2FwdHVyZUlEIGlzIG5vdCB1c2UgdG8gcHJvdmlkZQ0KPiA+PiBodW1hbi1y ZWFkYWJsZSB0ZXh0dWFsIGluZm9ybWF0aW9uIHdoaWNoIGlzIGluIHRoZSBkZXNjcmlwdGlvbg0K PiA+PiBhdHRyaWJ1dGUuDQo+ID4+DQo+ID4+IFJvbmkNCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tIEZyb206IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4+PiBbbWFpbHRvOm1h Z251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNvbV0gU2VudDog15nXldedINeTIDE4INeZ16DXldeQ 16gNCj4gMjAxNw0KPiA+Pj4gMTA6NDUgVG86IFJvbmkgRXZlbjsgY2x1ZUBpZXRmLm9yZyBDYzog Sm9uYXRoYW4gTGVubm94IFN1YmplY3Q6IFJlOg0KPiA+Pj4gQ29tbWVudHMgb24gQ2FwdHVyZUlE IGFuZCBzZWN1cml0eQ0KPiA+Pj4NCj4gPj4+IEhpLA0KPiA+Pj4NCj4gPj4+IEEgY29tbWVudCBh Ym91dCB0aGUgYmVsb3cuIEkgaGF2ZSBhbiBpc3N1ZSByYWlzZWQgYWdhaW5zdCB0aGUgYmVsb3cN Cj4gPj4+IHF1b3RlZCB0ZXh0IGZyb20gdGhlIHJ0Y3dlYi1zZWN1cml0eS1hcmNoaXRlY3R1cmUg aW4gdGhlIFJUQ1dlYiBXRywNCj4gPj4+IGFzIGl0IGZhaWxzIHRvIHNwZWNpZnkgaWYgUlRDUCBl bmNyeXB0aW9uIGlzIG1hbmRhdG9yeSB0byB1c2Ugb3INCj4gPj4+IG5vdC4gVGhlcmUgYXJlIHBy b3RlY3Rpb24gcHJvZmlsZXMgdGhhdCBvbmx5IGhhdmUgY29uZmlkZW50aWFsaXR5DQo+ID4+PiBw cm90ZWN0aW9uIGZvciBSVFAsIGFuZCBub3QgZm9yIFJUQ1AuIEkgd291bGQgcmVjb21tZW5kIHJl cXVpcmluZw0KPiA+Pj4gY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gYWxzbyBvZiBSVENQLg0K PiA+Pj4NCj4gPj4+IFRoZSBzZWNvbmQgbm90ZSBvbiB0aGUgYmVsb3cgaXMgdGhhdCBkZXBlbmRp bmcgb24gdGhlIG91dGNvbWUgb2YgdGhlDQo+ID4+PiBzZWN1cml0eSByZXF1aXJlbWVudHMgZm9y IHRoZSBDYXB0dXJlSUQgUlRQIGhlYWRlciBleHRlbnNpb24sIHlvdQ0KPiA+Pj4gbWlnaHQgaW4g YWRkaXRpb24gaGF2ZSB0byByZXF1aXJlIFJGQyA2OTA0LCBpbXBsZW1lbnRhdGlvbiBhbmQgdXNh Z2UNCj4gPj4+IGZvciB0aGUgQ2FwdHVyZUlkIGhlYWRlciBleHRlbnNpb24gZmllbGQuIE9yIHJh dGhlciBpZiB5b3Ugd3JpdGUNCj4gPj4+IG5vdGhpbmcgaXQgd2lsbCBieSBkZWZhdWx0IGJlIHJl cXVpcmVkIGlmIHlvdSBlbmNyeXB0IFJUQ1AsIGR1ZSB0bw0KPiA+Pj4gUkZDIDc5NDEuIEJ1dCwg SSByZWFsbHkgcmVjb21tZW5kIHRoYXQgeW91IGFyZSBleHBsaWNpdCBvbiB0aGlzDQo+ID4+PiBt YXR0ZXIuIEl0IGNvbWVzIGRvd24gdG8gd2hhdCBzZWN1cml0eSByaXNrcyB0aGUgZmllbGQgZW50 YWlscy4gV2hhdA0KPiA+Pj4gaW5mb3JtYXRpb24gd2lsbCBpdCBsZWFrIHRvIGEgdGhpcmQgcGFy dHkgdmlld2VyIG9mIHRoZSBSVFAvUlRDUA0KPiA+Pj4gc3RyZWFtIHRoZXkgY2FuIGNhcHR1cmUu DQo+ID4+Pg0KPiA+Pj4gQ2hlZXJzDQo+ID4+Pg0KPiA+Pj4gTWFnbnVzDQo+ID4+Pg0KPiA+Pj4g RGVuIDIwMTctMDEtMTgga2wuIDA5OjMzLCBza3JldiBSb25pIEV2ZW46DQo+ID4+Pj4gMi4gICAg ICAgV2hhdCBkbyB3ZSB3YW50IHRvIHNheSBhYm91dCBzdXBwb3J0ZWQgc2VjdXJpdHkgcHJvZmls ZT8NCj4gPj4+PiBGb3IgZXhhbXBsZSBkb2VzIHRoZSBmb2xsb3dpbmcgZGlyZWN0aXZlIGZyb20N Cj4gPj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2Vj dXJpdHktYXJjaC0xMiNzZWN0DQo+ID4+Pj4gaW9uLTUuNQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pg0KPiA+IGxvb2tzIGdvb2QgZm9yIENMVUU/DQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+ Pj4g4oCcSW1wbGVtZW50YXRpb25zIE1VU1QgaW1wbGVtZW50IFNSVFAgW1JGQzM3MTENCj4gPj4+ PiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM3MTE+XS4gSW1wbGVtZW50YXRpb25z IE1VU1QNCj4gPj4+Pg0KPiA+Pj4+IGltcGxlbWVudCBEVExTIFtSRkM0MzQ3IDxodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNDM0Nz5dDQo+ID4+Pj4gYW5kIERUTFMtU1JUUCBbUkZDNTc2 Mw0KPiA+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTc2Mz5dW1JGQzU3NjRd IGZvcg0KPiA+Pj4gU1JUUA0KPiA+Pj4+DQo+ID4+Pj4ga2V5aW5nLiAgSW1wbGVtZW50YXRpb25z IE1VU1QgaW1wbGVtZW50DQo+ID4+Pj4NCj4gPj4+PiBbSS1ELmlldGYtdHN2d2ctc2N0cC1kdGxz LWVuY2Fwcw0KPiA+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y dGN3ZWItc2VjdXJpdHktYXJjaC0xMiNyZWYNCj4gPj4+PiAtSS0NCj4gPj4+DQo+ID4+Pj4NCj4g PiBELmlldGYtdHN2d2ctc2N0cC1kdGxzLWVuY2Fwcz5dLg0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+ Pg0KPiA+Pj4+IEFsbCBtZWRpYSBjaGFubmVscyBNVVNUIGJlIHNlY3VyZWQgdmlhIFNSVFAuICBN ZWRpYSB0cmFmZmljIE1VU1QNCj4gPj4+PiBOT1QNCj4gPj4+Pg0KPiA+Pj4+IGJlIHNlbnQgb3Zl ciBwbGFpbiAodW5lbmNyeXB0ZWQpIFJUUDsgdGhhdCBpcywgaW1wbGVtZW50YXRpb25zIE1VU1QN Cj4gPj4+Pg0KPiA+Pj4+IE5PVCBuZWdvdGlhdGUgY2lwaGVyIHN1aXRlcyB3aXRoIE5VTEwgZW5j cnlwdGlvbiBtb2Rlcy4NCj4gPj4+PiBEVExTLVNSVFANCj4gPj4+Pg0KPiA+Pj4+IE1VU1QgYmUg b2ZmZXJlZCBmb3IgZXZlcnkgbWVkaWEgY2hhbm5lbC4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4N Cj4gPj4+PiBBbGwgZGF0YSBjaGFubmVscyBNVVNUIGJlIHNlY3VyZWQgdmlhIERUTFMuDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4gQWxsIGltcGxlbWVudGF0aW9ucyBNVVNUIGltcGxl bWVudCBEVExTIDEuMCwgd2l0aCB0aGUgY2lwaGVyIHN1aXRlDQo+ID4+Pj4NCj4gPj4+PiBUTFNf RUNESEVfRUNEU0FfV0lUSF9BRVNfMTI4X0NCQ19TSEEgd2l0aCB0aGUgdGhlIFAtMjU2IGN1cnZl DQo+ID4+Pj4NCj4gPj4+PiBbRklQUzE4Ng0KPiA+Pj4+IDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItc2VjdXJpdHktYXJjaC0xMiNyZWYNCj4gPj4+PiAtDQo+ ID4+Pg0KPiA+Pj4+DQo+ID4gRklQUzE4Nj5dLg0KPiA+Pj4+IFRoZSBEVExTLVNSVFAgcHJvdGVj dGlvbiBwcm9maWxlDQo+ID4+Pj4NCj4gPj4+PiBTUlRQX0FFUzEyOF9DTV9ITUFDX1NIQTFfODAg TVVTVCBiZSBzdXBwb3J0ZWQgZm9yIFNSVFAuDQo+ID4+Pj4NCj4gPj4+PiBJbXBsZW1lbnRhdGlv bnMgU0hPVUxEIGltcGxlbWVudCBEVExTIDEuMiB3aXRoIHRoZQ0KPiA+Pj4+DQo+ID4+Pj4gVExT X0VDREhFX0VDRFNBX1dJVEhfQUVTXzEyOF9HQ01fU0hBMjU2IGNpcGhlciBzdWl0ZS4NCj4gPj4+ Pg0KPiA+Pj4+IEltcGxlbWVudGF0aW9ucyBNVVNUIGZhdm9yIGNpcGhlciBzdWl0ZXMgd2hpY2gg c3VwcG9ydCBQRlMgb3Zlcg0KPiA+Pj4+IG5vbi0NCj4gPj4+Pg0KPiA+Pj4+IFBGUyBjaXBoZXIg c3VpdGVzIGFuZCBTSE9VTEQgZmF2b3IgQUVBRCBvdmVyIG5vbi1BRUFEIGNpcGhlcg0KPiA+Pj4+ IHN1aXRlcy4NCj4gPj4+Pg0KPiA+Pj4+IOKAnA0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+ Pj4NCj4gPj4+IE1hZ251cyBXZXN0ZXJsdW5kDQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4g Pj4+IC0tDQo+ID4+Pg0KPiA+Pj4NCj4gPiBTZXJ2aWNlcywgTWVkaWEgYW5kIE5ldHdvcmsgZmVh dHVyZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVBQi9UWE0NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+ PiAtLQ0KPiA+Pj4NCj4gPj4+DQo+ID4gRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgIHwgUGhv bmUgICs0NiAxMCA3MTQ4Mjg3DQo+ID4+PiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgICB8 IE1vYmlsZSArNDYgNzMgMDk0OTA3OSBTRS0xNjQgODANCj4gPj4+IFN0b2NraG9sbSwgU3dlZGVu IHwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20NCj4gPj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4+PiAtLQ0KPiA+Pg0KPiA+Pj4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNsdWUgbWFpbGluZyBsaXN0DQo+IGNsdWVAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jbHVlDQo= From nobody Sat Jan 21 21:14:38 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 6C0681295BE; Sat, 21 Jan 2017 21:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 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, RP_MATCHES_RCVD=-3.199, 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 FJW4RCTdFefy; Sat, 21 Jan 2017 21:14:33 -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 1A2351295A5; Sat, 21 Jan 2017 21:14:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEY91156; Sun, 22 Jan 2017 05:14:30 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 22 Jan 2017 05:14:28 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.117]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Sun, 22 Jan 2017 13:14:23 +0800 From: Roni Even To: Ben Campbell Thread-Topic: Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) Thread-Index: AQHScmWg2hAk/mNDMk6pAjLV4zEeEKFD9uwA Date: Sun, 22 Jan 2017 05:14:23 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD76E7C1@DGGEMM506-MBX.china.huawei.com> References: <148477248127.2230.11179332810356559654.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD76E261@DGGEMM506-MBX.china.huawei.com> <9BC2A817-5D7F-4AA9-B737-2FB45D2D3DE6@nostrum.com> In-Reply-To: <9BC2A817-5D7F-4AA9-B737-2FB45D2D3DE6@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.201.150] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0B0205.58843FB6.00D5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.117, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 46445391d95bfe6eb28117c3942037bd Archived-At: Cc: "clue@ietf.org" , "clue-chairs@ietf.org" , "draft-ietf-clue-rtp-mapping@ietf.org" , The IESG Subject: Re: [clue] Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (with DISCUSS and COMMENT) X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 22 Jan 2017 05:14:34 -0000 Hi Ben, See inline Roni > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: =E9=E5=ED=A0=E4 19 =E9=F0=E5=E0=F8 2017 17:06 > To: Roni Even > Cc: The IESG; draft-ietf-clue-rtp-mapping@ietf.org; Paul Kyzivat; clue- > chairs@ietf.org; clue@ietf.org > Subject: Re: Ben Campbell's Discuss on draft-ietf-clue-rtp-mapping-12: (w= ith > DISCUSS and COMMENT) >=20 > Hi Roni, thanks for the response. See comments below. I removed sections > that I think are resolved. >=20 > On 19 Jan 2017, at 0:51, Roni Even wrote: >=20 > > Hi Ben, > > See inline > > Roni > > > >> --------------------------------------------------------------------- > >> - > >> DISCUSS: > >> --------------------------------------------------------------------- > >> - > >> > >> I plan to ballot "yes" for this, but there's an issue in section 9 > >> that I think needs to be fixed first: > >> > >> In the second paragraph, the draft says "CLUE endpoints MUST support > >> RTP/ SAVPF and DTLS-SRTP keying [RFC5764]." But the framework draft > >> goes further by saying that media MUST be secured, and that DTLS-SRTP > >> SHOULD be used unless the media is secured by some other mechanism. I > >> think that readers will expect the mapping spec to be authoritative > >> about that sort of thing. It's likely to be misleading to have it > >> mention the requirement to support RTP/SAVPF and DTLS-SRTP without > >> also mentioning the MUST be secured, SHOULD be used requirements. > >> This can easily be fixed by mentioning the additional requirements > >> and citing the framework. > > [Roni Even] You are right, I will use the text from the framework > > which is the correct text > >> >=20 > Thanks. I will clear the discuss now, since this is a simple enough fix. >=20 > >> > >> --------------------------------------------------------------------- > >> - > >> COMMENT: > >> --------------------------------------------------------------------- > >> - > >> > >> Substantive: > >> > >> -3: The opening paragraph mentions "Point-to-Point, as well as > >> Media-Mixing > >> mixers, Media- Switching mixers, and Selective Forwarding > >> Middleboxs." > >> The section goes on to discuss the first two, but doesn't mention the > >> last two. > > [Roni Even] There was some text in previous revision but the feedback > > from the WG was to remove it since it was just repeating text from the > > topology draft (RFC7667) >=20 > Okay. Something to the effect that "Media-switching mixers and Selective > Forwarding Middleboxes behave as described in [RFC7677]" towards the end > of the section would help balance things--but it's not critical one way o= r the > other. [Roni Even] OK >=20 > [...] >=20 > >> > >> -5, paragraph 5: > >> It would be helpful to add a sentence or two clarifying the > >> difference between an MCC that carries multiple MCs at the same time, > >> and one that switch between MCs, but only carry one at a time. > > [Roni Even] I think that it is clear, it is not carrying multiple MCs > > it "sends a composed stream of multiple MCs". This document does not > > define what is an MCC so if you do not know what is an MCC you need to > > read the framework document which is a normative reference. >=20 > Your call on this one. I am not sure that people will realize that "compo= sed > stream of multiple MCs" means one at a time. [Roni Even] I thought that using singular language "stream" and not "stream= s" means a single stream but since English is a foreign language to me I ca= n change to "one compose stream" >=20 > [...] >=20 > >> > >> -9, 2nd paragraph: Please don't use 2119 to describe requirements > >> from other documents, unless in a direct quote (in quotation marks.) > > [Roni Even] I am not sure what to do, I assume it is about "CLUE > > endpoints MUST support RTP/ > > SAVPF and DTLS-SRTP keying [RFC5764].". We want to say that they > > MUST support SAVPF and DTLS-SRTP keying . but I think that this text > > will change based on Magnus request to provide specific security > > profile >=20 > You can always say that "[RFCXXXX] requires endpoints to..." [Roni Even] Thanks, will use your suggestion From nobody Mon Jan 23 00:57:30 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 73C1212949E; Mon, 23 Jan 2017 00:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148516184846.29574.7942980831044878338.idtracker@ietfa.amsl.com> Date: Mon, 23 Jan 2017 00:57:28 -0800 Archived-At: Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-protocol-12.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 08:57:28 -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 of the IETF. Title : CLUE protocol Authors : Roberta Presta Simon Pietro Romano Filename : draft-ietf-clue-protocol-12.txt Pages : 63 Date : 2017-01-23 Abstract: The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-clue-protocol-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-12 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 Jan 23 01:00:03 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 5212E1295D5 for ; Mon, 23 Jan 2017 01:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 S47Pe-WlujB6 for ; Mon, 23 Jan 2017 00:59:59 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBD812949E for ; Mon, 23 Jan 2017 00:59:58 -0800 (PST) X-ASG-Debug-ID: 1485161996-05f27574c6fa550001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id C3oJfHHvjow9JEmw (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 09:59:56 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v0N8xsOx002680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 09:59:55 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] Mark's WGLC comments on protocol-10 In-Reply-To: Date: Mon, 23 Jan 2017 10:00:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1D301144-1CF5-4874-AB66-7223C867011F@unina.it> References: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> To: mrducky73@outlook.com X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1485161996 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35999 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header Archived-At: Cc: clue@ietf.org Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 09:00:01 -0000 Hello Mark, please find in-line our answers to your comments. > About the clueId element - I guess my main point is I don't understand = what this is for or how to use it. As an implementer, I wouldn't know = what to do with it. As a sender, can I populate this field with any = random string? Can I send a different value for this element for every = message? If I send random values, or empty string, will it cause a = problem? As a receiver, what should I do with this element? Can I safely = ignore it? Should I check it for some type of validity, and possibly = send a nack if it is invalid? Is it permissible to display the value to = a human user? It seems to me the document isn't clear enough about how = to use this element, so my interpretation is that this clueId element is = useless because there are absolutely no rules about what to do with it. = It says the clueId is " > identifier (in the form of a >=20 > generic string) of the CP within the telepresence system". But what is = the "identifier"? I don't think this is defined anywhere. >=20 > If it is okay for an implementation to send an empty string for = clueId, and to ignore any value it receives, then can we add this = clarification to the document? If it is not okay, then can you please = add an explanation why, and what the additional rules are? In our view the clueId is similar to the =93confUserID=94 (and related = XCON-USERID) parameter we introduced in RFC6503 (CCMP) when = standardizing centralised conferencing. In that case, the specification = was much more detailed. The identifier was mentioned in the framework = (as well as in the protocol) and specified in the data model. In the = CLUE case we kept this more loose, since the only identifiers that are = mentioned in the framework document are those related to individual = encodings. As it is defined now, such an identifier can only have = application-specific semantics; yet, we believe it might be useful in a = number of different scenarios (we=92re clueIds in our prototype = telepresence architecture, for example). This said, we do not want this = to further delay the standardization process. We see two options here = (other than leaving things unchanged): i) we make the clueId optional (minOccurs=3D0) and leave the rest of the = document unchanged. In this way, those who want to rely on this piece of = information for their own implementations are allowed to do that; ii) we remove the clueId from the specification. We=92d like to gather the feeling of the WG on this and are ready to = apply any of the proposed solutions. > About "Each CP MUST be able to manage up to three (independent) = streams of sequence numbers" - okay, now I understand you are talking = about the sending side only. But this statement still isn't strictly = correct, because a CP doesn't have to be both a mediaProvider and a = mediaConsumer, so it doesn't necessarily have to manage three streams. = How about this instead, to replace the current paragraph: >=20 > "Each CP is responsible for creating and updating up to three = independent streams of sequence numbers in messages it sends: (i) one = for the messages sent in the initiation phase, (ii) one for the messages = sent as MP (if it is acting as a MP), and (iii) one for the messages = sent as MC (if it is acting as a MC).=94 Done. Thanks a lot, Simon & Roberta > Mark > From: clue on behalf of Simon Pietro Romano = > Sent: Monday, January 02, 2017 11:21 AM > To: Mark.Duckworth@polycom.com > Cc: clue@ietf.org > Subject: Re: [clue] Mark's WGLC comments on protocol-10 > =20 > Dear Mark, >=20 > thanks a lot for your review. Please find in-line our answers. >=20 > Cheers, >=20 > Simon & Roberta >=20 >> 4. "three main communication layers" - I agree with Christian these = are phases, not layers. >=20 > Fixed. >=20 >> 5. clueId - it still isn't clear to me what is the use of this = element. It seems wasteful to include this element in every message. >> Simon previously said "In my view, it is just a name for the CP". But = what is it used for? Can we delete clueId if it has no purpose? >> Or if it has a purpose and is meant to be static, can we make it part = of the options message exchange rather than every message? And explain = what the purpose is? >=20 > If we just look at the CLUE protocol level dialogue, the clueId = provides a means for properly identifying the interacting parties. What = is wrong with this? >=20 >> "Each CP MUST be able to manage up to three (independent) streams of >> sequence numbers" - sounds to me like it is really six streams of = sequence numbers. Because each of the three "streams" described actually = has separate independent sequence numbers for each direction. >> - initiation phase send >> - initiation phase receive >> - MP send >> - MP receive >> - MC send >> - MC receive >> It also is misleading because it is not required to be both an MC and = an MP, so possibly only one of those applies. So it could be either four = streams of sequence numbers, or six streams. >=20 > Got it. When we say =93manage=94 we actually mean =93being responsible = for the creation and the update=94. So, we were looking at the three = roles mentioned above, but by focusing just on the =93sending=94 = perspective. Would you like us to reword that sentence?=20 >=20 >> 5.2 "copied in the the" remove a =93the" >=20 > Done. >=20 >> 5.3 "an MP may send new ADV messages to replace the previously = advertised options" - this could be misunderstood as relating to the = options messages in the initiation phase. How about "an MP may send new = ADV messages to replace the previous advertisement=94 >=20 > Done. >=20 >> Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the = timeout and retry relates to the transport (e.g. SCTP) rather than = application level timers/counters? I'm a bit confused about the = descriptions in the draft as we have a reliable transport" >> I thought the timeout and retry stuff was application level, not to = account for transport errors but rather to account for application = behavior such as an application not responding for whatever reason. So I = think it does need to be clarified if Christian and I interpreted it = differently. >=20 > This is inline with our interpretation. See also our answer to = Christian=92s point in the related e-mail. >=20 >=20 >> Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is = unsuccessful (bad syntax, missing XML elements, etc.), and the number of = times this has happened is under the retry treshold," I don't understand = why the retry threshold comes in here? Wouldn't the MC simply send a = NACK is there's an error. It wouldn't wait for multiple instances of the = erroneous message." >> My understanding is it gives the MP an opportunity to send a = different advertisement after it receives a nack. It doesn't have to = send another copy of the same advertisement. >=20 > Agreed. As per above, see also our answer to Christian=92s point in = the related e-mail. >=20 >> 10.1 simple ADV - I suggest updating this to be consistent with the = sample XML file in the data model. We already fixed some problems with = that sample XML. I see problems, probably the same ones we already = fixed, here in the simple ADV example. For example captureID AC0 is a = video capture but the description says "main audio from the room". And = on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I = think we've done a good review of the XML in the data model, so let's = just use that as much as possible to avoid new mistakes in this = document. >=20 > Done. Thank you for pointing this out. >=20 >> 10.2 - same comment, I suggest using the already reviewed XML from = the data model, and show it here in the protocol message envelope. >=20 > Done. >=20 >=20 >> =20 >> Mark >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jan 23 01:00:51 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 B5C1C1295D5 for ; Mon, 23 Jan 2017 01:00:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, 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 VXPyCvHL9gyx for ; Mon, 23 Jan 2017 01:00:47 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A972129961 for ; Mon, 23 Jan 2017 01:00:47 -0800 (PST) X-ASG-Debug-ID: 1485162044-05f27574c2fa890001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id ZcgRGPrTFrZ0Mrxw (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 10:00:44 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [143.225.28.167] ([143.225.28.167]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v0N8xsP0002680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jan 2017 10:00:42 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1303319-D025-42CC-8203-CD8450B7E980" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] WGLC for draft-ietf-clue-protocol-10 In-Reply-To: Date: Mon, 23 Jan 2017 10:00:46 +0100 Message-Id: <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> To: Christian Groves X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1485162044 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.82 X-Barracuda-Spam-Status: No, SCORE=0.82 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE, MIME_QP_LONG_LINE, MIME_QP_LONG_LINE_2 X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35999 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 MIME_QP_LONG_LINE RAW: Quoted-printable line longer than 76 chars 0.82 MIME_QP_LONG_LINE_2 RAW: Quoted-printable line longer than 76 chars Archived-At: Cc: clue@ietf.org Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 09:00:50 -0000 --Apple-Mail=_B1303319-D025-42CC-8203-CD8450B7E980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Christian, please find in-line our answers to your comments. > ..snip >>> General: The document talks about extensions and options. Are they = different? if not should we use one term. >> The difference is indeed a subtle one. The idea should be that an = option is a predefined capability of the protocol that is not mandatory, = whereas an extension is a brand new feature one might be interested in = defining for their own purpose. Technically speaking, they look exactly = the same, as section 8 clearly illustrates. > [CNG]I think we need to separate whether something is an optional = capability or not from extending the protocol/data model. Extensions I = see are additions to the protocol. OK. We made this distinction clear, by redefining the

= --Apple-Mail=_B1303319-D025-42CC-8203-CD8450B7E980-- From nobody Mon Jan 23 09:04:42 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 DBF571295B6 for ; Mon, 23 Jan 2017 09:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 haImxBzTNRsC for ; Mon, 23 Jan 2017 09:04:39 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D711295AD for ; Mon, 23 Jan 2017 09:04:39 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-04v.sys.comcast.net with SMTP id Vi2ncXdQh9RIgVi2pcLWNy; Mon, 23 Jan 2017 17:04:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485191079; bh=aRobzzhrE+iXdLzAJHXisc7FB2xJDZwXpT/YIdcCSNo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GEqM5fKCQSBJQJNKA7VTh8JX4UP+ISqtifW98NLtMK7IrgeouVZYFBsLp1N+6NzlM kZOfINpsX71CH2F3oimPOgB1KEyOgN5i7dZZ5jdszZQ/wDqm+cbQdd2QK+AfXlK5R2 3C5cpwPUo9lg4LOkYnKwo51mV32VIA4HetQG1OzBM9xMSZUIqzj3HzYhima5MTmxPy OVCGj5fj1zihNHZT2FY6AxMlsN9JwoNhwYXM1ePTeyqxQXT1Ugy+KugM+TJ/6WdWvf 06XHEudq1KMZY1uZu7F5Lr7/jO7wThl5cWdbMUsqZZXPasF9IqA2vYekGYz07yx8to pcX6oYxmYQbLA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-06v.sys.comcast.net with SMTP id Vi2ocwm1WpJ41Vi2ocyxN6; Mon, 23 Jan 2017 17:04:39 +0000 To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> From: Paul Kyzivat Message-ID: Date: Mon, 23 Jan 2017 12:04:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfEbyDcicSkKGUCSNQnu2lV6aH9VGjLqcco2e04Br9qPA53gBQUMKhv6AgT5RLNU+WDIhIxHUCESjDMvXc+zYKs9K3udr9858VPHNgjuo2w53udw8Ddv5 kez3lMXDSXniaoNdbhTbRzhE5WdQM/HUCUC72EnZ8tOWUGBvt60OH6ny Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 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, 23 Jan 2017 17:04:41 -0000 On 1/23/17 4:00 AM, Simon Pietro Romano wrote: > We rephrased the sentence as follows: > > "Further response codes can be either defined in future versions of the > protocol (by adding them to the related IANA registry), or defined > by leveraging the extension mechanism. In any case, such new response > codes MUST NOT overwrite the ones here defined and they MUST > respect the semantics of the first code digit. > > Does this sound OK to you? I don't see how having two different mechanisms for defining new response codes can work. If a new response code is defined in an extension, and thus doesn't update the registry, then what is to prevent that code from being reused in a conflicting way? Considering that (IIUC) extensions don't need to be registered with the IETF it seems entirely possible that somebody defining a new one might not be aware of another that used the same new response code. So, ISTM that new response codes will always need to be registered with IANA, and we will thus need a suitable approval mechanism for that. Thanks, Paul From nobody Mon Jan 23 21:08:55 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 77DA3129568 for ; Mon, 23 Jan 2017 21:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 UN0MrZjuqBHJ for ; Mon, 23 Jan 2017 21:08:51 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6025126CD8 for ; Mon, 23 Jan 2017 21:08:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=udWm9JUKRDC9dx6uy+qwlVOmy7wkG8HNmffxu7vnRYg=; b=FS5GarNcvZQsSMjzJEq5Nvt9Vk 0bFayndDoGUU/vtHYzXs+mN53bTGvVVgTZlPU2yd4FdE7O29hSTpRydem9R7zPJVROQZQbD4uhr0x Md7fEbd0ag9dprCOnhqrVqtiNDYMlCeFnT0a8oKwR2xIFX1fXDdfoRVoUYd2jElx00/JTShAytPF6 yEnuPB4AMHgcBIWkmXMPqsfjb2fXh4B8chQqV+f4uuwwWePz+wiwPpwhxQxVO6ynnl1hYg6zcI8wn p08TLXZs2Hxs69CJmk8t7JsdF2X7HMUtz2QzZdv57Lo/AGyImVgosxCHJfFHGVP1vXsdfCpomK5gY q04jty0w==; Received: from ppp118-209-52-63.lns20.mel4.internode.on.net ([118.209.52.63]:49778 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cVtLc-003bLO-Ey; Tue, 24 Jan 2017 16:08:48 +1100 To: Simon Pietro Romano References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> From: Christian Groves Message-ID: <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> Date: Tue, 24 Jan 2017 16:08:45 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Cc: clue@ietf.org Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 05:08:53 -0000 Hello Simon and Roberta, Thanks for addressing the comments. Please see below. Regards, Christian ..snip > >>> Cl.5.7: It says future protocol version can introduce error codes? >>> How about options? It seems like an option could introduce a >>> specific error code. >>> Based on the discussion in section 8, a new response code might >>> indeed be added through the “extension” mechanism. Though, the >>> “cleanest” way for achieving such a task in a formal way is by adding >>> the new response code to the list of codes published in the >>> dedicated IANA registry (see section 12.4.2 fo the draft). In the >>> mentioned section, we refer to future versions of the standard. >> [CNG] By saying that error codes can be designed in future versions >> seems to preclude them being defined by extensions. (BTW 5.7 uses >> "designed", I think "defined" would be better). > > We rephrased the sentence as follows: > > "Further response codes can be either defined in future versions of the > protocol or defined > by leveraging the extension mechanism. In any case, such new response > codes MUST NOT overwrite the ones here defined and they MUST > respect the semantics of the first code digit.” > > Does this sound OK to you? [CNG] I agree with Paul in that any new response code will need to be registered by IANA. However I don't see the problem with having two mechanisms to define codes within the protocol. It should be possible to add an error code to CLUE without having to bump the version. I think if you delete "(by adding them to the related IANA registry)," and add a sentence along the lines of: "In both cases the new response code MUST be registered with IANA". > >> I agree one could simply update the IANA registry with the new code >> but I was thinking more of how an end point would know that it would >> be used. That's where registering an extension would make sense. Of >> course if you made a new version you wouldn't need an extension. > > OK. See above. > >> ..snip >>> Cl.6 para 5: "Otherwise ("channel error")…" >>> Should we add an "if" between “Otherwise” and the parenthesis? >>> Please advise on that. >> [CNG] If doesn't need to be in parentheses just "Otherwise if …" > > You’re the English master! We modified accordingly: > > "Otherwise if ("channel error"), it moves back to the IDLE state.” [CNG] You can delete the ( and ), i.e. just "Otherwise if "channel error", it... " > From nobody Mon Jan 23 21:35:53 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 6CBC112956A for ; Mon, 23 Jan 2017 21:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 ID2JwvfRjvw6 for ; Mon, 23 Jan 2017 21:35:50 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9766F126CD8 for ; Mon, 23 Jan 2017 21:35:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FeYWemLS/itjDAvUeBbbFNuEDpE5jNNQPFwjnefiQhc=; b=YPX0hQHF0URJW/YM5ajtWm0de6 jUUIEIHhf9pZ4xvI5x2+ygimJccgzviiwx9kA3HzhZFlmruBLSsAvhNicnjSAVV4z5kewcj/ZK26S MsNp27TFpT706zvWv5slbgiOCe1SCQixe+WJNOD2tVHFbLfJsffBAhqc5FLolGbp2YEUEJ2CPBv4C /OLDa05gf+WQhWnO2zrLNNWfBN61GL1DhOXSE+ZLSH6d3afo9SBi7A/ea1Qz4xnyIa6dItVp2RdFz QCVJZUsO1Wd+ytsdrqTHpHQewTFJVD5gFwg1xYfSC9fKpsk79cvamxuQuFSdARR1TQclzDQwUsKxA mbkRBR7g==; Received: from ppp118-209-52-63.lns20.mel4.internode.on.net ([118.209.52.63]:51443 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cVtlk-003drS-Id for clue@ietf.org; Tue, 24 Jan 2017 16:35:48 +1100 To: clue@ietf.org References: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> <1D301144-1CF5-4874-AB66-7223C867011F@unina.it> From: Christian Groves Message-ID: Date: Tue, 24 Jan 2017 16:35:45 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <1D301144-1CF5-4874-AB66-7223C867011F@unina.it> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 05:35:52 -0000 I'd vote for making it optional and providing some more text on what the information could actually be. Regards, Christian On 23/01/2017 8:00 PM, Simon Pietro Romano wrote: > Hello Mark, > > please find in-line our answers to your comments. > >> About the clueId element - I guess my main point is I don't understand what this is for or how to use it. As an implementer, I wouldn't know what to do with it. As a sender, can I populate this field with any random string? Can I send a different value for this element for every message? If I send random values, or empty string, will it cause a problem? As a receiver, what should I do with this element? Can I safely ignore it? Should I check it for some type of validity, and possibly send a nack if it is invalid? Is it permissible to display the value to a human user? It seems to me the document isn't clear enough about how to use this element, so my interpretation is that this clueId element is useless because there are absolutely no rules about what to do with it. It says the clueId is " >> identifier (in the form of a >> >> generic string) of the CP within the telepresence system". But what is the "identifier"? I don't think this is defined anywhere. >> >> If it is okay for an implementation to send an empty string for clueId, and to ignore any value it receives, then can we add this clarification to the document? If it is not okay, then can you please add an explanation why, and what the additional rules are? > In our view the clueId is similar to the confUserID (and related XCON-USERID) parameter we introduced in RFC6503 (CCMP) when standardizing centralised conferencing. In that case, the specification was much more detailed. The identifier was mentioned in the framework (as well as in the protocol) and specified in the data model. In the CLUE case we kept this more loose, since the only identifiers that are mentioned in the framework document are those related to individual encodings. As it is defined now, such an identifier can only have application-specific semantics; yet, we believe it might be useful in a number of different scenarios (were clueIds in our prototype telepresence architecture, for example). This said, we do not want this to further delay the standardization process. We see two options here (other than leaving things unchanged): > > i) we make the clueId optional (minOccurs=0) and leave the rest of the document unchanged. In this way, those who want to rely on this piece of information for their own implementations are allowed to do that; > ii) we remove the clueId from the specification. > > Wed like to gather the feeling of the WG on this and are ready to apply any of the proposed solutions. > > >> About "Each CP MUST be able to manage up to three (independent) streams of sequence numbers" - okay, now I understand you are talking about the sending side only. But this statement still isn't strictly correct, because a CP doesn't have to be both a mediaProvider and a mediaConsumer, so it doesn't necessarily have to manage three streams. How about this instead, to replace the current paragraph: >> >> "Each CP is responsible for creating and updating up to three independent streams of sequence numbers in messages it sends: (i) one for the messages sent in the initiation phase, (ii) one for the messages sent as MP (if it is acting as a MP), and (iii) one for the messages sent as MC (if it is acting as a MC). > Done. > > Thanks a lot, > > Simon & Roberta > >> Mark >> From: clue on behalf of Simon Pietro Romano >> Sent: Monday, January 02, 2017 11:21 AM >> To: Mark.Duckworth@polycom.com >> Cc: clue@ietf.org >> Subject: Re: [clue] Mark's WGLC comments on protocol-10 >> >> Dear Mark, >> >> thanks a lot for your review. Please find in-line our answers. >> >> Cheers, >> >> Simon & Roberta >> >>> 4. "three main communication layers" - I agree with Christian these are phases, not layers. >> Fixed. >> >>> 5. clueId - it still isn't clear to me what is the use of this element. It seems wasteful to include this element in every message. >>> Simon previously said "In my view, it is just a name for the CP". But what is it used for? Can we delete clueId if it has no purpose? >>> Or if it has a purpose and is meant to be static, can we make it part of the options message exchange rather than every message? And explain what the purpose is? >> If we just look at the CLUE protocol level dialogue, the clueId provides a means for properly identifying the interacting parties. What is wrong with this? >> >>> "Each CP MUST be able to manage up to three (independent) streams of >>> sequence numbers" - sounds to me like it is really six streams of sequence numbers. Because each of the three "streams" described actually has separate independent sequence numbers for each direction. >>> - initiation phase send >>> - initiation phase receive >>> - MP send >>> - MP receive >>> - MC send >>> - MC receive >>> It also is misleading because it is not required to be both an MC and an MP, so possibly only one of those applies. So it could be either four streams of sequence numbers, or six streams. >> Got it. When we say manage we actually mean being responsible for the creation and the update. So, we were looking at the three roles mentioned above, but by focusing just on the sending perspective. Would you like us to reword that sentence? >> >>> 5.2 "copied in the the" remove a the" >> Done. >> >>> 5.3 "an MP may send new ADV messages to replace the previously advertised options" - this could be misunderstood as relating to the options messages in the initiation phase. How about "an MP may send new ADV messages to replace the previous advertisement >> Done. >> >>> Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout and retry relates to the transport (e.g. SCTP) rather than application level timers/counters? I'm a bit confused about the descriptions in the draft as we have a reliable transport" >>> I thought the timeout and retry stuff was application level, not to account for transport errors but rather to account for application behavior such as an application not responding for whatever reason. So I think it does need to be clarified if Christian and I interpreted it differently. >> This is inline with our interpretation. See also our answer to Christians point in the related e-mail. >> >> >>> Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), and the number of times this has happened is under the retry treshold," I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multiple instances of the erroneous message." >>> My understanding is it gives the MP an opportunity to send a different advertisement after it receives a nack. It doesn't have to send another copy of the same advertisement. >> Agreed. As per above, see also our answer to Christians point in the related e-mail. >> >>> 10.1 simple ADV - I suggest updating this to be consistent with the sample XML file in the data model. We already fixed some problems with that sample XML. I see problems, probably the same ones we already fixed, here in the simple ADV example. For example captureID AC0 is a video capture but the description says "main audio from the room". And on page 36 sceneView SE3 and SE4 are the same, so that is a mistake. I think we've done a good review of the XML in the data model, so let's just use that as much as possible to avoid new mistakes in this document. >> Done. Thank you for pointing this out. >> >>> 10.2 - same comment, I suggest using the already reviewed XML from the data model, and show it here in the protocol message envelope. >> Done. >> >> >>> >>> Mark >>> _______________________________________________ >>> 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 > From nobody Tue Jan 24 08:11:19 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 B2C3812962B for ; Tue, 24 Jan 2017 08:11:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 7rV4r53wGHQJ for ; Tue, 24 Jan 2017 08:11:17 -0800 (PST) Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 152D8129617 for ; Tue, 24 Jan 2017 08:10:58 -0800 (PST) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with SMTP id W3gKcVs33IMkuW3gOcBolP; Tue, 24 Jan 2017 16:10:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485274256; bh=rSGtfFjzpKe+wn0V92YwwZMf5h+hHw8EjUKZdIqPRMY=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Q0lP1By42MFwNexqy+b+YRwlp8687b26pEHVyc1/RkHerkzht/r5zRQIWaK32omNJ UCq3QX51as+6XHent8bosoRioxa7sqwo76hBWo2u2MIx+nDUjXnciSvv/QBqavQ+o8 h1qLbtltA1QDPkQchWBMhU2bLnI8ojc9mwHHRmN/Y8l9UOwMCzS2qpOOPIcBQ6b/eq hcIjvVsTxpYgceGwd1UyU95eDuz90YgveFEXhRs7Zhpvol3Ip34u0ZYyl31fQ1Unuu s4kbUdwAQ0r+xWYWo59WyZ30MgK8Dj40j7dIzGjaEFcm5c3axDaX44aJ81kzIT79GN 01HrXsWPc2pSw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-06v.sys.comcast.net with SMTP id W3gNc1UNRpJ41W3gOc19mK; Tue, 24 Jan 2017 16:10:56 +0000 To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> From: Paul Kyzivat Message-ID: <6dc934ae-0485-8eca-b8c8-db887a82f50e@comcast.net> Date: Tue, 24 Jan 2017 11:10:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHk3FUJEDm8YzVE9mYXO5dl8xkoyffkDcGJ7e7U9MstE7JFrZFXA1t7PcRlX8wiob3Jg9UuowfI3VMc3heZLKF++fZkSSDmmQa+rUanbmZEBm4AFPlsb w7xWMOgi0s2fS5A4KqGOa2zdKtcRvm1SxcGu9/0xtEyvhu5mJdZZxCeM Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:11:19 -0000 On 1/24/17 12:08 AM, Christian Groves wrote: >> We rephrased the sentence as follows: >> >> "Further response codes can be either defined in future versions of the >> protocol or defined >> by leveraging the extension mechanism. In any case, such new response >> codes MUST NOT overwrite the ones here defined and they MUST >> respect the semantics of the first code digit.” >> >> Does this sound OK to you? > [CNG] I agree with Paul in that any new response code will need to be > registered by IANA. However I don't see the problem with having two > mechanisms to define codes within the protocol. It should be possible to > add an error code to CLUE without having to bump the version. I think if > you delete "(by adding them to the related IANA registry)," and add a > sentence along the lines of: > "In both cases the new response code MUST be registered with IANA". In principle that would work. But that leaves the issue of what policy to use for the registry. A new version of the protocol will be standards track, which is sufficient to control the registry. But IIUC anybody can define an extension. I doubt we would want to make the registry FCFS because the codes are a limited resource. For simplicity in the interest of getting this done I would be satisfied with requiring a new version to define a new response code. Thanks, Paul From nobody Tue Jan 24 08:36:24 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 961F21295E3 for ; Tue, 24 Jan 2017 08:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.769 X-Spam-Level: X-Spam-Status: No, score=-1.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 TRA1UQ9f2u6M for ; Tue, 24 Jan 2017 08:36:20 -0800 (PST) Received: from BAY004-OMC4S14.hotmail.com (bay004-omc4s14.hotmail.com [65.54.190.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6412D1295A6 for ; Tue, 24 Jan 2017 08:36:20 -0800 (PST) Received: from NAM04-CO1-obe.outbound.protection.outlook.com ([65.54.190.199]) by BAY004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 24 Jan 2017 08:36:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QM3SbILRR25UmTYxrrzkaHutUIqth5ghC1Z+efOGLjU=; b=Yrju5sY1mV0Lqx+wCVRt6vg7mMx49ErUIwH1Jft0foTuJUQTWolZ9Y2X/UKek7JfUAYODLNGrQC1YqxUF4pLbupFCaguEUnzKF2v+l7PReagXcjtRJDjqgXlRjGL1k0FIgCw0M+uXl/ea7Y5mhdbz55wzFiIBZyD+htUTsj66NR7Sji2sVqxrMpnEf4IIK+2QeZ1b6oPoIX9/Y3Y3k2ZHelW3ZjncCHZBgL4pc+O47iVxqhw4qqwRmRVM7eURkLFo4joG6xDK+NCr2l0ftfZHP+Oy/K1nMqgVCVkWChg9KDD4yLDrhSDwvKuUDWR29X0aP1odnrIQX9Wh3DVn+68Nw== Received: from CO1NAM04FT037.eop-NAM04.prod.protection.outlook.com (10.152.90.54) by CO1NAM04HT043.eop-NAM04.prod.protection.outlook.com (10.152.90.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8; Tue, 24 Jan 2017 16:36:18 +0000 Received: from BLUPR06MB196.namprd06.prod.outlook.com (10.152.90.53) by CO1NAM04FT037.mail.protection.outlook.com (10.152.90.254) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.8 via Frontend Transport; Tue, 24 Jan 2017 16:36:18 +0000 Received: from BLUPR06MB196.namprd06.prod.outlook.com ([169.254.6.5]) by BLUPR06MB196.namprd06.prod.outlook.com ([169.254.6.5]) with mapi id 15.01.0860.021; Tue, 24 Jan 2017 16:36:17 +0000 From: Mark Duckworth To: Christian Groves , "clue@ietf.org" Thread-Topic: [clue] Mark's WGLC comments on protocol-10 Thread-Index: AQHSZRRKixNb1xXFgk6cb7meUSaXBqEqZS6dgBt+0ACAAVlEgIAAuIuR Date: Tue, 24 Jan 2017 16:36:17 +0000 Message-ID: References: <54CC7438-AB52-45A5-A9B9-BB23525F9C07@unina.it> <1D301144-1CF5-4874-AB66-7223C867011F@unina.it>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nteczone.com; dkim=none (message not signed) header.d=none;nteczone.com; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:0298EE3665510906A08E32C6A1C5477032E9E62846EB75DB690ED8A6ABB7D7C9; UpperCasedChecksum:20564D3713CC7D2233359EF2C8EB450905BB5D560C64095B1E39A1262CEF6E03; SizeAsReceived:7931; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [d3jI21zWuh8+7cY2HKG8G/AIVHhcM0W4] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; CO1NAM04HT043; 7:CgTO7HIi8ND1nP1OV2bYfrurQ3oTv+OvMyOxjl1N+QJ6zPmlNif2Bz2Ag0ZZRNTOcYPN0Q+1rCwJ7f9Jzrlhrz7H25yJMJ3YydwMeyf35mhq1Bqwa2SUo+zWbcMyQw6crgWMyYaKpfX1T7QXAzfLTzBLJ2zYqGTGdsQlVF0NO0v19xEjPpbeQQf7zsvmNUiOfGfDu47aldaQ4AxBDiS+w6BLWiFwIWxXmz5VcxZXhHHtwnSBX15fb+a/2k7pXIPcc1mOpkGuA9irehl5EaBJSK3jNBQMvVoSYb7stue3jhL7chxI4+DS42VqADMNwQF/OeE8wuvlmCr6BvFhWvMtTb8rIG99USRIHJB/IH2PYZ3dAEJgqM+Dgx0QVcCUlyU+JpvmgbT4RZ7zoMgfcjUy33hVoj908evBDW8m4NJax5yCWfh6xuLA6vDSLU13VM7rrSjKgcqO0kGEYerl2va1kg== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900005); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1NAM04HT043; H:BLUPR06MB196.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: bb8a4993-ff99-4fb1-2db1-08d444771eab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506344)(1603103113)(1601125047)(1603101340)(1701031023); SRVR:CO1NAM04HT043; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(444112120)(432015012)(82015046); SRVR:CO1NAM04HT043; BCL:0; PCL:0; RULEID:; SRVR:CO1NAM04HT043; x-forefront-prvs: 0197AFBD92 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR06MB19631DC61791F1A2E6E1FB1A7750BLUPR06MB196namprd_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2017 16:36:17.0574 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT043 X-OriginalArrivalTime: 24 Jan 2017 16:36:20.0248 (UTC) FILETIME=[FDFEF180:01D2765F] Archived-At: Subject: Re: [clue] Mark's WGLC comments on protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 16:36:22 -0000 --_000_BLUPR06MB19631DC61791F1A2E6E1FB1A7750BLUPR06MB196namprd_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable That's fine with me, too. Mark -------- Original message -------- From: Christian Groves Date:01/24/2017 00:35 (GMT-05:00) To: clue@ietf.org Subject: Re: [clue] Mark's WGLC comments on protocol-10 I'd vote for making it optional and providing some more text on what the information could actually be. Regards, Christian On 23/01/2017 8:00 PM, Simon Pietro Romano wrote: > Hello Mark, > > please find in-line our answers to your comments. > >> About the clueId element - I guess my main point is I don't understand w= hat this is for or how to use it. As an implementer, I wouldn't know what t= o do with it. As a sender, can I populate this field with any random string= ? Can I send a different value for this element for every message? If I sen= d random values, or empty string, will it cause a problem? As a receiver, w= hat should I do with this element? Can I safely ignore it? Should I check i= t for some type of validity, and possibly send a nack if it is invalid? Is = it permissible to display the value to a human user? It seems to me the doc= ument isn't clear enough about how to use this element, so my interpretatio= n is that this clueId element is useless because there are absolutely no ru= les about what to do with it. It says the clueId is " >> identifier (in the form of a >> >> generic string) of the CP within the telepresence system". But what is t= he "identifier"? I don't think this is defined anywhere. >> >> If it is okay for an implementation to send an empty string for clueId, = and to ignore any value it receives, then can we add this clarification to = the document? If it is not okay, then can you please add an explanation why= , and what the additional rules are? > In our view the clueId is similar to the =93confUserID=94 (and related XC= ON-USERID) parameter we introduced in RFC6503 (CCMP) when standardizing cen= tralised conferencing. In that case, the specification was much more detail= ed. The identifier was mentioned in the framework (as well as in the protoc= ol) and specified in the data model. In the CLUE case we kept this more loo= se, since the only identifiers that are mentioned in the framework document= are those related to individual encodings. As it is defined now, such an i= dentifier can only have application-specific semantics; yet, we believe it = might be useful in a number of different scenarios (we=92re clueIds in our = prototype telepresence architecture, for example). This said, we do not wan= t this to further delay the standardization process. We see two options her= e (other than leaving things unchanged): > > i) we make the clueId optional (minOccurs=3D0) and leave the rest of the = document unchanged. In this way, those who want to rely on this piece of in= formation for their own implementations are allowed to do that; > ii) we remove the clueId from the specification. > > We=92d like to gather the feeling of the WG on this and are ready to appl= y any of the proposed solutions. > > >> About "Each CP MUST be able to manage up to three (independent) streams = of sequence numbers" - okay, now I understand you are talking about the sen= ding side only. But this statement still isn't strictly correct, because a = CP doesn't have to be both a mediaProvider and a mediaConsumer, so it doesn= 't necessarily have to manage three streams. How about this instead, to rep= lace the current paragraph: >> >> "Each CP is responsible for creating and updating up to three independen= t streams of sequence numbers in messages it sends: (i) one for the message= s sent in the initiation phase, (ii) one for the messages sent as MP (if it= is acting as a MP), and (iii) one for the messages sent as MC (if it is ac= ting as a MC).=94 > Done. > > Thanks a lot, > > Simon & Roberta > >> Mark >> From: clue on behalf of Simon Pietro Romano >> Sent: Monday, January 02, 2017 11:21 AM >> To: Mark.Duckworth@polycom.com >> Cc: clue@ietf.org >> Subject: Re: [clue] Mark's WGLC comments on protocol-10 >> >> Dear Mark, >> >> thanks a lot for your review. Please find in-line our answers. >> >> Cheers, >> >> Simon & Roberta >> >>> 4. "three main communication layers" - I agree with Christian these are= phases, not layers. >> Fixed. >> >>> 5. clueId - it still isn't clear to me what is the use of this elemen= t. It seems wasteful to include this element in every message. >>> Simon previously said "In my view, it is just a name for the CP". But w= hat is it used for? Can we delete clueId if it has no purpose? >>> Or if it has a purpose and is meant to be static, can we make it part o= f the options message exchange rather than every message? And explain what = the purpose is? >> If we just look at the CLUE protocol level dialogue, the clueId provides= a means for properly identifying the interacting parties. What is wrong wi= th this? >> >>> "Each CP MUST be able to manage up to three (independent) streams of >>> sequence numbers" - sounds to me like it is really six streams of seque= nce numbers. Because each of the three "streams" described actually has sep= arate independent sequence numbers for each direction. >>> - initiation phase send >>> - initiation phase receive >>> - MP send >>> - MP receive >>> - MC send >>> - MC receive >>> It also is misleading because it is not required to be both an MC and a= n MP, so possibly only one of those applies. So it could be either four str= eams of sequence numbers, or six streams. >> Got it. When we say =93manage=94 we actually mean =93being responsible f= or the creation and the update=94. So, we were looking at the three roles m= entioned above, but by focusing just on the =93sending=94 perspective. Woul= d you like us to reword that sentence? >> >>> 5.2 "copied in the the" remove a =93the" >> Done. >> >>> 5.3 "an MP may send new ADV messages to replace the previously advert= ised options" - this could be misunderstood as relating to the options mess= ages in the initiation phase. How about "an MP may send new ADV messages to= replace the previous advertisement=94 >> Done. >> >>> Christian wrote: "Cl.6.1&6.2: Do we need to indicate that the timeout= and retry relates to the transport (e.g. SCTP) rather than application lev= el timers/counters? I'm a bit confused about the descriptions in the draft = as we have a reliable transport" >>> I thought the timeout and retry stuff was application level, not to acc= ount for transport errors but rather to account for application behavior su= ch as an application not responding for whatever reason. So I think it does= need to be clarified if Christian and I interpreted it differently. >> This is inline with our interpretation. See also our answer to Christian= =92s point in the related e-mail. >> >> >>> Christian wrote: "Cl.6.2 para 3: "If the ADV elaboration is unsuccess= ful (bad syntax, missing XML elements, etc.), and the number of times this = has happened is under the retry treshold," I don't understand why the retry= threshold comes in here? Wouldn't the MC simply send a NACK is there's an = error. It wouldn't wait for multiple instances of the erroneous message." >>> My understanding is it gives the MP an opportunity to send a different = advertisement after it receives a nack. It doesn't have to send another cop= y of the same advertisement. >> Agreed. As per above, see also our answer to Christian=92s point in the = related e-mail. >> >>> 10.1 simple ADV - I suggest updating this to be consistent with the sam= ple XML file in the data model. We already fixed some problems with that sa= mple XML. I see problems, probably the same ones we already fixed, here in = the simple ADV example. For example captureID AC0 is a video capture but th= e description says "main audio from the room". And on page 36 sceneView SE3= and SE4 are the same, so that is a mistake. I think we've done a good revi= ew of the XML in the data model, so let's just use that as much as possible= to avoid new mistakes in this document. >> Done. Thank you for pointing this out. >> >>> 10.2 - same comment, I suggest using the already reviewed XML from th= e data model, and show it here in the protocol message envelope. >> Done. >> >> >>> >>> Mark >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_BLUPR06MB19631DC61791F1A2E6E1FB1A7750BLUPR06MB196namprd_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
That's fine with me, too.
Mark


-------- Original message --------
From: Christian Groves <Christian.Groves@nteczone.com>
Date:01/24/2017 00:35 (GMT-05:00)
To: clue@ietf.org
Subject: Re: [clue] Mark's WGLC comments on protocol-10

I'd vote for making it optional and providing some= more text on what the
information could actually be.

Regards, Christian


On 23/01/2017 8:00 PM, Simon Pietro Romano wrote:
> Hello Mark,
>
> please find in-line our answers to your comments.
>
>> About the clueId element - I guess my main point is I don't unders= tand what this is for or how to use it. As an implementer, I wouldn't know = what to do with it. As a sender, can I populate this field with any random = string? Can I send a different value for this element for every message? If I send random values, or empty string, = will it cause a problem? As a receiver, what should I do with this element?= Can I safely ignore it? Should I check it for some type of validity, and p= ossibly send a nack if it is invalid? Is it permissible to display the value to a human user? It seems to me the= document isn't clear enough about how to use this element, so my interpret= ation is that this clueId element is useless because there are absolutely n= o rules about what to do with it. It says the clueId is "
>> identifier (in the form of a
>>
>> generic string) of the CP within the telepresence system". Bu= t what is the "identifier"? I don't think this is defined anywher= e.
>>
>> If it is okay for an implementation to send an empty string for cl= ueId, and to ignore any value it receives, then can we add this clarificati= on to the document? If it is not okay, then can you please add an explanati= on why, and what the additional rules are?
> In our view the clueId is similar to the =93confUserID=94 (and related= XCON-USERID) parameter we introduced in RFC6503 (CCMP) when standardizing = centralised conferencing. In that case, the specification was much more det= ailed. The identifier was mentioned in the framework (as well as in the protocol) and specified in the data model= . In the CLUE case we kept this more loose, since the only identifiers that= are mentioned in the framework document are those related to individual en= codings. As it is defined now, such an identifier can only have application-specific semantics; yet, we believ= e it might be useful in a number of different scenarios (we=92re clueIds in= our prototype telepresence architecture, for example). This said, we do no= t want this to further delay the standardization process. We see two options here (other than leaving things unchanged): >
> i) we make the clueId optional (minOccurs=3D0) and leave the rest of t= he document unchanged. In this way, those who want to rely on this piece of= information for their own implementations are allowed to do that;
> ii) we remove the clueId from the specification.
>
> We=92d like to gather the feeling of the WG on this and are ready to a= pply any of the proposed solutions.
>
>
>> About "Each CP MUST be able to manage up to three (independen= t) streams of sequence numbers" - okay, now I understand you are talki= ng about the sending side only. But this statement still isn't strictly cor= rect, because a CP doesn't have to be both a mediaProvider and a mediaConsumer, so it doesn't necessarily have to manage three stream= s. How about this instead, to replace the current paragraph:
>>
>> "Each CP is responsible for creating and updating up to three= independent streams of sequence numbers in messages it sends: (i) one for = the messages sent in the initiation phase, (ii) one for the messages sent a= s MP (if it is acting as a MP), and (iii) one for the messages sent as MC (if it is acting as a MC).=94
> Done.
>
> Thanks a lot,
>
> Simon & Roberta
>
>> Mark
>> From: clue <clue-bounces@ietf.org> on behalf of Simon Pietro= Romano <spromano@unina.it>
>> Sent: Monday, January 02, 2017 11:21 AM
>> To: Mark.Duckworth@polycom.com
>> Cc: clue@ietf.org
>> Subject: Re: [clue] Mark's WGLC comments on protocol-10
>>  
>> Dear Mark,
>>
>> thanks a lot for your review. Please find in-line our answers.
>>
>> Cheers,
>>
>> Simon & Roberta
>>
>>> 4. "three main communication layers" - I agree with = Christian these are phases, not layers.
>> Fixed.
>>
>>>   5. clueId - it still isn't clear to me what is the= use of this element. It seems wasteful to include this element in every me= ssage.
>>> Simon previously said "In my view, it is just a name for = the CP". But what is it used for? Can we delete clueId if it has no pu= rpose?
>>> Or if it has a purpose and is meant to be static, can we make = it part of the options message exchange rather than every message? And expl= ain what the purpose is?
>> If we just look at the CLUE protocol level dialogue, the clueId pr= ovides a means for properly identifying the interacting parties. What is wr= ong with this?
>>
>>>   "Each CP MUST be able to manage up to three (= independent) streams of
>>> sequence numbers" - sounds to me like it is really six st= reams of sequence numbers. Because each of the three "streams" de= scribed actually has separate independent sequence numbers for each directi= on.
>>> - initiation phase send
>>> - initiation phase receive
>>> - MP send
>>> - MP receive
>>> - MC send
>>> - MC receive
>>> It also is misleading because it is not required to be both an= MC and an MP, so possibly only one of those applies. So it could be either= four streams of sequence numbers, or six streams.
>> Got it. When we say =93manage=94 we actually mean =93being respons= ible for the creation and the update=94. So, we were looking at the three r= oles mentioned above, but by focusing just on the =93sending=94 perspective= . Would you like us to reword that sentence?
>>
>>>   5.2 "copied in the the" remove a =93the&= quot;
>> Done.
>>
>>>   5.3 "an MP may send new ADV messages to repla= ce the previously advertised options" - this could be misunderstood as= relating to the options messages in the initiation phase. How about "= an MP may send new ADV messages to replace the previous advertisement=94 >> Done.
>>
>>>   Christian wrote: "Cl.6.1&6.2: Do we need = to indicate that the timeout and retry relates to the transport (e.g. SCTP)= rather than application level timers/counters? I'm a bit confused about th= e descriptions in the draft as we have a reliable transport"
>>> I thought the timeout and retry stuff was application level, n= ot to account for transport errors but rather to account for application be= havior such as an application not responding for whatever reason. So I thin= k it does need to be clarified if Christian and I interpreted it differently.
>> This is inline with our interpretation. See also our answer to Chr= istian=92s point in the related e-mail.
>>
>>
>>>   Christian wrote: "Cl.6.2 para 3: "If the= ADV elaboration is unsuccessful (bad syntax, missing XML elements, etc.), = and the number of times this has happened is under the retry treshold,"= ; I don't understand why the retry threshold comes in here? Wouldn't the MC simply send a NACK is there's an error. It wouldn't wait for multip= le instances of the erroneous message."
>>> My understanding is it gives the MP an opportunity to send a d= ifferent advertisement after it receives a nack. It doesn't have to send an= other copy of the same advertisement.
>> Agreed. As per above, see also our answer to Christian=92s point i= n the related e-mail.
>>
>>> 10.1 simple ADV - I suggest updating this to be consistent wit= h the sample XML file in the data model. We already fixed some problems wit= h that sample XML. I see problems, probably the same ones we already fixed,= here in the simple ADV example. For example captureID AC0 is a video capture but the description says "main audio= from the room". And on page 36 sceneView SE3 and SE4 are the same, so= that is a mistake. I think we've done a good review of the XML in the data= model, so let's just use that as much as possible to avoid new mistakes in this document.
>> Done. Thank you for pointing this out.
>>
>>>   10.2 - same comment, I suggest using the already r= eviewed XML from the data model, and show it here in the protocol message e= nvelope.
>> Done.
>>
>>
>>>  
>>> Mark
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org
>>> https:/= /www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.iet= f.org/mailman/listinfo/clue
>

_______________________________________________
clue mailing list
clue@ietf.org
https://www.ietf.org= /mailman/listinfo/clue
 --_000_BLUPR06MB19631DC61791F1A2E6E1FB1A7750BLUPR06MB196namprd_-- From nobody Tue Jan 24 14:20:54 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 818C412943E for ; Tue, 24 Jan 2017 14:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.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 t1sNO9CWbuhA for ; Tue, 24 Jan 2017 14:20:51 -0800 (PST) Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E9212943D for ; Tue, 24 Jan 2017 14:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=iT5K4QIfUsGQczewgrRg/nuw+4HJ2JlSmusul8tebKY=; b=HPlPGdV9iX12xj4RksQth8/4JX 1Nry8XFf8n8/05Ta/6pTyvWkEoIq0m0LTptnjdhvBKRzUrGdAZJIOoKMsJe6abSKsrUkSh6TVjfda bbJwqK84u9CH+Fbg4JrSXm/iduGmmMoEPs7/WRkgUb2UiBIuLk+37zJzAiE9DiCu8WmpAlt7VZkzB 0GIJg7PWNkO3dW1QgzOP/Z07cHaUW/xRvhO+Hddr1D7QOfN3o7yBIiaDysstAMBE/sikPobcCQreM F0ZapH+pCbcmsMLmtFq5LUMw0ErpOAB1IZ/88UDIrRj+Nma0mjMbaj/5CCVyFsQ7iWrlkpNYJS0K9 VtE3Z6ew==; Received: from ppp118-209-52-63.lns20.mel4.internode.on.net ([118.209.52.63]:52078 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1cW9SL-000TOe-5B for clue@ietf.org; Wed, 25 Jan 2017 09:20:49 +1100 To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> <6dc934ae-0485-8eca-b8c8-db887a82f50e@comcast.net> From: Christian Groves Message-ID: Date: Wed, 25 Jan 2017 09:20:46 +1100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6dc934ae-0485-8eca-b8c8-db887a82f50e@comcast.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - msh03.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 22:20:53 -0000 The current section 12.4.2 in the protocol indicates that to register a response code "specification is required". I can't see why this cannot apply to extensions? Having to up the version seems to be a very high bar for a response code. The document already has the registration information so I don't see how it delays things? Christian On 25/01/2017 3:10 AM, Paul Kyzivat wrote: > On 1/24/17 12:08 AM, Christian Groves wrote: > >>> We rephrased the sentence as follows: >>> >>> "Further response codes can be either defined in future versions of the >>> protocol or defined >>> by leveraging the extension mechanism. In any case, such new response >>> codes MUST NOT overwrite the ones here defined and they MUST >>> respect the semantics of the first code digit.” >>> >>> Does this sound OK to you? >> [CNG] I agree with Paul in that any new response code will need to be >> registered by IANA. However I don't see the problem with having two >> mechanisms to define codes within the protocol. It should be possible to >> add an error code to CLUE without having to bump the version. I think if >> you delete "(by adding them to the related IANA registry)," and add a >> sentence along the lines of: >> "In both cases the new response code MUST be registered with IANA". > > In principle that would work. But that leaves the issue of what policy > to use for the registry. A new version of the protocol will be > standards track, which is sufficient to control the registry. But IIUC > anybody can define an extension. I doubt we would want to make the > registry FCFS because the codes are a limited resource. > > For simplicity in the interest of getting this done I would be > satisfied with requiring a new version to define a new response code. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Jan 24 17:56: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 797C3129601 for ; Tue, 24 Jan 2017 17:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 FdTrHVwRreHL for ; Tue, 24 Jan 2017 17:56:18 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC881295F8 for ; Tue, 24 Jan 2017 17:56:18 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-02v.sys.comcast.net with SMTP id WCokcQCGxoFDdWCorcBykY; Wed, 25 Jan 2017 01:56:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485309377; bh=jvoEweZm+vq6tvuj2Ql+kRgznJFzVBTYl/5Ly30Vx/E=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=JN45Ij3Qy1PaDpS9Hl29dicaGKBYeDAYTICITn2ty/nV9T4u0npXVOfzW4lrb9zKu CjavUEcQBhpadvIuwOngdA1cPFnuXJqjkUH9KMB9a154ZsEtYjlor+J3q+8KE2sYuP NM1q8BHpmTz9VJZkGUuo5usUW8OM++9OAl+Z4dejMYNBV4i+D/CNz650yxcruL2VoE kFmV08ycQRSbcot24+J4u17X5MbKzts8ftl0zYbXppUAMbzi0DxXCx+GzRlwo/0Fx0 +oqDGYyCgHY9Nblg9sZGcCGPgWe5/ooV8h/+RTqIiDSx0UzNs5nD8CfDjgHYX9JGIF 5oQIbByjpdoIQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-18v.sys.comcast.net with SMTP id WCopcXfFx9HUeWCoqc2p5p; Wed, 25 Jan 2017 01:56:16 +0000 To: clue@ietf.org References: <075716a0-ab1d-f943-50d0-a65fd339f165@nteczone.com> <4B2480BA-75CA-4E73-A3D4-ABA3058EE6AD@unina.it> <8A070EF8-BEB7-4CA8-86C1-E10A25C91F04@unina.it> <5f5ddf96-41a9-9c55-c692-077791a04ec7@nteczone.com> <6dc934ae-0485-8eca-b8c8-db887a82f50e@comcast.net> From: Paul Kyzivat Message-ID: <0f89be85-792d-30e2-a0b2-9e799e3a68fe@comcast.net> Date: Tue, 24 Jan 2017 20:56:15 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfD7yHcGDDmgldMBul2saWnOEH2xpwQMdoknanREwoxbtTXZiUUnNuQApmYVFSdHyNmhPKS7ljMhMwZgkxEJWJk98y254h2zDy+hsMqwoK1+P8oDzJhfm Ox1A8D8qiZaEWI2TIpDawz/jU4sDfosfkW3eFmCz79A7OBI+2ZmkGAxh Archived-At: Subject: Re: [clue] WGLC for draft-ietf-clue-protocol-10 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 01:56:19 -0000 On 1/24/17 5:20 PM, Christian Groves wrote: > The current section 12.4.2 in the protocol indicates that to register a > response code "specification is required". I can't see why this cannot > apply to extensions? Having to up the version seems to be a very high > bar for a response code. The document already has the registration > information so I don't see how it delays things? OK, yes - if you still need s specification for the response code that is good enough for me. Thanks, Paul > Christian > > > On 25/01/2017 3:10 AM, Paul Kyzivat wrote: >> On 1/24/17 12:08 AM, Christian Groves wrote: >> >>>> We rephrased the sentence as follows: >>>> >>>> "Further response codes can be either defined in future versions of the >>>> protocol or defined >>>> by leveraging the extension mechanism. In any case, such new response >>>> codes MUST NOT overwrite the ones here defined and they MUST >>>> respect the semantics of the first code digit.” >>>> >>>> Does this sound OK to you? >>> [CNG] I agree with Paul in that any new response code will need to be >>> registered by IANA. However I don't see the problem with having two >>> mechanisms to define codes within the protocol. It should be possible to >>> add an error code to CLUE without having to bump the version. I think if >>> you delete "(by adding them to the related IANA registry)," and add a >>> sentence along the lines of: >>> "In both cases the new response code MUST be registered with IANA". >> >> In principle that would work. But that leaves the issue of what policy >> to use for the registry. A new version of the protocol will be >> standards track, which is sufficient to control the registry. But IIUC >> anybody can define an extension. I doubt we would want to make the >> registry FCFS because the codes are a limited resource. >> >> For simplicity in the interest of getting this done I would be >> satisfied with requiring a new version to define a new response code. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue