From nobody Mon Apr 3 08:30:38 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C023F129408; Mon, 3 Apr 2017 08:30:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liaison Statement Management Tool To: "Flemming Andreasen" , "Bo Burman" Cc: Adam Roach , Flemming Andreasen , Ben Campbell , stefhak@gmail.com, Bo Burman , Alexey Melnikov , alvestrand@gmail.com, Multiparty Multimedia Session Control Discussion List , bernard.aboba@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149123343669.13157.18402606352918183703.idtracker@ietfa.amsl.com> Date: Mon, 03 Apr 2017 08:30:36 -0700 Archived-At: Subject: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 15:30:37 -0000 Title: W3C WEBRTC WG to IETF MMUSIC WG Submission Date: 2017-04-03 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1511/ Please reply by 2017-04-16 From: Bernard Aboba To: Flemming Andreasen ,Bo Burman Cc: Adam Roach ,Flemming Andreasen ,Ben Campbell ,Bo Burman ,Alexey Melnikov ,Multiparty Multimedia Session Control Discussion List Response Contacts: bernard.aboba@gmail.com, alvestrand@gmail.com, stefhak@gmail.com Technical Contacts: Purpose: For action Body: Colleagues: In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media: https://github.com/w3c/webrtc-pc/issues/849 It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period (e.g. 5 seconds) prior to fingerprint verification: https://github.com/w3c/webrtc-pc/pull/1026 Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572: Note that when the offer/answer model is being used, it is possible for a media connection to outrace the answer back to the offerer. Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' role, it MUST (as specified in RFC 4145 [7]) begin listening for an incoming connection as soon as it sends its offer. However, it MUST NOT assume that the data transmitted over the TLS connection is valid until it has received a matching fingerprint in an SDP answer. If the fingerprint, once it arrives, does not match the client's certificate, the server endpoint MUST terminate the media connection with a bad_certificate error, as stated in the previous paragraph. Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the above paragraph. In particular, what is it permitted for a WebRTC implementation to do with received data prior to verification? For example: 1. May data received over the data channel be provided to the web application prior to verification? 2. May received media be played out prior to verification? Attachments: webrtc-liason-to-mmusic copy.pdf https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-04-03-w3c-webrtc-mmusic-w3c-webrtc-wg-to-ietf-mmusic-wg-attachment-1.pdf From nobody Mon Apr 3 11:29:45 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89624128BE1 for ; Mon, 3 Apr 2017 11:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 7uhrM4eQ8M5N for ; Mon, 3 Apr 2017 11:29:41 -0700 (PDT) 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 153D41294D0 for ; Mon, 3 Apr 2017 11:29:40 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-b2-58e29491d1b2 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by (Symantec Mail Security) with SMTP id C2.34.27378.19492E85; Mon, 3 Apr 2017 20:29:39 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.158]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0339.000; Mon, 3 Apr 2017 20:29:36 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Inconsistent text in BUNDLE and mux-exclusive regarding IDENTICAL/TRANSPORT SDP attributes Thread-Index: AdKssKohFejrmzmUQTaJpJ4fGwH2XQ== Date: Mon, 3 Apr 2017 18:29:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB487C3@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB487C3ESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM2J7oO7kKY8iDNY28llMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGatPtjEXtNpV3No8k6mBcadZFyMHh4SAicSqf3FdjFwcQgLr GSW6H61h7mLkBHIWM0psvVkCUsMmYCHR/U8bJCwioC7xdW8PWImwQKrE21/bmSDiWRIr7mxh g7D1JL49ewJmswioSKzY8BesnlfAV+LX/JusIDajgJjE91NrwHqZBcQlbj2ZD2ZLCAhILNlz nhnCFpV4+fgfK4StJNG45AkrRH2+xJ+bfWwQMwUlTs58wjKBUXAWklGzkJTNQlIGEdeRWLD7 ExuErS2xbOFrZhj7zIHHTMjiCxjZVzGKFqcWJ+WmGxnrpRZlJhcX5+fp5aWWbGIEhv3BLb9V dzBefuN4iFGAg1GJhzch9FGEEGtiWXFl7iFGCQ5mJRHeCX5AId6UxMqq1KL8+KLSnNTiQ4zS HCxK4ryO+y5ECAmkJ5akZqemFqQWwWSZODilGhh7mtZu2lJ0V1+0Livu4cKmi7Z8S0NlJrlU Vgo385SGzlTTFC9zvH78UtXDMpt48zbNnH2FD2R2fBXcfl1yz9ptXs+nm6vOqZRdco1RiLVi afnvqd+Pn1qzJu6W8rG4PbKTDAqqZiq0K4mwX1M5y+qor9zety/4eMX0ieYPTLKfMWX/On39 cLUSS3FGoqEWc1FxIgBkCO1wdwIAAA== Archived-At: Subject: [MMUSIC] Inconsistent text in BUNDLE and mux-exclusive regarding IDENTICAL/TRANSPORT SDP attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Apr 2017 18:29:43 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB487C3ESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When looking for the changes needed regarding including media specific attr= ibutes in bundled m- lines, I realized that there is inconsistent text betw= een BUNDLE and draft-mux-exclusive: Section 3 of draft-mux-exclusive says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. Section 8.1 of BUNDLE says: When an offerer associates SDP attributes with a bundled "m=3D" line associated with a shared address, IDENTICAL and TRANSPORT mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D" line only if the "m=3D" line is also associated with the offerer BUNDLE-tag. Otherwise the offerer MUST NOT associate such SDP attributes with the "m=3D" line. Section 10.3.1.1 of BUNDLE says: When an offerer generates an initial offer, the offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled RTP-based "m=3D" line in the offer, including a bundle-only "m=3D" line. In addition, the offerer MUST associate an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle- only "m=3D" line, and MAY associated an SDP 'rtcp-mux-only' attribute with other bundled RTP-based "m=3D" lines. The text in section 8.1 describes the correct behaviour. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB487C3ESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

When looking for the changes needed regarding includ= ing media specific attributes in bundled m- lines, I realized that there is= inconsistent text between BUNDLE and draft-mux-exclusive:

 

Section 3 of draft-mux-exclusive says:

 

   The mux category [= I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-

   mux-only' attribut= e is 'IDENTICAL', which means that the attribute,

   if used within a B= UNDLE group

   [I-D.ietf-mmusic-s= dp-bundle-negotiation], must be associated with all

   multiplexed RTP= -based media descriptions within the BUNDLE group.

 

Section 8.1 of BUNDLE says:

 

   When an offerer associates SDP attributes with a bundled =
"m=3D" line
   associated with a shared address, IDENTICAL and TRANSPORT=
 mux
   category SDP attributes [I-D.ietf-mmusic-sdp-mux-attribut=
es] are
   associated with the "m=3D" line only if the =
"m=3D" line is also
   associated with the offerer BUNDLE-tag.  Othe=
rwise the offerer MUST
   NOT associate such SDP attributes with the "m=3D&quo=
t; line.

 

Section 10.3.1.1 of BUNDLE says:

 

   When an offerer generates an initial offer, the offerer M=
UST
   associate an SDP 'rtcp-mux' attribute [RFC5761] with e=
ach bundled
   RTP-based "m=3D" line in the offer, incl=
uding a bundle-only "m=3D" line.
   In addition, the offerer MUST associate an SDP 'rtcp-mux-=
only'
   attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-b=
ased bundle-
   only "m=3D" line, and MAY associated an SDP 'rt=
cp-mux-only' attribute
   with other bundled RTP-based "m=3D" lines.=

 

The text in section 8.1 describes the correct behavi= our.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB487C3ESESSMB109erics_-- From nobody Thu Apr 6 00:42:21 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11F126C7B for ; Thu, 6 Apr 2017 00:42:19 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC6kfOmVo7K8 for ; Thu, 6 Apr 2017 00:42:16 -0700 (PDT) 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 4B72E1293F4 for ; Thu, 6 Apr 2017 00:42:16 -0700 (PDT) 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 DEF52131; Thu, 06 Apr 2017 07:42:14 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 6 Apr 2017 08:42:12 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.133]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Thu, 6 Apr 2017 15:42:06 +0800 From: Roni Even To: Bo Burman , "mmusic@ietf.org" Thread-Topic: I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt Thread-Index: AQHSnD6W8QFai2hqQUmkSGJeTIqSBKG4GdVw Date: Thu, 6 Apr 2017 07:42:05 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD7AE74B@DGGEMM506-MBX.china.huawei.com> References: <148943917767.20345.3859994881763997620@ietfa.amsl.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.207] 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.0A020201.58E5F156.00B8, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.133, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6291bde9baaca6124884b71d2271d57a Archived-At: Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 07:42:19 -0000 Hi, I already reviewed the 07 version, I reviewed the 08 version and find it re= ady for publication Roni Even > -----Original Message----- > From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman > Sent: =E9=E5=ED=A0=E1 13 =EE=F8=F5 2017 23:11 > To: mmusic@ietf.org > Subject: Re: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt >=20 > This update addresses all received comments: >=20 > o Correcting syntax of SDP examples in section 6.6.1, as found by > Inaki Baz Castillo. >=20 > o Changing ABNF to only define the sc-value, not the SDP attribute > itself, as suggested by Paul Kyzivat. >=20 > o Changing I-D reference to newly published RFC 8108. >=20 > /Bo > (as individual) >=20 > > -----Original Message----- > > From: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] On Behalf Of > > internet-drafts@ietf.org > > Sent: den 13 mars 2017 22:06 > > To: i-d-announce@ietf.org > > Cc: mmusic@ietf.org > > Subject: I-D Action: draft-ietf-mmusic-sdp-simulcast-08.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the Multiparty Multimedia Session Control = of > the IETF. > > > > Title : Using Simulcast in SDP and RTP Sessions > > Authors : Bo Burman > > Magnus Westerlund > > Suhas Nandakumar > > Mo Zanaty > > Filename : draft-ietf-mmusic-sdp-simulcast-08.txt > > Pages : 35 > > Date : 2017-03-13 > > > > Abstract: > > In some application scenarios it may be desirable to send multiple > > differently encoded versions of the same media source in different > > RTP streams. This is called simulcast. This document describes how > > to accomplish simulcast in RTP and how to signal it in SDP. The > > described solution uses an RTP/RTCP identification method to identif= y > > RTP streams belonging to the same media source, and makes an > > extension to SDP to relate those RTP streams as being different > > simulcast formats of that media source. The SDP extension consists > > of a new media level SDP attribute that expresses capability to send > > and/or receive simulcast RTP streams. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-08 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mmusic-sdp-simulcast-08 > > > > > > 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.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Apr 6 10:00:05 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 297A6126CD8; Thu, 6 Apr 2017 10:00:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz To: Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149149800009.21962.16244679330016077024@ietfa.amsl.com> Date: Thu, 06 Apr 2017 10:00:00 -0700 Archived-At: Subject: [MMUSIC] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 17:00:00 -0000 Reviewer: Rich Salz Review result: Has Nits The term "ufrag" should be explained, or at least have a reference on its first use. It seems important :) I think the "fingerprint" reference should be moved up to the bullet list in section 4, from the bullet list in 5.1 Sec 4 uses the term "cryptographic random function" which is not a common security term. (See https://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator) I would just say "strong random function"; it's the number of random bits that counts. Or use CSPRNG as the term. In Sec 9, it seems like quoting all the old text is way too verbose. I would just say "replace with the following NEW TEXT" If it's not replacing an entire section, then say "the nnn paragraphs starting with xxxxx" or similar construct. From nobody Thu Apr 6 11:37:18 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B2E12741D; Thu, 6 Apr 2017 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLeYD19iKbOu; Thu, 6 Apr 2017 11:37:07 -0700 (PDT) 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 86DE2127775; Thu, 6 Apr 2017 11:37:06 -0700 (PDT) X-AuditID: c1b4fb2d-dadfe700000033e1-4c-58e68ace1958 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id F4.C3.13281.ECA86E85; Thu, 6 Apr 2017 20:37:04 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Thu, 6 Apr 2017 20:37:02 +0200 From: Christer Holmberg To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSrvc7Q+l4Ggm5cUSsh7p7Glw+qqG4q/Pg Date: Thu, 6 Apr 2017 18:37:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> References: <149149800009.21962.16244679330016077024@ietfa.amsl.com> In-Reply-To: <149149800009.21962.16244679330016077024@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbE9SvdC17MIg2NtWhY77u5gs3i2cT6L xdTlj1ks/m/pZLH4sPAhiwOrx+QjC5g9liz5yRTAFMVlk5Kak1mWWqRvl8CVcfbfBJaCV0IV 525MZ25gXCPUxcjJISFgItHQ/Zili5GLQ0hgPaPE+mtH2SCcxYwSB16/Ye1i5OBgE7CQ6P6n DdIgIuAqsa33MzNIDbPAQkaJ72c/MYIkhIESk08eYIQocpNY8eAkG4RtJLH08ipmEJtFQEVi z+yHzCAzeQV8JX5OB5spJOAi8f9uHyuIzQk0prd9B5jNKCAm8f3UGiYQm1lAXOLWk/lMEEcL SCzZc54ZwhaVePn4HyuErSSx9vB2FpDxzAKaEut36UO0KkpM6X7IDmLzCghKnJz5hGUCo+gs JFNnIXTMQtIxC0nHAkaWVYyixanFxbnpRsZ6qUWZycXF+Xl6eaklmxiBEXRwy2/dHYyrXzse YhTgYFTi4U348SRCiDWxrLgy9xCjBAezkgiv+nugEG9KYmVValF+fFFpTmrxIUZpDhYlcV6H fRcihATSE0tSs1NTC1KLYLJMHJxSDYzafiEL/xjv2ey6MOeOtVybC8OW1eWnHzvdZj9+++zs G7M2x+xcYnMoui/zvUKcyMsX6455fb6n7z6nwDn/0JHv9r3/Hdjq/1248K9l8up625nFak2b 4w6E6Kmc1ubfayO6Zcuiee7yq4xCV82Xivcq+n06VL3U6M1TUaMFLqbSey6+7fedNrlSiaU4 I9FQi7moOBEAilxX65wCAAA= Archived-At: Subject: Re: [MMUSIC] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:37:09 -0000 SGkgUmljaCwNCg0KVGhhbmtzIGZvciB5b3VyIHJldmlldyENCg0KTm90ZSB0aGF0LCBiYXNlZCBv biBkaXNjdXNzaW9ucyBpbiBDaGljYWdvLCB0aGUgZHJhZnQgd2lsbCBiZSBleHRlbmRlZCB0byBh bHNvIGNvdmVyIFRMUyBhc3NvY2lhdGlvbnMuIFNvLCBpdCBtYXkgZW5kIHVwIG9uIHlvdXIgdGFi bGUgYWdhaW4gYXQgc29tZSBwb2ludCA6KQ0KDQpOZXZlciB0aGUgbGVzcywgSSB3aWxsIHJlcGx5 IHRvIHlvdXIgY29tbWVudHMsIGJlY2F1c2Ugc29tZSBvZiB0aGVtIGFyZSBub3QgcmVsYXRlZCB0 byB0aGUgY2hhbmdlLg0KDQo+UmV2aWV3ZXI6IFJpY2ggU2Fseg0KPlJldmlldyByZXN1bHQ6IEhh cyBOaXRzDQo+DQo+VGhlIHRlcm0gInVmcmFnIiBzaG91bGQgYmUgZXhwbGFpbmVkLCBvciBhdCBs ZWFzdCBoYXZlIGEgcmVmZXJlbmNlIG9uIGl0cyBmaXJzdCB1c2UuICBJdCBzZWVtcyBpbXBvcnRh bnQgOikNCg0KSSB3aWxsIGFkZCBhIHJlZmVyZW5jZSB0byBkcmFmdC01MjQ1YmlzLg0KDQo+SSB0 aGluayB0aGUgImZpbmdlcnByaW50IiByZWZlcmVuY2Ugc2hvdWxkIGJlIG1vdmVkIHVwIHRvIHRo ZSBidWxsZXQgbGlzdCBpbiBzZWN0aW9uIDQsIGZyb20gdGhlIGJ1bGxldCBsaXN0IGluIDUuMQ0K DQpJIGFtIG5vdCBzdXJlLiBUaGUgYnVsbGV0IGxpc3QgaW4gc2VjdGlvbiA0IHRhbGtzIGFib3V0 IHRoZSBmaW5nZXJwcmludCBpbiBnZW5lcmFsLCB3aGlsZSB0aGUgYnVsbGV0IGxpc3QgaW4gNS4x IHRhbGtzIGFib3V0IHRoZSBmaW5nZXJwcmludCBhdHRyaWJ1dGUuDQoNCj5TZWMgNCB1c2VzIHRo ZSB0ZXJtICJjcnlwdG9ncmFwaGljIHJhbmRvbSBmdW5jdGlvbiIgd2hpY2ggaXMgbm90IGEgY29t bW9uIHNlY3VyaXR5IHRlcm0uICAoU2VlDQo+aHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kv Q3J5cHRvZ3JhcGhpY2FsbHlfc2VjdXJlX3BzZXVkb3JhbmRvbV9udW1iZXJfZ2VuZXJhdG9yKQ0K Pkkgd291bGQganVzdCBzYXkgInN0cm9uZyByYW5kb20gZnVuY3Rpb24iOyBpdCdzIHRoZSBudW1i ZXIgb2YgcmFuZG9tIGJpdHMgdGhhdCBjb3VudHMuICBPciB1c2UgQ1NQUk5HIGFzIHRoZSB0ZXJt Lg0KDQpJIHdpbGwgdXNlICJzdHJvbmcgcmFuZG9tIGZ1bmN0aW9uIi4NCg0KPkluIFNlYyA5LCBp dCBzZWVtcyBsaWtlIHF1b3RpbmcgYWxsIHRoZSBvbGQgdGV4dCBpcyB3YXkgdG9vIHZlcmJvc2Uu IA0KPkkgd291bGQganVzdCBzYXkgInJlcGxhY2Ugd2l0aCB0aGUgZm9sbG93aW5nIE5FVyBURVhU Ig0KPklmIGl0J3Mgbm90IHJlcGxhY2luZyBhbiBlbnRpcmUgc2VjdGlvbiwgdGhlbiBzYXkgInRo ZSBubm4gcGFyYWdyYXBocyBzdGFydGluZyB3aXRoIHh4eHh4IiBvciBzaW1pbGFyIGNvbnN0cnVj dC4NCg0KVGhpcyBjb21lcyB1cCBldmVyeXRoaW5nIGEgc2VjdGlvbiBpcyB1cGRhdGVkLiBTb21l IHBlb3BsZSBvbmx5IHdhbnQgdG8gdXBkYXRlZCBwYXJ0cywgd2hpbGUgb3RoZXJzIHdhbnQgdGhl IHdob2xlIHVwZGF0ZWQgc2VjdGlvbiAtIG5vIG1hdHRlciBob3cgbXVjaCBvciBsaXR0bGUgaGFz IGJlZW4gdXBkYXRlZC4gU28sIEknZCBsaWtlIHRvIGtlZXAgaXQgYXMgaXQgaXMuDQoNCk5vdGUs IGhvd2V2ZXIsIHRoYXQgYmFzZWQgb24gdGhlIGdlbi1hcnQgcmV2aWV3IEkgd2lsbCBwbGFjZSB0 aGUgdXBkYXRlcyBvZiBlYWNoIGluZGl2aWR1YWwgc2VjdGlvbiBpbiBhIHNlcGFyYXRlIHN1YiBz ZWN0aW9uIG9mIHRoZSBkcmFmdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= From nobody Thu Apr 6 11:39:17 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32AE12949B; Thu, 6 Apr 2017 11:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 nh9lFdUhMNt8; Thu, 6 Apr 2017 11:39:05 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 027A112941C; Thu, 6 Apr 2017 11:39:01 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v36IaV8C003449; Thu, 6 Apr 2017 19:38:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=W9wYQnNEMLT7AxPFEue4BiMpLKjygKMbW64GWvb7WjE=; b=Yg1cPPPQrjaXgWEI00gk7vjIdckqRyXWPB7gWj0Wp/VyZLfjSFdhkrcNSx+qjXiA8W4f 3zy5vVXDDcKr3PIjQ5vE0am3CAqk8oBdqJk0igexx1DhxO/aOcsOajrxvFFL7ePHSpg9 AKBiyxiTkC35GkTCG+h0SnLkEyaolg4Uld3gKU3y4eO1a7nNy8WKcv6/UQz0cO1e5Exf 0K4tfRnRGPogx22qlacuAdUA3j99gArBffzSOaulCHO07yFIdGKP8yvWwNGwvpfGRhWX 2E//+lWJfC28ny0ZSbPDa9Af+LmhLP6PU8rPIK0z/EJbAo3TBbBHL+xM7rRSJVOnH4SJ JA== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 29nrut0s7g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 19:38:56 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v36IZqV4015275; Thu, 6 Apr 2017 14:38:56 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 29j7hujnc6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 06 Apr 2017 14:38:56 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 6 Apr 2017 14:38:53 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 6 Apr 2017 14:38:53 -0400 From: "Salz, Rich" To: Christer Holmberg , "secdir@ietf.org" CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" , "ietf@ietf.org" , "mmusic@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 Thread-Index: AQHSrwTMt/3hOQnvJkaFTThgvFfUh6G4q8xQ Date: Thu, 6 Apr 2017 18:38:52 +0000 Message-ID: <4f01bce56f4c4bf7b9d800b70d8cf9f5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <149149800009.21962.16244679330016077024@ietfa.amsl.com> <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB51809@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.153] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704060150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-04-06_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704060150 Archived-At: Subject: Re: [MMUSIC] Secdir last call review of draft-ietf-mmusic-dtls-sdp-22 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 18:39:08 -0000 PiBOb3RlIHRoYXQsIGJhc2VkIG9uIGRpc2N1c3Npb25zIGluIENoaWNhZ28sIHRoZSBkcmFmdCB3 aWxsIGJlIGV4dGVuZGVkIHRvIGFsc28NCj4gY292ZXIgVExTIGFzc29jaWF0aW9ucy4gU28sIGl0 IG1heSBlbmQgdXAgb24geW91ciB0YWJsZSBhZ2FpbiBhdCBzb21lIHBvaW50IDopDQoNCjopDQog DQo+ID5JIHRoaW5rIHRoZSAiZmluZ2VycHJpbnQiIHJlZmVyZW5jZSBzaG91bGQgYmUgbW92ZWQg dXAgdG8gdGhlIGJ1bGxldA0KPiA+bGlzdCBpbiBzZWN0aW9uIDQsIGZyb20gdGhlIGJ1bGxldCBs aXN0IGluIDUuMQ0KPiANCj4gSSBhbSBub3Qgc3VyZS4gVGhlIGJ1bGxldCBsaXN0IGluIHNlY3Rp b24gNCB0YWxrcyBhYm91dCB0aGUgZmluZ2VycHJpbnQgaW4gZ2VuZXJhbCwNCj4gd2hpbGUgdGhl IGJ1bGxldCBsaXN0IGluIDUuMSB0YWxrcyBhYm91dCB0aGUgZmluZ2VycHJpbnQgYXR0cmlidXRl Lg0KDQpBaCwgb2theS4gIFBlcmhhcHMgc29tZSB3b3JkaW5nIGNhbiAgY2xlYXIgdGhhdCB1cD8g IE9yIG1heWJlICJmaW5nZXJwcmludCBhdHRyaWJ1dGUiIGFuZCwgd2hhdCwgImFzc29jaWF0aW9u IGZpbmdlcnByaW50IiA/DQoNClRoYW5rcyBmb3IgcmVhZGluZy4NCg== From nobody Fri Apr 7 05:29:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86A9124281 for ; Fri, 7 Apr 2017 05:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G3hBL75gqbt for ; Fri, 7 Apr 2017 05:29:16 -0700 (PDT) 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 5FC5E129438 for ; Fri, 7 Apr 2017 05:29:16 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-e4-58e7861a3549 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 49.97.27378.A1687E85; Fri, 7 Apr 2017 14:29:14 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Fri, 7 Apr 2017 14:29:13 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: [MMUSIC] Inconsistent text in BUNDLE and mux-exclusive regarding IDENTICAL/TRANSPORT SDP attributes Thread-Index: AQHSr5qPeaTVwEGRC06ccSzz9agQmg== Date: Fri, 7 Apr 2017 12:29:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D50D611C1AB4Bchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHLMWRmVeSWpSXmKPExsUyM2K7qK5U2/MIg0erJCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPVP7rAWfAyq+DT9PFsD4z2PLkZODgkBE4kls86xdzFycQgJ rGeUuLrtNjOEs5hR4tPnA0AOBwebgIVE9z9tkAYRAXWJr3t7mEFsYYEiiVXzO1gg4sUStz/O g7L1JBbcXA9WwyKgIvHg+RomEJtXwFrixO3rjCA2o4CYxPdTEHFmAXGJW0/mM0EcJCCxZM95 ZghbVOLl43+sILYo0Mx9/76yQcQVJa5OXw7VmyBx/udKRoj5ghInZz5hmcAoNAvJ2FlIymYh KYOIG0i8PzefGcLWlli28DWUrS+x8ctZRgjbWuJ101cWZDULGDlWMYoWpxYn5aYbGeulFmUm Fxfn5+nlpZZsYgTGysEtv1V3MF5+43iIUYCDUYmHN+HHkwgh1sSy4srcQ4wSHMxKIrzq74FC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR33XYgQEkhPLEnNTk0tSC2CyTJxcEo1MLJdCmGzf7Ix bx+jgk+A/Zfpd6OLlR+80jO9zd95rYw/y06clyfp68753TPnn7Z30vG361Vl/CoUmr1k57y1 V0N3hOW+SFN0nM5bECNYpSof8GRKn+XHI9xL0xjWcMkvsolWkWUpSZuQvemjtVhxwu55Ux/x Gx++lyI6qXCym3sZ/6TNiktklViKMxINtZiLihMBNLjE5ZECAAA= Archived-At: Subject: Re: [MMUSIC] Inconsistent text in BUNDLE and mux-exclusive regarding IDENTICAL/TRANSPORT SDP attributes X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 12:29:19 -0000 --_000_D50D611C1AB4Bchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve now updated the BUNDLE text to be consistent and correct when it com= es to IDENTICAL/TRANSPORT SDP attributes. In addition, I have written text regarding the usage of media specific attr= ibutes (e.g., rtcp-mux) with m- lines associated with different media. https://github.com/cdh4u/draft-sdp-bundle/pull/33 Regards, Christer From: mmusic > on b= ehalf of Christer Holmberg > Date: Monday 3 April 2017 at 21:29 To: "mmusic@ietf.org" > Subject: [MMUSIC] Inconsistent text in BUNDLE and mux-exclusive regarding I= DENTICAL/TRANSPORT SDP attributes Hi, When looking for the changes needed regarding including media specific attr= ibutes in bundled m- lines, I realized that there is inconsistent text betw= een BUNDLE and draft-mux-exclusive: Section 3 of draft-mux-exclusive says: The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp- mux-only' attribute is 'IDENTICAL', which means that the attribute, if used within a BUNDLE group [I-D.ietf-mmusic-sdp-bundle-negotiation], must be associated with all multiplexed RTP-based media descriptions within the BUNDLE group. Section 8.1 of BUNDLE says: When an offerer associates SDP attributes with a bundled "m=3D" line associated with a shared address, IDENTICAL and TRANSPORT mux category SDP attributes [I-D.ietf-mmusic-sdp-mux-attributes] are associated with the "m=3D" line only if the "m=3D" line is also associated with the offerer BUNDLE-tag. Otherwise the offerer MUST NOT associate such SDP attributes with the "m=3D" line. Section 10.3.1.1 of BUNDLE says: When an offerer generates an initial offer, the offerer MUST associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled RTP-based "m=3D" line in the offer, including a bundle-only "m=3D" line. In addition, the offerer MUST associate an SDP 'rtcp-mux-only' attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-based bundle- only "m=3D" line, and MAY associated an SDP 'rtcp-mux-only' attribute with other bundled RTP-based "m=3D" lines. The text in section 8.1 describes the correct behaviour. Regards, Christer --_000_D50D611C1AB4Bchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <46A1F74273B79B429FA99C7F9A04F4A5@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve now updated the BUNDLE text to be consistent and correct when i= t comes to IDENTICAL/TRANSPORT SDP attributes.

In addition, I have written text regarding the usage of media specific= attributes (e.g., rtcp-mux) with m- lines associated with different media.=


Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Chris= ter Holmberg <christer= .holmberg@ericsson.com>
Date: Monday 3 April 2017 at 21:29<= br> To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] Inconsistent text= in BUNDLE and mux-exclusive regarding IDENTICAL/TRANSPORT SDP attributes

Hi,

 

When looking for the changes needed regarding includ= ing media specific attributes in bundled m- lines, I realized that there is= inconsistent text between BUNDLE and draft-mux-exclusive:

 

Section 3 of draft-mux-exclusive says:

 

   The mux category [= I-D.ietf-mmusic-sdp-mux-attributes] for the 'rtcp-

   mux-only' attribut= e is 'IDENTICAL', which means that the attribute,

   if used within a B= UNDLE group

   [I-D.ietf-mmusic-s= dp-bundle-negotiation], must be associated with all

   multiplexed RTP= -based media descriptions within the BUNDLE group.

 

Section 8.1 of BUNDLE says:

 

   When an offerer associates SDP attributes with a bundled =
"m=3D" line
   associated with a shared address, IDENTICAL and TRANSPORT=
 mux
   category SDP attributes [I-D.ietf-mmusic-sdp-mux-attribut=
es] are
   associated with the "m=3D" line only if the =
"m=3D" line is also
   associated with the offerer BUNDLE-tag.  Othe=
rwise the offerer MUST
   NOT associate such SDP attributes with the "m=3D&quo=
t; line.

 

Section 10.3.1.1 of BUNDLE says:

 

   When an offerer generates an initial offer, the offerer M=
UST
   associate an SDP 'rtcp-mux' attribute [RFC5761] with e=
ach bundled
   RTP-based "m=3D" line in the offer, incl=
uding a bundle-only "m=3D" line.
   In addition, the offerer MUST associate an SDP 'rtcp-mux-=
only'
   attribute [I-D.ietf-mmusic-mux-exclusive] with each RTP-b=
ased bundle-
   only "m=3D" line, and MAY associated an SDP 'rt=
cp-mux-only' attribute
   with other bundled RTP-based "m=3D" lines.=

 

The text in section 8.1 describes the correct behavi= our.

 

Regards,

 

Christer

 --_000_D50D611C1AB4Bchristerholmbergericssoncom_-- From nobody Fri Apr 7 10:06:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9EDA12955A for ; Fri, 7 Apr 2017 10:06:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h06mqzCEWS9b for ; Fri, 7 Apr 2017 10:06:43 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98CCD129549 for ; Fri, 7 Apr 2017 10:06:34 -0700 (PDT) Received: from [130.209.247.112] (port=62396 helo=mangole.dcs.gla.ac.uk) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1cwXLC-0007MS-JN for mmusic@ietf.org; Fri, 07 Apr 2017 18:06:33 +0100 From: Colin Perkins Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> Date: Fri, 7 Apr 2017 18:06:29 +0100 To: "mmusic (E-mail)" X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: -28 X-Mythic-Debug: State = no_sa; Score = Archived-At: Subject: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2017 17:06:48 -0000 I have some comments on BUNDLE -37 - apologies that I wasn=E2=80=99t = able to participate fully in the mailing list discussion before the = meeting.=20 The current text is generally reasonably clear, and is certainly = precisely written, but I do think it has some problems. Most of these = relate to the issue of whether RTP packets or RTP streams are being = processed. I think it=E2=80=99s important that this draft is written in = terms of how to associate RTP streams with m=3D lines, rather than how = to route and demultiplex RTP packets, since RTP packet routing and = demultiplexing is already specified by the various RTP specifications. = In particular, there are some places where the draft as written = conflates the two layers in ways that conflict with the RTP and RTCP = specifications, that I=E2=80=99ve tried to correct by more cleanly = separating the layers.=20 I=E2=80=99ve tried to write my suggestions in a prescriptive manner, = keeping to the style of the existing text where possible. Hopefully the = result is clear and understandable. Comments line below: > 10.2. Associating RTP/RTCP Streams With Correct SDP Media Description >=20 > NOTE: The text in this section is copied from Appendix B of JSEP. > The community has not yet agreed on the text. >=20 > As described in [RFC3550], RTP packets are associated with RTP > streams [RFC7656]. Each RTP stream is identified by an SSRC value, > and each RTP packet includes an SSRC field that is used to = associate > the packet with the correct RTP stream. RTCP packets also use = SSRCs > to identify which RTP streams the packet relates to. However, a = RTCP > packet can contain multiple SSRC fields, in the course of providing > feedback or reports on different RTP streams, and therefore can be > associated with multiple such streams. >=20 > In order to be able to process received RTP/RTCP packets correctly, > it must be possible to associate an RTP stream with the correct = "m=3D" >=20 >=20 >=20 > Holmberg, et al. Expires October 2, 2017 [Page = 20] > Internet-Draft Bundled media March = 2017 >=20 >=20 > line, as the "m=3D" line and SDP attributes associated with the = "m=3D" > line contain information needed to process the packets. >=20 > As all RTP streams associated with a BUNDLE group use the same > address:port combination for sending and receiving RTP/RTCP = packets, > the local address:port combination cannot be used to associate an = RTP > stream with the correct "m=3D" line. In addition, multiple RTP = streams > might be associated with the same "m=3D" line. >=20 > An offerer and answerer can inform each other which SSRC values = they > will use for an RTP stream by using the SDP 'ssrc' attribute > [RFC5576]. However, an offerer will not know which SSRC values the > answerer will use until the offerer has received the answer = providing > that information. Due to this, before the offerer has received the > answer, the offerer will not be able to associate an RTP stream = with > the correct "m=3D" line using the SSRC value associated with the = RTP > stream. In addition, the offerer and answerer may start using new > SSRC values mid-session, without informing each other using the SDP > 'ssrc' attribute. >=20 > In order for an offerer and answerer to always be able to associate > an RTP stream with the correct "m=3D" line, the offerer and = answerer > using the BUNDLE extension MUST support the mechanism defined in > section 14, where the offerer and answerer insert the = identification- > tag associated with an "m=3D" line (provided by the remote peer) = into > RTP and RTCP packets associated with a BUNDLE group. >=20 > When using this mechanism, the mapping from an SSRC to an > identification-tag is carried in RTP header extensions or RTCP SDES > packets, as specified in section 14. Since a compound RTCP packet > can contain multiple RTCP SDES packets, and each RTCP SDES packet = can > contain multiple chunks, a single RTCP packet can contain several > SSRC to identification-tag mappings. The offerer and answerer > maintain tables used for routing that are updated each time an RTP/ > RTCP packet contains new information that affects how packets = should > be routed. The text above looks good. In particular, it correctly focusses on = associating RTP streams with m=3D lines, which is the correct level of = abstraction.=20 > However, some implementations of may not include this = identification- > tag in their RTP and RTCP traffic when using the BUNDLE mechanism, > and instead use a payload type based mechanism for demuxing. In = this The term =E2=80=9Cdemuxing=E2=80=9D is unclear. For precision, I suggest = changing =E2=80=9Cuse a payload type based mechanisms for demuxing=E2=80=9D= to =E2=80=9Cuse a payload type based mechanism to associate RTP streams = with SDP m=3D lines=E2=80=9D. > situation, each "m=3D" line MUST use unique payload type values, in > order for the payload type to be a reliable indicator of the = relevant > "m=3D" line for the RTP stream. Note that when using payload type > based demuxing, Similarly, for precision, I suggest changing =E2=80=9Cwhen using payload = type based demuxing=E2=80=9D to =E2=80=9Cwhen using the payload type to = associate RTP streams with m=3D lines=E2=80=9D. > an SSRC will be mapped to an =E2=80=9Cm=3D=E2=80=9C = line Suggest changing to =E2=80=9Can RTP stream, identified by SSRC, will be = mapped=E2=80=A6=E2=80=9D to be clear what=E2=80=99s being done. =20 > by the first > packet with that SSRC, and the mapping will not be changed even if Suggest changing to =E2=80=9Cwhen the first RTP packet of that RTP = stream is received, and=E2=80=A6=E2=80=9D to be clear, since there could = be RTCP packets with the same SSRC. > the same SSRC is received with a different payload type. In other Suggest changing to =E2=80=9Cthe payload type used by that RTP stream = changes. In other=E2=80=9D to be precise. > words, the SSRC cannot to "move" to a different "m=3D" line simply = by > changing the payload type. >=20 > Holmberg, et al. Expires October 2, 2017 [Page = 21] > Internet-Draft Bundled media March = 2017 >=20 >=20 > Applications can implement RTP stacks in many different ways. The > algorithm below details one way that demultiplexing can be > accomplished, but is not meant to be prescriptive about exactly how To be clear about what is being demultiplexed, I suggest changing =E2=80=9C= one way that demultiplexing can be accomplished=E2=80=9D to =E2=80=9Cone = way that RTP streams can be associated with m=3D lines=E2=80=9D. > an RTP stack needs to be implemented. Applications MAY use any > algorithm that achieves equivalent results to those described in = the > algorithm below. >=20 > To prepare for demultiplexing RTP/RTCP packets to the correct "m=3D" > line, the following steps MUST be followed for each BUNDLE group. I suggest changing =E2=80=9C=E2=80=A6prepare for demultiplexing RTP/RTCP = packets to the correct=E2=80=A6=E2=80=9D to =E2=80=9C=E2=80=A6prepare to = associate RTP streams with the correct=E2=80=A6=E2=80=9D. RTP and RTCP = packets are not demultiplexed to m=3D lines, they=E2=80=99re = demultiplexed into RTP streams, and then those RTP streams are = associated with m=3D lines. The distinction is important, in order to = implement RTCP correctly.=20 > Construct a table mapping MID to "m=3D" line for each "m=3D" = line in > this BUNDLE group. Note that an "m=3D" line may only have one = MID. >=20 > Construct a table mapping incoming SSRC to "m=3D" line for each = "m=3D" > line in this BUNDLE group and for each SSRC configured for > receiving in that =E2=80=9Cm=3D" line. The SSRC is a property of an RTP stream, so I suggest changing = =E2=80=9Cmapping incoming SSRC to=E2=80=9D to =E2=80=9Cmapping SSRCs of = incoming RTP streams to=E2=80=9D. > Construct a table mapping outgoing SSRC to "m=3Dline" for each = "m=3D" > line in this BUNDLE group and for each SSRC configured for = sending > in that =E2=80=9Cm=3D" line. Similarly, change =E2=80=9Cmapping outgoing SSRC=E2=80=9D to =E2=80=9Cmapp= ing the SSRC of each outgoing RTP stream=E2=80=9D > Construct a table mapping payload type to "m=3D" line for each = "m=3D" > line in the BUNDLE group and for each payload type configured = for > receiving in that "m=3D" line. If any payload type is = configured > for receiving in more than one "m=3D" line in the BUNDLE group, = do > not it include it in the table, as it cannot be used to uniquely > identify a "m=3D" line. >=20 > Note that for each of these tables, there can only be one = mapping > for any given key (MID, SSRC, or PT). In other words, the = tables > are not multimaps. >=20 > As "m=3D" lines are added or removed from the BUNDLE groups, or = their > configurations are changed, the tables above MUST also be updated. >=20 > For each RTP packet received, the following steps MUST be followed = to > route the packet to the correct "m=3D" section within a BUNDLE = group. The goal is not to route RTP packets to m=3D lines, but rather to = associate the corresponding RTP streams with m=3D lines. This keeps the = distinction between RTP and RTCP processing that has to happen = irrespective of the m=3D line, and the application level processing that = depends on the choice of m=3D line. I suggest changing this sentence to: = =E2=80=9CWhen an RTP packet is received, it MUST be delivered to the RTP = stream corresponding to its SSRC. That RTP stream MUST then be = associated with the correct m=3D line within a BUNDLE group, according = to the following steps.=E2=80=9D > Note that the phrase 'deliver a packet to the "m=3D" line' means to > further process the packet as would normally happen with RTP/RTCP, = if > it were received on a transport associated with that "m=3D" line > outside of a BUNDLE group (i.e., if the "m=3D" line were not = BUNDLEd), > including dropping an RTP packet if the packet's PT does not match > any PT in the =E2=80=9Cm=3D" line. Dropping RTP packets with unknown payload type breaks RTCP. The RTP = packet must be processed by the RTP layer as normal, updating the = statistics that are maintained by RTCP. The payload is then discarded, = because there=E2=80=99s no decoder associated with the payload type. I = suggest removing this part of the paragraph entirely. > If the packet has a MID, and that MID is not in the table = mapping > MID to =E2=80=9Cm=3D" line, drop the packet and stop. Dropping the RTP packet will break the RTCP reports. The RTP packet has = to be processed as normal, but the corresponding RTP stream is not = decoded if it=E2=80=99s not associated with an =E2=80=9Cm=3D=E2=80=9C = line (i.e., you drop the payload, not the RTP packet). I suggest = replacing the above with something like: If the MID associated with the RTP stream is not in the table mapping=20= MID to =E2=80=9Cm=3D=E2=80=9C line, then the RTP stream is not = decoded and the payload data is discarded. > If the packet has a MID, and the packet's extended sequence = number > is greater than that of the last MID update, as discussed in > [RFC7941], Section 4.2.6, update the incoming SSRC mapping table > to include an entry that maps the packet's SSRC to the "m=3D" = line > for that MID. There are two things that need to be done here: update the MID = associated with the RTP stream to match that in the newly received RTP = packet, and update the mapping table. I suggest changing =E2=80=9Cupdate = the incoming SSRC mapping table to include an entry that maps the = packet=E2=80=99s SSRC to the =E2=80=9Cm=3D=E2=80=9C line for that MID=E2=80= =9D to =E2=80=9Cupdate the MID associated with the RTP stream to match = the MID carried in the RTP packet, then update the mapping tables to = include an entry that maps the SSRC of that RTP stream to the =E2=80=9Cm=3D= =E2=80=9C line for that MID=E2=80=9D. > If the packet's SSRC is in the incoming SSRC mapping table, = check > that the packet's PT matches a PT included on the associated = "m=3D" > line. If so, route the packet to that associated "m=3D" line = and > stop; otherwise drop the packet and stop. Dropping the packet breaks RTCP. The RTP packet is processed as normal, = but the corresponding RTP stream is not decoded if it=E2=80=99s not = associated with an =E2=80=9Cm=3D=E2=80=9C line. I suggest replacing the = above with: If the SSRC of the RTP stream is in the incoming SSRC mapping table,=20= check that the payload type used by the RTP stream matches a payload type included on the matching =E2=80=9Cm=3D=E2=80=9C line. If so, = associate the RTP stream with that =E2=80=9Cm=3D=E2=80=9C line. Otherwise, the RTP = stream is not decoded and the payload data is discarded. > If the packet's payload type is in the payload type table, = update > the the incoming SSRC mapping table to include an entry that = maps > the packet's SSRC to the "m=3D" line for that payload type. In > addition, route the packet to the associated =E2=80=9Cm=3D" line = and stop. RTP packets correspond to RTP streams, and those RTP streams are = associated with m=3D lines. Suggest changing to: If the payload type used by the RTP stream is in the payload type table, update the incoming SSRC mapping table to include an entry that maps the RTP stream=E2=80=99s SSRC to the =E2=80=9Cm=3D=E2=80=9C = line for that payload type. Associate the RTP stream with the corresponding =E2=80=9Cm=3D=E2=80= =9C line. > Otherwise, drop the packet. The packet cannot be discarded without breaking RTCP. I suggest = replacing the above with: Otherwise, mark the RTP stream as not for decoding and discard the=20 payload.=20 > For each RTCP packet received (including each RTCP packet that is > part of a compound RTCP packet), the packet MUST be routed to the > =E2=80=9Cm=3D=E2=80=9C line for the RTP streams it contains = information about. This > routing is type-dependent, as each kind of RTCP packet has its own > mechanism for associating it with the relevant RTP streams. The first sentence might be clearer written =E2=80=9CFor each RTCP = packet received (including each RTCP packet that is part of a compound = RTCP packet), the packet is processed as usual by the RTP layer, then is = passed to the =E2=80=9Cm=3D=E2=80=9C lines corresponding to the RTP = streams it contains information about for further processing.=E2=80=9D > Packets for which no appropriate "m=3D" line can be identified = (i.e., > for unknown RTP streams) are not relevant in the context of this > algorithm and MAY be dropped. This situation may occur with = certain > multiparty RTP topologies. These packets can=E2=80=99t be dropped. They setup state at the RTP = layer that might become relevant when further RTP/RTCP packets are = received (RTCP packets can round-robin SDES items, such as the MID, in = some cases, so these can potentially be important). I suggest changing = this to: RTCP packets for which no appropriate =E2=80=9Cm=3D=E2=80=9C line can = be identified MUST be processed as usual by the RTP layer, updating the metadata associated with the corresponding RTP streams, but are not passed to any =E2=80=9Cm=3D=E2=80=9C line. This situation can occur with = certain multiparty=20 RTP topologies, or when RTCP packets are sent containing a subset=20 of the SDES information. > Rules for handling the various types of RTCP packets are explained > below. Perhaps change to =E2=80=9CRules for additional processing of the = various=E2=80=A6=E2=80=9D, to make it clear that this doesn=E2=80=99t = replace the usual RTCP processing. > If the packet is of type SDES, for each chunk in the packet = whose "If the RTCP packet is=E2=80=A6=E2=80=9D > SSRC is found in the incoming SSRC table, deliver a copy of the > packet to the "m=3D" line associated with that SSRC. In = addition, =E2=80=9Ca copy of the SDES packet=E2=80=9D presumably, since otherwise = it=E2=80=99s ambiguous if the entire compound RTCP packet is delivered = or just the SDES packet. > for any SDES MID items contained in these chunks, if the MID is > found in the table mapping MID to "m=3D" line, update the = incoming > SSRC table to include an entry that maps the chunk=E2=80=99s = SSRC to the =E2=80=9C=E2=80=A6maps the RTP stream associated with the chunk=E2=80=99s = SSRC to=E2=80=A6=E2=80=9D > "m=3D" line associated with that MID, unless the packet is older > than the packet that most recently updated the mapping for this > SSRC, as discussed in [RFC7941], Section 4.2.6. >=20 > Note that if an SDES packet is received as part of a compound = RTCP > packet, the SSRC to "m=3D" line mapping may not exist until the = SDES > packet is handled (e.g., in the case where RTCP for a source is > received before any RTP packets). Therefore, when processing a > compound packet, any contained SDES packet MUST be handled = first. It might be worth referencing RFC 3550 section 6.1, which says: Each individual RTCP packet in the compound packet may be processed independently with no requirements upon the order or combination of packets. =20 as justification for this. > Holmberg, et al. Expires October 2, 2017 [Page = 23] > Internet-Draft Bundled media March = 2017 >=20 >=20 > If the packet is of type BYE, it indicates that the RTP streams =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > referenced in the packet are ending. Therefore, for each SSRC > indicated in the packet that is found in the incoming SSRC = table, =E2=80=9C=E2=80=A6in the BYE packet=E2=80=A6=E2=80=9D > first deliver a copy of the packet to the =E2=80=9Cm=3D" line = associated =E2=80=9C=E2=80=A6a copy of the BYE packet=E2=80=A6=E2=80=9D > with that SSRC, but then remove the entry for that SSRC from the > incoming SSRC table after an appropriate delay to account for > "straggler packets", as specified in [RFC3550], Section 6.2.1. >=20 > If the packet is of type SR or RR, for each report block in the =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > report whose "SSRC of source" is found in the outgoing SSRC = table, > deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line = associated with =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe SR or RR packet=E2=80=9D= ? To avoid confusion when compound RTCP packets are used, I suggest the = latter phrasing here, and in the later sections. > that SSRC. In addition, if the packet is of type SR, and the > sender SSRC for the packet is found in the incoming SSRC table, > deliver a copy of the packet to the =E2=80=9Cm=3D" line = associated with that =E2=80=9Ca copy of the SR packet=E2=80=9D? > SSRC. >=20 > If the implementation supports RTCP XR and the packet is of type > XR, as defined in [RFC3611], for each report block in the report > whose "SSRC of source" is is found in the outgoing SSRC table, > deliver a copy of the RTCP packet to the =E2=80=9Cm=3D" line = associated with =E2=80=9Cthe RTCP packet=E2=80=9D or =E2=80=9Cthe XR packet=E2=80=9D? > that SSRC. In addition, if the sender SSRC for the packet is > found in the incoming SSRC table, deliver a copy of the packet = to =E2=80=9Cthe packet=E2=80=9D -> =E2=80=9Cthe RTCP packet=E2=80=9D or = =E2=80=9Cthe XR packet=E2=80=9D? > the "m=3D" line associated with that SSRC. >=20 > If the packet is a feedback message of type RTPFB or PSFB, as =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > defined in [RFC4585], it will contain a media source SSRC, and > this SSRC is used for routing certain subtypes of feedback > messages. However, several subtypes of PSFB messages include > target SSRC(s) in a section called Feedback Control Information > (FCI). For these messages, the target SSRC(s) are used for > routing. >=20 > If the packet is a feedback message that does not include target =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > SSRCs in its FCI section, and the media source SSRC is found in > the outgoing SSRC table, deliver the packet to the =E2=80=9Cm=3D" = line Which packet?=20 > associated with that SSRC. RTPFB and PSFB types that are = handled > in this way include: >=20 > Generic NACK: [RFC4585] (PT=3DRTPFB, FMT=3D1). >=20 > Picture Loss Indication (PLI): [RFC4585] (PT=3DPSFB, FMT=3D1). >=20 > Slice Loss Indication (SLI): [RFC4585] (PT=3DPSFB, FMT=3D2). >=20 > Reference Picture Selection Indication (RPSI): [RFC4585] > (PT=3DPSFB, FMT=3D3). >=20 >=20 >=20 >=20 >=20 > Holmberg, et al. Expires October 2, 2017 [Page = 24] > Internet-Draft Bundled media March = 2017 >=20 >=20 > If the packet is a feedback message that does include target =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > SSRC(s) in its FCI section, it can either be a request or a > notification. Requests reference a RTP stream that is being = sent > by the message recipient, whereas notifications are responses to > an earlier request, and therefore reference a RTP stream that is > being received by the message recipient. >=20 > If the packet is a feedback request that includes target = SSRC(s), =E2=80=9CIf the RTCP packet is=E2=80=A6=E2=80=9D > for each target SSRC that is found in the outgoing SSRC table, > deliver a copy of the RTCP packet to the "m=3D" line associated = with > that SSRC. PSFB types that are handled in this way include: >=20 > Full Intra Request (FIR): [RFC5104] (PT=3DPSFB, FMT=3D4). >=20 > Temporal-Spatial Trade-off Request (TSTR): [RFC5104] (PT=3DPSFB, > FMT=3D5). >=20 > H.271 Video Back Channel Message (VBCM): [RFC5104] (PT=3DPSFB, > FMT=3D7). >=20 > Layer Refresh Request (LRR): [I-D.ietf-avtext-lrr] (PT=3DPSFB, > FMT=3DTBD). >=20 > If the packet is a feedback notification that include target > SSRC(s), for each target SSRC that is found in the incoming SSRC > table, deliver a copy of the RTCP packet to the "m=3D" line > associated with that SSRC. PSFB types that are handled in this =E2=80=9Cdeliver a copy of the RTCP packet to the =E2=80=9Cm=3D=E2=80=9C = line associated with the RTP stream with matching SSRC=E2=80=9D > way include: >=20 > Temporal-Spatial Trade-off Notification (TSTN): [RFC5104] > (PT=3DPSFB, FMT=3D6). This message is a notification in = response > to a prior TSTR. >=20 > If the packet is of type APP, the only routing information > included is the source of the packet, and therefore the packet > could be related to any existing "m=3D" line. Accordingly, = deliver > a copy of the packet to each =E2=80=9Cm=3D" line. Are APP packets exposed in the WebRTC APIs? Given that we have the data = channel, it=E2=80=99s not clear that we want to support arbitrary = application information passing via RTCP. It might be better to say that = APP packets are processed in an application specific manner, and if the = application doesn=E2=80=99t understand them, they=E2=80=99re not passed = to any m=3D line? Finally, I note that this section of the draft doesn=E2=80=99t mention = the CSRC list anywhere, but should probably do so. As written, RTP = packets with a CSRC list will be delivered to the RTP stream matching = their SSRC in the usual way, then passed up to the m=3D line associated = with that RTP stream. That may well be sufficient, but if so it=E2=80=99s = likely useful to say that, to make the intent clear. Colin --=20 Colin Perkins https://csperkins.org/ From nobody Sat Apr 8 23:54:12 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13C35129435 for ; Sat, 8 Apr 2017 23:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdPLEO3LWvYZ for ; Sat, 8 Apr 2017 23:54:07 -0700 (PDT) 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 B9795129408 for ; Sat, 8 Apr 2017 23:54:06 -0700 (PDT) X-AuditID: c1b4fb25-c27a798000006af2-b0-58e9da8cda44 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 53.45.27378.C8AD9E85; Sun, 9 Apr 2017 08:54:04 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Sun, 9 Apr 2017 08:54:03 +0200 From: Christer Holmberg To: Colin Perkins , "mmusic (E-mail)" Thread-Topic: [MMUSIC] Comments on BUNDLE -37 - RTP handling Thread-Index: AQHSr8FdWx51Nry6SECZI3BgadjWMKG8rSlg Date: Sun, 9 Apr 2017 06:54:35 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5BA24@ESESSMB102.ericsson.se> References: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> In-Reply-To: <0E29A586-1532-498D-86D2-D787D3F9FD3E@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrHLMWRmVeSWpSXmKPExsUyM2K7hG7PrZcRBl8ealgsf3mC0WLq8scs Dkwe0+7fZ/NYsuQnUwBTFJdNSmpOZllqkb5dAlfG82/6BW3/GSvu31jC0sB44AdjFyMnh4SA iUTrieVsXYxcHEIC6xkl7q24yQrhLGaUmHX6KlAVBwebgIVE9z9tkAYRAS+Jp41TWEFsYQFr ie57H1gh4jYSTS9OQ9lGEmc3TmMDaWURUJFoexAIEuYV8JVo7rzGDGILCThIfDi6EKycU8BR 4sbjSWD3MAqISXw/tYYJxGYWEJe49WQ+E8SdAhJL9pxnhrBFJV4+/scKYStJLLr9mQlkFbOA psT6XfoQrYoSU7ofskOsFZQ4OfMJywRGkVlIps5C6JiFpGMWko4FjCyrGEWLU4uTctONjPVS izKTi4vz8/TyUks2MQJj4eCW36o7GC+/cTzEKMDBqMTDmxD7MkKINbGsuDL3EKMEB7OSCO9q H6AQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwcnFINjB3b02o1 m9+oitjySB3QC18tahnHuilwQfCTAB8G6efTVu1dMu1rT/72hS81bh9M6LpyK07TspLf+Ozy +fL+Z1bu/cMaqufhWtaQcnX9dQslQwNWcdW1GROypBqNjpQuSP6Ssifwre3+VTJs6hNYPqr/ DP8rPneDG6c/4wPxgnWF2q4V8Xt2K7EUZyQaajEXFScCAAIZ/zKBAgAA Archived-At: Subject: Re: [MMUSIC] Comments on BUNDLE -37 - RTP handling X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 06:54:11 -0000 SGkgQ29saW4sDQoNClRoYW5rcyBmb3IgeW91ciBpbnB1dCENCg0KV291bGQgaXQgYmUgcG9zc2li bGUgZm9yIHlvdSB0byBjcmVhdGUgYSBwdWxsIHJlcXVlc3Qgd2l0aCB5b3VyIHN1Z2dlc3RlZCBj aGFuZ2VzPw0KDQpCVU5ETEUgY2FuIGJlIGZvdW5kIGF0OiBodHRwczovL2dpdGh1Yi5jb20vY2Ro NHUvZHJhZnQtc2RwLWJ1bmRsZQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQotLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBDb2xpbiBQZXJraW5zDQpTZW50OiAwNyBBcHJpbCAyMDE3IDIw OjA2DQpUbzogbW11c2ljIChFLW1haWwpIDxtbXVzaWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTU1V U0lDXSBDb21tZW50cyBvbiBCVU5ETEUgLTM3IC0gUlRQIGhhbmRsaW5nDQoNCkkgaGF2ZSBzb21l IGNvbW1lbnRzIG9uIEJVTkRMRSAtMzcgLSBhcG9sb2dpZXMgdGhhdCBJIHdhc27igJl0IGFibGUg dG8gcGFydGljaXBhdGUgZnVsbHkgaW4gdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGJlZm9y ZSB0aGUgbWVldGluZy4gDQoNClRoZSBjdXJyZW50IHRleHQgaXMgZ2VuZXJhbGx5IHJlYXNvbmFi bHkgY2xlYXIsIGFuZCBpcyBjZXJ0YWlubHkgcHJlY2lzZWx5IHdyaXR0ZW4sIGJ1dCBJIGRvIHRo aW5rIGl0IGhhcyBzb21lIHByb2JsZW1zLiBNb3N0IG9mIHRoZXNlIHJlbGF0ZSB0byB0aGUgaXNz dWUgb2Ygd2hldGhlciBSVFAgcGFja2V0cyBvciBSVFAgc3RyZWFtcyBhcmUgYmVpbmcgcHJvY2Vz c2VkLiBJIHRoaW5rIGl04oCZcyBpbXBvcnRhbnQgdGhhdCB0aGlzIGRyYWZ0IGlzIHdyaXR0ZW4g aW4gdGVybXMgb2YgaG93IHRvIGFzc29jaWF0ZSBSVFAgc3RyZWFtcyB3aXRoIG09IGxpbmVzLCBy YXRoZXIgdGhhbiBob3cgdG8gcm91dGUgYW5kIGRlbXVsdGlwbGV4IFJUUCBwYWNrZXRzLCBzaW5j ZSBSVFAgcGFja2V0IHJvdXRpbmcgYW5kIGRlbXVsdGlwbGV4aW5nIGlzIGFscmVhZHkgc3BlY2lm aWVkIGJ5IHRoZSB2YXJpb3VzIFJUUCBzcGVjaWZpY2F0aW9ucy4gSW4gcGFydGljdWxhciwgdGhl cmUgYXJlIHNvbWUgcGxhY2VzIHdoZXJlIHRoZSBkcmFmdCBhcyB3cml0dGVuIGNvbmZsYXRlcyB0 aGUgdHdvIGxheWVycyBpbiB3YXlzIHRoYXQgY29uZmxpY3Qgd2l0aCB0aGUgUlRQIGFuZCBSVENQ IHNwZWNpZmljYXRpb25zLCB0aGF0IEnigJl2ZSB0cmllZCB0byBjb3JyZWN0IGJ5IG1vcmUgY2xl YW5seSBzZXBhcmF0aW5nIHRoZSBsYXllcnMuIA0KDQpJ4oCZdmUgdHJpZWQgdG8gd3JpdGUgbXkg c3VnZ2VzdGlvbnMgaW4gYSBwcmVzY3JpcHRpdmUgbWFubmVyLCBrZWVwaW5nIHRvIHRoZSBzdHls ZSBvZiB0aGUgZXhpc3RpbmcgdGV4dCB3aGVyZSBwb3NzaWJsZS4gSG9wZWZ1bGx5IHRoZSByZXN1 bHQgaXMgY2xlYXIgYW5kIHVuZGVyc3RhbmRhYmxlLg0KDQpDb21tZW50cyBsaW5lIGJlbG93Og0K DQo+IDEwLjIuICBBc3NvY2lhdGluZyBSVFAvUlRDUCBTdHJlYW1zIFdpdGggQ29ycmVjdCBTRFAg TWVkaWEgRGVzY3JpcHRpb24NCj4gDQo+ICAgIE5PVEU6IFRoZSB0ZXh0IGluIHRoaXMgc2VjdGlv biBpcyBjb3BpZWQgZnJvbSBBcHBlbmRpeCBCIG9mIEpTRVAuDQo+ICAgIFRoZSBjb21tdW5pdHkg aGFzIG5vdCB5ZXQgYWdyZWVkIG9uIHRoZSB0ZXh0Lg0KPiANCj4gICAgQXMgZGVzY3JpYmVkIGlu IFtSRkMzNTUwXSwgUlRQIHBhY2tldHMgYXJlIGFzc29jaWF0ZWQgd2l0aCBSVFANCj4gICAgc3Ry ZWFtcyBbUkZDNzY1Nl0uICBFYWNoIFJUUCBzdHJlYW0gaXMgaWRlbnRpZmllZCBieSBhbiBTU1JD IHZhbHVlLA0KPiAgICBhbmQgZWFjaCBSVFAgcGFja2V0IGluY2x1ZGVzIGFuIFNTUkMgZmllbGQg dGhhdCBpcyB1c2VkIHRvIGFzc29jaWF0ZQ0KPiAgICB0aGUgcGFja2V0IHdpdGggdGhlIGNvcnJl Y3QgUlRQIHN0cmVhbS4gIFJUQ1AgcGFja2V0cyBhbHNvIHVzZSBTU1JDcw0KPiAgICB0byBpZGVu dGlmeSB3aGljaCBSVFAgc3RyZWFtcyB0aGUgcGFja2V0IHJlbGF0ZXMgdG8uICBIb3dldmVyLCBh IFJUQ1ANCj4gICAgcGFja2V0IGNhbiBjb250YWluIG11bHRpcGxlIFNTUkMgZmllbGRzLCBpbiB0 aGUgY291cnNlIG9mIHByb3ZpZGluZw0KPiAgICBmZWVkYmFjayBvciByZXBvcnRzIG9uIGRpZmZl cmVudCBSVFAgc3RyZWFtcywgYW5kIHRoZXJlZm9yZSBjYW4gYmUNCj4gICAgYXNzb2NpYXRlZCB3 aXRoIG11bHRpcGxlIHN1Y2ggc3RyZWFtcy4NCj4gDQo+ICAgIEluIG9yZGVyIHRvIGJlIGFibGUg dG8gcHJvY2VzcyByZWNlaXZlZCBSVFAvUlRDUCBwYWNrZXRzIGNvcnJlY3RseSwNCj4gICAgaXQg bXVzdCBiZSBwb3NzaWJsZSB0byBhc3NvY2lhdGUgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBjb3Jy ZWN0ICJtPSINCj4gDQo+IA0KPiANCj4gSG9sbWJlcmcsIGV0IGFsLiAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgMjBdDQo+IEludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgIEJ1bmRsZWQgbWVkaWEgICAgICAgICAgICAgICAgICAgTWFyY2ggMjAx Nw0KPiANCj4gDQo+ICAgIGxpbmUsIGFzIHRoZSAibT0iIGxpbmUgYW5kIFNEUCBhdHRyaWJ1dGVz IGFzc29jaWF0ZWQgd2l0aCB0aGUgIm09Ig0KPiAgICBsaW5lIGNvbnRhaW4gaW5mb3JtYXRpb24g bmVlZGVkIHRvIHByb2Nlc3MgdGhlIHBhY2tldHMuDQo+IA0KPiAgICBBcyBhbGwgUlRQIHN0cmVh bXMgYXNzb2NpYXRlZCB3aXRoIGEgQlVORExFIGdyb3VwIHVzZSB0aGUgc2FtZQ0KPiAgICBhZGRy ZXNzOnBvcnQgY29tYmluYXRpb24gZm9yIHNlbmRpbmcgYW5kIHJlY2VpdmluZyBSVFAvUlRDUCBw YWNrZXRzLA0KPiAgICB0aGUgbG9jYWwgYWRkcmVzczpwb3J0IGNvbWJpbmF0aW9uIGNhbm5vdCBi ZSB1c2VkIHRvIGFzc29jaWF0ZSBhbiBSVFANCj4gICAgc3RyZWFtIHdpdGggdGhlIGNvcnJlY3Qg Im09IiBsaW5lLiAgSW4gYWRkaXRpb24sIG11bHRpcGxlIFJUUCBzdHJlYW1zDQo+ICAgIG1pZ2h0 IGJlIGFzc29jaWF0ZWQgd2l0aCB0aGUgc2FtZSAibT0iIGxpbmUuDQo+IA0KPiAgICBBbiBvZmZl cmVyIGFuZCBhbnN3ZXJlciBjYW4gaW5mb3JtIGVhY2ggb3RoZXIgd2hpY2ggU1NSQyB2YWx1ZXMg dGhleQ0KPiAgICB3aWxsIHVzZSBmb3IgYW4gUlRQIHN0cmVhbSBieSB1c2luZyB0aGUgU0RQICdz c3JjJyBhdHRyaWJ1dGUNCj4gICAgW1JGQzU1NzZdLiAgSG93ZXZlciwgYW4gb2ZmZXJlciB3aWxs IG5vdCBrbm93IHdoaWNoIFNTUkMgdmFsdWVzIHRoZQ0KPiAgICBhbnN3ZXJlciB3aWxsIHVzZSB1 bnRpbCB0aGUgb2ZmZXJlciBoYXMgcmVjZWl2ZWQgdGhlIGFuc3dlciBwcm92aWRpbmcNCj4gICAg dGhhdCBpbmZvcm1hdGlvbi4gIER1ZSB0byB0aGlzLCBiZWZvcmUgdGhlIG9mZmVyZXIgaGFzIHJl Y2VpdmVkIHRoZQ0KPiAgICBhbnN3ZXIsIHRoZSBvZmZlcmVyIHdpbGwgbm90IGJlIGFibGUgdG8g YXNzb2NpYXRlIGFuIFJUUCBzdHJlYW0gd2l0aA0KPiAgICB0aGUgY29ycmVjdCAibT0iIGxpbmUg dXNpbmcgdGhlIFNTUkMgdmFsdWUgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFANCj4gICAgc3RyZWFt LiAgSW4gYWRkaXRpb24sIHRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlciBtYXkgc3RhcnQgdXNpbmcg bmV3DQo+ICAgIFNTUkMgdmFsdWVzIG1pZC1zZXNzaW9uLCB3aXRob3V0IGluZm9ybWluZyBlYWNo IG90aGVyIHVzaW5nIHRoZSBTRFANCj4gICAgJ3NzcmMnIGF0dHJpYnV0ZS4NCj4gDQo+ICAgIElu IG9yZGVyIGZvciBhbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciB0byBhbHdheXMgYmUgYWJsZSB0byBh c3NvY2lhdGUNCj4gICAgYW4gUlRQIHN0cmVhbSB3aXRoIHRoZSBjb3JyZWN0ICJtPSIgbGluZSwg dGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyDQo+ICAgIHVzaW5nIHRoZSBCVU5ETEUgZXh0ZW5zaW9u IE1VU1Qgc3VwcG9ydCB0aGUgbWVjaGFuaXNtIGRlZmluZWQgaW4NCj4gICAgc2VjdGlvbiAxNCwg d2hlcmUgdGhlIG9mZmVyZXIgYW5kIGFuc3dlcmVyIGluc2VydCB0aGUgaWRlbnRpZmljYXRpb24t DQo+ICAgIHRhZyBhc3NvY2lhdGVkIHdpdGggYW4gIm09IiBsaW5lIChwcm92aWRlZCBieSB0aGUg cmVtb3RlIHBlZXIpIGludG8NCj4gICAgUlRQIGFuZCBSVENQIHBhY2tldHMgYXNzb2NpYXRlZCB3 aXRoIGEgQlVORExFIGdyb3VwLg0KPiANCj4gICAgV2hlbiB1c2luZyB0aGlzIG1lY2hhbmlzbSwg dGhlIG1hcHBpbmcgZnJvbSBhbiBTU1JDIHRvIGFuDQo+ICAgIGlkZW50aWZpY2F0aW9uLXRhZyBp cyBjYXJyaWVkIGluIFJUUCBoZWFkZXIgZXh0ZW5zaW9ucyBvciBSVENQIFNERVMNCj4gICAgcGFj a2V0cywgYXMgc3BlY2lmaWVkIGluIHNlY3Rpb24gMTQuICBTaW5jZSBhIGNvbXBvdW5kIFJUQ1Ag cGFja2V0DQo+ICAgIGNhbiBjb250YWluIG11bHRpcGxlIFJUQ1AgU0RFUyBwYWNrZXRzLCBhbmQg ZWFjaCBSVENQIFNERVMgcGFja2V0IGNhbg0KPiAgICBjb250YWluIG11bHRpcGxlIGNodW5rcywg YSBzaW5nbGUgUlRDUCBwYWNrZXQgY2FuIGNvbnRhaW4gc2V2ZXJhbA0KPiAgICBTU1JDIHRvIGlk ZW50aWZpY2F0aW9uLXRhZyBtYXBwaW5ncy4gIFRoZSBvZmZlcmVyIGFuZCBhbnN3ZXJlcg0KPiAg ICBtYWludGFpbiB0YWJsZXMgdXNlZCBmb3Igcm91dGluZyB0aGF0IGFyZSB1cGRhdGVkIGVhY2gg dGltZSBhbiBSVFAvDQo+ICAgIFJUQ1AgcGFja2V0IGNvbnRhaW5zIG5ldyBpbmZvcm1hdGlvbiB0 aGF0IGFmZmVjdHMgaG93IHBhY2tldHMgc2hvdWxkDQo+ICAgIGJlIHJvdXRlZC4NCg0KVGhlIHRl eHQgYWJvdmUgbG9va3MgZ29vZC4gSW4gcGFydGljdWxhciwgaXQgY29ycmVjdGx5IGZvY3Vzc2Vz IG9uIGFzc29jaWF0aW5nIFJUUCBzdHJlYW1zIHdpdGggbT0gbGluZXMsIHdoaWNoIGlzIHRoZSBj b3JyZWN0IGxldmVsIG9mIGFic3RyYWN0aW9uLiANCg0KPiAgICBIb3dldmVyLCBzb21lIGltcGxl bWVudGF0aW9ucyBvZiBtYXkgbm90IGluY2x1ZGUgdGhpcyBpZGVudGlmaWNhdGlvbi0NCj4gICAg dGFnIGluIHRoZWlyIFJUUCBhbmQgUlRDUCB0cmFmZmljIHdoZW4gdXNpbmcgdGhlIEJVTkRMRSBt ZWNoYW5pc20sDQo+ICAgIGFuZCBpbnN0ZWFkIHVzZSBhIHBheWxvYWQgdHlwZSBiYXNlZCBtZWNo YW5pc20gZm9yIGRlbXV4aW5nLiAgSW4gdGhpcw0KDQpUaGUgdGVybSDigJxkZW11eGluZ+KAnSBp cyB1bmNsZWFyLiBGb3IgcHJlY2lzaW9uLCBJIHN1Z2dlc3QgY2hhbmdpbmcg4oCcdXNlIGEgcGF5 bG9hZCB0eXBlIGJhc2VkIG1lY2hhbmlzbXMgZm9yIGRlbXV4aW5n4oCdIHRvIOKAnHVzZSBhIHBh eWxvYWQgdHlwZSBiYXNlZCBtZWNoYW5pc20gdG8gYXNzb2NpYXRlIFJUUCBzdHJlYW1zIHdpdGgg U0RQIG09IGxpbmVz4oCdLg0KDQo+ICAgIHNpdHVhdGlvbiwgZWFjaCAibT0iIGxpbmUgTVVTVCB1 c2UgdW5pcXVlIHBheWxvYWQgdHlwZSB2YWx1ZXMsIGluDQo+ICAgIG9yZGVyIGZvciB0aGUgcGF5 bG9hZCB0eXBlIHRvIGJlIGEgcmVsaWFibGUgaW5kaWNhdG9yIG9mIHRoZSByZWxldmFudA0KPiAg ICAibT0iIGxpbmUgZm9yIHRoZSBSVFAgc3RyZWFtLiAgTm90ZSB0aGF0IHdoZW4gdXNpbmcgcGF5 bG9hZCB0eXBlDQo+ICAgIGJhc2VkIGRlbXV4aW5nLA0KDQpTaW1pbGFybHksIGZvciBwcmVjaXNp b24sIEkgc3VnZ2VzdCBjaGFuZ2luZyDigJx3aGVuIHVzaW5nIHBheWxvYWQgdHlwZSBiYXNlZCBk ZW11eGluZ+KAnSB0byDigJx3aGVuIHVzaW5nIHRoZSBwYXlsb2FkIHR5cGUgdG8gYXNzb2NpYXRl IFJUUCBzdHJlYW1zIHdpdGggbT0gbGluZXPigJ0uDQoNCj4gICAgICAgICAgICAgICAgICAgIGFu IFNTUkMgd2lsbCBiZSBtYXBwZWQgdG8gYW4g4oCcbT3igJwgbGluZQ0KDQpTdWdnZXN0IGNoYW5n aW5nIHRvIOKAnGFuIFJUUCBzdHJlYW0sIGlkZW50aWZpZWQgYnkgU1NSQywgd2lsbCBiZSBtYXBw ZWTigKbigJ0gdG8gYmUgY2xlYXIgd2hhdOKAmXMgYmVpbmcgZG9uZS4NCiANCj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJ5IHRoZSBm aXJzdA0KPiAgICBwYWNrZXQgd2l0aCB0aGF0IFNTUkMsIGFuZCB0aGUgbWFwcGluZyB3aWxsIG5v dCBiZSBjaGFuZ2VkIGV2ZW4gaWYNCg0KU3VnZ2VzdCBjaGFuZ2luZyB0byDigJx3aGVuIHRoZSBm aXJzdCBSVFAgcGFja2V0IG9mIHRoYXQgUlRQIHN0cmVhbSBpcyByZWNlaXZlZCwgYW5k4oCm4oCd IHRvIGJlIGNsZWFyLCBzaW5jZSB0aGVyZSBjb3VsZCBiZSBSVENQIHBhY2tldHMgd2l0aCB0aGUg c2FtZSBTU1JDLg0KDQo+ICAgIHRoZSBzYW1lIFNTUkMgaXMgcmVjZWl2ZWQgd2l0aCBhIGRpZmZl cmVudCBwYXlsb2FkIHR5cGUuICBJbiBvdGhlcg0KDQpTdWdnZXN0IGNoYW5naW5nIHRvIOKAnHRo ZSBwYXlsb2FkIHR5cGUgdXNlZCBieSB0aGF0IFJUUCBzdHJlYW0gY2hhbmdlcy4gSW4gb3RoZXLi gJ0gdG8gYmUgcHJlY2lzZS4NCg0KPiAgICB3b3JkcywgdGhlIFNTUkMgY2Fubm90IHRvICJtb3Zl IiB0byBhIGRpZmZlcmVudCAibT0iIGxpbmUgc2ltcGx5IGJ5DQo+ICAgIGNoYW5naW5nIHRoZSBw YXlsb2FkIHR5cGUuDQo+IA0KPiBIb2xtYmVyZywgZXQgYWwuICAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDIsIDIwMTcgICAgICAgICAgICAgICBbUGFnZSAyMV0NCj4gSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgQnVuZGxlZCBtZWRpYSAgICAgICAgICAgICAgICAgICBNYXJjaCAyMDE3DQo+ IA0KPiANCj4gICAgQXBwbGljYXRpb25zIGNhbiBpbXBsZW1lbnQgUlRQIHN0YWNrcyBpbiBtYW55 IGRpZmZlcmVudCB3YXlzLiAgVGhlDQo+ICAgIGFsZ29yaXRobSBiZWxvdyBkZXRhaWxzIG9uZSB3 YXkgdGhhdCBkZW11bHRpcGxleGluZyBjYW4gYmUNCj4gICAgYWNjb21wbGlzaGVkLCBidXQgaXMg bm90IG1lYW50IHRvIGJlIHByZXNjcmlwdGl2ZSBhYm91dCBleGFjdGx5IGhvdw0KDQpUbyBiZSBj bGVhciBhYm91dCB3aGF0IGlzIGJlaW5nIGRlbXVsdGlwbGV4ZWQsIEkgc3VnZ2VzdCBjaGFuZ2lu ZyDigJxvbmUgd2F5IHRoYXQgZGVtdWx0aXBsZXhpbmcgY2FuIGJlIGFjY29tcGxpc2hlZOKAnSB0 byDigJxvbmUgd2F5IHRoYXQgUlRQIHN0cmVhbXMgY2FuIGJlIGFzc29jaWF0ZWQgd2l0aCBtPSBs aW5lc+KAnS4NCg0KPiAgICBhbiBSVFAgc3RhY2sgbmVlZHMgdG8gYmUgaW1wbGVtZW50ZWQuICBB cHBsaWNhdGlvbnMgTUFZIHVzZSBhbnkNCj4gICAgYWxnb3JpdGhtIHRoYXQgYWNoaWV2ZXMgZXF1 aXZhbGVudCByZXN1bHRzIHRvIHRob3NlIGRlc2NyaWJlZCBpbiB0aGUNCj4gICAgYWxnb3JpdGht IGJlbG93Lg0KPiANCj4gICAgVG8gcHJlcGFyZSBmb3IgZGVtdWx0aXBsZXhpbmcgUlRQL1JUQ1Ag cGFja2V0cyB0byB0aGUgY29ycmVjdCAibT0iDQo+ICAgIGxpbmUsIHRoZSBmb2xsb3dpbmcgc3Rl cHMgTVVTVCBiZSBmb2xsb3dlZCBmb3IgZWFjaCBCVU5ETEUgZ3JvdXAuDQoNCkkgc3VnZ2VzdCBj aGFuZ2luZyDigJzigKZwcmVwYXJlIGZvciBkZW11bHRpcGxleGluZyBSVFAvUlRDUCBwYWNrZXRz IHRvIHRoZSBjb3JyZWN04oCm4oCdIHRvIOKAnOKApnByZXBhcmUgdG8gYXNzb2NpYXRlIFJUUCBz dHJlYW1zIHdpdGggdGhlIGNvcnJlY3TigKbigJ0uIFJUUCBhbmQgUlRDUCBwYWNrZXRzIGFyZSBu b3QgZGVtdWx0aXBsZXhlZCB0byBtPSBsaW5lcywgdGhleeKAmXJlIGRlbXVsdGlwbGV4ZWQgaW50 byBSVFAgc3RyZWFtcywgYW5kIHRoZW4gdGhvc2UgUlRQIHN0cmVhbXMgYXJlIGFzc29jaWF0ZWQg d2l0aCBtPSBsaW5lcy4gVGhlIGRpc3RpbmN0aW9uIGlzIGltcG9ydGFudCwgaW4gb3JkZXIgdG8g aW1wbGVtZW50IFJUQ1AgY29ycmVjdGx5LiANCg0KPiAgICAgICBDb25zdHJ1Y3QgYSB0YWJsZSBt YXBwaW5nIE1JRCB0byAibT0iIGxpbmUgZm9yIGVhY2ggIm09IiBsaW5lIGluDQo+ICAgICAgIHRo aXMgQlVORExFIGdyb3VwLiAgTm90ZSB0aGF0IGFuICJtPSIgbGluZSBtYXkgb25seSBoYXZlIG9u ZSBNSUQuDQo+IA0KPiAgICAgICBDb25zdHJ1Y3QgYSB0YWJsZSBtYXBwaW5nIGluY29taW5nIFNT UkMgdG8gIm09IiBsaW5lIGZvciBlYWNoICJtPSINCj4gICAgICAgbGluZSBpbiB0aGlzIEJVTkRM RSBncm91cCBhbmQgZm9yIGVhY2ggU1NSQyBjb25maWd1cmVkIGZvcg0KPiAgICAgICByZWNlaXZp bmcgaW4gdGhhdCDigJxtPSIgbGluZS4NCg0KVGhlIFNTUkMgaXMgYSBwcm9wZXJ0eSBvZiBhbiBS VFAgc3RyZWFtLCBzbyBJIHN1Z2dlc3QgY2hhbmdpbmcg4oCcbWFwcGluZyBpbmNvbWluZyBTU1JD IHRv4oCdIHRvIOKAnG1hcHBpbmcgU1NSQ3Mgb2YgaW5jb21pbmcgUlRQIHN0cmVhbXMgdG/igJ0u DQoNCj4gICAgICAgQ29uc3RydWN0IGEgdGFibGUgbWFwcGluZyBvdXRnb2luZyBTU1JDIHRvICJt PWxpbmUiIGZvciBlYWNoICJtPSINCj4gICAgICAgbGluZSBpbiB0aGlzIEJVTkRMRSBncm91cCBh bmQgZm9yIGVhY2ggU1NSQyBjb25maWd1cmVkIGZvciBzZW5kaW5nDQo+ICAgICAgIGluIHRoYXQg 4oCcbT0iIGxpbmUuDQoNClNpbWlsYXJseSwgY2hhbmdlIOKAnG1hcHBpbmcgb3V0Z29pbmcgU1NS Q+KAnSB0byDigJxtYXBwaW5nIHRoZSBTU1JDIG9mIGVhY2ggb3V0Z29pbmcgUlRQIHN0cmVhbeKA nQ0KDQo+ICAgICAgIENvbnN0cnVjdCBhIHRhYmxlIG1hcHBpbmcgcGF5bG9hZCB0eXBlIHRvICJt PSIgbGluZSBmb3IgZWFjaCAibT0iDQo+ICAgICAgIGxpbmUgaW4gdGhlIEJVTkRMRSBncm91cCBh bmQgZm9yIGVhY2ggcGF5bG9hZCB0eXBlIGNvbmZpZ3VyZWQgZm9yDQo+ICAgICAgIHJlY2Vpdmlu ZyBpbiB0aGF0ICJtPSIgbGluZS4gIElmIGFueSBwYXlsb2FkIHR5cGUgaXMgY29uZmlndXJlZA0K PiAgICAgICBmb3IgcmVjZWl2aW5nIGluIG1vcmUgdGhhbiBvbmUgIm09IiBsaW5lIGluIHRoZSBC VU5ETEUgZ3JvdXAsIGRvDQo+ICAgICAgIG5vdCBpdCBpbmNsdWRlIGl0IGluIHRoZSB0YWJsZSwg YXMgaXQgY2Fubm90IGJlIHVzZWQgdG8gdW5pcXVlbHkNCj4gICAgICAgaWRlbnRpZnkgYSAibT0i IGxpbmUuDQo+IA0KPiAgICAgICBOb3RlIHRoYXQgZm9yIGVhY2ggb2YgdGhlc2UgdGFibGVzLCB0 aGVyZSBjYW4gb25seSBiZSBvbmUgbWFwcGluZw0KPiAgICAgICBmb3IgYW55IGdpdmVuIGtleSAo TUlELCBTU1JDLCBvciBQVCkuICBJbiBvdGhlciB3b3JkcywgdGhlIHRhYmxlcw0KPiAgICAgICBh cmUgbm90IG11bHRpbWFwcy4NCj4gDQo+ICAgIEFzICJtPSIgbGluZXMgYXJlIGFkZGVkIG9yIHJl bW92ZWQgZnJvbSB0aGUgQlVORExFIGdyb3Vwcywgb3IgdGhlaXINCj4gICAgY29uZmlndXJhdGlv bnMgYXJlIGNoYW5nZWQsIHRoZSB0YWJsZXMgYWJvdmUgTVVTVCBhbHNvIGJlIHVwZGF0ZWQuDQo+ IA0KPiAgICBGb3IgZWFjaCBSVFAgcGFja2V0IHJlY2VpdmVkLCB0aGUgZm9sbG93aW5nIHN0ZXBz IE1VU1QgYmUgZm9sbG93ZWQgdG8NCj4gICAgcm91dGUgdGhlIHBhY2tldCB0byB0aGUgY29ycmVj dCAibT0iIHNlY3Rpb24gd2l0aGluIGEgQlVORExFIGdyb3VwLg0KDQpUaGUgZ29hbCBpcyBub3Qg dG8gcm91dGUgUlRQIHBhY2tldHMgdG8gbT0gbGluZXMsIGJ1dCByYXRoZXIgdG8gYXNzb2NpYXRl IHRoZSBjb3JyZXNwb25kaW5nIFJUUCBzdHJlYW1zIHdpdGggbT0gbGluZXMuIFRoaXMga2VlcHMg dGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gUlRQIGFuZCBSVENQIHByb2Nlc3NpbmcgdGhhdCBoYXMg dG8gaGFwcGVuIGlycmVzcGVjdGl2ZSBvZiB0aGUgbT0gbGluZSwgYW5kIHRoZSBhcHBsaWNhdGlv biBsZXZlbCBwcm9jZXNzaW5nIHRoYXQgZGVwZW5kcyBvbiB0aGUgY2hvaWNlIG9mIG09IGxpbmUu IEkgc3VnZ2VzdCBjaGFuZ2luZyB0aGlzIHNlbnRlbmNlIHRvOiDigJxXaGVuIGFuIFJUUCBwYWNr ZXQgaXMgcmVjZWl2ZWQsIGl0IE1VU1QgYmUgZGVsaXZlcmVkIHRvIHRoZSBSVFAgc3RyZWFtIGNv cnJlc3BvbmRpbmcgdG8gaXRzIFNTUkMuIFRoYXQgUlRQIHN0cmVhbSBNVVNUIHRoZW4gYmUgYXNz b2NpYXRlZCB3aXRoIHRoZSBjb3JyZWN0IG09IGxpbmUgd2l0aGluIGEgQlVORExFIGdyb3VwLCBh Y2NvcmRpbmcgdG8gdGhlIGZvbGxvd2luZyBzdGVwcy7igJ0NCg0KPiAgICBOb3RlIHRoYXQgdGhl IHBocmFzZSAnZGVsaXZlciBhIHBhY2tldCB0byB0aGUgIm09IiBsaW5lJyBtZWFucyB0bw0KPiAg ICBmdXJ0aGVyIHByb2Nlc3MgdGhlIHBhY2tldCBhcyB3b3VsZCBub3JtYWxseSBoYXBwZW4gd2l0 aCBSVFAvUlRDUCwgaWYNCj4gICAgaXQgd2VyZSByZWNlaXZlZCBvbiBhIHRyYW5zcG9ydCBhc3Nv Y2lhdGVkIHdpdGggdGhhdCAibT0iIGxpbmUNCj4gICAgb3V0c2lkZSBvZiBhIEJVTkRMRSBncm91 cCAoaS5lLiwgaWYgdGhlICJtPSIgbGluZSB3ZXJlIG5vdCBCVU5ETEVkKSwNCj4gICAgaW5jbHVk aW5nIGRyb3BwaW5nIGFuIFJUUCBwYWNrZXQgaWYgdGhlIHBhY2tldCdzIFBUIGRvZXMgbm90IG1h dGNoDQo+ICAgIGFueSBQVCBpbiB0aGUg4oCcbT0iIGxpbmUuDQoNCkRyb3BwaW5nIFJUUCBwYWNr ZXRzIHdpdGggdW5rbm93biBwYXlsb2FkIHR5cGUgYnJlYWtzIFJUQ1AuIFRoZSBSVFAgcGFja2V0 IG11c3QgYmUgcHJvY2Vzc2VkIGJ5IHRoZSBSVFAgbGF5ZXIgYXMgbm9ybWFsLCB1cGRhdGluZyB0 aGUgc3RhdGlzdGljcyB0aGF0IGFyZSBtYWludGFpbmVkIGJ5IFJUQ1AuIFRoZSBwYXlsb2FkIGlz IHRoZW4gZGlzY2FyZGVkLCBiZWNhdXNlIHRoZXJl4oCZcyBubyBkZWNvZGVyIGFzc29jaWF0ZWQg d2l0aCB0aGUgcGF5bG9hZCB0eXBlLiBJIHN1Z2dlc3QgcmVtb3ZpbmcgdGhpcyBwYXJ0IG9mIHRo ZSBwYXJhZ3JhcGggZW50aXJlbHkuDQoNCj4gICAgICAgSWYgdGhlIHBhY2tldCBoYXMgYSBNSUQs IGFuZCB0aGF0IE1JRCBpcyBub3QgaW4gdGhlIHRhYmxlIG1hcHBpbmcNCj4gICAgICAgTUlEIHRv IOKAnG09IiBsaW5lLCBkcm9wIHRoZSBwYWNrZXQgYW5kIHN0b3AuDQoNCkRyb3BwaW5nIHRoZSBS VFAgcGFja2V0IHdpbGwgYnJlYWsgdGhlIFJUQ1AgcmVwb3J0cy4gVGhlIFJUUCBwYWNrZXQgaGFz IHRvIGJlIHByb2Nlc3NlZCBhcyBub3JtYWwsIGJ1dCB0aGUgY29ycmVzcG9uZGluZyBSVFAgc3Ry ZWFtIGlzIG5vdCBkZWNvZGVkIGlmIGl04oCZcyBub3QgYXNzb2NpYXRlZCB3aXRoIGFuIOKAnG09 4oCcIGxpbmUgKGkuZS4sIHlvdSBkcm9wIHRoZSBwYXlsb2FkLCBub3QgdGhlIFJUUCBwYWNrZXQp LiBJIHN1Z2dlc3QgcmVwbGFjaW5nIHRoZSBhYm92ZSB3aXRoIHNvbWV0aGluZyBsaWtlOg0KDQog ICBJZiB0aGUgTUlEIGFzc29jaWF0ZWQgd2l0aCB0aGUgUlRQIHN0cmVhbSBpcyBub3QgaW4gdGhl IHRhYmxlIG1hcHBpbmcgDQogICBNSUQgdG8g4oCcbT3igJwgbGluZSwgdGhlbiB0aGUgUlRQIHN0 cmVhbSBpcyBub3QgZGVjb2RlZCBhbmQgdGhlIHBheWxvYWQNCiAgIGRhdGEgaXMgZGlzY2FyZGVk Lg0KDQo+ICAgICAgIElmIHRoZSBwYWNrZXQgaGFzIGEgTUlELCBhbmQgdGhlIHBhY2tldCdzIGV4 dGVuZGVkIHNlcXVlbmNlIG51bWJlcg0KPiAgICAgICBpcyBncmVhdGVyIHRoYW4gdGhhdCBvZiB0 aGUgbGFzdCBNSUQgdXBkYXRlLCBhcyBkaXNjdXNzZWQgaW4NCj4gICAgICAgW1JGQzc5NDFdLCBT ZWN0aW9uIDQuMi42LCB1cGRhdGUgdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJsZQ0KPiAg ICAgICB0byBpbmNsdWRlIGFuIGVudHJ5IHRoYXQgbWFwcyB0aGUgcGFja2V0J3MgU1NSQyB0byB0 aGUgIm09IiBsaW5lDQo+ICAgICAgIGZvciB0aGF0IE1JRC4NCg0KVGhlcmUgYXJlIHR3byB0aGlu Z3MgdGhhdCBuZWVkIHRvIGJlIGRvbmUgaGVyZTogdXBkYXRlIHRoZSBNSUQgYXNzb2NpYXRlZCB3 aXRoIHRoZSBSVFAgc3RyZWFtIHRvIG1hdGNoIHRoYXQgaW4gdGhlIG5ld2x5IHJlY2VpdmVkIFJU UCBwYWNrZXQsIGFuZCB1cGRhdGUgdGhlIG1hcHBpbmcgdGFibGUuIEkgc3VnZ2VzdCBjaGFuZ2lu ZyDigJx1cGRhdGUgdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJsZSB0byBpbmNsdWRlIGFu IGVudHJ5IHRoYXQgbWFwcyB0aGUgcGFja2V04oCZcyBTU1JDIHRvIHRoZSDigJxtPeKAnCBsaW5l IGZvciB0aGF0IE1JROKAnSB0byDigJx1cGRhdGUgdGhlIE1JRCBhc3NvY2lhdGVkIHdpdGggdGhl IFJUUCBzdHJlYW0gdG8gbWF0Y2ggdGhlIE1JRCBjYXJyaWVkIGluIHRoZSBSVFAgcGFja2V0LCB0 aGVuIHVwZGF0ZSB0aGUgbWFwcGluZyB0YWJsZXMgdG8gaW5jbHVkZSBhbiBlbnRyeSB0aGF0IG1h cHMgdGhlIFNTUkMgb2YgdGhhdCBSVFAgc3RyZWFtIHRvIHRoZSDigJxtPeKAnCBsaW5lIGZvciB0 aGF0IE1JROKAnS4NCg0KPiAgICAgICBJZiB0aGUgcGFja2V0J3MgU1NSQyBpcyBpbiB0aGUgaW5j b21pbmcgU1NSQyBtYXBwaW5nIHRhYmxlLCBjaGVjaw0KPiAgICAgICB0aGF0IHRoZSBwYWNrZXQn cyBQVCBtYXRjaGVzIGEgUFQgaW5jbHVkZWQgb24gdGhlIGFzc29jaWF0ZWQgIm09Ig0KPiAgICAg ICBsaW5lLiAgSWYgc28sIHJvdXRlIHRoZSBwYWNrZXQgdG8gdGhhdCBhc3NvY2lhdGVkICJtPSIg bGluZSBhbmQNCj4gICAgICAgc3RvcDsgb3RoZXJ3aXNlIGRyb3AgdGhlIHBhY2tldCBhbmQgc3Rv cC4NCg0KRHJvcHBpbmcgdGhlIHBhY2tldCBicmVha3MgUlRDUC4gVGhlIFJUUCBwYWNrZXQgaXMg cHJvY2Vzc2VkIGFzIG5vcm1hbCwgYnV0IHRoZSBjb3JyZXNwb25kaW5nIFJUUCBzdHJlYW0gaXMg bm90IGRlY29kZWQgaWYgaXTigJlzIG5vdCBhc3NvY2lhdGVkIHdpdGggYW4g4oCcbT3igJwgbGlu ZS4gSSBzdWdnZXN0IHJlcGxhY2luZyB0aGUgYWJvdmUgd2l0aDoNCg0KICAgSWYgdGhlIFNTUkMg b2YgdGhlIFJUUCBzdHJlYW0gaXMgaW4gdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJsZSwg DQogICBjaGVjayB0aGF0IHRoZSBwYXlsb2FkIHR5cGUgdXNlZCBieSB0aGUgUlRQIHN0cmVhbSBt YXRjaGVzIGEgcGF5bG9hZA0KICAgdHlwZSBpbmNsdWRlZCBvbiB0aGUgbWF0Y2hpbmcg4oCcbT3i gJwgbGluZS4gSWYgc28sIGFzc29jaWF0ZSB0aGUgUlRQDQogICBzdHJlYW0gd2l0aCB0aGF0IOKA nG094oCcIGxpbmUuIE90aGVyd2lzZSwgdGhlIFJUUCBzdHJlYW0gaXMgbm90IGRlY29kZWQNCiAg IGFuZCB0aGUgcGF5bG9hZCBkYXRhIGlzIGRpc2NhcmRlZC4NCg0KPiAgICAgICBJZiB0aGUgcGFj a2V0J3MgcGF5bG9hZCB0eXBlIGlzIGluIHRoZSBwYXlsb2FkIHR5cGUgdGFibGUsIHVwZGF0ZQ0K PiAgICAgICB0aGUgdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJsZSB0byBpbmNsdWRlIGFu IGVudHJ5IHRoYXQgbWFwcw0KPiAgICAgICB0aGUgcGFja2V0J3MgU1NSQyB0byB0aGUgIm09IiBs aW5lIGZvciB0aGF0IHBheWxvYWQgdHlwZS4gIEluDQo+ICAgICAgIGFkZGl0aW9uLCByb3V0ZSB0 aGUgcGFja2V0IHRvIHRoZSBhc3NvY2lhdGVkIOKAnG09IiBsaW5lIGFuZCBzdG9wLg0KDQpSVFAg cGFja2V0cyBjb3JyZXNwb25kIHRvIFJUUCBzdHJlYW1zLCBhbmQgdGhvc2UgUlRQIHN0cmVhbXMg YXJlIGFzc29jaWF0ZWQgd2l0aCBtPSBsaW5lcy4gU3VnZ2VzdCBjaGFuZ2luZyB0bzoNCg0KICAg SWYgdGhlIHBheWxvYWQgdHlwZSB1c2VkIGJ5IHRoZSBSVFAgc3RyZWFtIGlzIGluIHRoZSBwYXls b2FkIHR5cGUNCiAgIHRhYmxlLCB1cGRhdGUgdGhlIGluY29taW5nIFNTUkMgbWFwcGluZyB0YWJs ZSB0byBpbmNsdWRlIGFuIGVudHJ5DQogICB0aGF0IG1hcHMgdGhlIFJUUCBzdHJlYW3igJlzIFNT UkMgdG8gdGhlIOKAnG094oCcIGxpbmUgZm9yIHRoYXQgcGF5bG9hZA0KICAgdHlwZS4gQXNzb2Np YXRlIHRoZSBSVFAgc3RyZWFtIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcg4oCcbT3igJwgbGluZS4N Cg0KPiAgICAgICBPdGhlcndpc2UsIGRyb3AgdGhlIHBhY2tldC4NCg0KVGhlIHBhY2tldCBjYW5u b3QgYmUgZGlzY2FyZGVkIHdpdGhvdXQgYnJlYWtpbmcgUlRDUC4gSSBzdWdnZXN0IHJlcGxhY2lu ZyB0aGUgYWJvdmUgd2l0aDoNCg0KICAgT3RoZXJ3aXNlLCBtYXJrIHRoZSBSVFAgc3RyZWFtIGFz IG5vdCBmb3IgZGVjb2RpbmcgYW5kIGRpc2NhcmQgdGhlIA0KICAgcGF5bG9hZC4gDQoNCj4gICAg Rm9yIGVhY2ggUlRDUCBwYWNrZXQgcmVjZWl2ZWQgKGluY2x1ZGluZyBlYWNoIFJUQ1AgcGFja2V0 IHRoYXQgaXMNCj4gICAgcGFydCBvZiBhIGNvbXBvdW5kIFJUQ1AgcGFja2V0KSwgdGhlIHBhY2tl dCBNVVNUIGJlIHJvdXRlZCB0byB0aGUNCj4gICAg4oCcbT3igJwgbGluZSBmb3IgdGhlIFJUUCBz dHJlYW1zIGl0IGNvbnRhaW5zIGluZm9ybWF0aW9uIGFib3V0LiAgVGhpcw0KPiAgICByb3V0aW5n IGlzIHR5cGUtZGVwZW5kZW50LCBhcyBlYWNoIGtpbmQgb2YgUlRDUCBwYWNrZXQgaGFzIGl0cyBv d24NCj4gICAgbWVjaGFuaXNtIGZvciBhc3NvY2lhdGluZyBpdCB3aXRoIHRoZSByZWxldmFudCBS VFAgc3RyZWFtcy4NCg0KVGhlIGZpcnN0IHNlbnRlbmNlIG1pZ2h0IGJlIGNsZWFyZXIgd3JpdHRl biDigJxGb3IgZWFjaCBSVENQIHBhY2tldCByZWNlaXZlZCAoaW5jbHVkaW5nIGVhY2ggUlRDUCBw YWNrZXQgdGhhdCBpcyBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUCBwYWNrZXQpLCB0aGUgcGFja2V0 IGlzIHByb2Nlc3NlZCBhcyB1c3VhbCBieSB0aGUgUlRQIGxheWVyLCB0aGVuIGlzIHBhc3NlZCB0 byB0aGUg4oCcbT3igJwgbGluZXMgY29ycmVzcG9uZGluZyB0byB0aGUgUlRQIHN0cmVhbXMgaXQg Y29udGFpbnMgaW5mb3JtYXRpb24gYWJvdXQgZm9yIGZ1cnRoZXIgcHJvY2Vzc2luZy7igJ0NCg0K PiAgICBQYWNrZXRzIGZvciB3aGljaCBubyBhcHByb3ByaWF0ZSAibT0iIGxpbmUgY2FuIGJlIGlk ZW50aWZpZWQgKGkuZS4sDQo+ICAgIGZvciB1bmtub3duIFJUUCBzdHJlYW1zKSBhcmUgbm90IHJl bGV2YW50IGluIHRoZSBjb250ZXh0IG9mIHRoaXMNCj4gICAgYWxnb3JpdGhtIGFuZCBNQVkgYmUg ZHJvcHBlZC4gIFRoaXMgc2l0dWF0aW9uIG1heSBvY2N1ciB3aXRoIGNlcnRhaW4NCj4gICAgbXVs dGlwYXJ0eSBSVFAgdG9wb2xvZ2llcy4NCg0KVGhlc2UgcGFja2V0cyBjYW7igJl0IGJlIGRyb3Bw ZWQuIFRoZXkgc2V0dXAgc3RhdGUgYXQgdGhlIFJUUCBsYXllciB0aGF0IG1pZ2h0IGJlY29tZSBy ZWxldmFudCB3aGVuIGZ1cnRoZXIgUlRQL1JUQ1AgcGFja2V0cyBhcmUgcmVjZWl2ZWQgKFJUQ1Ag cGFja2V0cyBjYW4gcm91bmQtcm9iaW4gU0RFUyBpdGVtcywgc3VjaCBhcyB0aGUgTUlELCBpbiBz b21lIGNhc2VzLCBzbyB0aGVzZSBjYW4gcG90ZW50aWFsbHkgYmUgaW1wb3J0YW50KS4gSSBzdWdn ZXN0IGNoYW5naW5nIHRoaXMgdG86DQoNCiAgIFJUQ1AgcGFja2V0cyBmb3Igd2hpY2ggbm8gYXBw cm9wcmlhdGUg4oCcbT3igJwgbGluZSBjYW4gYmUgaWRlbnRpZmllZA0KICAgTVVTVCBiZSBwcm9j ZXNzZWQgYXMgdXN1YWwgYnkgdGhlIFJUUCBsYXllciwgdXBkYXRpbmcgdGhlIG1ldGFkYXRhDQog ICBhc3NvY2lhdGVkIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgUlRQIHN0cmVhbXMsIGJ1dCBhcmUg bm90IHBhc3NlZA0KICAgdG8gYW55IOKAnG094oCcIGxpbmUuIFRoaXMgc2l0dWF0aW9uIGNhbiBv Y2N1ciB3aXRoIGNlcnRhaW4gbXVsdGlwYXJ0eSANCiAgIFJUUCB0b3BvbG9naWVzLCBvciB3aGVu IFJUQ1AgcGFja2V0cyBhcmUgc2VudCBjb250YWluaW5nIGEgc3Vic2V0IA0KICAgb2YgdGhlIFNE RVMgaW5mb3JtYXRpb24uDQoNCj4gICAgUnVsZXMgZm9yIGhhbmRsaW5nIHRoZSB2YXJpb3VzIHR5 cGVzIG9mIFJUQ1AgcGFja2V0cyBhcmUgZXhwbGFpbmVkDQo+ICAgIGJlbG93Lg0KDQpQZXJoYXBz IGNoYW5nZSB0byDigJxSdWxlcyBmb3IgYWRkaXRpb25hbCBwcm9jZXNzaW5nIG9mIHRoZSB2YXJp b3Vz4oCm4oCdLCB0byBtYWtlIGl0IGNsZWFyIHRoYXQgdGhpcyBkb2VzbuKAmXQgcmVwbGFjZSB0 aGUgdXN1YWwgUlRDUCBwcm9jZXNzaW5nLg0KDQo+ICAgICAgIElmIHRoZSBwYWNrZXQgaXMgb2Yg dHlwZSBTREVTLCBmb3IgZWFjaCBjaHVuayBpbiB0aGUgcGFja2V0IHdob3NlDQoNCiJJZiB0aGUg UlRDUCBwYWNrZXQgaXPigKbigJ0NCg0KPiAgICAgICBTU1JDIGlzIGZvdW5kIGluIHRoZSBpbmNv bWluZyBTU1JDIHRhYmxlLCBkZWxpdmVyIGEgY29weSBvZiB0aGUNCj4gICAgICAgcGFja2V0IHRv IHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1NSQy4gIEluIGFkZGl0aW9uLA0K DQrigJxhIGNvcHkgb2YgdGhlIFNERVMgcGFja2V04oCdIHByZXN1bWFibHksIHNpbmNlIG90aGVy d2lzZSBpdOKAmXMgYW1iaWd1b3VzIGlmIHRoZSBlbnRpcmUgY29tcG91bmQgUlRDUCBwYWNrZXQg aXMgZGVsaXZlcmVkIG9yIGp1c3QgdGhlIFNERVMgcGFja2V0Lg0KDQo+ICAgICAgIGZvciBhbnkg U0RFUyBNSUQgaXRlbXMgY29udGFpbmVkIGluIHRoZXNlIGNodW5rcywgaWYgdGhlIE1JRCBpcw0K PiAgICAgICBmb3VuZCBpbiB0aGUgdGFibGUgbWFwcGluZyBNSUQgdG8gIm09IiBsaW5lLCB1cGRh dGUgdGhlIGluY29taW5nDQo+ICAgICAgIFNTUkMgdGFibGUgdG8gaW5jbHVkZSBhbiBlbnRyeSB0 aGF0IG1hcHMgdGhlIGNodW5r4oCZcyBTU1JDIHRvIHRoZQ0KDQrigJzigKZtYXBzIHRoZSBSVFAg c3RyZWFtIGFzc29jaWF0ZWQgd2l0aCB0aGUgY2h1bmvigJlzIFNTUkMgdG/igKbigJ0NCg0KPiAg ICAgICAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoYXQgTUlELCB1bmxlc3MgdGhlIHBhY2tl dCBpcyBvbGRlcg0KPiAgICAgICB0aGFuIHRoZSBwYWNrZXQgdGhhdCBtb3N0IHJlY2VudGx5IHVw ZGF0ZWQgdGhlIG1hcHBpbmcgZm9yIHRoaXMNCj4gICAgICAgU1NSQywgYXMgZGlzY3Vzc2VkIGlu IFtSRkM3OTQxXSwgU2VjdGlvbiA0LjIuNi4NCj4gDQo+ICAgICAgIE5vdGUgdGhhdCBpZiBhbiBT REVTIHBhY2tldCBpcyByZWNlaXZlZCBhcyBwYXJ0IG9mIGEgY29tcG91bmQgUlRDUA0KPiAgICAg ICBwYWNrZXQsIHRoZSBTU1JDIHRvICJtPSIgbGluZSBtYXBwaW5nIG1heSBub3QgZXhpc3QgdW50 aWwgdGhlIFNERVMNCj4gICAgICAgcGFja2V0IGlzIGhhbmRsZWQgKGUuZy4sIGluIHRoZSBjYXNl IHdoZXJlIFJUQ1AgZm9yIGEgc291cmNlIGlzDQo+ICAgICAgIHJlY2VpdmVkIGJlZm9yZSBhbnkg UlRQIHBhY2tldHMpLiAgVGhlcmVmb3JlLCB3aGVuIHByb2Nlc3NpbmcgYQ0KPiAgICAgICBjb21w b3VuZCBwYWNrZXQsIGFueSBjb250YWluZWQgU0RFUyBwYWNrZXQgTVVTVCBiZSBoYW5kbGVkIGZp cnN0Lg0KDQpJdCBtaWdodCBiZSB3b3J0aCByZWZlcmVuY2luZyBSRkMgMzU1MCBzZWN0aW9uIDYu MSwgd2hpY2ggc2F5czoNCg0KICAgRWFjaCBpbmRpdmlkdWFsIFJUQ1AgcGFja2V0IGluIHRoZSBj b21wb3VuZCBwYWNrZXQgbWF5IGJlIHByb2Nlc3NlZA0KICAgaW5kZXBlbmRlbnRseSB3aXRoIG5v IHJlcXVpcmVtZW50cyB1cG9uIHRoZSBvcmRlciBvciBjb21iaW5hdGlvbiBvZg0KICAgcGFja2V0 cy4gIA0KDQphcyBqdXN0aWZpY2F0aW9uIGZvciB0aGlzLg0KDQo+IEhvbG1iZXJnLCBldCBhbC4g ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMiwgMjAxNyAgICAgICAgICAgICAgIFtQYWdlIDIzXQ0K PiBJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBCdW5kbGVkIG1lZGlhICAgICAgICAgICAg ICAgICAgIE1hcmNoIDIwMTcNCj4gDQo+IA0KPiAgICAgICBJZiB0aGUgcGFja2V0IGlzIG9mIHR5 cGUgQllFLCBpdCBpbmRpY2F0ZXMgdGhhdCB0aGUgUlRQIHN0cmVhbXMNCg0K4oCcSWYgdGhlIFJU Q1AgcGFja2V0IGlz4oCm4oCdDQoNCj4gICAgICAgcmVmZXJlbmNlZCBpbiB0aGUgcGFja2V0IGFy ZSBlbmRpbmcuICBUaGVyZWZvcmUsIGZvciBlYWNoIFNTUkMNCj4gICAgICAgaW5kaWNhdGVkIGlu IHRoZSBwYWNrZXQgdGhhdCBpcyBmb3VuZCBpbiB0aGUgaW5jb21pbmcgU1NSQyB0YWJsZSwNCg0K 4oCc4oCmaW4gdGhlIEJZRSBwYWNrZXTigKbigJ0NCg0KPiAgICAgICBmaXJzdCBkZWxpdmVyIGEg Y29weSBvZiB0aGUgcGFja2V0IHRvIHRoZSDigJxtPSIgbGluZSBhc3NvY2lhdGVkDQoNCuKAnOKA pmEgY29weSBvZiB0aGUgQllFIHBhY2tldOKApuKAnQ0KDQo+ICAgICAgIHdpdGggdGhhdCBTU1JD LCBidXQgdGhlbiByZW1vdmUgdGhlIGVudHJ5IGZvciB0aGF0IFNTUkMgZnJvbSB0aGUNCj4gICAg ICAgaW5jb21pbmcgU1NSQyB0YWJsZSBhZnRlciBhbiBhcHByb3ByaWF0ZSBkZWxheSB0byBhY2Nv dW50IGZvcg0KPiAgICAgICAic3RyYWdnbGVyIHBhY2tldHMiLCBhcyBzcGVjaWZpZWQgaW4gW1JG QzM1NTBdLCBTZWN0aW9uIDYuMi4xLg0KPiANCj4gICAgICAgSWYgdGhlIHBhY2tldCBpcyBvZiB0 eXBlIFNSIG9yIFJSLCBmb3IgZWFjaCByZXBvcnQgYmxvY2sgaW4gdGhlDQoNCuKAnElmIHRoZSBS VENQIHBhY2tldCBpc+KApuKAnQ0KDQo+ICAgICAgIHJlcG9ydCB3aG9zZSAiU1NSQyBvZiBzb3Vy Y2UiIGlzIGZvdW5kIGluIHRoZSBvdXRnb2luZyBTU1JDIHRhYmxlLA0KPiAgICAgICBkZWxpdmVy IGEgY29weSBvZiB0aGUgUlRDUCBwYWNrZXQgdG8gdGhlIOKAnG09IiBsaW5lIGFzc29jaWF0ZWQg d2l0aA0KDQrigJx0aGUgUlRDUCBwYWNrZXTigJ0gb3Ig4oCcdGhlIFNSIG9yIFJSIHBhY2tldOKA nT8gVG8gYXZvaWQgY29uZnVzaW9uIHdoZW4gY29tcG91bmQgUlRDUCBwYWNrZXRzIGFyZSB1c2Vk LCBJIHN1Z2dlc3QgdGhlIGxhdHRlciBwaHJhc2luZyBoZXJlLCBhbmQgaW4gdGhlIGxhdGVyIHNl Y3Rpb25zLg0KDQo+ICAgICAgIHRoYXQgU1NSQy4gIEluIGFkZGl0aW9uLCBpZiB0aGUgcGFja2V0 IGlzIG9mIHR5cGUgU1IsIGFuZCB0aGUNCj4gICAgICAgc2VuZGVyIFNTUkMgZm9yIHRoZSBwYWNr ZXQgaXMgZm91bmQgaW4gdGhlIGluY29taW5nIFNTUkMgdGFibGUsDQo+ICAgICAgIGRlbGl2ZXIg YSBjb3B5IG9mIHRoZSBwYWNrZXQgdG8gdGhlIOKAnG09IiBsaW5lIGFzc29jaWF0ZWQgd2l0aCB0 aGF0DQoNCuKAnGEgY29weSBvZiB0aGUgU1IgcGFja2V04oCdPw0KDQo+ICAgICAgIFNTUkMuDQo+ IA0KPiAgICAgICBJZiB0aGUgaW1wbGVtZW50YXRpb24gc3VwcG9ydHMgUlRDUCBYUiBhbmQgdGhl IHBhY2tldCBpcyBvZiB0eXBlDQo+ICAgICAgIFhSLCBhcyBkZWZpbmVkIGluIFtSRkMzNjExXSwg Zm9yIGVhY2ggcmVwb3J0IGJsb2NrIGluIHRoZSByZXBvcnQNCj4gICAgICAgd2hvc2UgIlNTUkMg b2Ygc291cmNlIiBpcyBpcyBmb3VuZCBpbiB0aGUgb3V0Z29pbmcgU1NSQyB0YWJsZSwNCj4gICAg ICAgZGVsaXZlciBhIGNvcHkgb2YgdGhlIFJUQ1AgcGFja2V0IHRvIHRoZSDigJxtPSIgbGluZSBh c3NvY2lhdGVkIHdpdGgNCg0K4oCcdGhlIFJUQ1AgcGFja2V04oCdIG9yIOKAnHRoZSBYUiBwYWNr ZXTigJ0/DQoNCj4gICAgICAgdGhhdCBTU1JDLiAgSW4gYWRkaXRpb24sIGlmIHRoZSBzZW5kZXIg U1NSQyBmb3IgdGhlIHBhY2tldCBpcw0KPiAgICAgICBmb3VuZCBpbiB0aGUgaW5jb21pbmcgU1NS QyB0YWJsZSwgZGVsaXZlciBhIGNvcHkgb2YgdGhlIHBhY2tldCB0bw0KDQrigJx0aGUgcGFja2V0 4oCdIC0+IOKAnHRoZSBSVENQIHBhY2tldOKAnSBvciDigJx0aGUgWFIgcGFja2V04oCdPw0KDQo+ ICAgICAgIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoYXQgU1NSQy4NCj4gDQo+ICAg ICAgIElmIHRoZSBwYWNrZXQgaXMgYSBmZWVkYmFjayBtZXNzYWdlIG9mIHR5cGUgUlRQRkIgb3Ig UFNGQiwgYXMNCg0K4oCcSWYgdGhlIFJUQ1AgcGFja2V0IGlz4oCm4oCdDQoNCj4gICAgICAgZGVm aW5lZCBpbiBbUkZDNDU4NV0sIGl0IHdpbGwgY29udGFpbiBhIG1lZGlhIHNvdXJjZSBTU1JDLCBh bmQNCj4gICAgICAgdGhpcyBTU1JDIGlzIHVzZWQgZm9yIHJvdXRpbmcgY2VydGFpbiBzdWJ0eXBl cyBvZiBmZWVkYmFjaw0KPiAgICAgICBtZXNzYWdlcy4gIEhvd2V2ZXIsIHNldmVyYWwgc3VidHlw ZXMgb2YgUFNGQiBtZXNzYWdlcyBpbmNsdWRlDQo+ICAgICAgIHRhcmdldCBTU1JDKHMpIGluIGEg c2VjdGlvbiBjYWxsZWQgRmVlZGJhY2sgQ29udHJvbCBJbmZvcm1hdGlvbg0KPiAgICAgICAoRkNJ KS4gIEZvciB0aGVzZSBtZXNzYWdlcywgdGhlIHRhcmdldCBTU1JDKHMpIGFyZSB1c2VkIGZvcg0K PiAgICAgICByb3V0aW5nLg0KPiANCj4gICAgICAgSWYgdGhlIHBhY2tldCBpcyBhIGZlZWRiYWNr IG1lc3NhZ2UgdGhhdCBkb2VzIG5vdCBpbmNsdWRlIHRhcmdldA0KDQrigJxJZiB0aGUgUlRDUCBw YWNrZXQgaXPigKbigJ0NCg0KPiAgICAgICBTU1JDcyBpbiBpdHMgRkNJIHNlY3Rpb24sIGFuZCB0 aGUgbWVkaWEgc291cmNlIFNTUkMgaXMgZm91bmQgaW4NCj4gICAgICAgdGhlIG91dGdvaW5nIFNT UkMgdGFibGUsIGRlbGl2ZXIgdGhlIHBhY2tldCB0byB0aGUg4oCcbT0iIGxpbmUNCg0KV2hpY2gg cGFja2V0PyANCg0KPiAgICAgICBhc3NvY2lhdGVkIHdpdGggdGhhdCBTU1JDLiAgUlRQRkIgYW5k IFBTRkIgdHlwZXMgdGhhdCBhcmUgaGFuZGxlZA0KPiAgICAgICBpbiB0aGlzIHdheSBpbmNsdWRl Og0KPiANCj4gICAgICAgR2VuZXJpYyBOQUNLOiAgW1JGQzQ1ODVdIChQVD1SVFBGQiwgRk1UPTEp Lg0KPiANCj4gICAgICAgUGljdHVyZSBMb3NzIEluZGljYXRpb24gKFBMSSk6ICBbUkZDNDU4NV0g KFBUPVBTRkIsIEZNVD0xKS4NCj4gDQo+ICAgICAgIFNsaWNlIExvc3MgSW5kaWNhdGlvbiAoU0xJ KTogIFtSRkM0NTg1XSAoUFQ9UFNGQiwgRk1UPTIpLg0KPiANCj4gICAgICAgUmVmZXJlbmNlIFBp Y3R1cmUgU2VsZWN0aW9uIEluZGljYXRpb24gKFJQU0kpOiAgW1JGQzQ1ODVdDQo+ICAgICAgICAg IChQVD1QU0ZCLCBGTVQ9MykuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSG9sbWJlcmcsIGV0IGFs LiAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyLCAyMDE3ICAgICAgICAgICAgICAgW1BhZ2UgMjRd DQo+IEludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgIEJ1bmRsZWQgbWVkaWEgICAgICAgICAg ICAgICAgICAgTWFyY2ggMjAxNw0KPiANCj4gDQo+ICAgICAgIElmIHRoZSBwYWNrZXQgaXMgYSBm ZWVkYmFjayBtZXNzYWdlIHRoYXQgZG9lcyBpbmNsdWRlIHRhcmdldA0KDQrigJxJZiB0aGUgUlRD UCBwYWNrZXQgaXPigKbigJ0NCg0KPiAgICAgICBTU1JDKHMpIGluIGl0cyBGQ0kgc2VjdGlvbiwg aXQgY2FuIGVpdGhlciBiZSBhIHJlcXVlc3Qgb3IgYQ0KPiAgICAgICBub3RpZmljYXRpb24uICBS ZXF1ZXN0cyByZWZlcmVuY2UgYSBSVFAgc3RyZWFtIHRoYXQgaXMgYmVpbmcgc2VudA0KPiAgICAg ICBieSB0aGUgbWVzc2FnZSByZWNpcGllbnQsIHdoZXJlYXMgbm90aWZpY2F0aW9ucyBhcmUgcmVz cG9uc2VzIHRvDQo+ICAgICAgIGFuIGVhcmxpZXIgcmVxdWVzdCwgYW5kIHRoZXJlZm9yZSByZWZl cmVuY2UgYSBSVFAgc3RyZWFtIHRoYXQgaXMNCj4gICAgICAgYmVpbmcgcmVjZWl2ZWQgYnkgdGhl IG1lc3NhZ2UgcmVjaXBpZW50Lg0KPiANCj4gICAgICAgSWYgdGhlIHBhY2tldCBpcyBhIGZlZWRi YWNrIHJlcXVlc3QgdGhhdCBpbmNsdWRlcyB0YXJnZXQgU1NSQyhzKSwNCg0K4oCcSWYgdGhlIFJU Q1AgcGFja2V0IGlz4oCm4oCdDQoNCj4gICAgICAgZm9yIGVhY2ggdGFyZ2V0IFNTUkMgdGhhdCBp cyBmb3VuZCBpbiB0aGUgb3V0Z29pbmcgU1NSQyB0YWJsZSwNCj4gICAgICAgZGVsaXZlciBhIGNv cHkgb2YgdGhlIFJUQ1AgcGFja2V0IHRvIHRoZSAibT0iIGxpbmUgYXNzb2NpYXRlZCB3aXRoDQo+ ICAgICAgIHRoYXQgU1NSQy4gIFBTRkIgdHlwZXMgdGhhdCBhcmUgaGFuZGxlZCBpbiB0aGlzIHdh eSBpbmNsdWRlOg0KPiANCj4gICAgICAgRnVsbCBJbnRyYSBSZXF1ZXN0IChGSVIpOiAgW1JGQzUx MDRdIChQVD1QU0ZCLCBGTVQ9NCkuDQo+IA0KPiAgICAgICBUZW1wb3JhbC1TcGF0aWFsIFRyYWRl LW9mZiBSZXF1ZXN0IChUU1RSKTogIFtSRkM1MTA0XSAoUFQ9UFNGQiwNCj4gICAgICAgICAgRk1U PTUpLg0KPiANCj4gICAgICAgSC4yNzEgVmlkZW8gQmFjayBDaGFubmVsIE1lc3NhZ2UgKFZCQ00p OiAgW1JGQzUxMDRdIChQVD1QU0ZCLA0KPiAgICAgICAgICBGTVQ9NykuDQo+IA0KPiAgICAgICBM YXllciBSZWZyZXNoIFJlcXVlc3QgKExSUik6ICBbSS1ELmlldGYtYXZ0ZXh0LWxycl0gKFBUPVBT RkIsDQo+ICAgICAgICAgIEZNVD1UQkQpLg0KPiANCj4gICAgICAgSWYgdGhlIHBhY2tldCBpcyBh IGZlZWRiYWNrIG5vdGlmaWNhdGlvbiB0aGF0IGluY2x1ZGUgdGFyZ2V0DQo+ICAgICAgIFNTUkMo cyksIGZvciBlYWNoIHRhcmdldCBTU1JDIHRoYXQgaXMgZm91bmQgaW4gdGhlIGluY29taW5nIFNT UkMNCj4gICAgICAgdGFibGUsIGRlbGl2ZXIgYSBjb3B5IG9mIHRoZSBSVENQIHBhY2tldCB0byB0 aGUgIm09IiBsaW5lDQo+ICAgICAgIGFzc29jaWF0ZWQgd2l0aCB0aGF0IFNTUkMuICBQU0ZCIHR5 cGVzIHRoYXQgYXJlIGhhbmRsZWQgaW4gdGhpcw0KDQrigJxkZWxpdmVyIGEgY29weSBvZiB0aGUg UlRDUCBwYWNrZXQgdG8gdGhlIOKAnG094oCcIGxpbmUgYXNzb2NpYXRlZCB3aXRoIHRoZSBSVFAg c3RyZWFtIHdpdGggbWF0Y2hpbmcgU1NSQ+KAnQ0KDQo+ICAgICAgIHdheSBpbmNsdWRlOg0KPiAN Cj4gICAgICAgVGVtcG9yYWwtU3BhdGlhbCBUcmFkZS1vZmYgTm90aWZpY2F0aW9uIChUU1ROKTog IFtSRkM1MTA0XQ0KPiAgICAgICAgICAoUFQ9UFNGQiwgRk1UPTYpLiAgVGhpcyBtZXNzYWdlIGlz IGEgbm90aWZpY2F0aW9uIGluIHJlc3BvbnNlDQo+ICAgICAgICAgIHRvIGEgcHJpb3IgVFNUUi4N Cj4gDQo+ICAgICAgIElmIHRoZSBwYWNrZXQgaXMgb2YgdHlwZSBBUFAsIHRoZSBvbmx5IHJvdXRp bmcgaW5mb3JtYXRpb24NCj4gICAgICAgaW5jbHVkZWQgaXMgdGhlIHNvdXJjZSBvZiB0aGUgcGFj a2V0LCBhbmQgdGhlcmVmb3JlIHRoZSBwYWNrZXQNCj4gICAgICAgY291bGQgYmUgcmVsYXRlZCB0 byBhbnkgZXhpc3RpbmcgIm09IiBsaW5lLiAgQWNjb3JkaW5nbHksIGRlbGl2ZXINCj4gICAgICAg YSBjb3B5IG9mIHRoZSBwYWNrZXQgdG8gZWFjaCDigJxtPSIgbGluZS4NCg0KQXJlIEFQUCBwYWNr ZXRzIGV4cG9zZWQgaW4gdGhlIFdlYlJUQyBBUElzPyBHaXZlbiB0aGF0IHdlIGhhdmUgdGhlIGRh dGEgY2hhbm5lbCwgaXTigJlzIG5vdCBjbGVhciB0aGF0IHdlIHdhbnQgdG8gc3VwcG9ydCBhcmJp dHJhcnkgYXBwbGljYXRpb24gaW5mb3JtYXRpb24gcGFzc2luZyB2aWEgUlRDUC4gSXQgbWlnaHQg YmUgYmV0dGVyIHRvIHNheSB0aGF0IEFQUCBwYWNrZXRzIGFyZSBwcm9jZXNzZWQgaW4gYW4gYXBw bGljYXRpb24gc3BlY2lmaWMgbWFubmVyLCBhbmQgaWYgdGhlIGFwcGxpY2F0aW9uIGRvZXNu4oCZ dCB1bmRlcnN0YW5kIHRoZW0sIHRoZXnigJlyZSBub3QgcGFzc2VkIHRvIGFueSBtPSBsaW5lPw0K DQpGaW5hbGx5LCBJIG5vdGUgdGhhdCB0aGlzIHNlY3Rpb24gb2YgdGhlIGRyYWZ0IGRvZXNu4oCZ dCBtZW50aW9uIHRoZSBDU1JDIGxpc3QgYW55d2hlcmUsIGJ1dCBzaG91bGQgcHJvYmFibHkgZG8g c28uIEFzIHdyaXR0ZW4sIFJUUCBwYWNrZXRzIHdpdGggYSBDU1JDIGxpc3Qgd2lsbCBiZSBkZWxp dmVyZWQgdG8gdGhlIFJUUCBzdHJlYW0gbWF0Y2hpbmcgdGhlaXIgU1NSQyBpbiB0aGUgdXN1YWwg d2F5LCB0aGVuIHBhc3NlZCB1cCB0byB0aGUgbT0gbGluZSBhc3NvY2lhdGVkIHdpdGggdGhhdCBS VFAgc3RyZWFtLiBUaGF0IG1heSB3ZWxsIGJlIHN1ZmZpY2llbnQsIGJ1dCBpZiBzbyBpdOKAmXMg bGlrZWx5IHVzZWZ1bCB0byBzYXkgdGhhdCwgdG8gbWFrZSB0aGUgaW50ZW50IGNsZWFyLg0KDQpD b2xpbg0KDQoNCg0KDQotLSANCkNvbGluIFBlcmtpbnMNCmh0dHBzOi8vY3NwZXJraW5zLm9yZy8N Cg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCg== From nobody Sun Apr 9 00:14:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9891126D85; Sun, 9 Apr 2017 00:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oRh1259sXSb; Sun, 9 Apr 2017 00:14:04 -0700 (PDT) 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 2FB68127ABE; Sun, 9 Apr 2017 00:14:01 -0700 (PDT) X-AuditID: c1b4fb2d-18964980000033e1-bd-58e9df3794a6 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id A1.DB.13281.73FD9E85; Sun, 9 Apr 2017 09:13:59 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Sun, 9 Apr 2017 09:13:58 +0200 From: Christer Holmberg To: "mmusic (E-mail)" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: DTLS-SDP: TLS support added Thread-Index: AdKxB4Lc4UmU6rXIStewG5QwlYhu+Q== Date: Sun, 9 Apr 2017 07:14:30 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5BAC0@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5BAC0ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbFdVNf8/ssIg4/LhC3md55mtzi/cz2T xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxr93gKHmhWfNu1ga2BcYtKFyMn h4SAicTHOysZuxi5OIQE1jNKHNm/BspZzCjxZ+U7pi5GDg42AQuJ7n/aIA0iAuoSrZv7WEFs ZoFwiTlvzoDZwgIqEte2nGSHqNGU2N7aywZh60m86LgKFmcBqvl47CwTiM0r4CvRfnELI4jN KCAm8f3UGiaImeISt57MZ4I4TkBiyZ7zzBC2qMTLx/9YIWwliUW3P0PV50u0XHnPDjFTUOLk zCcsExiFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0Vo2hxanFxbrqR sV5qUWZycXF+nl5easkmRmC8HNzyW3cH4+rXjocYBTgYlXh4E2JfRgixJpYVV+YeYpTgYFYS 4V3tAxTiTUmsrEotyo8vKs1JLT7EKM3BoiTO67DvQoSQQHpiSWp2ampBahFMlomDU6qBsfP1 4j/eXJV94t9daxZsPjeHlTO4qvuytO6PjDMTfVjVCy8lt/sKVv+9qMp38mvPXS/25LmMqZEP H/x0jOrSXPrwsWTFc+7y2F3hd8Wvx8y4q3epxG+FufSsnwnqf8vfNB/7UR8dHRJuOtdltWyQ 4zOZNYoXrZa+DkiaYF37KOb83OMaGZpXlViKMxINtZiLihMB6//vkJMCAAA= Archived-At: Subject: [MMUSIC] DTLS-SDP: TLS support added X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Apr 2017 07:14:06 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5BAC0ESESSMB102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attrib= ute also for TLS connections, I have created a pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/26 Note that the name of the attribute has now been changed to 'tls-id'. The approach I've taken is: rather than talking about both DTLS and TLS thr= oughout the document, I've basically added a section describing the TLS-spe= cific considerations - mainly regarding the interaction with the SDP 'conne= ction' attribute. Now, I think we do need some text on WHY we also cover TLS connections sinc= e, as far as creating new connections is concerned, the 'connection' attrib= ute can be used. We know that it would be needed for draft-thomson-avtcore-= sdp-uks (https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). = But, AFAIK that work has not been adopted yet, so I don't think we can use = it as justification at this point? Note that this pull request does NOT include any of the changes to be done = based on the gen-art/sec-dir reviews. I have updated the 4572-update refere= nce, though. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB5BAC0ESESSMB102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the decision in Chicago to allow usage of t= he SDP ‘dtls-id’ attribute also for TLS connections, I have cre= ated a pull request:

 

https://github.com/cdh4u/draft-dtls-sdp/pull/26

 

Note that the name of the attribute has now been cha= nged to ‘tls-id’.

 

The approach I’ve taken is: rather than talkin= g about both DTLS and TLS throughout the document, I’ve basically add= ed a section describing the TLS-specific considerations – mainly rega= rding the interaction with the SDP ‘connection’ attribute.=

 

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the ‘connection’ attribute can be used. We know that it would b= e needed for draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/d= oc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don’t think we c= an use it as justification at this point?

 

Note that this pull request does NOT include any of = the changes to be done based on the gen-art/sec-dir reviews. I have updated= the 4572-update reference, though.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB5BAC0ESESSMB102erics_-- From nobody Mon Apr 10 12:09:20 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F7A129AC5; Mon, 10 Apr 2017 12:09:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 YlX4l_1FMao7; Mon, 10 Apr 2017 12:09:16 -0700 (PDT) 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 8CBF6127601; Mon, 10 Apr 2017 12:09:15 -0700 (PDT) X-AuditID: c1b4fb30-abffb70000006667-e6-58ebd85710b3 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 14.56.26215.758DBE85; Mon, 10 Apr 2017 21:09:13 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:09:11 +0200 From: Christer Holmberg To: Christer Holmberg , "mmusic (E-mail)" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: SDP connection attribute optional [was: DTLS-SDP: TLS support added] Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9g== Date: Mon, 10 Apr 2017 19:09:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E1CCESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGbHdQzfyxusIgw9TdC3md55mtzi/cz2T xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxt6z8xFizPrjiyvImxgXFFXBcj J4eEgInEj7W9jF2MXBxCAusZJdpfTGGBcJYwSsx5v4m1i5GDg03AQqL7nzZIg4hArMSOnl52 EJtZIFxizpszYCXCAr4S6+fxQZSESBxdP5UdwtaTuDS1jRnEZhFQlXi18QkTiM0LVP5nxRtG EJtRQEzi+6k1TBAjxSVuPZnPBHGbgMSSPeeZIWxRiZeP/7FC2EoSK7ZfYoSoz5eYdnMiI8RM QYmTM5+wTGAUmoVk1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjKLFqcVJ uelGRnqpRZnJxcX5eXp5qSWbGIHxcnDLb4MdjC+fOx5iFOBgVOLhfdD/OkKINbGsuDL3EKME B7OSCK/eIaAQb0piZVVqUX58UWlOavEhRmkOFiVxXsd9FyKEBNITS1KzU1MLUotgskwcnFIN jCVnvu5UknLg7rfyNhVxzfwfsNC8+a+uQUzsTicXrT3LlY/9dHW2+HOm7NCTM+/5dk5UCuxv mlXCGt4hpPWkhn3R59Iz9mu6Jid87gqyqHU5/E/7QvTZ0xxP5s/SPycalX9y4fYFX4SaFP+1 ROSGzeVRd8x9HBvWfu8Lu+n/892pwudigpPllFiKMxINtZiLihMBDSqLQ5MCAAA= Archived-At: Subject: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:09:18 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5E1CCESESSMB102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Section XXX of RFC 4145 says: "When an offerer generates an 'm' line that uses TCP, it SHOULD provide = a connection attribute for the 'm' line unless the application using the 'm' line has other means to deal with connection reestablishment." Now, if both endpoints support the 'tls-id' attribute, that would be "other= means". However, section of RFC 4145 says: "The default value of the connection attribute in both offers and answers is 'new'." So, I think we need to say something. Either: 1) If both endpoints support tls-id, they don't need to care about the= connection attribute (or the default value in case the attribute is not pr= esent); OR 2) We mandate that the connection attribute is present, with an 'exist= ing' value, whenever an existing connection is to be maintained. Option 2) seems most safe, i.e., we continue using the 'connection' attribu= te and its semantics even if both endpoints support the 'tls-id' attribute. Comments? Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 09 April 2017 10:15 To: mmusic (E-mail) Cc: mmusic-chairs@ietf.org; Ben Campbell Subject: [MMUSIC] DTLS-SDP: TLS support added Hi, Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attrib= ute also for TLS connections, I have created a pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/26 Note that the name of the attribute has now been changed to 'tls-id'. The approach I've taken is: rather than talking about both DTLS and TLS thr= oughout the document, I've basically added a section describing the TLS-spe= cific considerations - mainly regarding the interaction with the SDP 'conne= ction' attribute. Now, I think we do need some text on WHY we also cover TLS connections sinc= e, as far as creating new connections is concerned, the 'connection' attrib= ute can be used. We know that it would be needed for draft-thomson-avtcore-= sdp-uks (https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). = But, AFAIK that work has not been adopted yet, so I don't think we can use = it as justification at this point? Note that this pull request does NOT include any of the changes to be done = based on the gen-art/sec-dir reviews. I have updated the 4572-update refere= nce, though. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB5E1CCESESSMB102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

Section XXX of RFC 414= 5 says:

 

   “When an off= erer generates an 'm' line that uses TCP, it SHOULD provide a

   connection attribu= te for the 'm' line unless the application using

   the 'm' line has o= ther means to deal with connection reestablishment.”

 

Now, if both endpoints= support the ‘tls-id’ attribute, that would be “other mea= ns”.

 

However, section of RF= C 4145 says:

 

   “The default value of the connection attribute in b=
oth offers and
   answers is 'new'.”

 

So, I think we need to= say something. Either:

 

1)&= nbsp;     If both endpoi= nts support tls-id, they don’t need to care about the connection attr= ibute (or the default value in case the attribute is not present); OR<= /o:p>

2)&= nbsp;     We mandate tha= t the connection attribute is present, with an ‘existing’ value= , whenever an existing connection is to be maintained.

 

Option 2) seems most s= afe, i.e., we continue using the ‘connection’ attribute and its= semantics even if both endpoints support the ‘tls-id’ attribut= e.

 

Comments?

 

Regards,

 

Christer

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] DTLS-SDP: TLS support added

 

Hi,

 

Based on the decision in Chicago to allow usage of t= he SDP ‘dtls-id’ attribute also for TLS connections, I have cre= ated a pull request:

 

https://github.com/cdh4u/draft-dtls-sdp/pull/26

 

Note that the name of the attribute has now been cha= nged to ‘tls-id’.

 

The approach I’ve taken is: rather than talkin= g about both DTLS and TLS throughout the document, I’ve basically add= ed a section describing the TLS-specific considerations – mainly rega= rding the interaction with the SDP ‘connection’ attribute.=

 

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the ‘connection’ attribute can be used. We know that it would b= e needed for draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/d= oc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don’t think we c= an use it as justification at this point?

 

Note that this pull request does NOT include any of = the changes to be done based on the gen-art/sec-dir reviews. I have updated= the 4572-update reference, though.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB5E1CCESESSMB102erics_-- From nobody Mon Apr 10 12:10:35 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2877129AB6; Mon, 10 Apr 2017 12:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ANMVubtpVZae; Mon, 10 Apr 2017 12:10:31 -0700 (PDT) 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 4B121129AD2; Mon, 10 Apr 2017 12:10:25 -0700 (PDT) X-AuditID: c1b4fb2d-d97ff700000033e1-0d-58ebd89e88cd Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id F2.DF.13281.E98DBE85; Mon, 10 Apr 2017 21:10:23 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:10:22 +0200 From: Christer Holmberg To: "mmusic (E-mail)" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: SDP connection attribute optional [was: DTLS-SDP: TLS support added] Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw Date: Mon, 10 Apr 2017 19:10:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7n+78G68jDDY2aVrM7zzNbnF+53om i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBlLX1xiKrhSXtF4rIO1gXFTZhcj J4eEgInEz+YlrF2MXBxCAusZJd7M3csIkhASWMIo8fWbaxcjBwebgIVE9z9tkLCIgLpE6+Y+ VhCbWSBcYs6bM2C2sECwxMPOqawQNSESR9dPZYewjSQ+/v4IFmcRUJW4/+opWJxXwFdi/q6f UKt8JW5PO80GYnMK+EmcfTERLM4oICbx/dQaJohd4hK3nsxngrhZQGLJnvPMELaoxMvH/1gh bCWJFdsvMULU50t8etTPCLFLUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaG sc8ceMyELL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+nl5easkmRmB8HdzyW3cH4+rXjocYBTgY lXh4H/S/jhBiTSwrrsw9xCjBwawkwnu1AyjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQgh gfTEktTs1NSC1CKYLBMHp1QDY32l35rm/kPn9a32X32fzDhhauWqd0npt3Z9+W5rPbmGWTVg /wuGR59V/zRk2bXregkYHjINPhNw+rz7kYC9fM5+qfZ3KxYnr5/8v7Hnp/2ZFeGly1tr8yNP fj04S/uMYsqLu76ZdvlHum6d7rOryBaKXPZrw3kJxe3+6fvW/99/eq3PxuObcpRYijMSDbWY i4oTAeX98M+rAgAA Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:10:34 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And XXX stands for section 5.1 :) From: Christer Holmberg Sent: 10 April 2017 22:10 To: Christer Holmberg ; mmusic (E-mail) Cc: mmusic-chairs@ietf.org; Ben Campbell Subject: SDP connection attribute optional [was: DTLS-SDP: TLS support adde= d] Hi, Section XXX of RFC 4145 says: "When an offerer generates an 'm' line that uses TCP, it SHOULD provide = a connection attribute for the 'm' line unless the application using the 'm' line has other means to deal with connection reestablishment." Now, if both endpoints support the 'tls-id' attribute, that would be "other= means". However, section of RFC 4145 says: "The default value of the connection attribute in both offers and answers is 'new'." So, I think we need to say something. Either: 1) If both endpoints support tls-id, they don't need to care about the= connection attribute (or the default value in case the attribute is not pr= esent); OR 2) We mandate that the connection attribute is present, with an 'exist= ing' value, whenever an existing connection is to be maintained. Option 2) seems most safe, i.e., we continue using the 'connection' attribu= te and its semantics even if both endpoints support the 'tls-id' attribute. Comments? Regards, Christer From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmber= g Sent: 09 April 2017 10:15 To: mmusic (E-mail) > Cc: mmusic-chairs@ietf.org; Ben Campbell > Subject: [MMUSIC] DTLS-SDP: TLS support added Hi, Based on the decision in Chicago to allow usage of the SDP 'dtls-id' attrib= ute also for TLS connections, I have created a pull request: https://github.com/cdh4u/draft-dtls-sdp/pull/26 Note that the name of the attribute has now been changed to 'tls-id'. The approach I've taken is: rather than talking about both DTLS and TLS thr= oughout the document, I've basically added a section describing the TLS-spe= cific considerations - mainly regarding the interaction with the SDP 'conne= ction' attribute. Now, I think we do need some text on WHY we also cover TLS connections sinc= e, as far as creating new connections is concerned, the 'connection' attrib= ute can be used. We know that it would be needed for draft-thomson-avtcore-= sdp-uks (https://datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). = But, AFAIK that work has not been adopted yet, so I don't think we can use = it as justification at this point? Note that this pull request does NOT include any of the changes to be done = based on the gen-art/sec-dir reviews. I have updated the 4572-update refere= nce, though. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And XXX stands for sec= tion 5.1 :)

 

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmusic= (E-mail) <mmusic@ietf.org>
Cc: mmusic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: SDP connection attribute optional [was: DTLS-SDP: TLS suppo= rt added]

 

Hi,<= /p>

 

Section XXX of RFC 414= 5 says:

 

   “When an off= erer generates an 'm' line that uses TCP, it SHOULD provide a

   connection attribu= te for the 'm' line unless the application using

   the 'm' line has o= ther means to deal with connection reestablishment.”

 

Now, if both endpoints= support the ‘tls-id’ attribute, that would be “other mea= ns”.

 

However, section of RF= C 4145 says:

 

   “The default value of the connection attribute in b=
oth offers and
   answers is 'new'.”

 

So, I think we need to= say something. Either:

 

1)&= nbsp;     If both endpoi= nts support tls-id, they don’t need to care about the connection attr= ibute (or the default value in case the attribute is not present); OR<= /o:p>

2)&= nbsp;     We mandate tha= t the connection attribute is present, with an ‘existing’ value= , whenever an existing connection is to be maintained.

 

Option 2) seems most s= afe, i.e., we continue using the ‘connection’ attribute and its= semantics even if both endpoints support the ‘tls-id’ attribut= e.

 

Comments?

 

Regards,

 

Christer

 

 

From: mmusic [mailto:mmusic-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <mmusic@ie= tf.org>
Cc: mmusic-chairs@ietf.org= ; Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] DTLS-SDP: TLS support added

 

Hi,

 

Based on the decision in Chicago to allow usage of t= he SDP ‘dtls-id’ attribute also for TLS connections, I have cre= ated a pull request:

 

https://github.com/cdh4u/draft-dtls-sdp/pull/26

 

Note that the name of the attribute has now been cha= nged to ‘tls-id’.

 

The approach I’ve taken is: rather than talkin= g about both DTLS and TLS throughout the document, I’ve basically add= ed a section describing the TLS-specific considerations – mainly rega= rding the interaction with the SDP ‘connection’ attribute.=

 

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the ‘connection’ attribute can be used. We know that it would b= e needed for draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/d= oc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don’t think we c= an use it as justification at this point?

 

Note that this pull request does NOT include any of = the changes to be done based on the gen-art/sec-dir reviews. I have updated= the 4572-update reference, though.

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB5E219ESESSMB102erics_-- From nobody Mon Apr 10 12:26:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206C5129A91 for ; Mon, 10 Apr 2017 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 LXrZPn2rRGmH for ; Mon, 10 Apr 2017 12:26:09 -0700 (PDT) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 B7C70129AB6 for ; Mon, 10 Apr 2017 12:19:55 -0700 (PDT) Received: by mail-pg0-x231.google.com with SMTP id x125so110501388pgb.0 for ; Mon, 10 Apr 2017 12:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GOGwfTcKrUc7HUCkbcXQx98RnDkM2TB+TP/fw2SxmMQ=; b=IBMQsjbYdEMdKwqvanNhyrAgN3+mBR4qa41XXwRQcrwK9wrr0rA3hnXRkcps1iQhnY SX2BEEH3b0UidML6xi9KBB+8IlpVU+F7ImL4Q/fQ84gb50LAEx73t5hNzgZpxjv4XW2E 7yaMRWPU+lkGLtl/2qJD5c1BErOW5RKanALpcE6UNsUUOpj01wnrwkgkKAKpMPLYEGnj sGyTjulcqVUcfs7G6jr04ZYzWEWBfl3luFy6E1U0V5FFkw7WyIfCd49Q/mwRUngxlD17 Eb8ygYAOFCthxZOEnGU5OYr5CsHhClkBnbUVhvocJBYmR9WyWWeUJtbnOm+UIkzFpE00 mdsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GOGwfTcKrUc7HUCkbcXQx98RnDkM2TB+TP/fw2SxmMQ=; b=MY4AmVM9M1JPD1E60EN19oGZ47v3UcOk+SahCu+/g+LsJpHLkhgbm5MLbCWZVklcqC Jw4CSbcjymwruHYRHMaqZ657JzegARNTkCNWr/gWtTVa4Lyl90l6+BR1eyIN8DkJdzDE XcJydxLWSjqgeN2F6R7wszCPRUZTy+FLScl2yDGDH+S0Sh4TEHvBrT8le4+z8XBZKHdX 2osZeSMxwhobEG2JhX+Dynu+VsBOxOq0Zy9hFNs7Wz9PsL5JzTJu2mQLe8dCjj8xT+H6 RXzFmbCMpsRgqU9DNOteY3hjGfUxzZ8+hmCc9Bc6fJbo9zoRHneGZ7o4S96E7rdpm0m1 chlg== X-Gm-Message-State: AFeK/H1QA/DeNJ6tvaS1OapMD21GAcZcz/P79y1oXZyV0KeYBOQdCt/+/3GLYDHa30j3VA== X-Received: by 10.98.206.78 with SMTP id y75mr58008047pfg.108.1491851995260; Mon, 10 Apr 2017 12:19:55 -0700 (PDT) Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id y29sm9771883pfj.90.2017.04.10.12.19.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 12:19:54 -0700 (PDT) Received: by mail-pf0-f180.google.com with SMTP id o126so37664961pfb.3; Mon, 10 Apr 2017 12:19:54 -0700 (PDT) X-Received: by 10.84.209.204 with SMTP id y70mr6534095plh.155.1491851994335; Mon, 10 Apr 2017 12:19:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 10 Apr 2017 12:19:53 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> From: Roman Shpount Date: Mon, 10 Apr 2017 15:19:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic (E-mail)" , "mmusic-chairs@ietf.org" , Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c0354962e156f054cd4dc80 Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:26:12 -0000 --94eb2c0354962e156f054cd4dc80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi All, A think for all the normal cases m=3Dconnection attribute must be specified when TLS is used. There is no way to know if remote party supports tls-id when offer is sent, so if m=3Dconnection is not specified, then it is uncle= ar how the offer is going to be processed. The only exception I can this of would be ICE TLS candidates, if ICE TLS candidates would ever get defined. ICE procedures would overwrite a lot of what we are going to define here, including how fingerprints are specified and matched and when TLS connections are established. I believe this is something that should be defined in ICE TLS document and update this document, if necessary. Regards. _____________ Roman Shpount On Mon, Apr 10, 2017 at 3:10 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > And XXX stands for section 5.1 :) > > > > *From:* Christer Holmberg > *Sent:* 10 April 2017 22:10 > *To:* Christer Holmberg ; mmusic (E-mail) > > *Cc:* mmusic-chairs@ietf.org; Ben Campbell > *Subject:* SDP connection attribute optional [was: DTLS-SDP: TLS support > added] > > > > Hi, > > > > Section XXX of RFC 4145 says: > > > > =E2=80=9CWhen an offerer generates an 'm' line that uses TCP, it SHOUL= D provide > a > > connection attribute for the 'm' line unless the application using > > the 'm' line has other means to deal with connection reestablishment.= =E2=80=9D > > > > Now, if both endpoints support the =E2=80=98tls-id=E2=80=99 attribute, th= at would be > =E2=80=9Cother means=E2=80=9D. > > > > However, section of RFC 4145 says: > > > > =E2=80=9CThe default value of the connection attribute in both offers = and > > answers is 'new'.=E2=80=9D > > > > So, I think we need to say something. Either: > > > > 1) If both endpoints support tls-id, they don=E2=80=99t need to care= about > the connection attribute (or the default value in case the attribute is n= ot > present); OR > > 2) We mandate that the connection attribute is present, with an > =E2=80=98existing=E2=80=99 value, whenever an existing connection is to b= e maintained. > > > > Option 2) seems most safe, i.e., we continue using the =E2=80=98connectio= n=E2=80=99 > attribute and its semantics even if both endpoints support the =E2=80=98t= ls-id=E2=80=99 > attribute. > > > > Comments? > > > > Regards, > > > > Christer > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org ]= *On > Behalf Of *Christer Holmberg > *Sent:* 09 April 2017 10:15 > *To:* mmusic (E-mail) > *Cc:* mmusic-chairs@ietf.org; Ben Campbell > *Subject:* [MMUSIC] DTLS-SDP: TLS support added > > > > Hi, > > > > Based on the decision in Chicago to allow usage of the SDP =E2=80=98dtls-= id=E2=80=99 > attribute also for TLS connections, I have created a pull request: > > > > https://github.com/cdh4u/draft-dtls-sdp/pull/26 > > > > Note that the name of the attribute has now been changed to =E2=80=98tls-= id=E2=80=99. > > > > The approach I=E2=80=99ve taken is: rather than talking about both DTLS a= nd TLS > throughout the document, I=E2=80=99ve basically added a section describin= g the > TLS-specific considerations =E2=80=93 mainly regarding the interaction wi= th the SDP > =E2=80=98connection=E2=80=99 attribute. > > > > Now, I think we do need some text on WHY we also cover TLS connections > since, as far as creating new connections is concerned, the =E2=80=98conn= ection=E2=80=99 > attribute can be used. We know that it would be needed for > draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/ > doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been > adopted yet, so I don=E2=80=99t think we can use it as justification at t= his point? > > > > Note that this pull request does NOT include any of the changes to be don= e > based on the gen-art/sec-dir reviews. I have updated the 4572-update > reference, though. > > > > Regards, > > > > Christer > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > > --94eb2c0354962e156f054cd4dc80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

A think for all the = normal cases m=3Dconnection attribute must be specified when TLS is used. T= here is no way to know if remote party supports tls-id when offer is sent, = so if m=3Dconnection is not specified, then it is unclear how the offer is = going to be processed.

The only exception I can th= is of would be ICE TLS candidates, if ICE TLS candidates would ever get def= ined. ICE procedures would overwrite a lot of what we are going to define h= ere, including how fingerprints are specified and matched and when TLS conn= ections are established. I believe this is something that should be defined= in ICE TLS document and update this document, if necessary.

=
Regards.

___= __________
Roman Shpount

On Mon, Apr 10, 2017 at 3:10 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:<= br>

And XXX stands for sec= tion 5.1 :)

<= span style=3D"color:#1f497d">=C2=A0

From: Christer Holmberg
Sent: 10 April 2017 22:10
To: Christer Holmberg <christer.holmberg@ericsson.com>; mmus= ic (E-mail) <mmusic= @ietf.org>
Cc: mmus= ic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: SDP connection attribute optional [was: DTLS-SDP: TL= S support added]

=C2=A0

Hi,

=C2=A0

Section XXX of RFC 414= 5 says:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CWhen an offerer generates an 'm&= #39; line that uses TCP, it SHOULD provide a

=C2=A0=C2=A0 connection attribute for the 'm' line= unless the application using

=C2=A0=C2=A0 the 'm' line has other means to deal = with connection reestablishment.=E2=80=9D

=C2=A0

Now, if both endpoints= support the =E2=80=98tls-id=E2=80=99 attribute, that would be =E2=80=9Coth= er means=E2=80=9D.

=C2=A0

However, section of RF= C 4145 says:

=C2=A0

=C2=A0=C2=A0 =E2=80=9CThe default value of the connection attribute in=
 both offers and
=C2=A0=C2=A0 answers is 'new'.=E2=80=9D

=C2=A0

So, I think we need to= say something. Either:

=C2=A0

1)If both endpoints= support tls-id, they don=E2=80=99t need to care about the connection attri= bute (or the default value in case the attribute is not present); OR=

2)We mandate that t= he connection attribute is present, with an =E2=80=98existing=E2=80=99 valu= e, whenever an existing connection is to be maintained.

=C2=A0

Option 2) seems most s= afe, i.e., we continue using the =E2=80=98connection=E2=80=99 attribute and= its semantics even if both endpoints support the =E2=80=98tls-id=E2=80=99 = attribute.

=C2=A0

Comments?

=C2=A0

Regards,=

=C2=A0

Christer=

=C2=A0

=C2=A0

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer Holmberg
Sent: 09 April 2017 10:15
To: mmusic (E-mail) <mmusic@ietf.org>
Cc: mmus= ic-chairs@ietf.org; Ben Campbell <ben@nostrum.com>
Subject: [MMUSIC] DTLS-SDP: TLS support added

=C2=A0

Hi,

=C2=A0

Based on the decision in Chicago to allow usage of t= he SDP =E2=80=98dtls-id=E2=80=99 attribute also for TLS connections, I have= created a pull request:

=C2=A0

https://github.com/cdh4u/draft-dtls-sdp/pull= /26

=C2=A0

Note that the name of the attribute has now been cha= nged to =E2=80=98tls-id=E2=80=99.

=C2=A0

The approach I=E2=80=99ve taken is: rather than talk= ing about both DTLS and TLS throughout the document, I=E2=80=99ve basically= added a section describing the TLS-specific considerations =E2=80=93 mainl= y regarding the interaction with the SDP =E2=80=98connection=E2=80=99 attri= bute.

=C2=A0

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the =E2=80=98connection=E2=80=99 attribute can be used. We know that it wou= ld be needed for draft-thomson-avtcore-sdp-uks (https://= datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don=E2=80=99t think we= can use it as justification at this point?

=C2=A0

Note that this pull request does NOT include any of = the changes to be done based on the gen-art/sec-dir reviews. I have updated= the 4572-update reference, though.

=C2=A0

Regards,

=C2=A0

Christer


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

--94eb2c0354962e156f054cd4dc80-- From nobody Mon Apr 10 12:31:42 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23812129AC4; Mon, 10 Apr 2017 12:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4-HWEEm7biEk; Mon, 10 Apr 2017 12:31:37 -0700 (PDT) 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 C7200129A9C; Mon, 10 Apr 2017 12:31:36 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-60-58ebdd968c2a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 3A.3D.21650.69DDBE85; Mon, 10 Apr 2017 21:31:34 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:31:32 +0200 From: Christer Holmberg To: Roman Shpount CC: "mmusic (E-mail)" , "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw///QToD//8rxoA== Date: Mon, 10 Apr 2017 19:32:05 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E275@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E275ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7ve60u68jDM5cs7aY33ma3eL8zvVM FlOXP2axmHFhKrMDi8eSJT+ZPGbtfMLicWtKQQBzFJdNSmpOZllqkb5dAlfG6Um7mAqeXGKs uL9zIlsD45yzjF2MnBwSAiYSO3qfsHUxcnEICaxnlHi0eh47hLOEUaJhRRdQhoODTcBCovuf NkiDiICqxN/vk5lAbGaBGokP7Z1sILawQIxEx/KHzBA1sRJ75y9mgbCdJBasOgRmswD1Tru0 B2wxr4CvxKbXS8DiQgI3GCWW3c8GsTkFAiWm39/JDmIzCohJfD+1BmqXuMStJ/OZII4WkFiy 5zwzhC0q8fLxP1YIW0lixfZLjCAnMwvkS2zamwixSlDi5MwnLBMYRWYhmTQLoWoWkiqIsKbE +l36ENWKElO6H7JD2BoSrXPmsiOLL2BkX8UoWpxaXJybbmSkl1qUmVxcnJ+nl5dasokRGHEH t/y22sF48LnjIUYBDkYlHt4H/a8jhFgTy4orcw8xSnAwK4nwXu0ACvGmJFZWpRblxxeV5qQW H2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cDYmrVWbZFR76Kk5JqXhaWLbyj+DXF0 0/t45Y7xucqFGXV7fuYbHBC/P4W1zfr1Ak/Fl813tjj+Prgl7/TVH8ITnxbUdsqFvhLZk2Ai uOmymoHFRaGHGvn3Li/1uPG3zfSF6TrLO508b1ov8phJ3J/9z/xFf0fsqmcW1rfrzz1Mi+Tw L90QldulxFKckWioxVxUnAgAmZQG0bQCAAA= Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:31:40 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5E275ESESSMB102erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5BIHRoaW5rIGZvciBhbGwgdGhlIG5vcm1hbCBjYXNlcyBtPWNvbm5lY3Rpb24gYXR0 cmlidXRlIG11c3QgYmUgc3BlY2lmaWVkIHdoZW4gPlRMUyBpcyB1c2VkLiBUaGVyZSBpcyBubyB3 YXkgdG8ga25vdyBpZiByZW1vdGUgcGFydHkgc3VwcG9ydHMgdGxzLWlkIHdoZW4gb2ZmZXIgPmlz IHNlbnQsIHNvIGlmIG09Y29ubmVjdGlvbiBpcyBub3Qgc3BlY2lmaWVkLCB0aGVuIGl0IGlzIHVu Y2xlYXIgaG93IHRoZSBvZmZlciBpcyA+Z29pbmcgdG8gYmUgcHJvY2Vzc2VkLg0KDQpJIHdhcyB0 aGlua2luZyBtb3JlIGFib3V0IHN1YnNlcXVlbnQgb2ZmZXJzIGFuZCBhbnN3ZXJzLCB3aGVuIGl0 IGlzIGtub3duIHdoZXRoZXIgYm90aCBlbmRwb2ludHMgc3VwcG9ydCB0bHMtaWQuDQoNCkJ1dCwg SSBhbSBmaW5lIHRvIGtlZXAgdXNpbmcgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGFsc28gaW4g dGhhdCBjYXNlLCB0b2dldGhlciB3aXRoIHRscy1pZC4gU28sIGlmIHRoZSBjb25uZWN0aW9uIGF0 dHJpYnV0ZSBpcyBub3QgcHJlc2VudCwgaXMgc2hhbGwgYmUgaW50ZXJwcmV0ZWQgYXMg4oCYbmV3 4oCZLCBhY2NvcmRpbmcgdG8gUkZDIDQxNDUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCk9u IE1vbiwgQXByIDEwLCAyMDE3IGF0IDM6MTAgUE0sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208bWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbT4+IHdyb3RlOg0KQW5kIFhYWCBzdGFuZHMgZm9yIHNlY3Rpb24gNS4xIDopDQoNCkZyb206 IENocmlzdGVyIEhvbG1iZXJnDQpTZW50OiAxMCBBcHJpbCAyMDE3IDIyOjEwDQpUbzogQ2hyaXN0 ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj47IG1tdXNpYyAoRS1tYWlsKSA8bW11c2ljQGlldGYu b3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+Pg0KQ2M6IG1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc8 bWFpbHRvOm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVt LmNvbTxtYWlsdG86YmVuQG5vc3RydW0uY29tPj4NClN1YmplY3Q6IFNEUCBjb25uZWN0aW9uIGF0 dHJpYnV0ZSBvcHRpb25hbCBbd2FzOiBEVExTLVNEUDogVExTIHN1cHBvcnQgYWRkZWRdDQoNCkhp LA0KDQpTZWN0aW9uIFhYWCBvZiBSRkMgNDE0NSBzYXlzOg0KDQogICDigJxXaGVuIGFuIG9mZmVy ZXIgZ2VuZXJhdGVzIGFuICdtJyBsaW5lIHRoYXQgdXNlcyBUQ1AsIGl0IFNIT1VMRCBwcm92aWRl IGENCiAgIGNvbm5lY3Rpb24gYXR0cmlidXRlIGZvciB0aGUgJ20nIGxpbmUgdW5sZXNzIHRoZSBh cHBsaWNhdGlvbiB1c2luZw0KICAgdGhlICdtJyBsaW5lIGhhcyBvdGhlciBtZWFucyB0byBkZWFs IHdpdGggY29ubmVjdGlvbiByZWVzdGFibGlzaG1lbnQu4oCdDQoNCk5vdywgaWYgYm90aCBlbmRw b2ludHMgc3VwcG9ydCB0aGUg4oCYdGxzLWlk4oCZIGF0dHJpYnV0ZSwgdGhhdCB3b3VsZCBiZSDi gJxvdGhlciBtZWFuc+KAnS4NCg0KSG93ZXZlciwgc2VjdGlvbiBvZiBSRkMgNDE0NSBzYXlzOg0K DQoNCiAgIOKAnFRoZSBkZWZhdWx0IHZhbHVlIG9mIHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSBp biBib3RoIG9mZmVycyBhbmQNCg0KICAgYW5zd2VycyBpcyAnbmV3Jy7igJ0NCg0KU28sIEkgdGhp bmsgd2UgbmVlZCB0byBzYXkgc29tZXRoaW5nLiBFaXRoZXI6DQoNCg0KMSkgICAgICBJZiBib3Ro IGVuZHBvaW50cyBzdXBwb3J0IHRscy1pZCwgdGhleSBkb27igJl0IG5lZWQgdG8gY2FyZSBhYm91 dCB0aGUgY29ubmVjdGlvbiBhdHRyaWJ1dGUgKG9yIHRoZSBkZWZhdWx0IHZhbHVlIGluIGNhc2Ug dGhlIGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCk7IE9SDQoNCjIpICAgICAgV2UgbWFuZGF0ZSB0 aGF0IHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSBpcyBwcmVzZW50LCB3aXRoIGFuIOKAmGV4aXN0 aW5n4oCZIHZhbHVlLCB3aGVuZXZlciBhbiBleGlzdGluZyBjb25uZWN0aW9uIGlzIHRvIGJlIG1h aW50YWluZWQuDQoNCk9wdGlvbiAyKSBzZWVtcyBtb3N0IHNhZmUsIGkuZS4sIHdlIGNvbnRpbnVl IHVzaW5nIHRoZSDigJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZSBhbmQgaXRzIHNlbWFudGljcyBl dmVuIGlmIGJvdGggZW5kcG9pbnRzIHN1cHBvcnQgdGhlIOKAmHRscy1pZOKAmSBhdHRyaWJ1dGUu DQoNCkNvbW1lbnRzPw0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCkZyb206IG1tdXNpYyBb bWFpbHRvOm1tdXNpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQ2hyaXN0ZXIgSG9s bWJlcmcNClNlbnQ6IDA5IEFwcmlsIDIwMTcgMTA6MTUNClRvOiBtbXVzaWMgKEUtbWFpbCkgPG1t dXNpY0BpZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPj4NCkNjOiBtbXVzaWMtY2hhaXJz QGlldGYub3JnPG1haWx0bzptbXVzaWMtY2hhaXJzQGlldGYub3JnPjsgQmVuIENhbXBiZWxsIDxi ZW5Abm9zdHJ1bS5jb208bWFpbHRvOmJlbkBub3N0cnVtLmNvbT4+DQpTdWJqZWN0OiBbTU1VU0lD XSBEVExTLVNEUDogVExTIHN1cHBvcnQgYWRkZWQNCg0KSGksDQoNCkJhc2VkIG9uIHRoZSBkZWNp c2lvbiBpbiBDaGljYWdvIHRvIGFsbG93IHVzYWdlIG9mIHRoZSBTRFAg4oCYZHRscy1pZOKAmSBh dHRyaWJ1dGUgYWxzbyBmb3IgVExTIGNvbm5lY3Rpb25zLCBJIGhhdmUgY3JlYXRlZCBhIHB1bGwg cmVxdWVzdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0bHMtc2RwL3B1bGwv MjYNCg0KTm90ZSB0aGF0IHRoZSBuYW1lIG9mIHRoZSBhdHRyaWJ1dGUgaGFzIG5vdyBiZWVuIGNo YW5nZWQgdG8g4oCYdGxzLWlk4oCZLg0KDQpUaGUgYXBwcm9hY2ggSeKAmXZlIHRha2VuIGlzOiBy YXRoZXIgdGhhbiB0YWxraW5nIGFib3V0IGJvdGggRFRMUyBhbmQgVExTIHRocm91Z2hvdXQgdGhl IGRvY3VtZW50LCBJ4oCZdmUgYmFzaWNhbGx5IGFkZGVkIGEgc2VjdGlvbiBkZXNjcmliaW5nIHRo ZSBUTFMtc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMg4oCTIG1haW5seSByZWdhcmRpbmcgdGhlIGlu dGVyYWN0aW9uIHdpdGggdGhlIFNEUCDigJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZS4NCg0KTm93 LCBJIHRoaW5rIHdlIGRvIG5lZWQgc29tZSB0ZXh0IG9uIFdIWSB3ZSBhbHNvIGNvdmVyIFRMUyBj b25uZWN0aW9ucyBzaW5jZSwgYXMgZmFyIGFzIGNyZWF0aW5nIG5ldyBjb25uZWN0aW9ucyBpcyBj b25jZXJuZWQsIHRoZSDigJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZSBjYW4gYmUgdXNlZC4gV2Ug a25vdyB0aGF0IGl0IHdvdWxkIGJlIG5lZWRlZCBmb3IgZHJhZnQtdGhvbXNvbi1hdnRjb3JlLXNk cC11a3MgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRob21zb24tYXZ0 Y29yZS1zZHAtdWtzLykuIEJ1dCwgQUZBSUsgdGhhdCB3b3JrIGhhcyBub3QgYmVlbiBhZG9wdGVk IHlldCwgc28gSSBkb27igJl0IHRoaW5rIHdlIGNhbiB1c2UgaXQgYXMganVzdGlmaWNhdGlvbiBh dCB0aGlzIHBvaW50Pw0KDQpOb3RlIHRoYXQgdGhpcyBwdWxsIHJlcXVlc3QgZG9lcyBOT1QgaW5j bHVkZSBhbnkgb2YgdGhlIGNoYW5nZXMgdG8gYmUgZG9uZSBiYXNlZCBvbiB0aGUgZ2VuLWFydC9z ZWMtZGlyIHJldmlld3MuIEkgaGF2ZSB1cGRhdGVkIHRoZSA0NTcyLXVwZGF0ZSByZWZlcmVuY2Us IHRob3VnaC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBtYWlsaW5nIGxpc3QNCm1tdXNpY0Bp ZXRmLm9yZzxtYWlsdG86bW11c2ljQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tbXVzaWMNCg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB5E275ESESSMB102erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpwLm0tMjk4ODMyNDI2OTI2ODU2NDk2MW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tMjk4ODMy NDI2OTI2ODU2NDk2MW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTI5ODgzMjQyNjkyNjg1NjQ5NjFt c29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTI5ODgzMjQyNjkyNjg1NjQ5NjFt c29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3 Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkEgdGhpbmsg Zm9yIGFsbCB0aGUgbm9ybWFsIGNhc2VzIG09Y29ubmVjdGlvbiBhdHRyaWJ1dGUgbXVzdCBiZSBz cGVjaWZpZWQgd2hlbg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+VExT IGlzIHVzZWQuIFRoZXJlIGlzIG5vIHdheSB0byBrbm93IGlmIHJlbW90ZSBwYXJ0eSBzdXBwb3J0 cyB0bHMtaWQgd2hlbiBvZmZlcg0KPHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3Nw YW4+aXMgc2VudCwgc28gaWYgbT1jb25uZWN0aW9uIGlzIG5vdCBzcGVjaWZpZWQsIHRoZW4gaXQg aXMgdW5jbGVhciBob3cgdGhlIG9mZmVyIGlzDQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jmd0Ozwvc3Bhbj5nb2luZyB0byBiZSBwcm9jZXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd2FzIHRoaW5raW5nIG1vcmUgYWJvdXQgc3Vic2Vx dWVudCBvZmZlcnMgYW5kIGFuc3dlcnMsIHdoZW4gaXQgaXMga25vd24gd2hldGhlciBib3RoIGVu ZHBvaW50cyBzdXBwb3J0IHRscy1pZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkJ1dCwgSSBhbSBmaW5lIHRvIGtlZXAgdXNpbmcgdGhlIGNvbm5lY3Rpb24gYXR0 cmlidXRlIGFsc28gaW4gdGhhdCBjYXNlLCB0b2dldGhlciB3aXRoIHRscy1pZC4gU28sIGlmIHRo ZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSBpcyBub3QgcHJlc2VudCwgaXMgc2hhbGwgYmUgaW50ZXJw cmV0ZWQNCiBhcyDigJhuZXfigJksIGFjY29yZGluZyB0byBSRkMgNDE0NS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTAsIDIw MTcgYXQgMzoxMCBQTSwgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xt YmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBj bSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkFuZCBYWFggc3RhbmRzIGZvciBzZWN0aW9uIDUuMSA6KTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGEgbmFtZT0ibV8tMjk4ODMyNDI2 OTI2ODU2NDk2MV9fTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZy b206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IENocmlzdGVyIEhvbG1iZXJnDQo8YnI+ DQo8Yj5TZW50OjwvYj4gMTAgQXByaWwgMjAxNyAyMjoxMDxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nv bi5jb20iIHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+ Jmd0OzsgbW11c2ljIChFLW1haWwpICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+ IDxhIGhyZWY9Im1haWx0bzptbXVzaWMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bW11c2ljLWNoYWlyc0BpZXRmLm9yZzwvYT47IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmJlbkBub3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBub3N0cnVtLmNvbTwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFNEUCBjb25uZWN0aW9uIGF0dHJpYnV0ZSBvcHRpb25h bCBbd2FzOiBEVExTLVNEUDogVExTIHN1cHBvcnQgYWRkZWRdPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlNlY3Rpb24gWFhYIG9mIFJGQyA0MTQ1IHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ Jm5ic3A7Jm5ic3A7IOKAnFdoZW4gYW4gb2ZmZXJlciBnZW5lcmF0ZXMgYW4gJ20nIGxpbmUgdGhh dCB1c2VzIFRDUCwgaXQgU0hPVUxEIHByb3ZpZGUgYTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBjb25uZWN0aW9uIGF0 dHJpYnV0ZSBmb3IgdGhlICdtJyBsaW5lIHVubGVzcyB0aGUgYXBwbGljYXRpb24gdXNpbmc8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJz cDsmbmJzcDsgdGhlICdtJyBsaW5lIGhhcyBvdGhlciBtZWFucyB0byBkZWFsIHdpdGggY29ubmVj dGlvbiByZWVzdGFibGlzaG1lbnQu4oCdPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Tm93LCBpZiBib3RoIGVuZHBvaW50cyBzdXBwb3J0IHRoZSDigJh0bHMtaWTigJkg YXR0cmlidXRlLCB0aGF0IHdvdWxkIGJlIOKAnG90aGVyIG1lYW5z4oCdLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIHNlY3Rpb24gb2YgUkZDIDQxNDUg c2F5czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJl PiZuYnNwOyZuYnNwOyDigJxUaGUgZGVmYXVsdCB2YWx1ZSBvZiB0aGUgY29ubmVjdGlvbiBhdHRy aWJ1dGUgaW4gYm90aCBvZmZlcnMgYW5kPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5i c3A7IGFuc3dlcnMgaXMgJ25ldycu4oCdPG86cD48L286cD48L3ByZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPlNvLCBJIHRoaW5rIHdlIG5lZWQgdG8gc2F5IHNvbWV0aGluZy4gRWl0aGVyOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTI5ODgz MjQyNjkyNjg1NjQ5NjFtc29saXN0cGFyYWdyYXBoIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+MSk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+SWYgYm90aCBlbmRwb2ludHMgc3VwcG9ydCB0bHMtaWQsIHRoZXkgZG9u4oCZdCBu ZWVkIHRvIGNhcmUgYWJvdXQgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIChvciB0aGUgZGVmYXVs dCB2YWx1ZSBpbiBjYXNlIHRoZSBhdHRyaWJ1dGUgaXMgbm90IHByZXNlbnQpOyBPUjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTI5ODgzMjQyNjkyNjg1NjQ5NjFtc29saXN0cGFy YWdyYXBoIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Mik8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2UgbWFuZGF0ZSB0aGF0 IHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSBpcyBwcmVzZW50LCB3aXRoIGFuIOKAmGV4aXN0aW5n 4oCZIHZhbHVlLCB3aGVuZXZlciBhbiBleGlzdGluZyBjb25uZWN0aW9uIGlzIHRvIGJlIG1haW50 YWluZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+T3B0aW9uIDIp IHNlZW1zIG1vc3Qgc2FmZSwgaS5lLiwgd2UgY29udGludWUgdXNpbmcgdGhlIOKAmGNvbm5lY3Rp b27igJkgYXR0cmlidXRlIGFuZCBpdHMgc2VtYW50aWNzIGV2ZW4gaWYgYm90aCBlbmRwb2ludHMg c3VwcG9ydCB0aGUg4oCYdGxzLWlk4oCZIGF0dHJpYnV0ZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5Db21tZW50cz88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IG1tdXNpYyBbPGEgaHJlZj0ibWFpbHRvOm1t dXNpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOm1tdXNpYy1ib3Vu Y2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0ZXIgSG9sbWJlcmc8 YnI+DQo8Yj5TZW50OjwvYj4gMDkgQXByaWwgMjAxNyAxMDoxNTxicj4NCjxiPlRvOjwvYj4gbW11 c2ljIChFLW1haWwpICZsdDs8YSBocmVmPSJtYWlsdG86bW11c2ljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+bW11c2ljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzptbXVzaWMtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW11c2ljLWNo YWlyc0BpZXRmLm9yZzwvYT47IEJlbiBDYW1wYmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJlbkBu b3N0cnVtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJlbkBub3N0cnVtLmNvbTwvYT4mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFtNTVVTSUNdIERUTFMtU0RQOiBUTFMgc3VwcG9ydCBhZGRlZDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkJhc2VkIG9uIHRoZSBkZWNpc2lvbiBpbiBDaGljYWdvIHRv IGFsbG93IHVzYWdlIG9mIHRoZSBTRFAg4oCYZHRscy1pZOKAmSBhdHRyaWJ1dGUgYWxzbyBmb3Ig VExTIGNvbm5lY3Rpb25zLCBJIGhhdmUgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdDo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFm dC1kdGxzLXNkcC9wdWxsLzI2IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2Nk aDR1L2RyYWZ0LWR0bHMtc2RwL3B1bGwvMjY8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5Ob3RlIHRoYXQgdGhlIG5hbWUgb2YgdGhlIGF0dHJpYnV0ZSBoYXMgbm93IGJlZW4gY2hhbmdl ZCB0byDigJh0bHMtaWTigJkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgYXBwcm9h Y2ggSeKAmXZlIHRha2VuIGlzOiByYXRoZXIgdGhhbiB0YWxraW5nIGFib3V0IGJvdGggRFRMUyBh bmQgVExTIHRocm91Z2hvdXQgdGhlIGRvY3VtZW50LCBJ4oCZdmUgYmFzaWNhbGx5IGFkZGVkIGEg c2VjdGlvbiBkZXNjcmliaW5nIHRoZSBUTFMtc3BlY2lmaWMgY29uc2lkZXJhdGlvbnMg4oCTIG1h aW5seQ0KIHJlZ2FyZGluZyB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgU0RQIOKAmGNvbm5lY3Rp b27igJkgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm93LCBJIHRoaW5r IHdlIGRvIG5lZWQgc29tZSB0ZXh0IG9uIFdIWSB3ZSBhbHNvIGNvdmVyIFRMUyBjb25uZWN0aW9u cyBzaW5jZSwgYXMgZmFyIGFzIGNyZWF0aW5nIG5ldyBjb25uZWN0aW9ucyBpcyBjb25jZXJuZWQs IHRoZSDigJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZSBjYW4gYmUgdXNlZC4gV2Uga25vdyB0aGF0 DQogaXQgd291bGQgYmUgbmVlZGVkIGZvciBkcmFmdC10aG9tc29uLWF2dGNvcmUtc2RwLXVrcyAo PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGhvbXNvbi1h dnRjb3JlLXNkcC11a3MvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdGhvbXNvbi1hdnRjb3JlLXNkcC11a3MvPC9hPikuIEJ1dCwgQUZBSUsg dGhhdCB3b3JrIGhhcyBub3QgYmVlbiBhZG9wdGVkDQogeWV0LCBzbyBJIGRvbuKAmXQgdGhpbmsg d2UgY2FuIHVzZSBpdCBhcyBqdXN0aWZpY2F0aW9uIGF0IHRoaXMgcG9pbnQ/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Ob3RlIHRoYXQgdGhpcyBwdWxsIHJlcXVlc3QgZG9lcyBOT1QgaW5j bHVkZSBhbnkgb2YgdGhlIGNoYW5nZXMgdG8gYmUgZG9uZSBiYXNlZCBvbiB0aGUgZ2VuLWFydC9z ZWMtZGlyIHJldmlld3MuIEkgaGF2ZSB1cGRhdGVkIHRoZSA0NTcyLXVwZGF0ZSByZWZlcmVuY2Us IHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KbW11c2ljIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptbXVz aWNAaWV0Zi5vcmciPm1tdXNpY0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7594FB04B1934943A5C02806D1A2204B4CB5E275ESESSMB102erics_-- From nobody Mon Apr 10 12:40:30 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0B0127241; Mon, 10 Apr 2017 12:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 q7uzHWebEKyw; Mon, 10 Apr 2017 12:40:25 -0700 (PDT) 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 35F86129AB6; Mon, 10 Apr 2017 12:40:24 -0700 (PDT) X-AuditID: c1b4fb30-ea83298000006667-a0-58ebdfa648b0 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 2B.29.26215.6AFDBE85; Mon, 10 Apr 2017 21:40:22 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Mon, 10 Apr 2017 21:40:20 +0200 From: Christer Holmberg To: Christer Holmberg , Roman Shpount CC: "mmusic-chairs@ietf.org" , "mmusic (E-mail)" , Ben Campbell Thread-Topic: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] Thread-Index: AdKyNUrA9tbRCyqiRcKnD0Le75fq9gAATjfw///QToD//8rxoP//k0Sg Date: Mon, 10 Apr 2017 19:40:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5E2AA@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E275@ESESSMB102.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E275@ESESSMB102.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5E2AAESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7hO6y+68jDB62qFrM7zzNbnF+53om i6nLH7NYzLgwldmBxWPJkp9MHrN2PmHxuDWlIIA5issmJTUnsyy1SN8ugSvj2boljAWz/jJW 7Ht/mqWB8cQ3xi5GDg4JAROJ2Qciuhi5OIQE1jNK9HxYwAjhLGGUuLHzA1gRm4CFRPc/7S5G Tg4RgWiJDx8WMIHYzAI1Eu+vTWUEsYUFYiQ6lj9khqiJldg7fzELhO0msW3RFrB6FgFViZVd J9lAbF4BX4klR6YyQ+yawyTRO/EVWDOngJ/EroMbwYoYBcQkvp9aA7VMXOLWk/lgtoSAgMSS PeeZIWxRiZeP/7FC2EoSK7ZfAruZWSBf4sHjIohdghInZz5hmcAoMgvJpFkIVbOQVEGENSXW 79KHqFaUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTipNx0IyO91KLM5OLi/Dy9vNSSTYzAiDu4 5bfBDsaXzx0PMQpwMCrx8D7ofx0hxJpYVlyZe4hRgoNZSYRX7xBQiDclsbIqtSg/vqg0J7X4 EKM0B4uSOK/jvgsRQgLpiSWp2ampBalFMFkmDk6pBsbFtjsnFJxedbV1sUiM07M6c/vzi2y0 Ly2s94t/vCzEqK4pNUBmK9Os5Z+SLpx6kPXhvNEp7WPX+abxHd2r4HekdZrfydBDKSUiPnKs KzvsSya/N1lmsGxL2/dzv/bvkjt96JduUW3/sfPdKtyNh7ewfW9stLAUCWst7n8lPc1amaH8 /IpfExiVWIozEg21mIuKEwGvPWDjtAIAAA== Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:40:27 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5E2AAESESSMB102erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdWdnZXN0IHRvIGFkZCBzb21ldGhpbmcgbGlrZSB0aGUgZm9sbG93aW5nLCB0byBtYWtlIHN1 cmUgaXTigJlzIGNsZWFyOg0KDQrigJxBbiBvZmZlcmVyIGFuZCBhbnN3ZXJlciBNVVNUIHVzZSB0 aGUgU0RQICdjb25uZWN0aW9uJyBhdHRyaWJ1dGUgZXZlbiBpZiBpdA0KIGlzIGtub3duIHRoYXQg Ym90aCBzdXBwb3J0IHRoZSBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlLg0KICBOT1RFOiBBcyBkZWZp bmVkIGluIFtSRkM0MTQ1XSwgaWYgdGhlIFNEUCAnY29ubmVjdGlvbicgYXR0cmlidXRlIGlzIG5v dCBleHBsaWNpdGx5DQogIHByZXNlbnQsIHRoZSBpbXBsaWNpdCBkZWZhdWx0IHZhbHVlIGlzICdu ZXcnLuKAnQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQpGcm9tOiBtbXVzaWMgW21haWx0bzpt bXVzaWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIEhvbG1iZXJnDQpT ZW50OiAxMCBBcHJpbCAyMDE3IDIyOjMyDQpUbzogUm9tYW4gU2hwb3VudCA8cm9tYW5AdGVsdXJp eC5jb20+DQpDYzogbW11c2ljLWNoYWlyc0BpZXRmLm9yZzsgbW11c2ljIChFLW1haWwpIDxtbXVz aWNAaWV0Zi5vcmc+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NClN1YmplY3Q6IFJl OiBbTU1VU0lDXSBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1dGUgb3B0aW9uYWwgW3dhczogRFRMUy1T RFA6IFRMUyBzdXBwb3J0IGFkZGVkXQ0KDQpIaSwNCg0KPkEgdGhpbmsgZm9yIGFsbCB0aGUgbm9y bWFsIGNhc2VzIG09Y29ubmVjdGlvbiBhdHRyaWJ1dGUgbXVzdCBiZSBzcGVjaWZpZWQgd2hlbiA+ VExTIGlzIHVzZWQuIFRoZXJlIGlzIG5vIHdheSB0byBrbm93IGlmIHJlbW90ZSBwYXJ0eSBzdXBw b3J0cyB0bHMtaWQgd2hlbiBvZmZlciA+aXMgc2VudCwgc28gaWYgbT1jb25uZWN0aW9uIGlzIG5v dCBzcGVjaWZpZWQsIHRoZW4gaXQgaXMgdW5jbGVhciBob3cgdGhlIG9mZmVyIGlzID5nb2luZyB0 byBiZSBwcm9jZXNzZWQuDQoNCkkgd2FzIHRoaW5raW5nIG1vcmUgYWJvdXQgc3Vic2VxdWVudCBv ZmZlcnMgYW5kIGFuc3dlcnMsIHdoZW4gaXQgaXMga25vd24gd2hldGhlciBib3RoIGVuZHBvaW50 cyBzdXBwb3J0IHRscy1pZC4NCg0KQnV0LCBJIGFtIGZpbmUgdG8ga2VlcCB1c2luZyB0aGUgY29u bmVjdGlvbiBhdHRyaWJ1dGUgYWxzbyBpbiB0aGF0IGNhc2UsIHRvZ2V0aGVyIHdpdGggdGxzLWlk LiBTbywgaWYgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGlzIG5vdCBwcmVzZW50LCBpcyBzaGFs bCBiZSBpbnRlcnByZXRlZCBhcyDigJhuZXfigJksIGFjY29yZGluZyB0byBSRkMgNDE0NS4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KT24gTW9uLCBBcHIgMTAsIDIwMTcgYXQgMzoxMCBQTSwg Q2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbTxtYWlsdG86 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPj4gd3JvdGU6DQpBbmQgWFhYIHN0YW5kcyBm b3Igc2VjdGlvbiA1LjEgOikNCg0KRnJvbTogQ2hyaXN0ZXIgSG9sbWJlcmcNClNlbnQ6IDEwIEFw cmlsIDIwMTcgMjI6MTANClRvOiBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdA ZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PjsgbW11 c2ljIChFLW1haWwpIDxtbXVzaWNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpY0BpZXRmLm9yZz4+DQpD YzogbW11c2ljLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bW11c2ljLWNoYWlyc0BpZXRmLm9yZz47 IEJlbiBDYW1wYmVsbCA8YmVuQG5vc3RydW0uY29tPG1haWx0bzpiZW5Abm9zdHJ1bS5jb20+Pg0K U3ViamVjdDogU0RQIGNvbm5lY3Rpb24gYXR0cmlidXRlIG9wdGlvbmFsIFt3YXM6IERUTFMtU0RQ OiBUTFMgc3VwcG9ydCBhZGRlZF0NCg0KSGksDQoNClNlY3Rpb24gWFhYIG9mIFJGQyA0MTQ1IHNh eXM6DQoNCiAgIOKAnFdoZW4gYW4gb2ZmZXJlciBnZW5lcmF0ZXMgYW4gJ20nIGxpbmUgdGhhdCB1 c2VzIFRDUCwgaXQgU0hPVUxEIHByb3ZpZGUgYQ0KICAgY29ubmVjdGlvbiBhdHRyaWJ1dGUgZm9y IHRoZSAnbScgbGluZSB1bmxlc3MgdGhlIGFwcGxpY2F0aW9uIHVzaW5nDQogICB0aGUgJ20nIGxp bmUgaGFzIG90aGVyIG1lYW5zIHRvIGRlYWwgd2l0aCBjb25uZWN0aW9uIHJlZXN0YWJsaXNobWVu dC7igJ0NCg0KTm93LCBpZiBib3RoIGVuZHBvaW50cyBzdXBwb3J0IHRoZSDigJh0bHMtaWTigJkg YXR0cmlidXRlLCB0aGF0IHdvdWxkIGJlIOKAnG90aGVyIG1lYW5z4oCdLg0KDQpIb3dldmVyLCBz ZWN0aW9uIG9mIFJGQyA0MTQ1IHNheXM6DQoNCg0KICAg4oCcVGhlIGRlZmF1bHQgdmFsdWUgb2Yg dGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGluIGJvdGggb2ZmZXJzIGFuZA0KDQogICBhbnN3ZXJz IGlzICduZXcnLuKAnQ0KDQpTbywgSSB0aGluayB3ZSBuZWVkIHRvIHNheSBzb21ldGhpbmcuIEVp dGhlcjoNCg0KDQoxKSAgICAgIElmIGJvdGggZW5kcG9pbnRzIHN1cHBvcnQgdGxzLWlkLCB0aGV5 IGRvbuKAmXQgbmVlZCB0byBjYXJlIGFib3V0IHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSAob3Ig dGhlIGRlZmF1bHQgdmFsdWUgaW4gY2FzZSB0aGUgYXR0cmlidXRlIGlzIG5vdCBwcmVzZW50KTsg T1INCg0KMikgICAgICBXZSBtYW5kYXRlIHRoYXQgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGlz IHByZXNlbnQsIHdpdGggYW4g4oCYZXhpc3RpbmfigJkgdmFsdWUsIHdoZW5ldmVyIGFuIGV4aXN0 aW5nIGNvbm5lY3Rpb24gaXMgdG8gYmUgbWFpbnRhaW5lZC4NCg0KT3B0aW9uIDIpIHNlZW1zIG1v c3Qgc2FmZSwgaS5lLiwgd2UgY29udGludWUgdXNpbmcgdGhlIOKAmGNvbm5lY3Rpb27igJkgYXR0 cmlidXRlIGFuZCBpdHMgc2VtYW50aWNzIGV2ZW4gaWYgYm90aCBlbmRwb2ludHMgc3VwcG9ydCB0 aGUg4oCYdGxzLWlk4oCZIGF0dHJpYnV0ZS4NCg0KQ29tbWVudHM/DQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KRnJvbTogbW11c2ljIFttYWlsdG86bW11c2ljLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBDaHJpc3RlciBIb2xtYmVyZw0KU2VudDogMDkgQXByaWwgMjAxNyAxMDox NQ0KVG86IG1tdXNpYyAoRS1tYWlsKSA8bW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0 Zi5vcmc+Pg0KQ2M6IG1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm1tdXNpYy1jaGFpcnNA aWV0Zi5vcmc+OyBCZW4gQ2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbTxtYWlsdG86YmVuQG5vc3Ry dW0uY29tPj4NClN1YmplY3Q6IFtNTVVTSUNdIERUTFMtU0RQOiBUTFMgc3VwcG9ydCBhZGRlZA0K DQpIaSwNCg0KQmFzZWQgb24gdGhlIGRlY2lzaW9uIGluIENoaWNhZ28gdG8gYWxsb3cgdXNhZ2Ug b2YgdGhlIFNEUCDigJhkdGxzLWlk4oCZIGF0dHJpYnV0ZSBhbHNvIGZvciBUTFMgY29ubmVjdGlv bnMsIEkgaGF2ZSBjcmVhdGVkIGEgcHVsbCByZXF1ZXN0Og0KDQpodHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtZHRscy1zZHAvcHVsbC8yNg0KDQpOb3RlIHRoYXQgdGhlIG5hbWUgb2YgdGhl IGF0dHJpYnV0ZSBoYXMgbm93IGJlZW4gY2hhbmdlZCB0byDigJh0bHMtaWTigJkuDQoNClRoZSBh cHByb2FjaCBJ4oCZdmUgdGFrZW4gaXM6IHJhdGhlciB0aGFuIHRhbGtpbmcgYWJvdXQgYm90aCBE VExTIGFuZCBUTFMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQsIEnigJl2ZSBiYXNpY2FsbHkgYWRk ZWQgYSBzZWN0aW9uIGRlc2NyaWJpbmcgdGhlIFRMUy1zcGVjaWZpYyBjb25zaWRlcmF0aW9ucyDi gJMgbWFpbmx5IHJlZ2FyZGluZyB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgU0RQIOKAmGNvbm5l Y3Rpb27igJkgYXR0cmlidXRlLg0KDQpOb3csIEkgdGhpbmsgd2UgZG8gbmVlZCBzb21lIHRleHQg b24gV0hZIHdlIGFsc28gY292ZXIgVExTIGNvbm5lY3Rpb25zIHNpbmNlLCBhcyBmYXIgYXMgY3Jl YXRpbmcgbmV3IGNvbm5lY3Rpb25zIGlzIGNvbmNlcm5lZCwgdGhlIOKAmGNvbm5lY3Rpb27igJkg YXR0cmlidXRlIGNhbiBiZSB1c2VkLiBXZSBrbm93IHRoYXQgaXQgd291bGQgYmUgbmVlZGVkIGZv ciBkcmFmdC10aG9tc29uLWF2dGNvcmUtc2RwLXVrcyAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtdGhvbXNvbi1hdnRjb3JlLXNkcC11a3MvKS4gQnV0LCBBRkFJSyB0aGF0 IHdvcmsgaGFzIG5vdCBiZWVuIGFkb3B0ZWQgeWV0LCBzbyBJIGRvbuKAmXQgdGhpbmsgd2UgY2Fu IHVzZSBpdCBhcyBqdXN0aWZpY2F0aW9uIGF0IHRoaXMgcG9pbnQ/DQoNCk5vdGUgdGhhdCB0aGlz IHB1bGwgcmVxdWVzdCBkb2VzIE5PVCBpbmNsdWRlIGFueSBvZiB0aGUgY2hhbmdlcyB0byBiZSBk b25lIGJhc2VkIG9uIHRoZSBnZW4tYXJ0L3NlYy1kaXIgcmV2aWV3cy4gSSBoYXZlIHVwZGF0ZWQg dGhlIDQ1NzItdXBkYXRlIHJlZmVyZW5jZSwgdGhvdWdoLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbW11 c2ljIG1haWxpbmcgbGlzdA0KbW11c2ljQGlldGYub3JnPG1haWx0bzptbXVzaWNAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYw0KDQo= --_000_7594FB04B1934943A5C02806D1A2204B4CB5E2AAESESSMB102erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVm b3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0 dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1H Qjt9DQpwLm0tMjk4ODMyNDI2OTI2ODU2NDk2MW1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tMjk4ODMy NDI2OTI2ODU2NDk2MW1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5tLTI5ODgzMjQyNjkyNjg1NjQ5NjFt c29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOm1fLTI5ODgzMjQyNjkyNjg1NjQ5NjFt c29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pkkgc3VnZ2VzdCB0byBhZGQgc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZywgdG8gbWFrZSBz dXJlIGl04oCZcyBjbGVhcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPuKAnEFuIG9mZmVyZXIgYW5kIGFuc3dlcmVyIE1VU1QgdXNlIHRoZSBTRFAgJ2Nvbm5lY3Rp b24nIGF0dHJpYnV0ZSBldmVuIGlmIGl0PG86cD48L286cD48L3NwYW4+PC9pPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDtpcyBrbm93biB0aGF0IGJvdGggc3VwcG9ydCB0aGUg U0RQICd0bHMtaWQnIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+Jm5ic3A7Jm5ic3A7Tk9URTogQXMgZGVmaW5lZCBpbiBbUkZDNDE0NV0s IGlmIHRoZSBTRFAgJ2Nvbm5lY3Rpb24nIGF0dHJpYnV0ZSBpcyBub3QgZXhwbGljaXRseTxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7IHBy ZXNlbnQsIHRoZSBpbXBsaWNpdCBkZWZhdWx0IHZhbHVlIGlzICduZXcnLuKAnTxvOnA+PC9vOnA+ PC9zcGFuPjwvaT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBtbXVzaWMgW21h aWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Q2hyaXN0 ZXIgSG9sbWJlcmc8YnI+DQo8Yj5TZW50OjwvYj4gMTAgQXByaWwgMjAxNyAyMjozMjxicj4NCjxi PlRvOjwvYj4gUm9tYW4gU2hwb3VudCAmbHQ7cm9tYW5AdGVsdXJpeC5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBtbXVzaWMgKEUtbWFpbCkgJmx0O21tdXNp Y0BpZXRmLm9yZyZndDs7IEJlbiBDYW1wYmVsbCAmbHQ7YmVuQG5vc3RydW0uY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogW01NVVNJQ10gU0RQIGNvbm5lY3Rpb24gYXR0cmlidXRlIG9w dGlvbmFsIFt3YXM6IERUTFMtU0RQOiBUTFMgc3VwcG9ydCBhZGRlZF08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mZ3Q7PC9zcGFuPkEgdGhpbmsgZm9yIGFsbCB0aGUgbm9ybWFsIGNhc2VzIG09 Y29ubmVjdGlvbiBhdHRyaWJ1dGUgbXVzdCBiZSBzcGVjaWZpZWQgd2hlbg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+VExTIGlzIHVzZWQuIFRoZXJlIGlzIG5vIHdheSB0 byBrbm93IGlmIHJlbW90ZSBwYXJ0eSBzdXBwb3J0cyB0bHMtaWQgd2hlbiBvZmZlcg0KPHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+aXMgc2VudCwgc28gaWYgbT1jb25uZWN0 aW9uIGlzIG5vdCBzcGVjaWZpZWQsIHRoZW4gaXQgaXMgdW5jbGVhciBob3cgdGhlIG9mZmVyIGlz DQo8c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jmd0Ozwvc3Bhbj5nb2luZyB0byBiZSBwcm9j ZXNzZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg d2FzIHRoaW5raW5nIG1vcmUgYWJvdXQgc3Vic2VxdWVudCBvZmZlcnMgYW5kIGFuc3dlcnMsIHdo ZW4gaXQgaXMga25vd24gd2hldGhlciBib3RoIGVuZHBvaW50cyBzdXBwb3J0IHRscy1pZC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkJ1dCwgSSBhbSBmaW5lIHRv IGtlZXAgdXNpbmcgdGhlIGNvbm5lY3Rpb24gYXR0cmlidXRlIGFsc28gaW4gdGhhdCBjYXNlLCB0 b2dldGhlciB3aXRoIHRscy1pZC4gU28sIGlmIHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSBpcyBu b3QgcHJlc2VudCwgaXMgc2hhbGwgYmUgaW50ZXJwcmV0ZWQNCiBhcyDigJhuZXfigJksIGFjY29y ZGluZyB0byBSRkMgNDE0NS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5D aHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T24gTW9uLCBBcHIgMTAsIDIwMTcgYXQgMzoxMCBQTSwgQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0OzxhIGhyZWY9Im1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20i IHRhcmdldD0iX2JsYW5rIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5BbmQgWFhYIHN0YW5kcyBmb3Igc2VjdGlvbiA1LjEgOik8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1f LTI5ODgzMjQyNjkyNjg1NjQ5NjFfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iY29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9 IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBDaHJpc3RlciBIb2xt YmVyZw0KPGJyPg0KPGI+U2VudDo8L2I+IDEwIEFwcmlsIDIwMTcgMjI6MTA8YnI+DQo8Yj5Ubzo8 L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nz b24uY29tPC9hPiZndDs7IG1tdXNpYyAoRS1tYWlsKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86bW11c2ljLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBCZW4gQ2FtcGJlbGwgJmx0Ozxh IGhyZWY9Im1haWx0bzpiZW5Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5Abm9zdHJ1 bS5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBTRFAgY29ubmVjdGlvbiBhdHRyaWJ1 dGUgb3B0aW9uYWwgW3dhczogRFRMUy1TRFA6IFRMUyBzdXBwb3J0IGFkZGVkXTwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5TZWN0aW9uIFhYWCBvZiBSRkMgNDE0NSBzYXlzOjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyDigJxXaGVuIGFuIG9mZmVyZXIgZ2VuZXJhdGVzIGFuICdt JyBsaW5lIHRoYXQgdXNlcyBUQ1AsIGl0IFNIT1VMRCBwcm92aWRlIGE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgY29u bmVjdGlvbiBhdHRyaWJ1dGUgZm9yIHRoZSAnbScgbGluZSB1bmxlc3MgdGhlIGFwcGxpY2F0aW9u IHVzaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IHRoZSAnbScgbGluZSBoYXMgb3RoZXIgbWVhbnMgdG8gZGVhbCB3 aXRoIGNvbm5lY3Rpb24gcmVlc3RhYmxpc2htZW50LuKAnTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPk5vdywgaWYgYm90aCBlbmRwb2ludHMgc3VwcG9ydCB0aGUg4oCY dGxzLWlk4oCZIGF0dHJpYnV0ZSwgdGhhdCB3b3VsZCBiZSDigJxvdGhlciBtZWFuc+KAnS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Ib3dldmVyLCBzZWN0aW9uIG9m IFJGQyA0MTQ1IHNheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHByZT4mbmJzcDsmbmJzcDsg4oCcVGhlIGRlZmF1bHQgdmFsdWUgb2YgdGhlIGNvbm5l Y3Rpb24gYXR0cmlidXRlIGluIGJvdGggb2ZmZXJzIGFuZDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZuYnNwOyZuYnNwOyBhbnN3ZXJzIGlzICduZXcnLuKAnTxvOnA+PC9vOnA+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj5TbywgSSB0aGluayB3ZSBuZWVkIHRvIHNheSBzb21ldGhpbmcuIEVpdGhl cjo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0ibS0yOTg4MzI0MjY5MjY4NTY0OTYxbXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjEpPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPklmIGJvdGggZW5kcG9pbnRzIHN1cHBvcnQgdGxzLWlkLCB0aGV5 IGRvbuKAmXQgbmVlZCB0byBjYXJlIGFib3V0IHRoZSBjb25uZWN0aW9uIGF0dHJpYnV0ZSAob3Ig dGhlIGRlZmF1bHQgdmFsdWUgaW4gY2FzZSB0aGUgYXR0cmlidXRlIGlzIG5vdCBwcmVzZW50KTsg T1I8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibS0yOTg4MzI0MjY5MjY4NTY0OTYx bXNvbGlzdHBhcmFncmFwaCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjIpPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIG1h bmRhdGUgdGhhdCB0aGUgY29ubmVjdGlvbiBhdHRyaWJ1dGUgaXMgcHJlc2VudCwgd2l0aCBhbiDi gJhleGlzdGluZ+KAmSB2YWx1ZSwgd2hlbmV2ZXIgYW4gZXhpc3RpbmcgY29ubmVjdGlvbiBpcyB0 byBiZSBtYWludGFpbmVkLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi Pk9wdGlvbiAyKSBzZWVtcyBtb3N0IHNhZmUsIGkuZS4sIHdlIGNvbnRpbnVlIHVzaW5nIHRoZSDi gJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZSBhbmQgaXRzIHNlbWFudGljcyBldmVuIGlmIGJvdGgg ZW5kcG9pbnRzIHN1cHBvcnQgdGhlIOKAmHRscy1pZOKAmSBhdHRyaWJ1dGUuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Q29tbWVudHM/PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVO LVVTIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBtbXVzaWMgWzxhIGhyZWY9 Im1haWx0bzptbXVzaWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpt bXVzaWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkNocmlzdGVy IEhvbG1iZXJnPGJyPg0KPGI+U2VudDo8L2I+IDA5IEFwcmlsIDIwMTcgMTA6MTU8YnI+DQo8Yj5U bzo8L2I+IG1tdXNpYyAoRS1tYWlsKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1tdXNpY0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1tdXNpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9i PiA8YSBocmVmPSJtYWlsdG86bW11c2ljLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1tdXNpYy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyBCZW4gQ2FtcGJlbGwgJmx0OzxhIGhyZWY9Im1h aWx0bzpiZW5Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5iZW5Abm9zdHJ1bS5jb208L2E+ Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTU1VU0lDXSBEVExTLVNEUDogVExTIHN1cHBvcnQg YWRkZWQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SGksPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CYXNlZCBvbiB0aGUgZGVjaXNpb24gaW4g Q2hpY2FnbyB0byBhbGxvdyB1c2FnZSBvZiB0aGUgU0RQIOKAmGR0bHMtaWTigJkgYXR0cmlidXRl IGFsc28gZm9yIFRMUyBjb25uZWN0aW9ucywgSSBoYXZlIGNyZWF0ZWQgYSBwdWxsIHJlcXVlc3Q6 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v Y2RoNHUvZHJhZnQtZHRscy1zZHAvcHVsbC8yNiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0 aHViLmNvbS9jZGg0dS9kcmFmdC1kdGxzLXNkcC9wdWxsLzI2PC9hPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Tm90ZSB0aGF0IHRoZSBuYW1lIG9mIHRoZSBhdHRyaWJ1dGUgaGFzIG5vdyBi ZWVuIGNoYW5nZWQgdG8g4oCYdGxzLWlk4oCZLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIGFwcHJvYWNoIEnigJl2ZSB0YWtlbiBpczogcmF0aGVyIHRoYW4gdGFsa2luZyBhYm91dCBi b3RoIERUTFMgYW5kIFRMUyB0aHJvdWdob3V0IHRoZSBkb2N1bWVudCwgSeKAmXZlIGJhc2ljYWxs eSBhZGRlZCBhIHNlY3Rpb24gZGVzY3JpYmluZyB0aGUgVExTLXNwZWNpZmljIGNvbnNpZGVyYXRp b25zIOKAkyBtYWlubHkNCiByZWdhcmRpbmcgdGhlIGludGVyYWN0aW9uIHdpdGggdGhlIFNEUCDi gJhjb25uZWN0aW9u4oCZIGF0dHJpYnV0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk5v dywgSSB0aGluayB3ZSBkbyBuZWVkIHNvbWUgdGV4dCBvbiBXSFkgd2UgYWxzbyBjb3ZlciBUTFMg Y29ubmVjdGlvbnMgc2luY2UsIGFzIGZhciBhcyBjcmVhdGluZyBuZXcgY29ubmVjdGlvbnMgaXMg Y29uY2VybmVkLCB0aGUg4oCYY29ubmVjdGlvbuKAmSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQuIFdl IGtub3cgdGhhdA0KIGl0IHdvdWxkIGJlIG5lZWRlZCBmb3IgZHJhZnQtdGhvbXNvbi1hdnRjb3Jl LXNkcC11a3MgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LXRob21zb24tYXZ0Y29yZS1zZHAtdWtzLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXRob21zb24tYXZ0Y29yZS1zZHAtdWtzLzwvYT4pLiBC dXQsIEFGQUlLIHRoYXQgd29yayBoYXMgbm90IGJlZW4gYWRvcHRlZA0KIHlldCwgc28gSSBkb27i gJl0IHRoaW5rIHdlIGNhbiB1c2UgaXQgYXMganVzdGlmaWNhdGlvbiBhdCB0aGlzIHBvaW50Pzxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm90ZSB0aGF0IHRoaXMgcHVsbCByZXF1ZXN0IGRv ZXMgTk9UIGluY2x1ZGUgYW55IG9mIHRoZSBjaGFuZ2VzIHRvIGJlIGRvbmUgYmFzZWQgb24gdGhl IGdlbi1hcnQvc2VjLWRpciByZXZpZXdzLiBJIGhhdmUgdXBkYXRlZCB0aGUgNDU3Mi11cGRhdGUg cmVmZXJlbmNlLCB0aG91Z2guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCm1tdXNpYyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86bW11c2ljQGlldGYub3JnIj5tbXVzaWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21tdXNpYzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7594FB04B1934943A5C02806D1A2204B4CB5E2AAESESSMB102erics_-- From nobody Mon Apr 10 12:49:43 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58B67129AB7 for ; Mon, 10 Apr 2017 12:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 1ggzFSkWVMH7 for ; Mon, 10 Apr 2017 12:49:39 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (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 0D2AC129A9C for ; Mon, 10 Apr 2017 12:49:39 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id c198so26846573pfc.1 for ; Mon, 10 Apr 2017 12:49:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xEBJGboRRMcW51J+bQTP/5LKDvL/hg7QAgXihHrc75g=; b=fCp0bkAPzU1scObV8yEqYYR6Vl+/vuKnQ8lTIZyLRjewxH0km1e2AneBPYL8NUPQ/Z 8WJ/9rV/5IfCh7kHsBLCSOAfh+1Fy1b5RBMgRt2dGBXU9ZD3Sav90D2dOPGces6Z7d92 hO0VbH1vTgCCqgDxQeZmfgaH6ZDYmScF8kfcjGwrg2tRomEdxmYPOxhSBCgI1FCMhM3N U2//Gt6L1qIUH3TFtKYx8ya4VAK6sKIg28sTvFfsPnJZW3OVypYtpxeRRIcuKLoFIMQ8 xegl3PyxUSSG0g3Mv4a+I1i3dpZTaYn1ybecTS5lD5IkDrpn6Zh9Cy2I+gyWom6N+hT3 K+FA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xEBJGboRRMcW51J+bQTP/5LKDvL/hg7QAgXihHrc75g=; b=e/KH2quUBUEwNmX6ww9sB58WNMGSMmYlVStWnhwxuUkAEwUg7gPo5FaMQSP37+Inwb 0804DvAA4lJjy/Dr1mZBmz1eo/kKnzJpCF1sglUr6ztdQGcJ8h5en7n1MAz1zhaJZfcN +R5e1FbMWiTbIHp4/+ldXrQX5RMqi/BKr1mD6G5ioVQrFAXpDlC7Gk2OFNm5agtBYZwg K4un+oyO1Rzr/7KJhTbdl+Raup0yzvn1MPUNT02acgcJOhACohG1AWpNeqQq3L/8CQKa C/ih3kCvJ9SDnRAaHiar9V8/N3QsJVEN6pN8Aw1wqWZkKDTUmrP1Af0qXMAK1ma4Kg6m y04A== X-Gm-Message-State: AN3rC/7npajp9CZenUMW6O43hArvVkS54l9JMKSoMnQnwcYsGTt0M7I5T+QII4FbXCFatg== X-Received: by 10.84.217.136 with SMTP id p8mr25722254pli.47.1491853778667; Mon, 10 Apr 2017 12:49:38 -0700 (PDT) Received: from mail-pg0-f48.google.com (mail-pg0-f48.google.com. [74.125.83.48]) by smtp.gmail.com with ESMTPSA id z21sm4426564pfk.95.2017.04.10.12.49.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 12:49:38 -0700 (PDT) Received: by mail-pg0-f48.google.com with SMTP id 81so110809617pgh.2; Mon, 10 Apr 2017 12:49:38 -0700 (PDT) X-Received: by 10.99.122.78 with SMTP id j14mr57087472pgn.52.1491853777822; Mon, 10 Apr 2017 12:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 10 Apr 2017 12:49:37 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5E2AA@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5E1CC@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E219@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E275@ESESSMB102.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4CB5E2AA@ESESSMB102.ericsson.se> From: Roman Shpount Date: Mon, 10 Apr 2017 15:49:37 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic-chairs@ietf.org" , "mmusic (E-mail)" , Ben Campbell Content-Type: multipart/alternative; boundary=f403045c5df47bf0c0054cd5468d Archived-At: Subject: Re: [MMUSIC] SDP connection attribute optional [was: DTLS-SDP: TLS support added] X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 19:49:41 -0000 --f403045c5df47bf0c0054cd5468d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Apr 10, 2017 at 3:40 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > I suggest to add something like the following, to make sure it=E2=80=99s = clear: > > > > *=E2=80=9CAn offerer and answerer MUST use the SDP 'connection' attribute= even if > it* > > * is known that both support the SDP 'tls-id' attribute.* > > * NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is no= t > explicitly* > > * present, the implicit default value is 'new'.=E2=80=9D* > If third party call control is used it is not known that the same end points are communicating. Because of this it is never quite known what is supported by the remote end point when offer is generated. Because of this I would prefer this language to say that "Offerers should not make assumptions about the support of SDP 'tls-id' attribute and MUST always use SDP 'connection' attribute. To avoid ambiguity, answerers MUST always use SDP 'connection' attribute as well. NOTE: As defined in [RFC4145], if the SDP 'connection' attribute is not explicitly present, the implicit default value is 'new'." Regards, _____________ Roman Shpount --f403045c5df47bf0c0054cd5468d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Apr 10, 2017 at 3:4= 0 PM, Christer Holmberg <christer.holmberg@ericsson.com&g= t; wrote:

I suggest to add something like the followin= g, to make sure it=E2=80=99s clear:

=C2=A0

=E2=80=9CAn offerer and answerer MUST use= the SDP 'connection' attribute even if it=

=C2=A0is known that both support the SDP = 'tls-id' attribute.

=C2=A0=C2=A0NOTE: As defined in [RFC4145]= , if the SDP 'connection' attribute is not explicitly=

=C2=A0 present, the implicit default valu= e is 'new'.=E2=80=9D

= =C2=A0
If third party call control is used it is not known that t= he same end points are communicating. Because of this it is never quite kno= wn what is supported by the remote end point when offer is generated. Becau= se of this I would prefer this language to say that "Offerers should n= ot make assumptions about the support of SDP=C2=A0'tls-id' attribut= e and MUST always use SDP 'connection' attribute. To avoid ambiguit= y, answerers MUST always use SDP 'connection' attribute as well.=C2= =A0 NOTE: As defined in [RFC4145], if the SDP 'connection' attribut= e is not explicitly=C2=A0present, the implicit default value is 'new= 9;."

Regards,
_____________
Roman Shpount
=C2=A0
=
--f403045c5df47bf0c0054cd5468d-- From nobody Mon Apr 10 13:01:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC771201F8 for ; Mon, 10 Apr 2017 13:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 50kRD9aHeor0 for ; Mon, 10 Apr 2017 13:01:36 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 DDC9E129AEB for ; Mon, 10 Apr 2017 13:01:14 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c198so26966082pfc.1 for ; Mon, 10 Apr 2017 13:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtG1ajATo1a+5squbtAk56ffw6Et76wA5XYkBQmWpHo=; b=2Mp3gkFrjgTXR2JFQ89lbBueMpCK7RcTEOsBsVkjoVEtJQZKkefwjqJK7zo+dS2W0I +S8WAa44U5CBY3Ecmo3XNIJ04msK3Z+L9BlYGvUFFbuZemCnnWZv2XK7RXLXy9JLvsJw hXQ/kLxaX1JEk6BgpBpb1qgkCTEWJOszO67U+WllM4pNW2jM6nYXBaiA+WA8DchAT8hg hbyVM7y2N0t8N9XXcsJXhtOHNq7/SE7mLNU3GQlRPG+HcZrOoJdnk65alYmpp2C6f2d0 XSyaCDV/tENTw2UT6NKGwNOJB6cEBtnnbhFPWHNkm4cNBw5unvim8x74FVifO6ywjn2V 4svw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtG1ajATo1a+5squbtAk56ffw6Et76wA5XYkBQmWpHo=; b=YE0Ux6xSBXUCvPkQ3gzMzKh3Rr1eW804mGQUss4+ZJNhx67EdDMiNf+4ppaEWS+ja9 uuee17LOPpqNz9RUiM9gMXrLGsKd5rXl8h8vBqHvnS1p9QXGaxJwIzWnMNg644wjx+gp 3jWu3V0653Mdx4KSaRIquWZRiehvjRjPG39ZN2C/6S5Nf9LEjaV1dA/KA0wQzhz+m5f9 geu752NrI7Pdo347/iTIYt5nin3tlY/0rVN2UkWh7HehKsmX16QeLZ4Y2cJny8eszZhS mAgz75EDIImuMhbEVtcdHLNIh9zpqOXbZj8IFPp2Sqcp5apUw+bJrsIbc4EbGwFdJSAk K8Aw== X-Gm-Message-State: AFeK/H0KlqxTHNhU/p1D1MSzls1cCyU4wTcl5GzgYZn/qs++RP8+KfDH9Uiu+L3DlnIQsQ== X-Received: by 10.84.248.74 with SMTP id e10mr32362325pln.76.1491854474528; Mon, 10 Apr 2017 13:01:14 -0700 (PDT) Received: from mail-pf0-f173.google.com (mail-pf0-f173.google.com. [209.85.192.173]) by smtp.gmail.com with ESMTPSA id p68sm26192984pga.6.2017.04.10.13.01.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 10 Apr 2017 13:01:14 -0700 (PDT) Received: by mail-pf0-f173.google.com with SMTP id s16so38088727pfs.0; Mon, 10 Apr 2017 13:01:13 -0700 (PDT) X-Received: by 10.84.177.164 with SMTP id x33mr39739771plb.147.1491854473652; Mon, 10 Apr 2017 13:01:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Mon, 10 Apr 2017 13:01:13 -0700 (PDT) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB5BAC0@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5BAC0@ESESSMB102.ericsson.se> From: Roman Shpount Date: Mon, 10 Apr 2017 16:01:13 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "mmusic (E-mail)" , "mmusic-chairs@ietf.org" , Ben Campbell Content-Type: multipart/alternative; boundary=94eb2c11a6acf57522054cd56f5f Archived-At: Subject: Re: [MMUSIC] DTLS-SDP: TLS support added X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Apr 2017 20:01:38 -0000 --94eb2c11a6acf57522054cd56f5f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Apr 9, 2017 at 3:14 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Now, I think we do need some text on WHY we also cover TLS connections > since, as far as creating new connections is concerned, the =E2=80=98conn= ection=E2=80=99 > attribute can be used. We know that it would be needed for > draft-thomson-avtcore-sdp-uks (https://datatracker.ietf.org/ > doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been > adopted yet, so I don=E2=80=99t think we can use it as justification at t= his point? > > > I was thinking that we should include something like: The pair of newly defined SDP 'tls-id' attribute values from the offer and the corresponding answer can be used to uniquely identify TLS or DTLS association. This unique identifier can be used by TLS protocol extensions to differentiate between multiple TLS and DTLS association and correlate these associations with specific offer/answer exchanges. _____________ Roman Shpount --94eb2c11a6acf57522054cd56f5f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Apr 9, 2017 at 3:14 AM, Christer Holmberg &l= t;chris= ter.holmberg@ericsson.com> wrote:

Now, I think we do need some text on WHY we also cov= er TLS connections since, as far as creating new connections is concerned, = the =E2=80=98connection=E2=80=99 attribute can be used. We know that it wou= ld be needed for draft-thomson-avtcore-sdp-uks (https://= datatracker.ietf.org/doc/draft-thomson-avtcore-sdp-uks/). But, AFAIK that work has not been adopted yet, so I don=E2=80=99t think we= can use it as justification at this point?

<= u>



I was thinking that we should include something like:

=
The pair of newly defined SDP 'tls-id' attribute values from t= he offer and the corresponding answer can be used to uniquely identify TLS = or DTLS association. This unique identifier can be used by TLS protocol ext= ensions to differentiate between multiple TLS and DTLS association and corr= elate these associations with specific offer/answer exchanges.
_____________
Roman Shpount
=C2=A0
--94eb2c11a6acf57522054cd56f5f-- From nobody Tue Apr 11 00:10:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CB15128954; Tue, 11 Apr 2017 00:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0sJ_9nengrV; Tue, 11 Apr 2017 00:10:34 -0700 (PDT) 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 51749126DFB; Tue, 11 Apr 2017 00:10:34 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-83-58ec81684c19 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 16.93.21650.8618CE85; Tue, 11 Apr 2017 09:10:32 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0339.000; Tue, 11 Apr 2017 09:10:31 +0200 From: Christer Holmberg To: Roman Shpount CC: "mmusic (E-mail)" , "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: [MMUSIC] DTLS-SDP: TLS support added Thread-Index: AdKxB4Lc4UmU6rXIStewG5QwlYhu+QBHO4OAAB2jAbA= Date: Tue, 11 Apr 2017 07:11:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB5F5F8@ESESSMB102.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4CB5BAC0@ESESSMB102.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB5F5F8ESESSMB102erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIIsWRmVeSWpSXmKPExsUyM2K7qG5G45sIg1//JCzmd55mtzi/cz2T xdTlj1ksZlyYyuzA4rFkyU8mj1k7n7B43JpSEMAcxWWTkpqTWZZapG+XwJXRP6eLseBQRMXU D6cYGxh7wroYOTgkBEwktt7g72Lk4hASWM8o8fbqKUYIZwmjxPzOnUwgRWwCFhLd/7S7GDk5 RARUJf5+n8wEYjML1Eh8aO9kA7GFBQwlbr59yQZRYyTRsvIdE4RtJXHi3SYWEJsFqHfNm2us IDavgK/EsuPr2SB2TWGUmLRzIjNIglMgUOLalE1gNqOAmMT3U2uglolL3HoyH8yWEBCQWLLn PDOELSrx8vE/VghbSWLR7c9Q9fkSJ6/9YIRYJihxcuYTlgmMIrOQjJqFpGwWkrJZQC8zC2hK rN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgRF3 cMtvqx2MB587HmIU4GBU4uF90P86Qog1say4MvcQowQHs5II79UOoBBvSmJlVWpRfnxRaU5q 8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2Mmc/PZjyMWlHAU9m0wevapXW9MrkW v24Zhc2akSFTwTJ5SfSKQlcWm09nD9p7rrgvz/PH4seVTgEPbmd3Fe5fe1QP2di1zDB0mv9t gbaXzpawUxHuko0nubK4gxLupf0Sf/3jx5Ljt5XVUuWPVvTP7N46++qFR04OazZLX3MKnRq4 y+jU2e8cSizFGYmGWsxFxYkAz23wKbQCAAA= Archived-At: Subject: Re: [MMUSIC] DTLS-SDP: TLS support added X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Apr 2017 07:10:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB5F5F8ESESSMB102erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJhc2VkIG9uIHRoZSBpbnB1dCBmcm9tIFJvbWFuLCBJ4oCZdmUgdXBkYXRlZCB0aGUg cHVsbCByZXF1ZXN0Lg0KDQpodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtZHRscy1zZHAv cHVsbC8yNg0KDQpJIHVzZWQgc2VwYXJhdGUgY29tbWl0cyBmb3IgdGhlIOKAmGNvbm5lY3Rpb24g YXR0cmlidXRlIGNsYXJpZmljYXRpb27igJkgYW5kIHRoZSDigJhUTFMganVzdGlmaWNhdGlvbuKA mS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9tYW4gU2hwb3VudCBbbWFpbHRv OnJvbWFuQHRlbHVyaXguY29tXQ0KU2VudDogMTAgQXByaWwgMjAxNyAyMzowMQ0KVG86IENocmlz dGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQpDYzogbW11c2lj IChFLW1haWwpIDxtbXVzaWNAaWV0Zi5vcmc+OyBtbXVzaWMtY2hhaXJzQGlldGYub3JnOyBCZW4g Q2FtcGJlbGwgPGJlbkBub3N0cnVtLmNvbT4NClN1YmplY3Q6IFJlOiBbTU1VU0lDXSBEVExTLVNE UDogVExTIHN1cHBvcnQgYWRkZWQNCg0KT24gU3VuLCBBcHIgOSwgMjAxNyBhdCAzOjE0IEFNLCBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpj aHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCk5vdywgSSB0aGluayB3ZSBk byBuZWVkIHNvbWUgdGV4dCBvbiBXSFkgd2UgYWxzbyBjb3ZlciBUTFMgY29ubmVjdGlvbnMgc2lu Y2UsIGFzIGZhciBhcyBjcmVhdGluZyBuZXcgY29ubmVjdGlvbnMgaXMgY29uY2VybmVkLCB0aGUg 4oCYY29ubmVjdGlvbuKAmSBhdHRyaWJ1dGUgY2FuIGJlIHVzZWQuIFdlIGtub3cgdGhhdCBpdCB3 b3VsZCBiZSBuZWVkZWQgZm9yIGRyYWZ0LXRob21zb24tYXZ0Y29yZS1zZHAtdWtzIChodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC10aG9tc29uLWF2dGNvcmUtc2RwLXVrcy8p LiBCdXQsIEFGQUlLIHRoYXQgd29yayBoYXMgbm90IGJlZW4gYWRvcHRlZCB5ZXQsIHNvIEkgZG9u 4oCZdCB0aGluayB3ZSBjYW4gdXNlIGl0IGFzIGp1c3RpZmljYXRpb24gYXQgdGhpcyBwb2ludD8N Cg0KDQpJIHdhcyB0aGlua2luZyB0aGF0IHdlIHNob3VsZCBpbmNsdWRlIHNvbWV0aGluZyBsaWtl Og0KDQpUaGUgcGFpciBvZiBuZXdseSBkZWZpbmVkIFNEUCAndGxzLWlkJyBhdHRyaWJ1dGUgdmFs dWVzIGZyb20gdGhlIG9mZmVyIGFuZCB0aGUgY29ycmVzcG9uZGluZyBhbnN3ZXIgY2FuIGJlIHVz ZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgVExTIG9yIERUTFMgYXNzb2NpYXRpb24uIFRoaXMgdW5p cXVlIGlkZW50aWZpZXIgY2FuIGJlIHVzZWQgYnkgVExTIHByb3RvY29sIGV4dGVuc2lvbnMgdG8g ZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIG11bHRpcGxlIFRMUyBhbmQgRFRMUyBhc3NvY2lhdGlvbiBh bmQgY29ycmVsYXRlIHRoZXNlIGFzc29jaWF0aW9ucyB3aXRoIHNwZWNpZmljIG9mZmVyL2Fuc3dl ciBleGNoYW5nZXMuDQpfX19fX19fX19fX19fDQpSb21hbiBTaHBvdW50DQoNCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB5F5F8ESESSMB102erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJhc2VkIG9uIHRoZSBpbnB1dCBmcm9tIFJvbWFuLCBJ 4oCZdmUgdXBkYXRlZCB0aGUgcHVsbCByZXF1ZXN0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL2NkaDR1L2RyYWZ0LWR0 bHMtc2RwL3B1bGwvMjYiPmh0dHBzOi8vZ2l0aHViLmNvbS9jZGg0dS9kcmFmdC1kdGxzLXNkcC9w dWxsLzI2PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB1c2Vk IHNlcGFyYXRlIGNvbW1pdHMgZm9yIHRoZSDigJhjb25uZWN0aW9uIGF0dHJpYnV0ZSBjbGFyaWZp Y2F0aW9u4oCZIGFuZCB0aGUg4oCYVExTIGp1c3RpZmljYXRpb27igJkuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2E+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiBSb21hbiBTaHBvdW50IFttYWlsdG86cm9tYW5AdGVsdXJpeC5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gMTAgQXByaWwgMjAxNyAyMzowMTxicj4NCjxiPlRvOjwvYj4gQ2hyaXN0ZXIgSG9s bWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IG1tdXNpYyAoRS1tYWlsKSAmbHQ7bW11c2ljQGlldGYub3JnJmd0OzsgbW11c2ljLWNoYWly c0BpZXRmLm9yZzsgQmVuIENhbXBiZWxsICZsdDtiZW5Abm9zdHJ1bS5jb20mZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbTU1VU0lDXSBEVExTLVNEUDogVExTIHN1cHBvcnQgYWRkZWQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBTdW4sIEFwciA5LCAyMDE3IGF0IDM6MTQgQU0sIENocmlzdGVyIEhvbG1iZXJnICZsdDs8YSBo cmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFu ayI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm93LCBJIHRoaW5rIHdlIGRvIG5lZWQgc29tZSB0ZXh0 IG9uIFdIWSB3ZSBhbHNvIGNvdmVyIFRMUyBjb25uZWN0aW9ucyBzaW5jZSwgYXMgZmFyIGFzIGNy ZWF0aW5nIG5ldyBjb25uZWN0aW9ucyBpcyBjb25jZXJuZWQsIHRoZSDigJhjb25uZWN0aW9u4oCZ IGF0dHJpYnV0ZSBjYW4gYmUgdXNlZC4gV2Uga25vdyB0aGF0DQogaXQgd291bGQgYmUgbmVlZGVk IGZvciBkcmFmdC10aG9tc29uLWF2dGNvcmUtc2RwLXVrcyAoPGEgaHJlZj0iaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGhvbXNvbi1hdnRjb3JlLXNkcC11a3MvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGhvbXNv bi1hdnRjb3JlLXNkcC11a3MvPC9hPikuIEJ1dCwgQUZBSUsgdGhhdCB3b3JrIGhhcyBub3QgYmVl biBhZG9wdGVkDQogeWV0LCBzbyBJIGRvbuKAmXQgdGhpbmsgd2UgY2FuIHVzZSBpdCBhcyBqdXN0 aWZpY2F0aW9uIGF0IHRoaXMgcG9pbnQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHRoaW5raW5nIHRoYXQgd2Ug c2hvdWxkIGluY2x1ZGUgc29tZXRoaW5nIGxpa2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBwYWlyIG9mIG5ld2x5IGRlZmluZWQgU0RQ ICd0bHMtaWQnIGF0dHJpYnV0ZSB2YWx1ZXMgZnJvbSB0aGUgb2ZmZXIgYW5kIHRoZSBjb3JyZXNw b25kaW5nIGFuc3dlciBjYW4gYmUgdXNlZCB0byB1bmlxdWVseSBpZGVudGlmeSBUTFMgb3IgRFRM UyBhc3NvY2lhdGlvbi4gVGhpcyB1bmlxdWUgaWRlbnRpZmllciBjYW4gYmUgdXNlZCBieSBUTFMg cHJvdG9jb2wgZXh0ZW5zaW9ucyB0byBkaWZmZXJlbnRpYXRlDQogYmV0d2VlbiBtdWx0aXBsZSBU TFMgYW5kIERUTFMgYXNzb2NpYXRpb24gYW5kIGNvcnJlbGF0ZSB0aGVzZSBhc3NvY2lhdGlvbnMg d2l0aCBzcGVjaWZpYyBvZmZlci9hbnN3ZXIgZXhjaGFuZ2VzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX188YnI+ DQpSb21hbiBTaHBvdW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7594FB04B1934943A5C02806D1A2204B4CB5F5F8ESESSMB102erics_-- From nobody Wed Apr 12 03:58:05 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C0B131610; Wed, 12 Apr 2017 03:57:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149199467744.15674.14741768486102085461@ietfa.amsl.com> Date: Wed, 12 Apr 2017 03:57:57 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sdp-bundle-negotiation-38.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 10:57:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Negotiating Media Multiplexing Using the Session Description Protocol (SDP) Authors : Christer Holmberg Harald Tveit Alvestrand Cullen Jennings Filename : draft-ietf-mmusic-sdp-bundle-negotiation-38.txt Pages : 63 Date : 2017-04-12 Abstract: This specification defines a new Session Description Protocol (SDP) Grouping Framework extension, 'BUNDLE'. The extension can be used with the SDP Offer/Answer mechanism to negotiate the usage of a single address:port combination (BUNDLE address) for receiving media, referred to as bundled media, specified by multiple SDP media descriptions ("m=" lines). To assist endpoints in negotiating the use of bundle this specification defines a new SDP attribute, 'bundle-only', which can be used to request that specific media is only used if bundled. The specification also updates RFC 3264, to allow usage of zero port values without meaning that media is rejected. There are multiple ways to correlate the bundled RTP packets with the appropriate media descriptions. This specification defines a new Real-time Transport Protocol (RTP) source description (SDES) item and a new RTP header extension that provides an additional way to do this correlation by using them to carry a value that associates the RTP/ RTCP packets with a specific media description. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-bundle-negotiation/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sdp-bundle-negotiation-38 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sdp-bundle-negotiation-38 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sdp-bundle-negotiation-38 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 Wed Apr 12 04:01:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081AF131605; Wed, 12 Apr 2017 04:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 npEDzlMf_Oh8; Wed, 12 Apr 2017 04:01:02 -0700 (PDT) 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 DFED7131608; Wed, 12 Apr 2017 04:00:52 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-69-58ee08e2235e Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 3A.98.21650.2E80EE85; Wed, 12 Apr 2017 13:00:51 +0200 (CEST) Received: from ESESSMB102.ericsson.se ([169.254.2.218]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0339.000; Wed, 12 Apr 2017 13:00:50 +0200 From: Christer Holmberg To: "mmusic@ietf.org" CC: "mmusic-chairs@ietf.org" Thread-Topic: Draft new version: BUNDLE-38 Thread-Index: AQHSs3wKywzCC5RTV0m91fygDaACsQ== Date: Wed, 12 Apr 2017 11:01:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D513E4881B076christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphkeLIzCtJLcpLzFFi42KZGbFdS/cxx7sIgyu/+CzO71zPZDF1+WMW ByaPJUt+MgUwRnHZpKTmZJalFunbJXBl3Lv7hLlgi1DF4m8n2RoYFwt0MXJySAiYSFydc4YV xBYSWM8o0TfVuYuRC8hewihx4c8hli5GDg42AQuJ7n/aIDUiAuoSX/f2MIPYzAKmEg9frWEE KREWUJVYOFMVokRLYv/8JmYIW09i/4MJYONZgEpWb9jNBmLzClhLnPl4H6yGUUBM4vupNUwQ I8Ulbj2ZzwRxmoDEkj3nmSFsUYmXj/+BzREFmrnv31c2kLUSAkoS07amQbQmSMx88IQRYryg xMmZT1gmMArPQjJ1FpKyWUjKIOIGEu/PzWeGsLUlli18DWXrS2z8cpYRwga6uu0hC7KaBYwc qxhFi1OLi3PTjYz0Uosyk4uL8/P08lJLNjEC4+jglt9WOxgPPnc8xCjAwajEw5vw8E2EEGti WXFl7iFGCQ5mJRFe9ctAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQW wWSZODilGhiz5lcs3b3SP2f3mpicKTVPbPT3bO4MfmCzb4WlQnpd9VPrZcVnBZLbrl//EmHv /2DdvZrPi/lmc+ztDXruxzDx8GM+of8SgUW8giuaW1xSpZiCDmyflefDJSjJq8EqeW76DKlV 4bExB2tObVvaqhiRqyv7JoDTQc3iI4eegO3aWZXnNdq+f1JiKc5INNRiLipOBADx2OaPnwIA AA== Archived-At: Subject: [MMUSIC] Draft new version: BUNDLE-38 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Apr 2017 11:01:05 -0000 --_000_D513E4881B076christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I=92ve submitted a new version (-38) of BUNDLE, based on the discussions in= Chicago. The new version contains the following merged pull request: https://github.com/cdh4u/draft-sdp-bundle/pull/33 ("Text added, describing = the usage of media specific attributes") Regards, Christer --_000_D513E4881B076christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

I=92ve su= bmitted a new version (-38) of BUNDLE, based on the discussions in Chicago.=

The new v= ersion contains the following merged pull request:

https://github.com/c= dh4u/draft-sdp-bundle/pull/33 ("Text added, describing the usage of media specific attributes")

Regards,<= /div>

Christer<= /div> --_000_D513E4881B076christerholmbergericssoncom_-- From nobody Tue Apr 18 03:22:09 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5518C129B48; Tue, 18 Apr 2017 03:22:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149251092729.20337.3783351645495493536@ietfa.amsl.com> Date: Tue, 18 Apr 2017 03:22:07 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-23.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 10:22:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-23.txt Pages : 28 Date : 2017-04-18 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-23 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-23 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 Tue Apr 18 05:09:01 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A099012EB42 for ; Tue, 18 Apr 2017 05:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 L_H6wZIOLpHh for ; Tue, 18 Apr 2017 05:08:57 -0700 (PDT) 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 44F6A12EAAF for ; Tue, 18 Apr 2017 05:08:57 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-59-58f601d75258 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by (Symantec Mail Security) with SMTP id 40.84.21650.7D106F85; Tue, 18 Apr 2017 14:08:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0339.000; Tue, 18 Apr 2017 14:08:54 +0200 From: Christer Holmberg To: "mmusic@ietf.org" Thread-Topic: Draft new version: draft-dtls-sdp-23 Thread-Index: AQHSuDyMB+AQhGikr0efWfxRWcALiw== Date: Tue, 18 Apr 2017 12:08:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_D51BDD8C1B37Achristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM2J7iO51xm8RBvO/K1hMXf6YxYHRY8mS n0wBjFFcNimpOZllqUX6dglcGQ8uaRUs5qq4vugJcwPjB44uRk4OCQETiWPdu1i6GLk4hATW M0pMnr6FGcJZwijR2HmMqYuRg4NNwEKi+582SIOIgLrE1709zCBhYQFdiZtr+UFMEQEjiW8L UiEq9CTmL9/FDGKzCKhKTPs2iR3E5hWwlvi/eR8biM0oICbx/dQaJhCbWUBc4taT+UwQ5whI LNlznhnCFpV4+fgfK4gtCjRz37+vbCCrJASUJKZtTQMxmQUSJGZfE4aYLihxcuYTlgmMQrOQ DJ2FUDULSRVEiY7Egt2f2CBsbYllC18zw9hnDjyGarWW2HG2BlnJAkaOVYyixanFxbnpRkZ6 qUWZycXF+Xl6eaklmxiB0XFwy2+rHYwHnzseYhTgYFTi4U049SVCiDWxrLgy9xCjBAezkgjv rw1AId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwO+y5ECAmkJ5akZqemFqQWwWSZODilGhj9mqWD DXnmTvt8p1D4U+1pMe+JLo1fb57bUyHA3zW75O+23O1JEsf+/54abDi3LLdr/ZWA9rCGo/OW NdpsujPxktFvY7Xu221bQlN8V9oyr2Q3nvqsT4slL2ifZ8/S2wYNH7eYcBYdK/frcF+xUveY 48zpfVWiH+Lqc3YdLo8uLlt1ZtpF65VKLMUZiYZazEXFiQApyBftigIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-dtls-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 12:08:59 -0000 --_000_D51BDD8C1B37Achristerholmbergericssoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A new version (-23) of draft-dtls-sdp has been submitted. The draft now als= o covers TLS connections. In addition, changes done based on the gen-art, ops-dir and sec-dir reviews= have been implemented. Regards, Christer --_000_D51BDD8C1B37Achristerholmbergericssoncom_ Content-Type: text/html; charset="us-ascii" Content-ID: <4A88F224D78CF54786374983189E830E@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

A new version (-23) of draft-dtls-sdp has been submitted. The draft no= w also covers TLS connections.

In addition, changes done based on the gen-art, ops-dir and sec-dir re= views have been implemented.

Regards,

Christer
--_000_D51BDD8C1B37Achristerholmbergericssoncom_-- From nobody Tue Apr 18 12:17:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FE9128CD5 for ; Tue, 18 Apr 2017 12:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 IGwp2CtA-jhQ for ; Tue, 18 Apr 2017 12:17:55 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 BD4A81270AC for ; Tue, 18 Apr 2017 12:17:55 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id 194so1041889pfv.3 for ; Tue, 18 Apr 2017 12:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=bIsk51PiYOFMWOcMY48c0OP7c4wLynvTbf7evcGkFz4=; b=NMKssFqhd3TvXyTr5O7i9VHq4OXTwKZ2FsBhhWfKok58wlueO1N84fmBgAj+/u0xQW Z3cOUIRzaw7uO+0FzIjbZhqjIGkRWxPpxjEbP7Ztzbphb1HQZ5jm5imI5t8dHs2tfxsq cI5hr67s7to3bC5cxV2GfD5GmUGeAHdWQW+lWhcMMI8GpuCo2GrvAvo5P/RBssRtEI4s eGbBP/qYmyxCVZHQBtOfjiF2DRJO/moYWZHNxVqrFDJNEnLLs77VgxktZpBhQoQinRDk 35cB5mi2GbjwSkEntvX6E68s/xn9BJW0VpAyu7lv4jl49UmseaZlYNiNSq9bq6Rp7rGW vw1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=bIsk51PiYOFMWOcMY48c0OP7c4wLynvTbf7evcGkFz4=; b=m3C/ASuBmLG52f12zxODI6+wePSbcfAV7JR0ApXkLnD6UF043y7wL/VPbW8FDcDdbA xO324kXsGAvTGV0jcVJ83AQHrEyaZDcc0EyrQlAc4mJ26bv+DeDB9VVzBRn3DNp33qaW eReaERETIZeJGAYY60kHMYtU/fdhRgvEWKRNsXkZxdh5YP6Y/vyFBAP71YjEAnalZM+F UdqyZ/rrOo/P6Zkcf8jRcK7uN16H2O1Vzel9AHh3gvmkNRb1m9kCn90NW/Y9Fy2AOOSu 94UPnxhW1EGCI23pqujwSFM2c2X3CtxD9QXARGn7i54QWScUhBzG6ylY4y1xaK3HGFsE y69A== X-Gm-Message-State: AN3rC/4nmmhj84fmOf9MbijrNnL5XYl7qrPS7y0/MKXikDa/xwHtAOWj 6drEZP5NKkJuXdn9 X-Received: by 10.99.185.1 with SMTP id z1mr19829749pge.165.1492543075067; Tue, 18 Apr 2017 12:17:55 -0700 (PDT) Received: from mail-pg0-f41.google.com (mail-pg0-f41.google.com. [74.125.83.41]) by smtp.gmail.com with ESMTPSA id o124sm54558pfb.92.2017.04.18.12.17.54 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 18 Apr 2017 12:17:54 -0700 (PDT) Received: by mail-pg0-f41.google.com with SMTP id 72so1132884pge.2 for ; Tue, 18 Apr 2017 12:17:54 -0700 (PDT) X-Received: by 10.99.140.67 with SMTP id q3mr20378633pgn.210.1492543073900; Tue, 18 Apr 2017 12:17:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Tue, 18 Apr 2017 12:17:53 -0700 (PDT) From: Roman Shpount Date: Tue, 18 Apr 2017 15:17:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg , Ben Campbell Content-Type: multipart/alternative; boundary=f403045e2196bb656d054d75c3f7 Archived-At: Subject: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 19:17:57 -0000 --f403045e2196bb656d054d75c3f7 Content-Type: text/plain; charset=UTF-8 Re-sending to mmusic list and changing the title: On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat wrote: > Section 8 has a number of normative requirements around the use of > 'tls-id'. This seems to break interoperability with existing > implementations that follow RFC4572. > > What is the intent here regarding interoperability with RFC4572? > Perhaps this doc should now also be a formal update to that. > Should we reword those requirements that they only apply when tls-id is used? So instead of If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' value in the offer/answer, the offerer/answerer MUST also insert an SDP 'tls-id' attribute with a new unique value. We would say: If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' value in the offer/answer and also provides SDP 'tls-id' attribute, the value of tls-id' attribute MUST be new and unique. And instead of If an offerer or answerer inserts an SDP 'connection' attribute with a 'existing' value in the offer/answer, and if a previously established TLS connection exists, the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the previously assigned value in the offer/answer. We would say If an offerer or answerer inserts an SDP 'connection' attribute with a 'existing' value in the offer/answer, if a previously established TLS connection exists, and if the offerer/answerer provided 'tls-id' value in the previous offer/answer which established this TLS connection, the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the previously assigned value in the offer/answer. If we reword these statements like this, do we still need to specify that this document updates RFC4572? Regards, _____________ Roman Shpount --f403045e2196bb656d054d75c3f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Re-sending to mmusic list and changing the title:
On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat <pkyzivat@alum.mit.ed= u> wrote:
Section 8 = has a number of normative requirements around the use of 'tls-id'. = This seems to break interoperability with existing implementations that fol= low RFC4572.

What is the intent here regarding interoperability with RFC4572?
Perhaps this doc should now also be a formal update to that.

Should we reword those requirements that they = only apply when tls-id is used?

So instead of

If an offerer or answerer inserts an SDP = 9;connection' attribute with=C2=A0a 'new' value in the offer/an= swer, the offerer/answerer MUST also=C2=A0insert an SDP 'tls-id' at= tribute with a new unique value.

=
We would say:
If an offerer= or answerer inserts an SDP 'connection' attribute with=C2=A0a '= ;new' value in the offer/answer and also provides SDP 'tls-id' = attribute, the value of tls-id' attribute MUST be new and unique.
=

And instead of

If an offerer or answerer inserts= an SDP 'connection' attribute with a 'existing' value in t= he offer/answer, and if a previously established TLS connection exists, the= =C2=A0offerer/answerer MUST also insert an SDP 'tls-id' attribute w= ith the previously assigned value in the offer/answer.

We would say

If an offerer or an= swerer inserts an SDP 'connection' attribute with a 'existing&#= 39; value in the offer/answer, if a previously established TLS connection e= xists, and if the=C2=A0offerer/answerer provided 'tls-id' value in = the previous offer/answer which established this TLS connection, the=C2=A0o= fferer/answerer=C2=A0MUST also insert an SDP 'tls-id' attribute wit= h the previously assigned value in the offer/answer.

If we reword these statements like this, do we still need to specify tha= t this document updates RFC4572?

Regards,
_____________
Ro= man Shpount
=C2=A0

--f403045e2196bb656d054d75c3f7-- From nobody Tue Apr 18 13:13:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41058127876 for ; Tue, 18 Apr 2017 13:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 ciynFPrw306J for ; Tue, 18 Apr 2017 13:13:12 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 60907129442 for ; Tue, 18 Apr 2017 13:13:12 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-03v.sys.comcast.net with SMTP id 0ZUndrWs5fuM30ZUtd1IHr; Tue, 18 Apr 2017 20:13:11 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with SMTP id 0ZUsdsdR8qoNE0ZUtdMeJw; Tue, 18 Apr 2017 20:13:11 +0000 From: Paul Kyzivat To: IETF MMUSIC WG References: Message-ID: Date: Tue, 18 Apr 2017 16:13:10 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfPR/WOn6bakJsfBibBhP61oiHMjWU5bRLb9GdJelGadEGnRiJ7Okhlh3ESpAdZXgkLtUZxX5B9s2poklk2kWureRm0OYM5fddTHv5Qr9gEuJ5xfUSOEV BACOY3Vfg4IlpdhrPLaOEDUM693PMS/8wxYOwgBqINcLVR6fG/jJ7Iv/ Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-dtls-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:13:13 -0000 On 4/18/17 6:24 AM, Christer Holmberg wrote: > Hi, > > A new version (-23) of draft-dtls-sdp has been submitted. The draft now > also covers TLS connections. Section 8 has a number of normative requirements around the use of 'tls-id'. This seems to break interoperability with existing implementations that follow RFC4572. What is the intent here regarding interoperability with RFC4572? Perhaps this doc should now also be a formal update to that. Thanks, Paul From nobody Tue Apr 18 13:15:27 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79690127876 for ; Tue, 18 Apr 2017 13:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no 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 2xeiw709AzKR for ; Tue, 18 Apr 2017 13:15:23 -0700 (PDT) Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (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 14E60131475 for ; Tue, 18 Apr 2017 13:15:21 -0700 (PDT) Received: from resomta-ch2-13v.sys.comcast.net ([69.252.207.109]) by resqmta-ch2-12v.sys.comcast.net with SMTP id 0ZWndze78dlFQ0ZWydaLvi; Tue, 18 Apr 2017 20:15:20 +0000 Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-13v.sys.comcast.net with SMTP id 0ZWxd6zZJAtR20ZWyd8x3u; Tue, 18 Apr 2017 20:15:20 +0000 References: <08acc295-e7bd-09f6-f957-7f88c5241593@alum.mit.edu> To: Roman Shpount Cc: IETF MMUSIC WG From: Paul Kyzivat Message-ID: Date: Tue, 18 Apr 2017 16:15:19 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAV86x7ScpAnk4ttEbKvFlhqsxTUSvLrXBUn3TTXknpgELeEPHBA11HK5mFknZ+zPXcHizMr4cbEM40hRVaQK5FgY4sSd0o+mNDniZgSlhHSChFXbC/J PpiIc5nAbwATXIFbxSfFBA3Un5XUjPdDzv8hnL2xIzFdvk/IVKqhKUz+RqLsATBCCAFsFSmTuGioWmecmmxi4FpzVk9gQceV6UA= Archived-At: Subject: Re: [MMUSIC] Draft new version: draft-dtls-sdp-23 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 20:15:24 -0000 (retargeting to mmusic) On 4/18/17 3:08 PM, Roman Shpount wrote: > On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat > wrote: > > Section 8 has a number of normative requirements around the use of > 'tls-id'. This seems to break interoperability with existing > implementations that follow RFC4572. > > What is the intent here regarding interoperability with RFC4572? > Perhaps this doc should now also be a formal update to that. > > > Should we reword those requirements that they only apply when tls-id is > used? > > So instead of > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'new' value in the offer/answer, the offerer/answerer MUST also insert > an SDP 'tls-id' attribute with a new unique value. > > We would say: > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'new' value in the offer/answer and also provides SDP 'tls-id' > attribute, the value of tls-id' attribute MUST be new and unique. > > And instead of > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'existing' value in the offer/answer, and if a previously established > TLS connection exists, the offerer/answerer MUST also insert an SDP > 'tls-id' attribute with the previously assigned value in the offer/answer. > > We would say > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'existing' value in the offer/answer, if a previously established TLS > connection exists, and if the offerer/answerer provided 'tls-id' value > in the previous offer/answer which established this TLS connection, > the offerer/answerer MUST also insert an SDP 'tls-id' attribute with the > previously assigned value in the offer/answer. I think that would do the trick. > If we reword these statements like this, do we still need to specify > that this document updates RFC4572? In that case I think not. Thanks, Paul From nobody Tue Apr 18 16:39:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94341314FF for ; Tue, 18 Apr 2017 16:39:55 -0700 (PDT) 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 TdAnDBbYAl8o for ; Tue, 18 Apr 2017 16:39:54 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 097831314F7 for ; Tue, 18 Apr 2017 16:39:54 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id c80so3931202lfh.3 for ; Tue, 18 Apr 2017 16:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LpazS/yqhLOHs1F42Y9KXZgqfSFOGBZy9IdtxtKZX/M=; b=r4ikKQ5HCuJgkZhGdbCiiqajq9f6i3AWEaB08SmwuiWg9cVUzsZyr6xfTADYjH2V8n bYuv6TpPDyzCmzayJgAK4KbqWBILk4Wl40exhuRcbOvXlGxcPnPnGD46j8XkgQlms36w ESb29edbnSoOEC05jjxfz0pkiFa134jVwj93HSJag7uR2f+hau3398e+pUhQoZguSr3D ZugwLcs41g/21fcZJUxHZwvgAofuiVlX7kERavLslrHKjWN0ssg5Awwe6EQfbd0ZXnYU VRca0LcFOTejm5b60x24qvMJ97rwlk4HJMGx5wif2NqYpqORkLQ6DTD+G9TXQCGZVe7b fV/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LpazS/yqhLOHs1F42Y9KXZgqfSFOGBZy9IdtxtKZX/M=; b=CXf7CTVWSSXAIQInNsTgRQFwAAJy2Q94yu98+63hC6E6VKjiseoYjPWaWAaryHMiOS NcSgMPc5oMea4VJWaY1kOpD1iYQFcWlf1mD8dCcRbURCIJOQRwkATz+f168kZk1jEiqA zWDvjzX6qMmBZT/1PEMjbWBsQY7N1Y6Le1O7utDaU4HnWX0qIZmW5IAubfHVCbqXCxM3 kMTIOvjRzgRS1yD7Y+neXlzKoyxrguzyUV26tFlXG9yVStU/wzEZIYZAr0oisMfmdZqv zt5+YxwwrK/Ff8/pRU8znAsqqj2A2iheaNHfDmA9s7ko5eg55Tk+iUxIiGj3lRMhXub4 Ibkg== X-Gm-Message-State: AN3rC/5lE9lQqJykNQ+venI1QD2+nVZIUjIfuWT5/zuGYz3EvUlEZ0je 8hxcwKtS1rFZpfvaBdLIAYxUjo/g/g== X-Received: by 10.46.69.133 with SMTP id s127mr2769lja.44.1492558792357; Tue, 18 Apr 2017 16:39:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.5 with HTTP; Tue, 18 Apr 2017 16:39:51 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 19 Apr 2017 09:39:51 +1000 Message-ID: To: Roman Shpount Cc: "mmusic@ietf.org" , Paul Kyzivat , Christer Holmberg , Ben Campbell Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Apr 2017 23:39:56 -0000 I agree with Roman, we can and should just ensure that this is a new feature, not a rewrite. I don't think that we need to invalidate RFC 4572 implementations. This is an enhancement (a very useful one, but an enhancement only). p.s., Any updating should be done to RFC 8122 now, if at all. That probably removes any heat from the discussion as pertains to updating of old specs. On 19 April 2017 at 05:17, Roman Shpount wrote: > Re-sending to mmusic list and changing the title: > > On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat > wrote: >> >> Section 8 has a number of normative requirements around the use of >> 'tls-id'. This seems to break interoperability with existing implementations >> that follow RFC4572. >> >> What is the intent here regarding interoperability with RFC4572? >> Perhaps this doc should now also be a formal update to that. > > > Should we reword those requirements that they only apply when tls-id is > used? > > So instead of > > If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' > value in the offer/answer, the offerer/answerer MUST also insert an SDP > 'tls-id' attribute with a new unique value. > > We would say: > > If an offerer or answerer inserts an SDP 'connection' attribute with a 'new' > value in the offer/answer and also provides SDP 'tls-id' attribute, the > value of tls-id' attribute MUST be new and unique. > > And instead of > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'existing' value in the offer/answer, and if a previously established TLS > connection exists, the offerer/answerer MUST also insert an SDP 'tls-id' > attribute with the previously assigned value in the offer/answer. > > We would say > > If an offerer or answerer inserts an SDP 'connection' attribute with a > 'existing' value in the offer/answer, if a previously established TLS > connection exists, and if the offerer/answerer provided 'tls-id' value in > the previous offer/answer which established this TLS connection, the > offerer/answerer MUST also insert an SDP 'tls-id' attribute with the > previously assigned value in the offer/answer. > > If we reword these statements like this, do we still need to specify that > this document updates RFC4572? > > Regards, > _____________ > Roman Shpount > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Wed Apr 19 00:45:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEA66131545 for ; Wed, 19 Apr 2017 00:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq9hobWrQqCf for ; Wed, 19 Apr 2017 00:45:12 -0700 (PDT) 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 7C154131537 for ; Wed, 19 Apr 2017 00:45:12 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-1e-58f71585b398 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id A1.8B.27378.58517F85; Wed, 19 Apr 2017 09:45:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Wed, 19 Apr 2017 09:45:09 +0200 From: Christer Holmberg To: Martin Thomson , Roman Shpount CC: "mmusic@ietf.org" , Paul Kyzivat , Ben Campbell Thread-Topic: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 Thread-Index: AQHSuHh8UB3Rm+4deESPQDlsxlQ7eaHLp62AgAC7HgA= Date: Wed, 19 Apr 2017 07:45:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLIsWRmVeSWpSXmKPExsUyM2K7hG6b6PcIg453lhbzO0+zW1w784/R YuryxywWKzYcYLWYcWEqswOrx9/3H5g8ds66y+6xZMlPJo9ZO5+weNyaUhDAGsVlk5Kak1mW WqRvl8CV8fvrHqaCO2IVS3a0sjYwrhTqYuTkkBAwkTh6cz9zFyMXh5DAekaJL9vnsEM4Sxgl Zuw/z9rFyMHBJmAh0f1PG6RBRCBI4uHDxywgNrNAvsSSqbtYQWxhgUCJOe+vsMHUtJ87wA5h W0k8/fKFDWQMi4CqxNk1NiBhXgFriYkH7zBCrJrOKHGu4S8jSIITaM7UXY1g8xkFxCS+n1rD BLFLXOLWk/lMEEcLSCzZc54ZwhaVePn4H9gNogJ6Evv+fWWDiCtK7DzbzgzRqyOxYPcnNgjb WuLOngeMELa2xLKFr5khDhKUODnzCcsERvFZSNbNQtI+C0n7LCTts5C0L2BkXcUoWpxanJSb bmSsl1qUmVxcnJ+nl5dasokRGKkHt/xW3cF4+Y3jIUYBDkYlHt4H0t8ihFgTy4orcw8xSnAw K4nwrvvwNUKINyWxsiq1KD++qDQntfgQozQHi5I4r+O+CxFCAumJJanZqakFqUUwWSYOTqkG Rt/ka/s36bRO/S4s/GPSjWfeG3OlNxefFrWesvnSrv8m5/UfupWuvLryd9dWOYO3X0Kavzol Tdd4u1ytdo7apVVpNQ/TvvMY7Vs6Z4pMUL3izbr4VTlPFh8oejZ9ms2Uy+ULw/KOlLrnSJ9Z yuds0/um4/ePwDf7rvq8Z1v289H3pOm+V5e15/MosRRnJBpqMRcVJwIAz/nBAtACAAA= Archived-At: Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:45:14 -0000 Hi, I agree that the draft should be an update to 8122 (not 4572). That was actually my intention, but I forgot about it. The changes suggested by Paul look good. Regards, Christer On 19/04/17 02:39, "Martin Thomson" wrote: >I agree with Roman, we can and should just ensure that this is a new >feature, not a rewrite. I don't think that we need to invalidate RFC >4572 implementations. This is an enhancement (a very useful one, but >an enhancement only). > >p.s., Any updating should be done to RFC 8122 now, if at all. That >probably removes any heat from the discussion as pertains to updating >of old specs. > >On 19 April 2017 at 05:17, Roman Shpount wrote: >> Re-sending to mmusic list and changing the title: >> >> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat >> wrote: >>> >>> Section 8 has a number of normative requirements around the use of >>> 'tls-id'. This seems to break interoperability with existing >>>implementations >>> that follow RFC4572. >>> >>> What is the intent here regarding interoperability with RFC4572? >>> Perhaps this doc should now also be a formal update to that. >> >> >> Should we reword those requirements that they only apply when tls-id is >> used? >> >> So instead of >> >> If an offerer or answerer inserts an SDP 'connection' attribute with a >>'new' >> value in the offer/answer, the offerer/answerer MUST also insert an SDP >> 'tls-id' attribute with a new unique value. >> >> We would say: >> >> If an offerer or answerer inserts an SDP 'connection' attribute with a >>'new' >> value in the offer/answer and also provides SDP 'tls-id' attribute, the >> value of tls-id' attribute MUST be new and unique. >> >> And instead of >> >> If an offerer or answerer inserts an SDP 'connection' attribute with a >> 'existing' value in the offer/answer, and if a previously established >>TLS >> connection exists, the offerer/answerer MUST also insert an SDP 'tls-id' >> attribute with the previously assigned value in the offer/answer. >> >> We would say >> >> If an offerer or answerer inserts an SDP 'connection' attribute with a >> 'existing' value in the offer/answer, if a previously established TLS >> connection exists, and if the offerer/answerer provided 'tls-id' value >>in >> the previous offer/answer which established this TLS connection, the >> offerer/answerer MUST also insert an SDP 'tls-id' attribute with the >> previously assigned value in the offer/answer. >> >> If we reword these statements like this, do we still need to specify >>that >> this document updates RFC4572? >> >> Regards, >> _____________ >> Roman Shpount >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> From nobody Wed Apr 19 00:52:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8E613149B for ; Wed, 19 Apr 2017 00:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCYjq-lrub9Q for ; Wed, 19 Apr 2017 00:52:12 -0700 (PDT) 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 18D7D131549 for ; Wed, 19 Apr 2017 00:52:11 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-e3-58f7172ad97a Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by (Symantec Mail Security) with SMTP id 76.2A.21650.A2717F85; Wed, 19 Apr 2017 09:52:10 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.03.0339.000; Wed, 19 Apr 2017 09:51:46 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson , Roman Shpount CC: Ben Campbell , "mmusic@ietf.org" , "Paul Kyzivat" Thread-Topic: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 Thread-Index: AQHSuHh8UB3Rm+4deESPQDlsxlQ7eaHLp62AgAC7HgCAAAHYAA== Date: Wed, 19 Apr 2017 07:51:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDIsWRmVeSWpSXmKPExsUyM2K7t66W+PcIg6mrJS3md55mt7h25h+j xdTlj1ksVmw4wGox48JUZgdWj7/vPzB57Jx1l91jyZKfTB6zdj5h8bg1pSCANYrLJiU1J7Ms tUjfLoEr4+yuy+wFZ6QrJjfwNTDuFuti5OSQEDCR6Hy+j6WLkYtDSGA9o8T7n+2MEM4SRonX h/cydzFycLAJWEh0/9MGiYsItDFKfOpvZwfpZhYolJh68ysbiC0sECgx5/0VMFtEIEii/dwB dgjbSWL6pN9gc1gEVCV+b0oFCfMKWEtcuLKXBcQWEjjJKDHhdzaIzSlgI3H50UUmEJtRQEzi +6k1TBCrxCVuPZnPBHG0gMSSPeeZIWxRiZeP/7GC2KICehL7/kGcIyGgKPHx1T5GiF49iRtT p7BB2NYSqxZtg4prSyxb+JoZ4h5BiZMzn7BMYBSfhWTdLCTts5C0z0LSPgtJ+wJG1lWMosWp xcW56UZGeqlFmcnFxfl5enmpJZsYgXF6cMtvqx2MB587HmIU4GBU4uF9IP0tQog1say4MvcQ owQHs5II77oPXyOEeFMSK6tSi/Lji0pzUosPMUpzsCiJ8zrsuxAhJJCeWJKanZpakFoEk2Xi 4JRqYEw+zM7upqNtbaOaslyeV7jm7uuK6V8nzt2bcuL73venLmWua0/aox9rrPygrXZtgfSa 2XFbDBw6J7bd28+U/nRrW96T/KPmDmdvH3n27cu+ZbKrzjPw3L7K1OB49damNE6ZuzvylFKM 5nAc3KdoeK6Fob7myKEjOyP+rlrlt/jKoi9/a9b+zPBXYinOSDTUYi4qTgQAkc6nec8CAAA= Archived-At: Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:52:15 -0000 Hi, Sorry, I messed up the RFCs. I do NOT think we need to update 8122. The text says that the new procedures are used =B3in conjunction=B2 with the 8122 procedures, and the text suggested by Paul fits into that. Regards, Christer On 19/04/17 10:45, "mmusic on behalf of Christer Holmberg" wrote: >Hi, > >I agree that the draft should be an update to 8122 (not 4572). That was >actually my intention, but I forgot about it. > >The changes suggested by Paul look good. > >Regards, > >Christer > > > >On 19/04/17 02:39, "Martin Thomson" wrote: > >>I agree with Roman, we can and should just ensure that this is a new >>feature, not a rewrite. I don't think that we need to invalidate RFC >>4572 implementations. This is an enhancement (a very useful one, but >>an enhancement only). >> >>p.s., Any updating should be done to RFC 8122 now, if at all. That >>probably removes any heat from the discussion as pertains to updating >>of old specs. >> >>On 19 April 2017 at 05:17, Roman Shpount wrote: >>> Re-sending to mmusic list and changing the title: >>> >>> On Tue, Apr 18, 2017 at 10:51 AM, Paul Kyzivat >>> wrote: >>>> >>>> Section 8 has a number of normative requirements around the use of >>>> 'tls-id'. This seems to break interoperability with existing >>>>implementations >>>> that follow RFC4572. >>>> >>>> What is the intent here regarding interoperability with RFC4572? >>>> Perhaps this doc should now also be a formal update to that. >>> >>> >>> Should we reword those requirements that they only apply when tls-id is >>> used? >>> >>> So instead of >>> >>> If an offerer or answerer inserts an SDP 'connection' attribute with a >>>'new' >>> value in the offer/answer, the offerer/answerer MUST also insert an SDP >>> 'tls-id' attribute with a new unique value. >>> >>> We would say: >>> >>> If an offerer or answerer inserts an SDP 'connection' attribute with a >>>'new' >>> value in the offer/answer and also provides SDP 'tls-id' attribute, the >>> value of tls-id' attribute MUST be new and unique. >>> >>> And instead of >>> >>> If an offerer or answerer inserts an SDP 'connection' attribute with a >>> 'existing' value in the offer/answer, and if a previously established >>>TLS >>> connection exists, the offerer/answerer MUST also insert an SDP >>>'tls-id' >>> attribute with the previously assigned value in the offer/answer. >>> >>> We would say >>> >>> If an offerer or answerer inserts an SDP 'connection' attribute with a >>> 'existing' value in the offer/answer, if a previously established TLS >>> connection exists, and if the offerer/answerer provided 'tls-id' value >>>in >>> the previous offer/answer which established this TLS connection, the >>> offerer/answerer MUST also insert an SDP 'tls-id' attribute with the >>> previously assigned value in the offer/answer. >>> >>> If we reword these statements like this, do we still need to specify >>>that >>> this document updates RFC4572? >>> >>> Regards, >>> _____________ >>> Roman Shpount >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Wed Apr 19 00:54:19 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3056B131548 for ; Wed, 19 Apr 2017 00:54:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKSQEq928Ppd for ; Wed, 19 Apr 2017 00:54:16 -0700 (PDT) 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 4E9D813149B for ; Wed, 19 Apr 2017 00:54:16 -0700 (PDT) X-AuditID: c1b4fb2d-89fff70000004c5d-ed-58f717a42fd7 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 0C.0C.19549.4A717F85; Wed, 19 Apr 2017 09:54:14 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Wed, 19 Apr 2017 09:54:11 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson , Roman Shpount CC: Ben Campbell , "mmusic@ietf.org" , "Paul Kyzivat" Thread-Topic: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 Thread-Index: AQHSuHh8UB3Rm+4deESPQDlsxlQ7eaHLp62AgAC7HgCAAAHYAIAAAK4A Date: Wed, 19 Apr 2017 07:54:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="euc-kr" Content-ID: <2BA79E7F9362DF489BAEC18D7F5DD32D@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHIsWRmVeSWpSXmKPExsUyM2K7me4y8e8RBqdatC3md55mt7h25h+j xdTlj1ksVmw4wGox48JUZgdWj7/vPzB57Jx1l91jyZKfTB6zdj5h8bg1pSCANYrLJiU1J7Ms tUjfLoEr48rtzWwFzzQqOk41MzcwPlDvYuTgkBAwkdjUZtfFyMUhJLCeUWLyyYtsEM4SRokp k74zgxSxCVhIdP/TBomLCLQxSnzqb2fvYuTkYBYolJh68ysbiC0sECgx5/0VMFtEIEii/dwB dgjbTeL05TWMIDaLgKrE9h23wWxeAWuJrlMLGSGW/WaU+L1zMitIglPARuLSq6VggxgFxCS+ n1rDBLFMXOLWk/lgtoSAgMSSPeeZIWxRiZeP/4H1igroSez7B3GQhICixM6z7cwQvVoSX37s Y4OwrSUa76xihLAVJaZ0P2SHOEhQ4uTMJywTGMVnIVk3C0n7LCTts5C0z0LSvoCRdRWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYKwe3PJbdwfj6teOhxgFOBiVeHgfSH+LEGJNLCuuzD3E KMHBrCTCu+7D1wgh3pTEyqrUovz4otKc1OJDjNIcLErivA77LkQICaQnlqRmp6YWpBbBZJk4 OKUaGA0/aqdqsp97qHzxsmy6dWqtIIPlwpUR2zYKF59PEro/7cN31bUhqy/9Zs5bd8TIXVNw 2apg7YB75Xf+zNERmHxFSjaRpVF5jv+RupczxE+7bPMK9Prt6mLz6sgKJ4G2cF4ru7/HTWqZ v9yN7dIJWa21bx+Pn4CZynvbZz3yO4/NPv7hz2nLf0osxRmJhlrMRcWJAAt4DcrRAgAA Archived-At: Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 07:54:18 -0000 VGV4dCBzdWdnZXN0ZWQgYnkgUm9tYW4sIHRoYXQgaXOhpiBJIHJlYWxseSBuZWVkIGEgY3VwIG9m IGNvZmZlZSA6KQ0KDQpPbiAxOS8wNC8xNyAxMDo1MSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8Y2hy aXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0Kd3JvdGU6DQoNCj5IaSwNCj4NCj5Tb3JyeSwg SSBtZXNzZWQgdXAgdGhlIFJGQ3MuDQo+DQo+SSBkbyBOT1QgdGhpbmsgd2UgbmVlZCB0byB1cGRh dGUgODEyMi4gVGhlIHRleHQgc2F5cyB0aGF0IHRoZSBuZXcNCj5wcm9jZWR1cmVzIGFyZSB1c2Vk IKn4aW4gY29uanVuY3Rpb26p9yB3aXRoIHRoZSA4MTIyIHByb2NlZHVyZXMsIGFuZCB0aGUNCj50 ZXh0IHN1Z2dlc3RlZCBieSBQYXVsIGZpdHMgaW50byB0aGF0Lg0KPg0KPlJlZ2FyZHMsDQo+DQo+ Q2hyaXN0ZXINCj4NCj4NCj5PbiAxOS8wNC8xNyAxMDo0NSwgIm1tdXNpYyBvbiBiZWhhbGYgb2Yg Q2hyaXN0ZXIgSG9sbWJlcmciDQo+PG1tdXNpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQo+d3JvdGU6DQo+DQo+PkhpLA0KPj4N Cj4+SSBhZ3JlZSB0aGF0IHRoZSBkcmFmdCBzaG91bGQgYmUgYW4gdXBkYXRlIHRvIDgxMjIgKG5v dCA0NTcyKS4gVGhhdCB3YXMNCj4+YWN0dWFsbHkgbXkgaW50ZW50aW9uLCBidXQgSSBmb3Jnb3Qg YWJvdXQgaXQuDQo+Pg0KPj5UaGUgY2hhbmdlcyBzdWdnZXN0ZWQgYnkgUGF1bCBsb29rIGdvb2Qu DQo+Pg0KPj5SZWdhcmRzLA0KPj4NCj4+Q2hyaXN0ZXINCj4+DQo+Pg0KPj4NCj4+T24gMTkvMDQv MTcgMDI6MzksICJNYXJ0aW4gVGhvbXNvbiIgPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gd3Jv dGU6DQo+Pg0KPj4+SSBhZ3JlZSB3aXRoIFJvbWFuLCB3ZSBjYW4gYW5kIHNob3VsZCBqdXN0IGVu c3VyZSB0aGF0IHRoaXMgaXMgYSBuZXcNCj4+PmZlYXR1cmUsIG5vdCBhIHJld3JpdGUuICBJIGRv bid0IHRoaW5rIHRoYXQgd2UgbmVlZCB0byBpbnZhbGlkYXRlIFJGQw0KPj4+NDU3MiBpbXBsZW1l bnRhdGlvbnMuICBUaGlzIGlzIGFuIGVuaGFuY2VtZW50IChhIHZlcnkgdXNlZnVsIG9uZSwgYnV0 DQo+Pj5hbiBlbmhhbmNlbWVudCBvbmx5KS4NCj4+Pg0KPj4+cC5zLiwgQW55IHVwZGF0aW5nIHNo b3VsZCBiZSBkb25lIHRvIFJGQyA4MTIyIG5vdywgaWYgYXQgYWxsLiAgVGhhdA0KPj4+cHJvYmFi bHkgcmVtb3ZlcyBhbnkgaGVhdCBmcm9tIHRoZSBkaXNjdXNzaW9uIGFzIHBlcnRhaW5zIHRvIHVw ZGF0aW5nDQo+Pj5vZiBvbGQgc3BlY3MuDQo+Pj4NCj4+Pk9uIDE5IEFwcmlsIDIwMTcgYXQgMDU6 MTcsIFJvbWFuIFNocG91bnQgPHJvbWFuQHRlbHVyaXguY29tPiB3cm90ZToNCj4+Pj4gUmUtc2Vu ZGluZyB0byBtbXVzaWMgbGlzdCBhbmQgY2hhbmdpbmcgdGhlIHRpdGxlOg0KPj4+Pg0KPj4+PiBP biBUdWUsIEFwciAxOCwgMjAxNyBhdCAxMDo1MSBBTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBh bHVtLm1pdC5lZHU+DQo+Pj4+IHdyb3RlOg0KPj4+Pj4NCj4+Pj4+IFNlY3Rpb24gOCBoYXMgYSBu dW1iZXIgb2Ygbm9ybWF0aXZlIHJlcXVpcmVtZW50cyBhcm91bmQgdGhlIHVzZSBvZg0KPj4+Pj4g J3Rscy1pZCcuIFRoaXMgc2VlbXMgdG8gYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIGV4aXN0 aW5nDQo+Pj4+PmltcGxlbWVudGF0aW9ucw0KPj4+Pj4gdGhhdCBmb2xsb3cgUkZDNDU3Mi4NCj4+ Pj4+DQo+Pj4+PiBXaGF0IGlzIHRoZSBpbnRlbnQgaGVyZSByZWdhcmRpbmcgaW50ZXJvcGVyYWJp bGl0eSB3aXRoIFJGQzQ1NzI/DQo+Pj4+PiBQZXJoYXBzIHRoaXMgZG9jIHNob3VsZCBub3cgYWxz byBiZSBhIGZvcm1hbCB1cGRhdGUgdG8gdGhhdC4NCj4+Pj4NCj4+Pj4NCj4+Pj4gU2hvdWxkIHdl IHJld29yZCB0aG9zZSByZXF1aXJlbWVudHMgdGhhdCB0aGV5IG9ubHkgYXBwbHkgd2hlbiB0bHMt aWQNCj4+Pj5pcw0KPj4+PiB1c2VkPw0KPj4+Pg0KPj4+PiBTbyBpbnN0ZWFkIG9mDQo+Pj4+DQo+ Pj4+IElmIGFuIG9mZmVyZXIgb3IgYW5zd2VyZXIgaW5zZXJ0cyBhbiBTRFAgJ2Nvbm5lY3Rpb24n IGF0dHJpYnV0ZSB3aXRoIGENCj4+Pj4nbmV3Jw0KPj4+PiB2YWx1ZSBpbiB0aGUgb2ZmZXIvYW5z d2VyLCB0aGUgb2ZmZXJlci9hbnN3ZXJlciBNVVNUIGFsc28gaW5zZXJ0IGFuDQo+Pj4+U0RQDQo+ Pj4+ICd0bHMtaWQnIGF0dHJpYnV0ZSB3aXRoIGEgbmV3IHVuaXF1ZSB2YWx1ZS4NCj4+Pj4NCj4+ Pj4gV2Ugd291bGQgc2F5Og0KPj4+Pg0KPj4+PiBJZiBhbiBvZmZlcmVyIG9yIGFuc3dlcmVyIGlu c2VydHMgYW4gU0RQICdjb25uZWN0aW9uJyBhdHRyaWJ1dGUgd2l0aCBhDQo+Pj4+J25ldycNCj4+ Pj4gdmFsdWUgaW4gdGhlIG9mZmVyL2Fuc3dlciBhbmQgYWxzbyBwcm92aWRlcyBTRFAgJ3Rscy1p ZCcgYXR0cmlidXRlLA0KPj4+PnRoZQ0KPj4+PiB2YWx1ZSBvZiB0bHMtaWQnIGF0dHJpYnV0ZSBN VVNUIGJlIG5ldyBhbmQgdW5pcXVlLg0KPj4+Pg0KPj4+PiBBbmQgaW5zdGVhZCBvZg0KPj4+Pg0K Pj4+PiBJZiBhbiBvZmZlcmVyIG9yIGFuc3dlcmVyIGluc2VydHMgYW4gU0RQICdjb25uZWN0aW9u JyBhdHRyaWJ1dGUgd2l0aCBhDQo+Pj4+ICdleGlzdGluZycgdmFsdWUgaW4gdGhlIG9mZmVyL2Fu c3dlciwgYW5kIGlmIGEgcHJldmlvdXNseSBlc3RhYmxpc2hlZA0KPj4+PlRMUw0KPj4+PiBjb25u ZWN0aW9uIGV4aXN0cywgdGhlIG9mZmVyZXIvYW5zd2VyZXIgTVVTVCBhbHNvIGluc2VydCBhbiBT RFANCj4+Pj4ndGxzLWlkJw0KPj4+PiBhdHRyaWJ1dGUgd2l0aCB0aGUgcHJldmlvdXNseSBhc3Np Z25lZCB2YWx1ZSBpbiB0aGUgb2ZmZXIvYW5zd2VyLg0KPj4+Pg0KPj4+PiBXZSB3b3VsZCBzYXkN Cj4+Pj4NCj4+Pj4gSWYgYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBpbnNlcnRzIGFuIFNEUCAnY29u bmVjdGlvbicgYXR0cmlidXRlIHdpdGggYQ0KPj4+PiAnZXhpc3RpbmcnIHZhbHVlIGluIHRoZSBv ZmZlci9hbnN3ZXIsIGlmIGEgcHJldmlvdXNseSBlc3RhYmxpc2hlZCBUTFMNCj4+Pj4gY29ubmVj dGlvbiBleGlzdHMsIGFuZCBpZiB0aGUgb2ZmZXJlci9hbnN3ZXJlciBwcm92aWRlZCAndGxzLWlk JyB2YWx1ZQ0KPj4+PmluDQo+Pj4+IHRoZSBwcmV2aW91cyBvZmZlci9hbnN3ZXIgd2hpY2ggZXN0 YWJsaXNoZWQgdGhpcyBUTFMgY29ubmVjdGlvbiwgdGhlDQo+Pj4+IG9mZmVyZXIvYW5zd2VyZXIg TVVTVCBhbHNvIGluc2VydCBhbiBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlIHdpdGggdGhlDQo+Pj4+ IHByZXZpb3VzbHkgYXNzaWduZWQgdmFsdWUgaW4gdGhlIG9mZmVyL2Fuc3dlci4NCj4+Pj4NCj4+ Pj4gSWYgd2UgcmV3b3JkIHRoZXNlIHN0YXRlbWVudHMgbGlrZSB0aGlzLCBkbyB3ZSBzdGlsbCBu ZWVkIHRvIHNwZWNpZnkNCj4+Pj50aGF0DQo+Pj4+IHRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkM0 NTcyPw0KPj4+Pg0KPj4+PiBSZWdhcmRzLA0KPj4+PiBfX19fX19fX19fX19fDQo+Pj4+IFJvbWFu IFNocG91bnQNCj4+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+Pj4gbW11c2ljIG1haWxpbmcgbGlzdA0KPj4+PiBt bXVzaWNAaWV0Zi5vcmcNCj4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9tbXVzaWMNCj4+Pj4NCj4+DQo+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+Pm1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+bW11c2ljQGlldGYub3JnDQo+ Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+DQoNCg== From nobody Wed Apr 19 01:08:40 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 724FA13155F for ; Wed, 19 Apr 2017 01:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh7tPHVAILpz for ; Wed, 19 Apr 2017 01:08:36 -0700 (PDT) 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 4807713155A for ; Wed, 19 Apr 2017 01:08:36 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-f8-58f71b02ef4d Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id 32.2E.21650.20B17F85; Wed, 19 Apr 2017 10:08:34 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0339.000; Wed, 19 Apr 2017 10:08:32 +0200 From: Christer Holmberg To: Christer Holmberg , Martin Thomson , Roman Shpount CC: Ben Campbell , "mmusic@ietf.org" , "Paul Kyzivat" Thread-Topic: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 - Pull request Thread-Index: AQHSuOQi1vm4+eD2VkmIGD2Fr7Jn4w== Date: Wed, 19 Apr 2017 08:08:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="euc-kr" Content-ID: <4570DE62DF151E4AB2A2ADC15C8B31D7@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUyM2K7vS6T9PcIgwM/ZS3md55mt7h25h+j xdTlj1ksVmw4wGox48JUZgdWj7/vPzB57Jx1l91jyZKfTB6zdj5h8bg1pSCANYrLJiU1J7Ms tUjfLoEr49fi10wF63QqVi4/yNbAOEe7i5GTQ0LARGLivynsXYxcHEIC6xklWtdeZoNwljBK LJoymbGLkYODTcBCovufNkhcRKCNUeJTfzs7SDezQKHE1Jtf2UBsYYEEiRMXX7GC2CICiRLt C4+zQdh6Ei3/u8DiLAKqEt0vDzGB2LwC1hL/381nAbEZBcQkvp9awwQxU1zi1pP5TBDXCUgs 2XOeGcIWlXj5+B/YHFGgmfv+QeyVEFCU+PhqHyNEr5bElx/72CBsa4kF5z5D3akoMaX7ITvE XkGJkzOfsExgFJ2FZN0sJO2zkLTPQtI+C0n7AkbWVYyixanFxbnpRkZ6qUWZycXF+Xl6eakl mxiBsXdwy2+rHYwHnzseYhTgYFTi4X0g/S1CiDWxrLgy9xCjBAezkgjvug9fI4R4UxIrq1KL 8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpgbDfr6vyno85ob8yvvlc7 VzssSnOu8l+RdW+/7Fxc4re8njfMg+eL2S/vydpPG2/YuE05EJuUuIM1wdVA8F2wy64C/Zid jlpViR4Tdzpvmh53wjZIJaWx2+vvnZYzi3hZkrT1cvaGGoXf/th0I6Be1i9j/Z7sfCOveI1P yyebsWyf+/D3OUMlluKMREMt5qLiRAAcKkJXuQIAAA== Archived-At: Subject: Re: [MMUSIC] Should draft-dtls-sdp-23 be a normative update to RFC4572 - Pull request X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Apr 2017 08:08:38 -0000 UHVsbCByZXF1ZXN0OiBodHRwczovL2dpdGh1Yi5jb20vY2RoNHUvZHJhZnQtZHRscy1zZHAvcHVs bC8zMA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCk9uIDE5LzA0LzE3IDEwOjU0LCAiQ2hy aXN0ZXIgSG9sbWJlcmciIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+DQp3cm90ZToN Cg0KPlRleHQgc3VnZ2VzdGVkIGJ5IFJvbWFuLCB0aGF0IGlzoaYgSSByZWFsbHkgbmVlZCBhIGN1 cCBvZiBjb2ZmZWUgOikNCj4NCj5PbiAxOS8wNC8xNyAxMDo1MSwgIkNocmlzdGVyIEhvbG1iZXJn IiA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPg0KPndyb3RlOg0KPg0KPj5IaSwNCj4+ DQo+PlNvcnJ5LCBJIG1lc3NlZCB1cCB0aGUgUkZDcy4NCj4+DQo+PkkgZG8gTk9UIHRoaW5rIHdl IG5lZWQgdG8gdXBkYXRlIDgxMjIuIFRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgbmV3DQo+PnByb2Nl ZHVyZXMgYXJlIHVzZWQgqfhpbiBjb25qdW5jdGlvbqn3IHdpdGggdGhlIDgxMjIgcHJvY2VkdXJl cywgYW5kIHRoZQ0KPj50ZXh0IHN1Z2dlc3RlZCBieSBQYXVsIGZpdHMgaW50byB0aGF0Lg0KPj4N Cj4+UmVnYXJkcywNCj4+DQo+PkNocmlzdGVyDQo+Pg0KPj4NCj4+T24gMTkvMDQvMTcgMTA6NDUs ICJtbXVzaWMgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIg0KPj48bW11c2ljLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4N Cj4+d3JvdGU6DQo+Pg0KPj4+SGksDQo+Pj4NCj4+PkkgYWdyZWUgdGhhdCB0aGUgZHJhZnQgc2hv dWxkIGJlIGFuIHVwZGF0ZSB0byA4MTIyIChub3QgNDU3MikuIFRoYXQgd2FzDQo+Pj5hY3R1YWxs eSBteSBpbnRlbnRpb24sIGJ1dCBJIGZvcmdvdCBhYm91dCBpdC4NCj4+Pg0KPj4+VGhlIGNoYW5n ZXMgc3VnZ2VzdGVkIGJ5IFBhdWwgbG9vayBnb29kLg0KPj4+DQo+Pj5SZWdhcmRzLA0KPj4+DQo+ Pj5DaHJpc3Rlcg0KPj4+DQo+Pj4NCj4+Pg0KPj4+T24gMTkvMDQvMTcgMDI6MzksICJNYXJ0aW4g VGhvbXNvbiIgPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4NCj4+Pj5JIGFn cmVlIHdpdGggUm9tYW4sIHdlIGNhbiBhbmQgc2hvdWxkIGp1c3QgZW5zdXJlIHRoYXQgdGhpcyBp cyBhIG5ldw0KPj4+PmZlYXR1cmUsIG5vdCBhIHJld3JpdGUuICBJIGRvbid0IHRoaW5rIHRoYXQg d2UgbmVlZCB0byBpbnZhbGlkYXRlIFJGQw0KPj4+PjQ1NzIgaW1wbGVtZW50YXRpb25zLiAgVGhp cyBpcyBhbiBlbmhhbmNlbWVudCAoYSB2ZXJ5IHVzZWZ1bCBvbmUsIGJ1dA0KPj4+PmFuIGVuaGFu Y2VtZW50IG9ubHkpLg0KPj4+Pg0KPj4+PnAucy4sIEFueSB1cGRhdGluZyBzaG91bGQgYmUgZG9u ZSB0byBSRkMgODEyMiBub3csIGlmIGF0IGFsbC4gIFRoYXQNCj4+Pj5wcm9iYWJseSByZW1vdmVz IGFueSBoZWF0IGZyb20gdGhlIGRpc2N1c3Npb24gYXMgcGVydGFpbnMgdG8gdXBkYXRpbmcNCj4+ Pj5vZiBvbGQgc3BlY3MuDQo+Pj4+DQo+Pj4+T24gMTkgQXByaWwgMjAxNyBhdCAwNToxNywgUm9t YW4gU2hwb3VudCA8cm9tYW5AdGVsdXJpeC5jb20+IHdyb3RlOg0KPj4+Pj4gUmUtc2VuZGluZyB0 byBtbXVzaWMgbGlzdCBhbmQgY2hhbmdpbmcgdGhlIHRpdGxlOg0KPj4+Pj4NCj4+Pj4+IE9uIFR1 ZSwgQXByIDE4LCAyMDE3IGF0IDEwOjUxIEFNLCBQYXVsIEt5eml2YXQNCj4+Pj4+PHBreXppdmF0 QGFsdW0ubWl0LmVkdT4NCj4+Pj4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gU2VjdGlvbiA4IGhh cyBhIG51bWJlciBvZiBub3JtYXRpdmUgcmVxdWlyZW1lbnRzIGFyb3VuZCB0aGUgdXNlIG9mDQo+ Pj4+Pj4gJ3Rscy1pZCcuIFRoaXMgc2VlbXMgdG8gYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSB3aXRo IGV4aXN0aW5nDQo+Pj4+Pj5pbXBsZW1lbnRhdGlvbnMNCj4+Pj4+PiB0aGF0IGZvbGxvdyBSRkM0 NTcyLg0KPj4+Pj4+DQo+Pj4+Pj4gV2hhdCBpcyB0aGUgaW50ZW50IGhlcmUgcmVnYXJkaW5nIGlu dGVyb3BlcmFiaWxpdHkgd2l0aCBSRkM0NTcyPw0KPj4+Pj4+IFBlcmhhcHMgdGhpcyBkb2Mgc2hv dWxkIG5vdyBhbHNvIGJlIGEgZm9ybWFsIHVwZGF0ZSB0byB0aGF0Lg0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+PiBTaG91bGQgd2UgcmV3b3JkIHRob3NlIHJlcXVpcmVtZW50cyB0aGF0IHRoZXkgb25seSBh cHBseSB3aGVuIHRscy1pZA0KPj4+Pj5pcw0KPj4+Pj4gdXNlZD8NCj4+Pj4+DQo+Pj4+PiBTbyBp bnN0ZWFkIG9mDQo+Pj4+Pg0KPj4+Pj4gSWYgYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBpbnNlcnRz IGFuIFNEUCAnY29ubmVjdGlvbicgYXR0cmlidXRlIHdpdGgNCj4+Pj4+YQ0KPj4+Pj4nbmV3Jw0K Pj4+Pj4gdmFsdWUgaW4gdGhlIG9mZmVyL2Fuc3dlciwgdGhlIG9mZmVyZXIvYW5zd2VyZXIgTVVT VCBhbHNvIGluc2VydCBhbg0KPj4+Pj5TRFANCj4+Pj4+ICd0bHMtaWQnIGF0dHJpYnV0ZSB3aXRo IGEgbmV3IHVuaXF1ZSB2YWx1ZS4NCj4+Pj4+DQo+Pj4+PiBXZSB3b3VsZCBzYXk6DQo+Pj4+Pg0K Pj4+Pj4gSWYgYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBpbnNlcnRzIGFuIFNEUCAnY29ubmVjdGlv bicgYXR0cmlidXRlIHdpdGgNCj4+Pj4+YQ0KPj4+Pj4nbmV3Jw0KPj4+Pj4gdmFsdWUgaW4gdGhl IG9mZmVyL2Fuc3dlciBhbmQgYWxzbyBwcm92aWRlcyBTRFAgJ3Rscy1pZCcgYXR0cmlidXRlLA0K Pj4+Pj50aGUNCj4+Pj4+IHZhbHVlIG9mIHRscy1pZCcgYXR0cmlidXRlIE1VU1QgYmUgbmV3IGFu ZCB1bmlxdWUuDQo+Pj4+Pg0KPj4+Pj4gQW5kIGluc3RlYWQgb2YNCj4+Pj4+DQo+Pj4+PiBJZiBh biBvZmZlcmVyIG9yIGFuc3dlcmVyIGluc2VydHMgYW4gU0RQICdjb25uZWN0aW9uJyBhdHRyaWJ1 dGUgd2l0aA0KPj4+Pj5hDQo+Pj4+PiAnZXhpc3RpbmcnIHZhbHVlIGluIHRoZSBvZmZlci9hbnN3 ZXIsIGFuZCBpZiBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQNCj4+Pj4+VExTDQo+Pj4+PiBjb25u ZWN0aW9uIGV4aXN0cywgdGhlIG9mZmVyZXIvYW5zd2VyZXIgTVVTVCBhbHNvIGluc2VydCBhbiBT RFANCj4+Pj4+J3Rscy1pZCcNCj4+Pj4+IGF0dHJpYnV0ZSB3aXRoIHRoZSBwcmV2aW91c2x5IGFz c2lnbmVkIHZhbHVlIGluIHRoZSBvZmZlci9hbnN3ZXIuDQo+Pj4+Pg0KPj4+Pj4gV2Ugd291bGQg c2F5DQo+Pj4+Pg0KPj4+Pj4gSWYgYW4gb2ZmZXJlciBvciBhbnN3ZXJlciBpbnNlcnRzIGFuIFNE UCAnY29ubmVjdGlvbicgYXR0cmlidXRlIHdpdGgNCj4+Pj4+YQ0KPj4+Pj4gJ2V4aXN0aW5nJyB2 YWx1ZSBpbiB0aGUgb2ZmZXIvYW5zd2VyLCBpZiBhIHByZXZpb3VzbHkgZXN0YWJsaXNoZWQgVExT DQo+Pj4+PiBjb25uZWN0aW9uIGV4aXN0cywgYW5kIGlmIHRoZSBvZmZlcmVyL2Fuc3dlcmVyIHBy b3ZpZGVkICd0bHMtaWQnDQo+Pj4+PnZhbHVlDQo+Pj4+PmluDQo+Pj4+PiB0aGUgcHJldmlvdXMg b2ZmZXIvYW5zd2VyIHdoaWNoIGVzdGFibGlzaGVkIHRoaXMgVExTIGNvbm5lY3Rpb24sIHRoZQ0K Pj4+Pj4gb2ZmZXJlci9hbnN3ZXJlciBNVVNUIGFsc28gaW5zZXJ0IGFuIFNEUCAndGxzLWlkJyBh dHRyaWJ1dGUgd2l0aCB0aGUNCj4+Pj4+IHByZXZpb3VzbHkgYXNzaWduZWQgdmFsdWUgaW4gdGhl IG9mZmVyL2Fuc3dlci4NCj4+Pj4+DQo+Pj4+PiBJZiB3ZSByZXdvcmQgdGhlc2Ugc3RhdGVtZW50 cyBsaWtlIHRoaXMsIGRvIHdlIHN0aWxsIG5lZWQgdG8gc3BlY2lmeQ0KPj4+Pj50aGF0DQo+Pj4+ PiB0aGlzIGRvY3VtZW50IHVwZGF0ZXMgUkZDNDU3Mj8NCj4+Pj4+DQo+Pj4+PiBSZWdhcmRzLA0K Pj4+Pj4gX19fX19fX19fX19fXw0KPj4+Pj4gUm9tYW4gU2hwb3VudA0KPj4+Pj4NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+Pj4+IG1tdXNpYyBtYWlsaW5nIGxpc3QNCj4+Pj4+IG1tdXNpY0BpZXRmLm9yZw0KPj4+ Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tbXVzaWMNCj4+Pj4+DQo+ Pj4NCj4+Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ Pj5tbXVzaWMgbWFpbGluZyBsaXN0DQo+Pj5tbXVzaWNAaWV0Zi5vcmcNCj4+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbW11c2ljDQo+Pg0KPg0KDQo= From nobody Thu Apr 20 03:30:44 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BEFA912EB7C; Thu, 20 Apr 2017 03:30:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149268424173.22225.5583262223580587645@ietfa.amsl.com> Date: Thu, 20 Apr 2017 03:30:41 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-dtls-sdp-24.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 10:30:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Using the SDP Offer/Answer Mechanism for DTLS Authors : Christer Holmberg Roman Shpount Filename : draft-ietf-mmusic-dtls-sdp-24.txt Pages : 29 Date : 2017-04-20 Abstract: This document defines the SDP offer/answer procedures for negotiating and establishing a DTLS association. The document also defines the criteria for when a new DTLS association must be established. The document updates RFC 5763 and RFC 7345, by replacing common SDP offer/answer procedures with a reference to this specification. This document defines a new SDP media-level attribute, 'tls-id'. This document also defines how the 'tls-id' attribute can be used for negotiating and establishing a TLS connection, in conjunction with the procedures in RFC 4145 and RFC 8122. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-24 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-dtls-sdp-24 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-dtls-sdp-24 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 Apr 20 03:36:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B48212F258; Thu, 20 Apr 2017 03:36:00 -0700 (PDT) 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 0IzBBnEJ61a6; Thu, 20 Apr 2017 03:35:59 -0700 (PDT) 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 03E6D12F274; Thu, 20 Apr 2017 03:35:56 -0700 (PDT) X-AuditID: c1b4fb25-84bff70000006af2-47-58f88f0a4452 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 4B.CF.27378.A0F88F85; Thu, 20 Apr 2017 12:35:55 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 12:35:54 +0200 From: Christer Holmberg To: "mmusic@ietf.org" CC: "mmusic-chairs@ietf.org" , Ben Campbell Thread-Topic: Draft new version: draft-dtls-sdp-24 Thread-Index: AQHSucHj0bpWIfzW9E6qpGSp+5/b7g== Date: Thu, 20 Apr 2017 10:35:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <0CD94FA4E2475A45A558967B492F2408@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZGbFdQpe7/0eEwZI+SYv5nafZLc7vXM9k MXX5YxYHZo8lS34yecza+YQlgCmKyyYlNSezLLVI3y6BK+PavNvMBV8YK75sX8/SwHiIsYuR k0NCwETi8bLPrF2MXBxCAusZJWb9OcQKkhASWMIoMfGaTRcjBwebgIVE9z9tkLCIgLrE1709 zCA2s0C4xJw3Z8DKhQV0JU5tgbBFBIwkGtfeYYaw9SQWbVrJBmKzCKhKLL99hQlkJK+AtcSa PekgYUYBMYnvp9YwQYwUl7j1ZD4TxGkCEkv2nGeGsEUlXj7+BzZeFGjkvn9f2SDiihLtTxsY IXr1JG5MncIGYVtLrO2ezQJha0ssW/gabA6vgKDEyZlPWCYwis5Csm4WkvZZSNpnIWmfhaR9 ASPrKkbR4tTipNx0I2O91KLM5OLi/Dy9vNSSTYzAKDq45bfqDsbLbxwPMQpwMCrx8Cbkfo8Q Yk0sK67MPcQowcGsJMLrlgkU4k1JrKxKLcqPLyrNSS0+xCjNwaIkzuu470KEkEB6Yklqdmpq QWoRTJaJg1OqgdG/jil+X9/83suhRxMdN046sXpN5WEb1wOGk23Vu5ZrcsbO/bnSQsFf+rR2 zoILWg+nBYU7h1/1N1/P9HBbmKD3ssOXvB7sntUmdGHfZ7FQR+fYp3v2Cyx+bvInuOGAvt+s 5QqFGTdL7hnkKGzL5Tj6e6/Trk1fQt+2eDZXT5mqfolphtQitXolluKMREMt5qLiRABGw0uw ngIAAA== Archived-At: Subject: [MMUSIC] Draft new version: draft-dtls-sdp-24 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 10:36:00 -0000 Hi, I=B9ve submitted a new version (-24) of draft-dlls-sdp. The new version makes it more clear that RFC 8122 is not updated, based on the input from Roman. (https://github.com/cdh4u/draft-dtls-sdp/pull/30) Regards, Christer From nobody Thu Apr 20 03:52:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA62E12F258 for ; Thu, 20 Apr 2017 03:52:10 -0700 (PDT) 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 YKS5DIaSegS5 for ; Thu, 20 Apr 2017 03:52:09 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 0F89A127B5A for ; Thu, 20 Apr 2017 03:52:09 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id 88so26652495lfr.0 for ; Thu, 20 Apr 2017 03:52:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=e/5lo7vt+uIcWhvLTkoINjVxO3XefnieYL7cK4MYMvE=; b=ipuahRbrz3fn0H9EjTAwsCR+jukcVSiJj7miQYuIiIU7ktFrmgwh7JtE0DZuk9ilqP W5LhMGBN6MUDuUBTAO2SB3jQT0Bt75ibSpUgps4QW7BBqmZcdLa0gTmIjjVZddxgopnw nliA//1WzX9a6fzZVj1O+RTRDBQcuodDMG/3KrtM3HGw+N2IKIFT9Ciqud0rrSt6iF9s f4SOBYupujwV72UxphgHyKs/z0wjs5ZzRqd5nbu/w2jC4qsgZS1lAya8QxAKlwoTASJR eTkTyUldPtkTRxm6aSS8sUkjkFIlzx9aXO9PfsD82FsFlITCrc0Bid5kcW71tY6cGEcF iqAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=e/5lo7vt+uIcWhvLTkoINjVxO3XefnieYL7cK4MYMvE=; b=DLVTSudzt2Q4sk2IqjVcqVkuOmZp6o3gNRc5bvWXJtVHKVcEbOaOnphb9YF8rqprJH UCduu36tBdLzjYevxGov5b2fivmvVbYhV60f8so7NgJ1HSPO/fVqHSAPHBDmEE7P7Kdw DacYX6G+mNGHrsEsd2ow+VEeipN0eA4/r+WUjHnD9ezW0kGjM/t19W9v+/4bIFwAgvcZ RLzYAbANP3XAf6ejDYFUmG5FhSDy5N+bLlmTa1IU9wgtUU2oKVuWPiXgvfpx6mPGslEL jd4d19dQyuA6rX/FOWCrRrbAEJPEb0Ybns82vNr5Kph1QaAuCF79C41l+4ZiwvueFVQa gvug== X-Gm-Message-State: AN3rC/7kntYYLMDi8FK30dgvuFfuYPBpNSimeyoOOuWm/KD5fdjlgTS9 fsEZ0hhG5xA6u6zEhlnG9RHFmNhvHA+3H0I= X-Received: by 10.46.14.10 with SMTP id 10mr2616813ljo.22.1492685527192; Thu, 20 Apr 2017 03:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 03:52:06 -0700 (PDT) From: Martin Thomson Date: Thu, 20 Apr 2017 20:52:06 +1000 Message-ID: To: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 10:52:11 -0000 https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks Inspired by Christer updating the dtls-sdp draft, I have updated the SDP UKS draft to match the recent changes (thanks Christer!). I found a few minor errors while editing this. I'd appreciate it if people can take a look and see if it is ready. I'm biased, but I think that it's in reasonable shape. From nobody Thu Apr 20 05:59:41 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33812426E for ; Thu, 20 Apr 2017 05:59:39 -0700 (PDT) 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 iMwtUB3kwpzO for ; Thu, 20 Apr 2017 05:59:38 -0700 (PDT) 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 D365D129435 for ; Thu, 20 Apr 2017 05:59:37 -0700 (PDT) X-AuditID: c1b4fb3a-baef298000005492-0f-58f8b0b79a17 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 77.14.21650.7B0B8F85; Thu, 20 Apr 2017 14:59:36 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC012.ericsson.se ([153.88.183.54]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 14:59:35 +0200 From: Christer Holmberg To: Martin Thomson , "mmusic@ietf.org" Thread-Topic: [MMUSIC] New version of SDP UKS draft Thread-Index: AQHSucQtLLUtJKLc50K9G9/NZEEaQKHOSmaA Date: Thu, 20 Apr 2017 12:59:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-ID: <7A18E7137E35DC4F86B8E836B03C7AD4@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7me6ODT8iDNbO5LS4duYfo8XU5Y9Z HJg8ds66y+6xZMlPpgCmKC6blNSczLLUIn27BK6MthV3WQvesFac7Olnb2B8z9LFyMkhIWAi cXfOUiCbi0NIYD2jxIwnP9ghnCWMEpvbnjF2MXJwsAlYSHT/0wZpEBEIkZj4fBlYs7CAkcTP Ez8ZIeLGEjt/TWSHsI0kFp1sYwOxWQRUJfrWvwCr5xWwlvh5dQdYvZBAgMTLw1/B4pwCgRJf D3wEizMKiEl8P7WGCcRmFhCXuPVkPhPEoQISS/acZ4awRSVePv7HCmKLCuhJ7Pv3lQ3kTAkB RYnl/XIQrToSC3Z/YoOwrSXu7zjHDGFrSyxb+JoZ4hxBiZMzn7BMYBSbhWTbLCTts5C0z0LS PgtJ+wJG1lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgVF1cMtvqx2MB587HmIU4GBU4uFN yP0eIcSaWFZcmXuIUYKDWUmE1y0TKMSbklhZlVqUH19UmpNafIhRmoNFSZzXYd+FCCGB9MSS 1OzU1ILUIpgsEwenVANju9nu3g8TQ9VPccpf7Yt/3CHafyzJbceCToM7W6Yd17yXb5lva9v9 oWT317nyjt/+b5J5vc9hp3fQg+IX570DInZv51vwsWbthr+RJ2yuyvK+ieOeybL2w7Gqxzs2 Mqtvtta71S75Yb1eX5Tz9BfPcx5tmfxrguD2b7f9n6rcfr3u+oP8urkMNkosxRmJhlrMRcWJ ALHb6TGmAgAA Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 12:59:40 -0000 Hi, Should the draft reference RFC 8122 instead of 4572? Regards, Christer On 20/04/17 13:52, "mmusic on behalf of Martin Thomson" wrote: >https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks > >Inspired by Christer updating the dtls-sdp draft, I have updated the >SDP UKS draft to match the recent changes (thanks Christer!). > >I found a few minor errors while editing this. I'd appreciate it if >people can take a look and see if it is ready. I'm biased, but I >think that it's in reasonable shape. > >_______________________________________________ >mmusic mailing list >mmusic@ietf.org >https://www.ietf.org/mailman/listinfo/mmusic From nobody Thu Apr 20 07:43:31 2017 Return-Path: X-Original-To: mmusic@ietf.org Delivered-To: mmusic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7C6127B60; Thu, 20 Apr 2017 07:43:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.50.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149269940933.22278.1221564609730022931@ietfa.amsl.com> Date: Thu, 20 Apr 2017 07:43:29 -0700 Archived-At: Subject: [MMUSIC] I-D Action: draft-ietf-mmusic-sctp-sdp-26.txt X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:43:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiparty Multimedia Session Control of the IETF. Title : Session Description Protocol (SDP) Offer/Answer Procedures For Stream Control Transmission Protocol (SCTP) over Datagram Transport Layer Security (DTLS) Transport. Authors : Christer Holmberg Roman Shpount Salvatore Loreto Gonzalo Camarillo Filename : draft-ietf-mmusic-sctp-sdp-26.txt Pages : 26 Date : 2017-04-20 Abstract: The Stream Control Transmission Protocol (SCTP) is a transport protocol used to establish associations between two endpoints. draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used on top of the Datagram Transport Layer Security (DTLS) protocol, referred to as SCTP-over-DTLS. This specification defines the following new Session Description Protocol (SDP) protocol identifiers (proto values):'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'. This specification also specifies how to use the new proto values with the SDP Offer/Answer mechanism for negotiating SCTP-over-DTLS associations. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mmusic-sctp-sdp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-26 https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-sctp-sdp-26 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-sctp-sdp-26 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 Apr 20 07:46:37 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9BA1295A0; Thu, 20 Apr 2017 07:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 1XYfBAHafEAe; Thu, 20 Apr 2017 07:46:34 -0700 (PDT) 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 5B9F812957F; Thu, 20 Apr 2017 07:46:34 -0700 (PDT) X-AuditID: c1b4fb3a-7cfff70000005492-c8-58f8c9c7fa1e Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by (Symantec Mail Security) with SMTP id 75.5C.21650.7C9C8F85; Thu, 20 Apr 2017 16:46:32 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0339.000; Thu, 20 Apr 2017 16:46:31 +0200 From: Christer Holmberg To: "mmusic (E-mail)" CC: Ben Campbell , "mmusic-chairs@ietf.org" Thread-Topic: Draft new version: draft-sctp-sdp-26 Thread-Index: AdK55JMvq3tcbDMeSWCHk8K/q+aKzA== Date: Thu, 20 Apr 2017 14:46:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB7BE8E@ESESSMB109.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B4CB7BE8EESESSMB109erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPLMWRmVeSWpSXmKPExsUyM2K7tO6Jkz8iDKbMFraY33ma3eL8zvVM FlOXP2ZxYPZYsuQnk8esnU9YApiiuGxSUnMyy1KL9O0SuDLubXvDUnBOouLc/Y2sDYwPRLsY OTkkBEwk5u0/ygpiCwmsZ5Q4tDu1i5ELyF7CKHHv5lW2LkYODjYBC4nuf9ogNSIC6hKtm/vA 6pkFwiWuvF7JDlIiLKArce97MESJkcTf65dYIGw9iRUfDjOC2CwCqhJTuueA2bwCvhKffx1n BrEZBcQkvp9awwQxUlzi1pP5TBCnCUgs2XOeGcIWlXj5+B8rhK0k0bjkCdQJ+RKX5m5lhpgp KHFy5hOWCYxCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4 N93ISC+1KDO5uDg/Ty8vtWQTIzBaDm75bbWD8eBzx0OMAhyMSjy8D/b9iBBiTSwrrsw9xCjB wawkwtu7HSjEm5JYWZValB9fVJqTWnyIUZqDRUmc12HfhQghgfTEktTs1NSC1CKYLBMHp1QD o1Djx5YlSvsPda65bSi9+YuBzDTVioCQN4ft+04mSQcV75OrYn5jyJui1xfnX/Xz6ZLnXzJO 9q+zuVxTLhpw26dN/d20CJ8VLXJvynJnrtRW9zPYa7dOxzbEYHZMwc7l1nvX3S+TPRZ/au0x priIC/qL2dLs7tony3rL9W3lXVJXpp8+gWOFEktxRqKhFnNRcSIAk0bbuZICAAA= Archived-At: Subject: [MMUSIC] Draft new version: draft-sctp-sdp-26 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 14:46:36 -0000 --_000_7594FB04B1934943A5C02806D1A2204B4CB7BE8EESESSMB109erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have submitted a new version (-26) of draft-sctp-sdp. The only technical change is changing the SDP 'dtls-id' attribute name to '= tls-id', due to the change in draft-dtls-sdp. (The draft is currently in the RFC EQ, in MISSREF state.) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B4CB7BE8EESESSMB109erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have submitted a new version (-26) of draft-sctp-s= dp.

 

The only technical change is changing the SDP ‘= ;dtls-id’ attribute name to ‘tls-id’, due to the change i= n draft-dtls-sdp.

 

(The draft is currently in the RFC EQ, in MISSREF st= ate.)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B4CB7BE8EESESSMB109erics_-- From nobody Thu Apr 20 16:22:48 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5317C127A97 for ; Thu, 20 Apr 2017 16:22:46 -0700 (PDT) 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 WUJNwa3u4asT for ; Thu, 20 Apr 2017 16:22:44 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (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 5B6BC1293FD for ; Thu, 20 Apr 2017 16:22:44 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id 88so36777579lfr.0 for ; Thu, 20 Apr 2017 16:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zbjZvoNDXQSIlw3/TKzs+7fTCm3/pmygEIfHNcpSnxg=; b=dG/jCPfgBth+Jn6uuzoIdwMNKCEE1sh3XME22gzFfLZYiv9VAkn232/JhTt6qoTHFm toS7y7my6v29alS7AeVj9G2qJnf7Ic10ea1oONAUkve45qtPRrgZlXPaCBP5pB72WCIl dXECF+pgjo1wOffnFjC3TfUH0Cob2WxkwcYxb/jXSmydQzUJVlCQK1X6vh2zqTQ6JM7X uOqzIxEr/tDBI7+08cYv7E9x9mD4Ite9tSEIgtoijUIgmZBCVKU1qbtu4p9dop+6MxWh d41iJm+apHMSBcUdyLe4tUCLsq2H59hU568ocC7q3/0qQGgCZL4b+jQ/TdVYXH40y0Y9 LS/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zbjZvoNDXQSIlw3/TKzs+7fTCm3/pmygEIfHNcpSnxg=; b=FpSuGNNPcDJrDM/GQFoqZ/N7GFdwivcR4nYIJUHlIphJxJhWCtt4xidzBy30OHWW0g /XXU6Ktrz7jJ3UwAAiSGX1LjxjrAX9gpCvsOsfVewcfrN/TW+DGBoGpxQoiW8CsmUcL0 yDxi36FJ67DZN6XtcGSjohx+3aQLHYMzdfHkgc/MIqw9qW4zQUWz7M0czU17HARnAY7Y 0xbOLfJBmjBuewKUJeHpZp07VhuUhzyaBMYDamCfayKYYGdnOwPB3FkrY2QMLxveu7Bs T/lUyGLn4Rk0Fb2PUfW+r/n7mC+ZLwu1NJ9tbK/wubhf2L2Wc4qzWN1XH0wkwsLdTUNB Ak1g== X-Gm-Message-State: AN3rC/6TVtI00lEff4EO8nYwJJn1HL63iCQe2Pxwa3X1q/VqvD1CpPhG zIX4B0MC7++kESCU5J3qiF1THZG4zg== X-Received: by 10.25.76.6 with SMTP id z6mr3678858lfa.172.1492730562541; Thu, 20 Apr 2017 16:22:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 16:22:41 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 21 Apr 2017 09:22:41 +1000 Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:22:46 -0000 You sir, caught me out. Yes. On 20 April 2017 at 22:59, Christer Holmberg wrote: > Hi, > > Should the draft reference RFC 8122 instead of 4572? > > Regards, > > Christer > > On 20/04/17 13:52, "mmusic on behalf of Martin Thomson" > wrote: > >>https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks >> >>Inspired by Christer updating the dtls-sdp draft, I have updated the >>SDP UKS draft to match the recent changes (thanks Christer!). >> >>I found a few minor errors while editing this. I'd appreciate it if >>people can take a look and see if it is ready. I'm biased, but I >>think that it's in reasonable shape. >> >>_______________________________________________ >>mmusic mailing list >>mmusic@ietf.org >>https://www.ietf.org/mailman/listinfo/mmusic > From nobody Thu Apr 20 16:24:11 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58641293FD for ; Thu, 20 Apr 2017 16:24:09 -0700 (PDT) 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 zrLPPu63XWMC for ; Thu, 20 Apr 2017 16:24:08 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 28FAD127A97 for ; Thu, 20 Apr 2017 16:24:08 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id 75so36749691lfs.2 for ; Thu, 20 Apr 2017 16:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mGoGpQpareFAInUMHH4SiKd3pNhrnzuIN0WzQ/m0CNc=; b=qLbWyszN3vcI6BO/+bUaS6ZqrWOmKnXMPvZmcEs8g/+4Lt21PGiWhf/O7Qa6diUE3R 4AAo/2jNvhwapISZFgwu0rEEJ03XD++gHyipCeGi9agy/T0/CRDagCRlHCItK44x00Ta I7XM+gJkulGAZzN4mcdD57VT5RLc+HB0Tn0EpYvvWdWqR9olDUw1LWk+01amuLFw2qEB xT6QuGtNXJ0QKEpkDp3sidMqPJplCtxY4Ch9gNDhPcVXtmChkeNVLbiduSiihp6veH20 7+3eHfsHnQDZlzuZ7ivowVFahlkf1zP0eUY6MM7IztkJaUXIgsfKQ6FBHeua6aKjlXvl ROnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mGoGpQpareFAInUMHH4SiKd3pNhrnzuIN0WzQ/m0CNc=; b=LbSc70fycFjTROHpIHyB7kOqPBXogNp6FausaAWmi814+8wYiKbnSY/1FxWSvvjiO8 DqehCtjReBjrmAN+S9wEXql6F1yndN6T/SjQ608J9zk46tR6oDs6eoJv4S4mZ3f61wyN EMoLhOyUmwQqA3Q4mS35OhliFn8puaKSWwm5tKZrpYFK2qprH58mieEVUOicjIHACpez VxK6jVMlC+PvBiwf4Ledw5sOF5hAF8OgArLFYsfVwZzwo1ap3AZ9rG0KE+ZfGq45EvBJ bK+p5PHQtwqMtIYvO7xByDqy3gjUTvJ3KRG1n8fmexTVE4Kr7G9iS8m8PEzYDNoxjWCf iMxA== X-Gm-Message-State: AN3rC/7boEHUHkx1hbJZheDruqHQTn11NuDmzJWL9RjNQcWxnj5PAkHE qJOk+5Mh+PL69OajgI0geF+qmihaZQ== X-Received: by 10.46.0.70 with SMTP id 67mr3868852lja.113.1492730646532; Thu, 20 Apr 2017 16:24:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Thu, 20 Apr 2017 16:24:05 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Fri, 21 Apr 2017 09:24:05 +1000 Message-ID: To: Christer Holmberg Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Apr 2017 23:24:10 -0000 On 20 April 2017 at 22:59, Christer Holmberg wrote: > Should the draft reference RFC 8122 instead of 4572? I've updated the editor's copy. No sense publishing an update for that though. From nobody Fri Apr 21 05:44:13 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03D9124234 for ; Fri, 21 Apr 2017 05:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i_RV1li0JOsA for ; Fri, 21 Apr 2017 05:44:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A58120454 for ; Fri, 21 Apr 2017 05:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4036; q=dns/txt; s=iport; t=1492778649; x=1493988249; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=5fvSf1IPQFrDxSdRHc94/8PJJveNOKr7Rlx7dkUGxjA=; b=LR4swXuGUwq+DfWgfsQ3gygWdqLFQtae7Kjv7BKrgqIlNwuU3eb1/gxf Atbaz1UgPjZMypuJcAPK09EAu9MGj+dNBi+V/ir+L9D4zb4pTMCzPmIY8 NBLFb48dv+daWJM+wowT7jT16Lqf2jEHSQeU+nMfpcHRPallvMzjvob4o k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAQD3/flY/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQyDZ4oVkUghiB+NRYIPMIUqSgKECT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFQEBAQEBAiMVLwcLEAsUAQMCAiYCAiE2Bg0GAgEBigADCA0OqTuCJocsDYNmA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARoFgQuFSIFdKwuCY4JRHoFEBwEBBYMcgl8FlkW?= =?us-ascii?q?GOTuHFYcmhEmCAIUzg0CGYohvgiOJBB84gQZDIBUaKocEJDUBhnAPF4IXAQEBE?= =?us-ascii?q?g?= X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208";a="235729033" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 12:44:08 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v3LCi6tb006943; Fri, 21 Apr 2017 12:44:07 GMT To: Bo Burman References: <149123343669.13157.18402606352918183703.idtracker@ietfa.amsl.com> Cc: Adam Roach , Ben Campbell , stefhak@gmail.com, Alexey Melnikov , alvestrand@gmail.com, Multiparty Multimedia Session Control Discussion List , bernard.aboba@gmail.com From: Flemming Andreasen Message-ID: <7db1eac1-1667-8371-34ae-1462910f561c@cisco.com> Date: Fri, 21 Apr 2017 08:44:06 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149123343669.13157.18402606352918183703.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [MMUSIC] New Liaison Statement, "W3C WEBRTC WG to IETF MMUSIC WG" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:44:12 -0000 Greetings MMUSIC. The issue raised below has been discussed on the MMUSIC mailing (see thread starting at https://www.ietf.org/mail-archive/web/mmusic/current/msg17646.html) and the recent MMUSIC meeting at IETF 98 (Chicago). A summary discussion has been provided at https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291194679 as well. Based on the above, we suggest to answer the liaison statement as follows: Thank you for raising the question regarding playout of unverified media to the MMUSIC WG. We have looked further into the issue raised and we would like to request a clarification of the exact sequence of events that WEBRTC believes can lead to this. In particular, we ask you to please show either (a) how ICE can complete prior to DTLS fingerprint exchange, or (b) how media can be received prior to ICE completing It is currently unclear to us how either of these situations can arise in which case we do not believe the issue raised would apply to WebRTC. For further background information, please refer to: - https://www.ietf.org/mail-archive/web/mmusic/current/msg17646.html - https://github.com/w3c/webrtc-pc/pull/1026#issuecomment-291194679 Please let the chairs know (before April 28) if you have any comments. Thanks -- Flemming On 4/3/17 11:30 AM, Liaison Statement Management Tool wrote: > Title: W3C WEBRTC WG to IETF MMUSIC WG > Submission Date: 2017-04-03 > URL of the IETF Web page: https://datatracker.ietf.org/liaison/1511/ > Please reply by 2017-04-16 > From: Bernard Aboba > To: Flemming Andreasen ,Bo Burman > Cc: Adam Roach ,Flemming Andreasen ,Ben Campbell ,Bo Burman ,Alexey Melnikov ,Multiparty Multimedia Session Control Discussion List > Response Contacts: bernard.aboba@gmail.com, alvestrand@gmail.com, stefhak@gmail.com > Technical Contacts: > Purpose: For action > > Body: Colleagues: > > In the W3C WEBRTC WG, an issue has been submitted relating to playout of unverified media: > https://github.com/w3c/webrtc-pc/issues/849 > > It has been suggested that if the browser is configured to do so, that playout be allowed for a limited period > (e.g. 5 seconds) prior to fingerprint verification: > https://github.com/w3c/webrtc-pc/pull/1026 > > Section 6.2 of draft-ietf-mmusic-4572-update-13 contains the following text, carried over from RFC 4572: > > Note that when the offer/answer model is being used, it is possible > for a media connection to outrace the answer back to the offerer. > Thus, if the offerer has offered a 'setup:passive' or 'setup:actpass' > role, it MUST (as specified in RFC 4145 [7]) begin listening for an > incoming connection as soon as it sends its offer. However, it MUST > NOT assume that the data transmitted over the TLS connection is valid > until it has received a matching fingerprint in an SDP answer. If > the fingerprint, once it arrives, does not match the client's > certificate, the server endpoint MUST terminate the media connection > with a bad_certificate error, as stated in the previous paragraph. > > Given the outstanding issue relating to handling of unverified media, the Chairs of the W3C WEBRTC WG > would like to request clarification from the IETF MMUSIC WG as to the meaning of the "MUST NOT" in the > above paragraph. In particular, what is it permitted for a WebRTC implementation to do with received data prior > to verification? For example: > > 1. May data received over the data channel be provided to the web application prior to verification? > 2. May received media be played out prior to verification? > Attachments: > > webrtc-liason-to-mmusic copy.pdf > https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2017-04-03-w3c-webrtc-mmusic-w3c-webrtc-wg-to-ietf-mmusic-wg-attachment-1.pdf > > . > From nobody Fri Apr 21 05:54:44 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC00129478 for ; Fri, 21 Apr 2017 05:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIO8RIxCQpKY for ; Fri, 21 Apr 2017 05:54:40 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F66E129466 for ; Fri, 21 Apr 2017 05:54:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7898; q=dns/txt; s=iport; t=1492779280; x=1493988880; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=FxPIg34tRCHltS6F5whfoQD+GuPNrslbwO2mtflUe6o=; b=WGEd+i6aQy/8VHJ5+BpKZPHSjm7TqBRUfopXD3kd+J1fFdE/ioI2lrHL 2LXbnaD2fK9bP/grwwWed3dZwMOY0HnXn2rCklOa+64tmaLSyHeKe+itO /Vqkl/6Bbk2NsL2yJOGlA91S5OnS5hfeFMyC/hPnD2AIm16VJvZGU+47/ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQBsAPpY/5JdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQyNfJFIIZAvhTWCDyEBCoUuSgKECT8YAQIBAQEBAQEBayi?= =?us-ascii?q?FFgEBAQMBAWwLEAsYJwcnHxEGAQwGAgEBigsNDqt3K4p1AQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGAWGU4IIC4JjijwFiS6IK4tgkwSCAIhzhmKIb4Z/hCgfOIEGQyA?= =?us-ascii?q?VRIQwboFmJDWJLgEBAQ?= X-IronPort-AV: E=Sophos;i="5.37,229,1488844800"; d="scan'208,217";a="415454011" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 12:54:39 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id v3LCscRq010564; Fri, 21 Apr 2017 12:54:39 GMT To: "Ali C. Begen" , Cullen Jennings References: <5136C735-5EF5-4E4E-A748-B3F1507A5CB4@iii.ca> Cc: mmusic From: Flemming Andreasen Message-ID: <3c4278c0-6851-11b1-a81e-5f9e3509d4f4@cisco.com> Date: Fri, 21 Apr 2017 08:54:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F9DBA19C26DFD1B12CF5538C" Archived-At: Subject: Re: [MMUSIC] References to iana-charset-reg-procedure in draft-ietf-mmusic-rfc4566bis X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 12:54:42 -0000 This is a multi-part message in MIME format. --------------F9DBA19C26DFD1B12CF5538C Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Since we have not received any further feedback on this, we will proceed as described below. Thanks -- Flemming (as MMUSIC co-chair) On 3/24/17 10:21 AM, Flemming Andreasen wrote: > Any further opinions on this (positive or negative) ? > > Thanks > > -- Flemming > > On 3/10/17 8:47 AM, Flemming Andreasen wrote: >> >> >> On 11/23/16 12:17 AM, Ali C. Begen wrote: >>> Was there a decision on this during the meeting? I can make the >>> change if it has been agreed to. >>> >> I don't believe we decided on this during the meeting, but it seems >> reasonable to me, not least considering that the charset-reg draft >> expired quite a while ago. Also, do note, that we are trying to >> ensure that RTCWeb does not have any normative dependencies on >> 4566bis, so from that point of view, there may not be an issue here. >> >> Thanks >> >> -- Flemming >> >> >>> On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings >> > wrote: >>> >>> >>> draft-ietf-mmusic-rfc4566bis has a normative references to >>> draft-iana-charset-reg-procedure. draft-iana-charset-reg is an >>> update of RFC2978 and will obsolete RFC2978 when it is published. >>> >>> When I look at what parts of iana-charset-reg-procedure that >>> 4566bis uses, I think it would be perfectly reasonable to >>> instead have 4566bis reference RFC2978. >>> >>> I'd like to propose we make this change so that publication of >>> 4566bis is not blocked by iana-charset-reg-procedure >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic --------------F9DBA19C26DFD1B12CF5538C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Since we have not received any further feedback on this, we will proceed as described below.

Thanks

-- Flemming (as MMUSIC co-chair)

On 3/24/17 10:21 AM, Flemming Andreasen wrote:
Any further opinions on this (positive or negative) ?

Thanks

-- Flemming

On 3/10/17 8:47 AM, Flemming Andreasen wrote:


On 11/23/16 12:17 AM, Ali C. Begen wrote:
Was there a decision on this during the meeting? I can make the change if it has been agreed to.

I don't believe we decided on this during the meeting, but it seems reasonable to me, not least considering that the charset-reg draft expired quite a while ago. Also, do note, that we are trying to ensure that RTCWeb does not have any normative dependencies on 4566bis, so from that point of view, there may not be an issue here.

Thanks

-- Flemming


On Wed, Nov 16, 2016 at 5:51 AM, Cullen Jennings <fluffy@iii.ca> wrote:

draft-ietf-mmusic-rfc4566bis has a normative references to draft-iana-charset-reg-procedure. draft-iana-charset-reg is an update of RFC2978 and will obsolete RFC2978 when it is published.

When I look at what parts of iana-charset-reg-procedure that 4566bis uses, I think it would be perfectly reasonable to instead have 4566bis reference RFC2978.

I'd like to propose we make this change so that publication of 4566bis is not blocked by  iana-charset-reg-procedure


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



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




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




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

--------------F9DBA19C26DFD1B12CF5538C-- From nobody Fri Apr 21 06:08:06 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD3B12943A; Fri, 21 Apr 2017 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.022 X-Spam-Level: X-Spam-Status: No, score=-14.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0u68UFc_WY4j; Fri, 21 Apr 2017 06:08:02 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F4B126BF7; Fri, 21 Apr 2017 06:08:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=442; q=dns/txt; s=iport; t=1492780082; x=1493989682; h=from:subject:to:message-id:date:mime-version: content-transfer-encoding; bh=5S+4c17NpWWeIRjRMRHb6LmXzvv6ik90WfGp/VAvjnI=; b=Kke7CGTYCSG6xc1tzqOL6/bF/U3INRbLnxICxEMcz2ZdMzUil3Z33WZC BaubYx2MgvLJCfMOUBTQpqwhQwGC7sLjZj/QPRSUsgcui1yPu9LyQX7Qg ABcP1xoLTcEB1Z6Ad/PfEgHDD10uzPJVFC7Ud6bApudZtSCpQLth3qNl9 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMAQCVA/pY/4sNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhhHOKFZFIlgWCDy6KAj8YAQIBAQEBAQEBayiFPxV2AiYCXwE?= =?us-ascii?q?MCAEBigsNDqlCgiaLIAEBAQEBBQEBAQEBHgWBC4VIgV0rC4V7hEWCXwEEnTmTB?= =?us-ascii?q?IFoAReFM4NAhmKUFh84gQZDIBVEhwQkiWMBAQE?= X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208";a="17766340" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Apr 2017 13:08:01 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v3LD80NU007720; Fri, 21 Apr 2017 13:08:00 GMT From: Flemming Andreasen To: mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" Message-ID: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com> Date: Fri, 21 Apr 2017 09:08:00 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:08:04 -0000 Greetings MMUSIC Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on the changes from -22 to -24, i.e.: https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp-22&url2=draft-ietf-mmusic-dtls-sdp-24 If you have any comments on the changes, please provide those by Friday, April 28. Comments should be sent to the document authors and the MMUSIC WG list. Thanks -- Flemming (as MMUSIC co-chair) From nobody Fri Apr 21 06:50:58 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC9312944C for ; Fri, 21 Apr 2017 06:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.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 HTI4jZ3JRTVc for ; Fri, 21 Apr 2017 06:50:53 -0700 (PDT) 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 24A8D120227 for ; Fri, 21 Apr 2017 06:50:52 -0700 (PDT) X-AuditID: c1b4fb30-aabff70000006667-ac-58fa0e3a9e2e Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 42.AC.26215.A3E0AF85; Fri, 21 Apr 2017 15:50:51 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.90) with Microsoft SMTP Server (TLS) id 14.3.339.0; Fri, 21 Apr 2017 15:50:50 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hiieTIYGPrA1308i0uK80gsEpUE1W8I9g/8Db9WMOHE=; b=T8MdPCz0fhe/Hw9CaspuOx2VH3AVsE5ku+Yg5nDowog7MJXkQ22e5VVCzMxGNDS+VhniYRb7I9x7LN+X2OaZAnA6EVqClHiZLnYmATnc/GrHmL5erob00DPyr4tB4EZSHLbgCcy2CnEv3+pLfukguXKzljV8U66t8E9DDvBucWs= Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) by AM5PR0701MB2577.eurprd07.prod.outlook.com (10.173.92.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.6; Fri, 21 Apr 2017 13:50:49 +0000 Received: from AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) by AM5PR0701MB2577.eurprd07.prod.outlook.com ([10.173.92.21]) with mapi id 15.01.1047.013; Fri, 21 Apr 2017 13:50:49 +0000 From: Bo Burman To: "Makaraju, Raju (Nokia - US)" , "mmusic (mmusic@ietf.org)" Thread-Topic: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 Thread-Index: AQHSm5yGz6G1c3++IkS/LRYJALgIgaGSn/owgACyV4CAAsGt4IAAFcAAgDnm1SA= Date: Fri, 21 Apr 2017 13:50:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: nokia.com; dkim=none (message not signed) header.d=none;nokia.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.92] x-microsoft-exchange-diagnostics: 1; AM5PR0701MB2577; 7:DzKhFi8tKiL0AeUmrnUOeS9N8WdiFl0KkC4pPg5ZlrGqsA+JAtttD0PZV0M39JevFtw0b5q8AJDvDTRlAgoqopkeVphTTU2bU6pjwmwkVI8bgfJlYIkDirbeufxYqjpJQWk60m1bc1fUn0e/RsDiQ+5EnN8FSbmQTBnr5McNSA9t4MXdWg/iJaGSMNpiwnXX6TyWdacJkOkGuKtscJ0Gt4YhIML7fCUJFFGzz/KbWn0UV6smdKDbr/hECHArYCIewNVlWzAgEmfTSIl22AlFJj524h2fV7hYW3LVqVcB59N4I5Oh6jpxLkbBS+I3T/+2UY2m67hVrUkr77RwHznygQ== x-ms-office365-filtering-correlation-id: 7d87b572-227a-42d6-449b-08d488bd6b14 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081); SRVR:AM5PR0701MB2577; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123555025)(6072148); SRVR:AM5PR0701MB2577; BCL:0; PCL:0; RULEID:; SRVR:AM5PR0701MB2577; x-forefront-prvs: 02843AA9E0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39850400002)(39400400002)(39450400003)(39860400002)(43784003)(377454003)(52314003)(6116002)(790700001)(102836003)(3846002)(6506006)(77096006)(9326002)(8936002)(229853002)(53936002)(6246003)(33656002)(99286003)(55016002)(6436002)(606005)(189998001)(6306002)(54896002)(236005)(9686003)(38730400002)(93886004)(7736002)(5660300001)(7906003)(122556002)(2900100001)(74316002)(8676002)(3280700002)(3660700001)(81166006)(2950100002)(7696004)(53546009)(66066001)(86362001)(2906002)(19609705001)(50986999)(76176999)(54356999)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:AM5PR0701MB2577; H:AM5PR0701MB2577.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM5PR0701MB2577772C4FA66A297F541D2C8D1A0AM5PR0701MB2577_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2017 13:50:48.9266 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0701MB2577 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe+69266j2XU6djCLWEmlpWYhUiJKCIKUUV/Wetlm3lScm+2q pBBNDEFtUZroRvhCy8CcgkYZS7GFoLjyNQJrs1Ryw4oaiW8j293V8NvvnP85z/mfw0PiYisv nMzTFtF6rVoj4wsJk/yl4uip4DV5nM+yK7H+6RyR2GVzESlYusWyiqU7pyewc5hCmJRNa/JK aH1sskqY22SSFHZ1YDdrO58gAyqvxKpREAnUCVh4NsZnWUx1IbBWxFYjoZ+HEMxONiA2ICgj Dt/tDh6nNGLgcU/w/5fVjvzksf186hA09zoRy2FUPtisPgHLoZQCHIOPeFz+EvhqNgQcnwWz bTHABBUJfRu/Ap5ElAoMdifiBhgJGBr+g7NCEKUEa3tFoAFRe2Bm2UWwjFNSmJ5v3lyIAsvr UZxjCXjm/gZsI8qIoN5XQ3DCPvBNzAZWAOoeDmvffJvCGRitqhRwggFBi+3O5rM6qAx0sKwA 94sOjCv6gIGjzeafR/qDCFj4reTykzxwD9hx7gDh4JyqQhxHgPtzH4/zrYPlOgv/Pjpo3raG eZtkDtwjBIZN8wSXP+L35OVzHA1trYv4FjsG5rDt+RYkaEcShmayCnLi42Nofd41htFpY7R0 UTfyf6I3z9fjepFnIdWOKBLJdoq+9K/IxTx1CVNaYEdA4rIw0WnvqlwsylaXltF6nVJfrKEZ O9pNEjKpKLV/TC6mctRFdD5NF9L6LRUjg8INKIN2zuz13dZn4geartgeMIOfit+ZgiNLaiyH W23jdeUNZddXXI8TGpeOtzmjR7QXzqfFZl7OvPu2M1UStV9wdVDYs0M6qwpJHl3PKYxLuki4 fnRbb9U9NI2o6pVG7/tX0u6UtClvqNxmGUcm5ob1a8/+As3JBA/9cTqDzFoKlRFMrvpYFK5n 1P8AknZ+mEADAAA= Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 13:50:56 -0000 --_000_AM5PR0701MB2577772C4FA66A297F541D2C8D1A0AM5PR0701MB2577_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Raju, Unless someone strongly objects, and given that a) 4566bis is nowhere near = to RFC status, b) there are other documents that make use of the new templa= te, without normatively referencing 4566bis, and c) that we have documents = with dependencies on -sdpneg that we want to progress and avoid becoming st= uck in RFC Editor's queue in MISSREF, I still believe that it would be bett= er to make it an informative reference. Cheers, /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 15 mars 2017 18:21 To: Bo Burman ; mmusic (mmusic@ietf.org) Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo, Paul, Since I don't have a strong preference one way or other, I slightly lean to= wards to keeping 4566bis as a normative reference for the mentioned reason = 'use of new template defined by 4566bis'. I assume the impact of this being both must get RFC status simultaneously!? Do you know if 4566bis is close to RFC status? Bo, really appreciate bringing these comments to our attention! Thanks Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Wednesday, March 15, 2017 11:11 AM To: Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, I should probably have remembered also this in my "unaddressed" list below,= but I put a question to the list to change 4566bis from normative to infor= mative reference (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKe= wDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else= answered. What is the author's view on this? /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 22:57 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo, > It was a bit unclear if it was some kind of quote from somewhere, which i= s also commonly indicated by such indentation. I suggest just making it exp= licit that it is a note, starting the first line >with "Note: ". Will do. Thanks. BR Raju From: Bo Burman [mailto:bo.burman@ericsson.com] Sent: Monday, March 13, 2017 6:30 AM To: Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Raju, Regarding: 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? It was a bit unclear if it was some kind of quote from somewhere, which is = also commonly indicated by such indentation. I suggest just making it expli= cit that it is a note, starting the first line with "Note: ". /Bo From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] Sent: den 13 mars 2017 02:52 To: Bo Burman >; mmus= ic (mmusic@ietf.org) > Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-chan= nel-sdpneg-11 Hi Bo Burman, Christian Groves, Paul Kyzivat, Thank you so much for your time in making this document better, we apprecia= te it. Sorry for the extended delay. I accepted all the comments. Please see my comments inserted below. Thanks again Raju From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman Sent: Tuesday, February 28, 2017 10:11 AM To: mmusic (mmusic@ietf.org) > Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-channel-= sdpneg-11 Authors, WG, I think this document is getting ready for publication request. As part of = making the shepherd's write-up, I have the following comments, to be addres= sed in an updated document: Issues: 1) In section 1: add that also BFCP (Binary Floor Control Protocol) i= s used in the same way as MSRP in examples. [Raju] Will add BFCP. 2) In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infinite length of t= his identifier, which seems inappropriate. I suggest providing a maximum le= ngth, maybe matching this to the unsigned 16 bit integer in SCTP (RFC 4960)= , in which case 1*5DIGIT should be sufficient. [Raju] Will change as suggested. 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing "x" af= ter "%" when defining hex characters. Change to: quoted-visible =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or % [Raju] Will change as suggested. 4) In 5.1.2.1, text below the example makes reference to MSRP subproto= col, but the example does not explicitly include any MSRP. The single examp= le line uses "accept-types", which is admittedly related to MSRP, but I thi= nk this should be clarified to avoid confusion for readers not familiar wit= h MSRP. [Raju] Will change "Example" to "Example (other MSRP related SDP attributes= are omitted for brevity):" 5) In 5.2.2: It is unclear why you differentiate handling of offers an= d answers that contain both "max-retr" and "max-time", mandating to reject = the offer but allowing it in the answer. I think allowing this asymmetry sh= ould either be motivated, or handling should be aligned between offer and a= nswer. [Raju] I think it was thought giving a bit of flexibility to offerer while = receiving answer is probably good but I see your point on aligning both. Wi= ll change text to align both. 6) In section 6: several examples uses IP addresses that are not align= ed with RFC 6890 (10.10.10.x), which must be changed. Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3). [Raju] Will change as suggested. 7) In Appendix A: same IP address issue as above, change from 79.97.21= 5.79 to an address in the allowed range. [Raju] Will change as suggested. Nits: 1) The date line in the document header is one character too long (bey= ond column 72) [Raju] Good catch! Hmmm... not sure how it is getting messed up as the it i= s supposed to be an auto generated line. Anyway, I just checked the new upd= ated draft at https://xml2rfc.tools.ietf.org and output looks good. 2) In section 1: s/In future data channels could/In the future, data c= hannels could/ [Raju] Will change as suggested. 3) In section 3: s/sending and receive data/sending and receiving data= / [Raju] Will change as suggested. 4) At the very end of section 5.1.2.1: s/in the same document, which r= egisters/in the same document that registers/ [Raju] Will change as suggested. 5) In 5.2.4: s/other data channels which are now not included/other da= ta channels that are now not included/ [Raju] Will change as suggested. 6) In 5.2.5: s/channels are expected be closed now/channels are expect= ed to be closed now/ [Raju] Will change as suggested. 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only SHA= LL use/ [Raju] Will change as suggested. 8) In Appendix A.1: s/either pass to the data channel stack the stream= identifier to assign/either pass the stream identifier to the data channel= stack to assign/ [Raju] Will change as suggested. 9) In Appendix A.1: Why are two paragraphs starting with "For data cha= nnels negotiated" indented compared to other text? Is it supposed to be som= e kind of note? [Raju] Yes, meant to be a note. Need to change indentation? Or change to so= me other style? Comments from others that are not addressed in -11: 1) Christian Groves commented on Jan 20 that the example in Appendix A= should contain an "a=3Ddtls-id:..." attribute as per other examples in the= draft. [Raju] Will add a=3Ddtls-id. 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 sho= uld be changed to: o For accepted data channels, the agent MUST create peer instances for the data channels using the SCTP stream identifiers and channel parameters contained in the SDP offer. [Raju] Will change as suggested. Thanks raju Cheers, /Bo MMUSIC co-chair --_000_AM5PR0701MB2577772C4FA66A297F541D2C8D1A0AM5PR0701MB2577_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Raju,

 

Unless someone strongly objects, and given that a) 4= 566bis is nowhere near to RFC status, b) there are other documents that mak= e use of the new template, without normatively referencing 4566bis, and c) = that we have documents with dependencies on -sdpneg that we want to progress and avoid becoming stuck in RFC Editor= ’s queue in MISSREF, I still believe that it would be better to make = it an informative reference.

 

Cheers,

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raj= u.makaraju@nokia.com]
Sent: den 15 mars 2017 18:21
To: Bo Burman <bo.burman@ericsson.com>; mmusic (mmusic@ietf.or= g) <mmusic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo, Paul,

Since I don’t have a strong preference one way= or other, I slightly lean towards to keeping 4566bis as a normative refere= nce for the mentioned reason ‘use of new template defined by 4566bis&= #8217;.

I assume the impact of this being both must get RFC = status simultaneously!?

Do you know if 4566bis is close to RFC status?<= /o:p>

 

Bo, really appreciate bringing these comments to our= attention!

 

Thanks

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.com]
Sent: Wednesday, March 15, 2017 11:11 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmusic (mmusic@ietf.org) <mmu= sic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

I should probably have remembered also this in my &#= 8220;unaddressed” list below, but I put a question to the list to cha= nge 4566bis from normative to informative reference (https://mail= archive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), which seemed acceptable to Paul K, but so far no one else answered. What i= s the author’s view on this?

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 22:57
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo,

> It was a bit unclear if it was some kind of quo= te from somewhere, which is also commonly indicated by such indentation. I = suggest just making it explicit that it is a note, starting the first line

>with “Note: ”.

 

Will do. Thanks.

 

BR

Raju

 

From: Bo Burman [mailto:bo.burman@ericsson.com]
Sent: Monday, March 13, 2017 6:30 AM
To: Makaraju, Raju (Nokia - US) <raju.makaraju@nokia.com>; mmusic (mmusic@ietf.org) <mmu= sic@ietf.org>
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Raju,

 

Regarding:

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

It was a bit unclear if it was some kind of quote fr= om somewhere, which is also commonly indicated by such indentation. I sugge= st just making it explicit that it is a note, starting the first line with = “Note: ”.

 

/Bo

 

From: Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com]
Sent: den 13 mars 2017 02:52
To: Bo Burman <bo.burma= n@ericsson.com>; mmusic (mmusic@i= etf.org) <mmusic@ietf.org>=
Subject: RE: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-da= ta-channel-sdpneg-11

 

Hi Bo Burman, Christian Groves, Paul Kyzivat,

 

Thank you so much for your time in making this docum= ent better, we appreciate it. Sorry for the extended delay.

I accepted all the comments.

Please see my comments inserted below.

 

Thanks again

Raju

 

 

From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Bo Burman
Sent: Tuesday, February 28, 2017 10:11 AM
To: mmusic (mmusic@ietf.org) = <mmusic@ietf.org>
Subject: [ALU] [MMUSIC] Shepherd's review ofdraft-ietf-mmusic-data-c= hannel-sdpneg-11

 

Authors, WG,

 

I think this document is getting ready for publicati= on request. As part of making the shepherd’s write-up, I have the fol= lowing comments, to be addressed in an updated document:

 

Issues:

1)      In section 1: add that also BFCP (Binary Floor Cont= rol Protocol)  is used in the same way as MSRP in examples.=

[Raju] Will add BFCP.

2)      In 5.1.1.1, dcmap-stream-id =3D 1*DIGIT allows infi= nite length of this identifier, which seems inappropriate. I suggest provid= ing a maximum length, maybe matching this to the unsigned 16 bit integer in= SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient.

[Raju] Will change as suggested.<= /o:p>

3)      In 5.1.1.1, quoted-visible ABNF syntax is incorrect= , missing “x” after “%” when defining hex character= s. Change to:
quoted-visible  =3D %x21 / %x23-24 / %x26-7E ; VCHAR without " or= %

[Raju] Will change as suggested.<= /o:p>

4)      In 5.1.2.1, text below the example makes reference = to MSRP subprotocol, but the example does not explicitly include any MSRP. = The single example line uses “accept-types”, which is admittedl= y related to MSRP, but I think this should be clarified to avoid confusion for readers not familiar with MSRP.

[Raju] Will change “Example” to &#= 8220;Example (other MSRP related SDP attributes are omitted for brevity):&#= 8221;

5)      In 5.2.2: It is unclear why you differentiate handl= ing of offers and answers that contain both “max-retr” and R= 20;max-time”, mandating to reject the offer but allowing it in the an= swer. I think allowing this asymmetry should either be motivated, or handling should be aligned between offer and answer.

[Raju] I think it was thought giving a bit of = flexibility to offerer while receiving answer is probably good but I see yo= ur point on aligning both. Will change text to align both.

6)      In section 6: several examples uses IP addresses th= at are not aligned with RFC 6890 (10.10.10.x), which must be changed.
Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2),= or 203.0.113.0/24 (TEST-NET-3).

[Raju] Will change as suggested. =

7)      In Appendix A: same IP address issue as above, chan= ge from 79.97.215.79 to an address in the allowed range.

[Raju] Will change as suggested. =

 

Nits:

1)      The date line in the document header is one charact= er too long (beyond column 72)

[Raju] Good catch! Hmmm… not sure how it= is getting messed up as the it is supposed to be an auto generated line. A= nyway, I just checked the new updated draft at https://xml2rfc.tools.ie= tf.org and output looks good.

2)      In section 1: s/In future data channels could/In th= e future, data channels could/

[Raju] Will change as suggested. =

3)      In section 3: s/sending and receive data/sending an= d receiving data/

[Raju] Will change as suggested. =

4)      At the very end of section 5.1.2.1: s/in the same d= ocument, which registers/in the same document that registers/

[Raju] Will change as suggested. =

5)      In 5.2.4: s/other data channels which are now not i= ncluded/other data channels that are now not included/

[Raju] Will change as suggested.<= /o:p>

6)      In 5.2.5: s/channels are expected be closed now/cha= nnels are expected to be closed now/

[Raju] Will change as suggested.<= /o:p>

7)      In 8.3: s/dcsa usage level only shall use/dcsa usag= e level only SHALL use/

[Raju] Will change as suggested.<= /o:p>

8)      In Appendix A.1: s/either pass to the data channel = stack the stream identifier to assign/either pass the stream identifier to = the data channel stack to assign/

[Raju] Will change as suggested.<= /o:p>

9)      In Appendix A.1: Why are two paragraphs starting wi= th “For data channels negotiated” indented compared to other te= xt? Is it supposed to be some kind of note?

[Raju] Yes, meant to be a note. Need to change= indentation? Or change to some other style?

 

Comments from others that are not addressed in -11:<= o:p>

1)      Christian Groves commented on Jan 20 that the examp= le in Appendix A should contain an “a=3Ddtls-id:…” attrib= ute as per other examples in the draft.

[Raju] Will add a= =3Ddtls-id.

2)      Paul Kyzivat commented on Jan 21 that a bullet in s= ection 5.2.3 should be changed to:
o For accepted data channels, the agent MUST create peer instances
   for the data channels using the SCTP stream identifiers and    channel parameters contained in the SDP offer.=

[Raju] Will change as suggested.

 

Thanks

raju

 

Cheers,

/Bo

MMUSIC co-chair

 

--_000_AM5PR0701MB2577772C4FA66A297F541D2C8D1A0AM5PR0701MB2577_-- From nobody Fri Apr 21 08:21:56 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B706129535 for ; Fri, 21 Apr 2017 08:21:54 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 99rLRGGcvQFu for ; Fri, 21 Apr 2017 08:21:52 -0700 (PDT) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (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 9376B129516 for ; Fri, 21 Apr 2017 08:21:40 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-11v.sys.comcast.net with SMTP id 1aMadlzXXT4XX1aNPdQHHr; Fri, 21 Apr 2017 15:21:39 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1492788099; bh=s1fnIfmxHHElB3qmv0Yp18CwHvDwXKj4kBkR9Zfu5Dc=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fDjm5CHYUWUqR6V7L2a8FHYrpNC7x3UzjTUWRQ5m6qHdeEmjcQBZDfWjLwcXJmows yJSG1+nLQ5R+QkZBVxGC8bFX2kQqRLbKRsRVh2JMHHYm7ilK/HJ1YkaEzrP6tfDeZN AGnWrf2Q3eMX2mytQlnZs2FcefTfXGn13KzgmO0flo5bW2p+bq6zjgq8hz3+ZMKYy3 Akjg9oFcZX6Uxlo16fTtO/WGqsM2xWrcCfF41FcB6YZBixTK9a/BoDXhpkSoXkNWhu P3gvMCjQqWJHwL4PdcDIvS94aiMcnnCSlDURpzwDCcRukhMX+7ebXYuL9hFPQmAg5F oIw9HzHTj+DNA== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-02v.sys.comcast.net with SMTP id 1aNOdvjD5gFBH1aNOdMkPY; Fri, 21 Apr 2017 15:21:39 +0000 To: mmusic@ietf.org, "mmusic-chairs@tools.ietf.org" References: From: Paul Kyzivat Message-ID: <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> Date: Fri, 21 Apr 2017 11:21:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfHOJ+0P1Yqw5nExEE+L6IhYGPhPMFeislos2kjHbj72HdRBDp6pgvC50XERJMYMrUYgUjeJY2BYfTyeE5J4iHR4Qu3Fh/WgKfKitF9obq4IoQJVohT+Q ejY+pZMd5hewQKDqrnTXHHgWtjmMuDH0sKBkOkuOZgtSH2XU/p+8/pQ235WeNgEdxiJkZrVgiMelAdHOGkWvkFWqPAazXaraQjU= Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 15:21:54 -0000 On 4/21/17 9:50 AM, Bo Burman wrote: > Hi Raju, > > Unless someone strongly objects, and given that a) 4566bis is nowhere > near to RFC status, b) there are other documents that make use of the > new template, without normatively referencing 4566bis, and c) that we > have documents with dependencies on -sdpneg that we want to progress and > avoid becoming stuck in RFC Editor’s queue in MISSREF, I still believe > that it would be better to make it an informative reference. I don't see a need for a normative reference to 4566bis. OTOH, AFAIK there is nothing to prevent 4566bis from going to WGLC *today*. It just needs for the motion to be made. I'm interested to hear about this from the chairs. Thanks, Paul > Cheers, > > /Bo > > > > *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > *Sent:* den 15 mars 2017 18:21 > *To:* Bo Burman ; mmusic (mmusic@ietf.org) > > *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Hi Bo, Paul, > > Since I don’t have a strong preference one way or other, I slightly lean > towards to keeping 4566bis as a normative reference for the mentioned > reason ‘use of new template defined by 4566bis’. > > I assume the impact of this being both must get RFC status simultaneously!? > > Do you know if 4566bis is close to RFC status? > > > > Bo, really appreciate bringing these comments to our attention! > > > > Thanks > > Raju > > > > *From:* Bo Burman [mailto:bo.burman@ericsson.com] > *Sent:* Wednesday, March 15, 2017 11:11 AM > *To:* Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org > ) > > *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Hi Raju, > > > > I should probably have remembered also this in my “unaddressed” list > below, but I put a question to the list to change 4566bis from normative > to informative reference > (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), > which seemed acceptable to Paul K, but so far no one else answered. What > is the author’s view on this? > > > > /Bo > > > > *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > *Sent:* den 13 mars 2017 22:57 > *To:* Bo Burman >; mmusic (mmusic@ietf.org > ) > > *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Hi Bo, > >> It was a bit unclear if it was some kind of quote from somewhere, > which is also commonly indicated by such indentation. I suggest just > making it explicit that it is a note, starting the first line > >>with “Note: ”. > > > > Will do. Thanks. > > > > BR > > Raju > > > > *From:* Bo Burman [mailto:bo.burman@ericsson.com] > *Sent:* Monday, March 13, 2017 6:30 AM > *To:* Makaraju, Raju (Nokia - US) >; mmusic (mmusic@ietf.org > ) > > *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Hi Raju, > > > > Regarding: > > 9) In Appendix A.1: Why are two paragraphs starting with “For data > channels negotiated” indented compared to other text? Is it supposed to > be some kind of note? > > */[Raju] Yes, meant to be a note. Need to change indentation? Or change > to some other style?/* > > > > It was a bit unclear if it was some kind of quote from somewhere, which > is also commonly indicated by such indentation. I suggest just making it > explicit that it is a note, starting the first line with “Note: ”. > > > > /Bo > > > > *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] > *Sent:* den 13 mars 2017 02:52 > *To:* Bo Burman >; mmusic (mmusic@ietf.org > ) > > *Subject:* RE: [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Hi Bo Burman, Christian Groves, Paul Kyzivat, > > > > Thank you so much for your time in making this document better, we > appreciate it. Sorry for the extended delay. > > I accepted all the comments. > > Please see my comments inserted below. > > > > Thanks again > > Raju > > > > > > *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman > *Sent:* Tuesday, February 28, 2017 10:11 AM > *To:* mmusic (mmusic@ietf.org ) > > *Subject:* [ALU] [MMUSIC] Shepherd's review > ofdraft-ietf-mmusic-data-channel-sdpneg-11 > > > > Authors, WG, > > > > I think this document is getting ready for publication request. As part > of making the shepherd’s write-up, I have the following comments, to be > addressed in an updated document: > > > > Issues: > > 1) In section 1: add that also BFCP (Binary Floor Control > Protocol) is used in the same way as MSRP in examples. > > */[Raju] Will add BFCP./* > > 2) In 5.1.1.1, dcmap-stream-id = 1*DIGIT allows infinite length of > this identifier, which seems inappropriate. I suggest providing a > maximum length, maybe matching this to the unsigned 16 bit integer in > SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient. > > */[Raju] Will change as suggested./* > > 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing “x” > after “%” when defining hex characters. Change to: > quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % > > */[Raju] Will change as suggested./* > > 4) In 5.1.2.1, text below the example makes reference to MSRP > subprotocol, but the example does not explicitly include any MSRP. The > single example line uses “accept-types”, which is admittedly related to > MSRP, but I think this should be clarified to avoid confusion for > readers not familiar with MSRP. > > */[Raju] Will change “Example” to “Example (other MSRP related SDP > attributes are omitted for brevity):”/* > > 5) In 5.2.2: It is unclear why you differentiate handling of offers > and answers that contain both “max-retr” and “max-time”, mandating to > reject the offer but allowing it in the answer. I think allowing this > asymmetry should either be motivated, or handling should be aligned > between offer and answer. > > */[Raju] I think it was thought giving a bit of flexibility to offerer > while receiving answer is probably good but I see your point on aligning > both. Will change text to align both./* > > 6) In section 6: several examples uses IP addresses that are not > aligned with RFC 6890 (10.10.10.x), which must be changed. > Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 > (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3). > > */[Raju] Will change as suggested. /* > > 7) In Appendix A: same IP address issue as above, change from > 79.97.215.79 to an address in the allowed range. > > */[Raju] Will change as suggested. /* > > > > Nits: > > 1) The date line in the document header is one character too long > (beyond column 72) > > */[Raju] Good catch! Hmmm… not sure how it is getting messed up as the > it is supposed to be an auto generated line. Anyway, I just checked the > new updated draft at /*https://xml2rfc.tools.ietf.org*/and output looks > good./* > > 2) In section 1: s/In future data channels could/In the future, > data channels could/ > > */[Raju] Will change as suggested. /* > > 3) In section 3: s/sending and receive data/sending and receiving data/ > > */[Raju] Will change as suggested. /* > > 4) At the very end of section 5.1.2.1: s/in the same document, > which registers/in the same document that registers/ > > */[Raju] Will change as suggested. /* > > 5) In 5.2.4: s/other data channels which are now not included/other > data channels that are now not included/ > > */[Raju] Will change as suggested./* > > 6) In 5.2.5: s/channels are expected be closed now/channels are > expected to be closed now/ > > */[Raju] Will change as suggested./* > > 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only > SHALL use/ > > */[Raju] Will change as suggested./* > > 8) In Appendix A.1: s/either pass to the data channel stack the > stream identifier to assign/either pass the stream identifier to the > data channel stack to assign/ > > */[Raju] Will change as suggested./* > > 9) In Appendix A.1: Why are two paragraphs starting with “For data > channels negotiated” indented compared to other text? Is it supposed to > be some kind of note? > > */[Raju] Yes, meant to be a note. Need to change indentation? Or change > to some other style?/* > > > > Comments from others that are not addressed in -11: > > 1) Christian Groves commented on Jan 20 that the example in > Appendix A should contain an “a=dtls-id:…” attribute as per other > examples in the draft. > > */[Raju] Will add a=dtls-id./* > > 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 > should be changed to: > o For accepted data channels, the agent MUST create peer instances > for the data channels using the SCTP stream identifiers and > channel parameters contained in the SDP offer. > > */[Raju] Will change as suggested./* > > */ /* > > */Thanks/* > > */raju/* > > > > Cheers, > > /Bo > > MMUSIC co-chair > > > > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > From nobody Fri Apr 21 10:31:28 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21CEB129ADA for ; Fri, 21 Apr 2017 10:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 PxKeTAZmUCXK for ; Fri, 21 Apr 2017 10:31:25 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 1AC56129A98 for ; Fri, 21 Apr 2017 10:31:25 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id r190so22706498wme.1 for ; Fri, 21 Apr 2017 10:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OWkZlwtVGdKzp/cPb6RfpdtVkg6I2/UUy+Mo3ZAgCkw=; b=ntovGs/BxPjV+v+T5ahsxXugkIvUhmUU04aJ60s6Xi8XVx2jyRoLfjSrP5wvW7w8HY 3Rg8klHBEIMDqHzjmzhCOeZly5OF1hl0hD1bqYAPFA5ckMno+tjAaNO+NUXSU/GlMZCX dv7VnDZnzsoXeX0Q6DTXx41BFvT4bWFiiF7jjIyhEkH7v2k5EUrG11U6boX0i4BRGVHq PDIM+eTardCWbBRqnblHTH3aH5iu7YTrrD9tJth410MQ4ONqf2v1vYNFPZzgLNOvTV0W W+8WaxSi6MdChAltU0DbydC6qqN31oqJWdhzXFJB6TLWNnn67VtLG2sVcFXdntIfDM9S GqQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OWkZlwtVGdKzp/cPb6RfpdtVkg6I2/UUy+Mo3ZAgCkw=; b=VCm0tVBJ6AEvdKQxQROUxcDEmBTDKEealLVjbWj9YK1IyHIWGoaW11VFD4D/RfxWpD s/2B69fZ2S/ofyR2bMKMMNzHcx2XY3Yu8RYnxaj9zAN5iwETB81bkIQeG5VYS1h/gKLQ 1QQmloWnjQhdoFOPf3LF1bEm+pE2gaTE9yr2SR4A4kjjYpGCFje/JIN8jUZlBoSqU3iZ Ssnos5IGa8irKdcfxM8o8jHEsWQdJ9NgPXz6YL2Y2a61TRT7+FgSKWKD04gvZRNjKxwL ED4rmQ0G8VijCIwwjePSwMlT8lCpeelEP6x8DmN4FeAOk32gYAMEUzrEscEy0Lb7dAtV Ztdw== X-Gm-Message-State: AN3rC/59tja3+VzzVAiTEWDWr8bSvRjN3r3zZSEziJaIJknryFnFQ4wp ULflEKAUI0OiRUBKZ6cAQXMwKtB25Q== X-Received: by 10.28.176.5 with SMTP id z5mr9434409wme.3.1492795883633; Fri, 21 Apr 2017 10:31:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.163.244 with HTTP; Fri, 21 Apr 2017 10:31:03 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Apr 2017 19:31:03 +0200 Message-ID: To: Martin Thomson Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:31:27 -0000 2017-04-20 12:52 GMT+02:00 Martin Thomson : > > https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks > > Inspired by Christer updating the dtls-sdp draft, I have updated the > SDP UKS draft to match the recent changes (thanks Christer!). > > I found a few minor errors while editing this. I'd appreciate it if > people can take a look and see if it is ready. I'm biased, but I > think that it's in reasonable shape. In section 2: By substituting the the fingerprint (double "the"). Also in section 2: In usages of TLS and DTLS that use SDP for negotiation, an endpoint is able to acquire the certificate fingerprint another entity. (*of* another entity). --=20 I=C3=B1aki Baz Castillo From nobody Fri Apr 21 10:44:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF6012EAAC for ; Fri, 21 Apr 2017 10:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 C8kIu7kS8hV5 for ; Fri, 21 Apr 2017 10:44:51 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (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 E058E129B55 for ; Fri, 21 Apr 2017 10:44:50 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id j201so105051424oih.2 for ; Fri, 21 Apr 2017 10:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yzcGh5UW9mFx3cY/+5FwdTikCtyouIMpG9LzXy0h5TI=; b=FVA9GXId11q0+HZ0hfbj6SdtyoMIB5XdZdFQhEJHsyUNsIY1/+LSu0kig5p+Tuxbhy 642fToQ7xv1V6ef7bCHFlh9bJiJP3tunwI3XRMdEk4Bi/EONlr38bLMGL71ZUYoVUvoI TneM+IMSAHiWHy+pgQTvLYE3Xq8x3ysuH9ExXz56RYJap6dXi1qn6pDzGVDstH2twklo wWMnG4uBhznTHsQn0V8+i2s2GbPQFkLqYXrNJ8Lqk+OnSq34ub32jnDQ6kJ8oSrBrlCS F+o6j3hM4eJSJYu5n1vGuETsG9XLYtPKZbRShULqLHFaXEpTNF7cgPRxuA9JCjKYKR1O u//w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yzcGh5UW9mFx3cY/+5FwdTikCtyouIMpG9LzXy0h5TI=; b=KqvgLo9mMNB5HHOh2LjsiJUCLCKbvpR0iNrzM83cr6dZiuI4Wf1Fd6t5VZOKa5CYzr f2c6Ln+40GJQEVqE9Oro4QYVxd8XWxIkgtX197oS1Q1UjpGmQrQkUZEoO05ZkRqbI6gA sPA/6SZnTdW/h+pg1F39xO/JWKbnw+WvdHtRAw/b9eZF6RUTS2uTzFDa1c+0d6EgBVZU eyGWyBKvXdumCmKhyYLcJlbUslF0lNp7N8o8YgCkulIXhVVrE9MOluuzJyfAcUM8un1g YW11awL6U0VohKa3PQLbR3yZrWYzSq3I6QhQPB1KRm69kxBx6iM75C41F18mC2UuixhL uEYw== X-Gm-Message-State: AN3rC/7Ct1N45aQPSA+5JUb7tl3sVgmM2x44IzQ++QAUMJn0wodn3IXM HrT83ieDcA5+DfQd X-Received: by 10.202.62.4 with SMTP id l4mr8021145oia.50.1492796690022; Fri, 21 Apr 2017 10:44:50 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com. [209.85.218.54]) by smtp.gmail.com with ESMTPSA id q35sm1082595otg.7.2017.04.21.10.44.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 21 Apr 2017 10:44:49 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id j201so105050750oih.2 for ; Fri, 21 Apr 2017 10:44:49 -0700 (PDT) X-Received: by 10.98.252.72 with SMTP id e69mr13344747pfh.247.1492796689270; Fri, 21 Apr 2017 10:44:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Fri, 21 Apr 2017 10:44:48 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Fri, 21 Apr 2017 13:44:48 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a1141f7dc62d11d054db0d0ea Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:44:53 -0000 --001a1141f7dc62d11d054db0d0ea Content-Type: text/plain; charset=UTF-8 I have already mentioned that I prefer not to call this extension sdp_tls_id. Since this extension applies to Jingle and ORTC, this extension is not SDP specific. It should be called simply tls_id or tls_helo_id. Regards, _____________ Roman Shpount On Thu, Apr 20, 2017 at 6:52 AM, Martin Thomson wrote: > https://datatracker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks > > Inspired by Christer updating the dtls-sdp draft, I have updated the > SDP UKS draft to match the recent changes (thanks Christer!). > > I found a few minor errors while editing this. I'd appreciate it if > people can take a look and see if it is ready. I'm biased, but I > think that it's in reasonable shape. > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --001a1141f7dc62d11d054db0d0ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have already mentioned that I prefer not to call this ex= tension sdp_tls_id. Since this extension applies to Jingle and ORTC, this e= xtension is not SDP specific. It should be called simply tls_id or tls_helo= _id.

Regards,
=
_____________
Roman Shpount

On Thu, Apr 20, 2017 at 6:52 AM, Martin Thom= son <martin.thomson@gmail.com> wrote:
https://datatra= cker.ietf.org/doc/html/draft-thomson-mmusic-sdp-uks

Inspired by Christer updating the dtls-sdp draft, I have updated the
SDP UKS draft to match the recent changes (thanks Christer!).

I found a few minor errors while editing this.=C2=A0 I'd appreciate it = if
people can take a look and see if it is ready.=C2=A0 I'm biased, but I<= br> think that it's in reasonable shape.

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

--001a1141f7dc62d11d054db0d0ea-- From nobody Fri Apr 21 10:46:39 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B63129B1B for ; Fri, 21 Apr 2017 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.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 Dyy9qyIvPWwL for ; Fri, 21 Apr 2017 10:46:29 -0700 (PDT) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 20D9312422F for ; Fri, 21 Apr 2017 10:46:29 -0700 (PDT) Received: by mail-wm0-x233.google.com with SMTP id w64so21256996wma.0 for ; Fri, 21 Apr 2017 10:46:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MiSWXITmOgBJn2xiUF5k3VcOUhNUWep65ec/f3QB97A=; b=NAua6t+9fhdHHm6JU7Mk4KkNAbxjaObjBjboxtDhvCIxadGuUkKO7XHx80fr9o7JSi KpQXTh0S7W+1sQ3kpsIx9GPMsMiVa2vgpKDfRY8mdqVjJeqTppW0Z1fP7ihduXdPsUCG h2htRJwVm43W90BCy4QYYRCB7LnCjR/LkXqhhSgDJjmd7JyalWL2LWNS+c5/ZuXhJXy6 eItH3FL8GkrHIMC8n21Nrzx7ovi5b6ruaNG4ixyRtH6cWnWYFJqCSmEnl7yI9oFoo1FJ VF0hYdFPFCw77HQvED49fHe622fgn2V2QGkCqo0XFeZQ93rprQa74nQPkXHcC03WE68K IJKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MiSWXITmOgBJn2xiUF5k3VcOUhNUWep65ec/f3QB97A=; b=jqFcSCasdJdvOJUNhPfbDonwsTrnsFgf3kNvYM4gqkuBQlb9FJ2f1Ufx+uuvSl2sMD c9JwvnVJm6Z3HzXcIz1W/3ns+st32BAUpdzQhOmrosDGKz0093tHCUjpvzNh4ZYFv8y4 hp5oPUDOoQkFME4+n6+NSfdEWFJFxXpypNPJFuVNFZ8kQvqLE6HjFR2CUW4qDmJFyHG3 jWSxE+eR+Phnt1v7gkoXz/UzyoI88Ssqc69w3EwviMNZXle23QGR/D9JKZzsIlhj82UI g1G7hSd4NPYuKi7QN+QAGLwVhRLMlrRh2nXZeSgqa1t0/IjjnipqZxw01zvCLR5JyS6R cW0w== X-Gm-Message-State: AN3rC/5kg/JqpP+Iax5hQ9xeO4PQtVCoV6FPz7xFfOgYqhAk8eMX4sO8 9IAN5sH0VtQXGGUByniJwvIUnqm/Ow== X-Received: by 10.80.162.38 with SMTP id 35mr63744edl.99.1492796787679; Fri, 21 Apr 2017 10:46:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.163.244 with HTTP; Fri, 21 Apr 2017 10:46:07 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 21 Apr 2017 19:46:07 +0200 Message-ID: To: Roman Shpount Cc: Martin Thomson , "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 17:46:38 -0000 2017-04-21 19:44 GMT+02:00 Roman Shpount : > I have already mentioned that I prefer not to call this extension > sdp_tls_id. Since this extension applies to Jingle and ORTC, this extensi= on > is not SDP specific. It should be called simply tls_id or tls_helo_id. Agreed. --=20 I=C3=B1aki Baz Castillo From nobody Fri Apr 21 11:21:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C0F128DE7 for ; Fri, 21 Apr 2017 11:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.522 X-Spam-Level: X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmxMFPqkXVKE for ; Fri, 21 Apr 2017 11:20:57 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D639812EAAF for ; Fri, 21 Apr 2017 11:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10815; q=dns/txt; s=iport; t=1492798856; x=1494008456; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=5ME7PQWOJWSYx/rtwau7E7QqkkGhgfMa7kAJUh2pb8Y=; b=WsfTxnCxxVHy5R/zhosjB/vNQY9htzyxqbSdMEtRIeaTy535EqciyWz5 J/OW3XNsOlAuERy8FgnpmEOU83R3R8V3PE59ficXgiEVRSrR/K/9UqhEF WdJrGHI4kTbUtz5Ibg0jLNhTMywLc9fIp59IH6br15+i9RHoYO7CMD4QM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D9AABwTPpY/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBg1RhgQyNfJFHIZVkgg8hDYUsSgKECz8YAQIBAQEBAQEBayiFFQE?= =?us-ascii?q?BAQEDAQEKJgEFNhsLEQQBAQEnBycfCQgGAQwGAgEBigsNDqwViyEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEYBYZTgV0rC4JjijwBBIcGljuHF4ZbhRSCAIUzg0KGYpQ?= =?us-ascii?q?ZHziBBkMgFUSHBCQ1AYk1AQEB?= X-IronPort-AV: E=Sophos;i="5.37,230,1488844800"; d="scan'208";a="239476435" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Apr 2017 18:20:55 +0000 Received: from [10.98.149.205] (bxb-fandreas-88112.cisco.com [10.98.149.205]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v3LIKsMH009585; Fri, 21 Apr 2017 18:20:54 GMT To: Paul Kyzivat , mmusic@ietf.org, "mmusic-chairs@tools.ietf.org" References: <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> From: Flemming Andreasen Message-ID: Date: Fri, 21 Apr 2017 14:20:54 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 18:21:00 -0000 Hi Paul From a chair point of view, we are prioritizing the deliverables that have external dependencies, and we still have several of those for RTCWeb. 4566bis may or may not be ready to advance at this point, however we prefer to focus the group on the RTCWeb deliverables for now. Cheers -- Flemming (as MMUSIC co-chair) On 4/21/17 11:21 AM, Paul Kyzivat wrote: > On 4/21/17 9:50 AM, Bo Burman wrote: >> Hi Raju, >> >> Unless someone strongly objects, and given that a) 4566bis is nowhere >> near to RFC status, b) there are other documents that make use of the >> new template, without normatively referencing 4566bis, and c) that we >> have documents with dependencies on -sdpneg that we want to progress and >> avoid becoming stuck in RFC Editor’s queue in MISSREF, I still believe >> that it would be better to make it an informative reference. > > I don't see a need for a normative reference to 4566bis. > > OTOH, AFAIK there is nothing to prevent 4566bis from going to WGLC > *today*. It just needs for the motion to be made. I'm interested to > hear about this from the chairs. > > Thanks, > Paul > >> Cheers, >> >> /Bo >> >> >> >> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >> *Sent:* den 15 mars 2017 18:21 >> *To:* Bo Burman ; mmusic (mmusic@ietf.org) >> >> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Hi Bo, Paul, >> >> Since I don’t have a strong preference one way or other, I slightly lean >> towards to keeping 4566bis as a normative reference for the mentioned >> reason ‘use of new template defined by 4566bis’. >> >> I assume the impact of this being both must get RFC status >> simultaneously!? >> >> Do you know if 4566bis is close to RFC status? >> >> >> >> Bo, really appreciate bringing these comments to our attention! >> >> >> >> Thanks >> >> Raju >> >> >> >> *From:* Bo Burman [mailto:bo.burman@ericsson.com] >> *Sent:* Wednesday, March 15, 2017 11:11 AM >> *To:* Makaraju, Raju (Nokia - US) > >; mmusic (mmusic@ietf.org >> ) > >> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Hi Raju, >> >> >> >> I should probably have remembered also this in my “unaddressed” list >> below, but I put a question to the list to change 4566bis from normative >> to informative reference >> (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), >> >> which seemed acceptable to Paul K, but so far no one else answered. What >> is the author’s view on this? >> >> >> >> /Bo >> >> >> >> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >> *Sent:* den 13 mars 2017 22:57 >> *To:* Bo Burman > >; mmusic (mmusic@ietf.org >> ) > >> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Hi Bo, >> >>> It was a bit unclear if it was some kind of quote from somewhere, >> which is also commonly indicated by such indentation. I suggest just >> making it explicit that it is a note, starting the first line >> >>> with “Note: ”. >> >> >> >> Will do. Thanks. >> >> >> >> BR >> >> Raju >> >> >> >> *From:* Bo Burman [mailto:bo.burman@ericsson.com] >> *Sent:* Monday, March 13, 2017 6:30 AM >> *To:* Makaraju, Raju (Nokia - US) > >; mmusic (mmusic@ietf.org >> ) > >> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Hi Raju, >> >> >> >> Regarding: >> >> 9) In Appendix A.1: Why are two paragraphs starting with “For data >> channels negotiated” indented compared to other text? Is it supposed to >> be some kind of note? >> >> */[Raju] Yes, meant to be a note. Need to change indentation? Or change >> to some other style?/* >> >> >> >> It was a bit unclear if it was some kind of quote from somewhere, which >> is also commonly indicated by such indentation. I suggest just making it >> explicit that it is a note, starting the first line with “Note: ”. >> >> >> >> /Bo >> >> >> >> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >> *Sent:* den 13 mars 2017 02:52 >> *To:* Bo Burman > >; mmusic (mmusic@ietf.org >> ) > >> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Hi Bo Burman, Christian Groves, Paul Kyzivat, >> >> >> >> Thank you so much for your time in making this document better, we >> appreciate it. Sorry for the extended delay. >> >> I accepted all the comments. >> >> Please see my comments inserted below. >> >> >> >> Thanks again >> >> Raju >> >> >> >> >> >> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman >> *Sent:* Tuesday, February 28, 2017 10:11 AM >> *To:* mmusic (mmusic@ietf.org ) > > >> *Subject:* [ALU] [MMUSIC] Shepherd's review >> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >> >> >> >> Authors, WG, >> >> >> >> I think this document is getting ready for publication request. As part >> of making the shepherd’s write-up, I have the following comments, to be >> addressed in an updated document: >> >> >> >> Issues: >> >> 1) In section 1: add that also BFCP (Binary Floor Control >> Protocol) is used in the same way as MSRP in examples. >> >> */[Raju] Will add BFCP./* >> >> 2) In 5.1.1.1, dcmap-stream-id = 1*DIGIT allows infinite length of >> this identifier, which seems inappropriate. I suggest providing a >> maximum length, maybe matching this to the unsigned 16 bit integer in >> SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient. >> >> */[Raju] Will change as suggested./* >> >> 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing “x” >> after “%” when defining hex characters. Change to: >> quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % >> >> */[Raju] Will change as suggested./* >> >> 4) In 5.1.2.1, text below the example makes reference to MSRP >> subprotocol, but the example does not explicitly include any MSRP. The >> single example line uses “accept-types”, which is admittedly related to >> MSRP, but I think this should be clarified to avoid confusion for >> readers not familiar with MSRP. >> >> */[Raju] Will change “Example” to “Example (other MSRP related SDP >> attributes are omitted for brevity):”/* >> >> 5) In 5.2.2: It is unclear why you differentiate handling of offers >> and answers that contain both “max-retr” and “max-time”, mandating to >> reject the offer but allowing it in the answer. I think allowing this >> asymmetry should either be motivated, or handling should be aligned >> between offer and answer. >> >> */[Raju] I think it was thought giving a bit of flexibility to offerer >> while receiving answer is probably good but I see your point on aligning >> both. Will change text to align both./* >> >> 6) In section 6: several examples uses IP addresses that are not >> aligned with RFC 6890 (10.10.10.x), which must be changed. >> Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 >> (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3). >> >> */[Raju] Will change as suggested. /* >> >> 7) In Appendix A: same IP address issue as above, change from >> 79.97.215.79 to an address in the allowed range. >> >> */[Raju] Will change as suggested. /* >> >> >> >> Nits: >> >> 1) The date line in the document header is one character too long >> (beyond column 72) >> >> */[Raju] Good catch! Hmmm… not sure how it is getting messed up as the >> it is supposed to be an auto generated line. Anyway, I just checked the >> new updated draft at /*https://xml2rfc.tools.ietf.org*/and output looks >> good./* >> >> 2) In section 1: s/In future data channels could/In the future, >> data channels could/ >> >> */[Raju] Will change as suggested. /* >> >> 3) In section 3: s/sending and receive data/sending and >> receiving data/ >> >> */[Raju] Will change as suggested. /* >> >> 4) At the very end of section 5.1.2.1: s/in the same document, >> which registers/in the same document that registers/ >> >> */[Raju] Will change as suggested. /* >> >> 5) In 5.2.4: s/other data channels which are now not included/other >> data channels that are now not included/ >> >> */[Raju] Will change as suggested./* >> >> 6) In 5.2.5: s/channels are expected be closed now/channels are >> expected to be closed now/ >> >> */[Raju] Will change as suggested./* >> >> 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only >> SHALL use/ >> >> */[Raju] Will change as suggested./* >> >> 8) In Appendix A.1: s/either pass to the data channel stack the >> stream identifier to assign/either pass the stream identifier to the >> data channel stack to assign/ >> >> */[Raju] Will change as suggested./* >> >> 9) In Appendix A.1: Why are two paragraphs starting with “For data >> channels negotiated” indented compared to other text? Is it supposed to >> be some kind of note? >> >> */[Raju] Yes, meant to be a note. Need to change indentation? Or change >> to some other style?/* >> >> >> >> Comments from others that are not addressed in -11: >> >> 1) Christian Groves commented on Jan 20 that the example in >> Appendix A should contain an “a=dtls-id:…” attribute as per other >> examples in the draft. >> >> */[Raju] Will add a=dtls-id./* >> >> 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 >> should be changed to: >> o For accepted data channels, the agent MUST create peer instances >> for the data channels using the SCTP stream identifiers and >> channel parameters contained in the SDP offer. >> >> */[Raju] Will change as suggested./* >> >> */ /* >> >> */Thanks/* >> >> */raju/* >> >> >> >> Cheers, >> >> /Bo >> >> MMUSIC co-chair >> >> >> >> >> >> _______________________________________________ >> mmusic mailing list >> mmusic@ietf.org >> https://www.ietf.org/mailman/listinfo/mmusic >> > > . > From nobody Fri Apr 21 12:43:09 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE5B12706D for ; Fri, 21 Apr 2017 12:43:06 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 m0YEQF1kCRp1 for ; Fri, 21 Apr 2017 12:43:03 -0700 (PDT) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 0877712441E for ; Fri, 21 Apr 2017 12:43:02 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-01v.sys.comcast.net with SMTP id 1eS9d5PTwO3Qo1eSKds5cw; Fri, 21 Apr 2017 19:43:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1492803780; bh=meaXYdvkjJWUIX6BA6f1T7gqX2NZ5iw7iFKJDCRZ5Co=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ookVm7OCZnHOabaycwJXMnnstzjnDUny6QJBWvaFzAIqFSosFxiKbtq2r1i9GHSya nCONhEFRwDpLs80TsWzYYbM0b+2B9AMTxsCdJNIjNKpGf0F3tdCq6VKSYc1K1SHk/Z VNV451TWeIVdlzp/7UMN4bp4XfvuL2Ry41NrVRMdyjz25GqXvCr5vt0tb+LtAzjgRg luWwl9G/SxkMSyNgPeGjzPFnqI/xFWeuUYL6at7Df6Z9oLiu7mQEeUOxfo7g3Ns2TO FxuzI5lWGpFnHWXAHTjKi9AcSgbH4kIEwumXfHmh38mMztUKRvqi0/w2Sut+JvTR5d cShmhN60VU7cg== Received: from [192.168.1.110] ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with SMTP id 1eSIdGdejY10N1eSJdig3X; Fri, 21 Apr 2017 19:43:00 +0000 To: Flemming Andreasen , mmusic@ietf.org, "mmusic-chairs@tools.ietf.org" References: <1bebf711-3459-a30f-44d2-e182b6fb132e@comcast.net> From: Paul Kyzivat Message-ID: <34b42aa1-adc0-ea98-a0c3-beec16bcd69e@comcast.net> Date: Fri, 21 Apr 2017 15:42:58 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfAHdVjEbrEcVDW9YCh++3huZCLxGPDusPpgN+M9FCPpJXVsMhYn2K+7aM0Cr27/Nywvqu+glV786lIoRVg27n0cc9isnL+xvDcYPXLZZ78KosHsYQLN8 T8amW7gRDRmYxyftzf+dqcderAUb2KmjyaRc9M8Jzin1Ywp1hYfACCKWn+6WGgdJb/228OYN+9MTTKL/coq0UePTq7g8qJE4Sqs13RjEZ0ZvQFcBfl7lSfaI aU8tfpIaMhjlAnCtYsAcaw== Archived-At: Subject: Re: [MMUSIC] [ALU] Shepherd's review ofdraft-ietf-mmusic-data-channel-sdpneg-11 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Apr 2017 19:43:07 -0000 On 4/21/17 2:20 PM, Flemming Andreasen wrote: > Hi Paul > > From a chair point of view, we are prioritizing the deliverables that > have external dependencies, and we still have several of those for > RTCWeb. 4566bis may or may not be ready to advance at this point, > however we prefer to focus the group on the RTCWeb deliverables for now. OK. But when it starts to block things then it out to get done. Thanks, Paul > Cheers > > -- Flemming (as MMUSIC co-chair) > > On 4/21/17 11:21 AM, Paul Kyzivat wrote: >> On 4/21/17 9:50 AM, Bo Burman wrote: >>> Hi Raju, >>> >>> Unless someone strongly objects, and given that a) 4566bis is nowhere >>> near to RFC status, b) there are other documents that make use of the >>> new template, without normatively referencing 4566bis, and c) that we >>> have documents with dependencies on -sdpneg that we want to progress and >>> avoid becoming stuck in RFC Editor’s queue in MISSREF, I still believe >>> that it would be better to make it an informative reference. >> >> I don't see a need for a normative reference to 4566bis. >> >> OTOH, AFAIK there is nothing to prevent 4566bis from going to WGLC >> *today*. It just needs for the motion to be made. I'm interested to >> hear about this from the chairs. >> >> Thanks, >> Paul >> >>> Cheers, >>> >>> /Bo >>> >>> >>> >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >>> *Sent:* den 15 mars 2017 18:21 >>> *To:* Bo Burman ; mmusic (mmusic@ietf.org) >>> >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Hi Bo, Paul, >>> >>> Since I don’t have a strong preference one way or other, I slightly lean >>> towards to keeping 4566bis as a normative reference for the mentioned >>> reason ‘use of new template defined by 4566bis’. >>> >>> I assume the impact of this being both must get RFC status >>> simultaneously!? >>> >>> Do you know if 4566bis is close to RFC status? >>> >>> >>> >>> Bo, really appreciate bringing these comments to our attention! >>> >>> >>> >>> Thanks >>> >>> Raju >>> >>> >>> >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] >>> *Sent:* Wednesday, March 15, 2017 11:11 AM >>> *To:* Makaraju, Raju (Nokia - US) >> >; mmusic (mmusic@ietf.org >>> ) > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Hi Raju, >>> >>> >>> >>> I should probably have remembered also this in my “unaddressed” list >>> below, but I put a question to the list to change 4566bis from normative >>> to informative reference >>> (https://mailarchive.ietf.org/arch/msg/mmusic/8TZ_yX45geKewDqgHCv1HmURC-I), >>> >>> which seemed acceptable to Paul K, but so far no one else answered. What >>> is the author’s view on this? >>> >>> >>> >>> /Bo >>> >>> >>> >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >>> *Sent:* den 13 mars 2017 22:57 >>> *To:* Bo Burman >> >; mmusic (mmusic@ietf.org >>> ) > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Hi Bo, >>> >>>> It was a bit unclear if it was some kind of quote from somewhere, >>> which is also commonly indicated by such indentation. I suggest just >>> making it explicit that it is a note, starting the first line >>> >>>> with “Note: ”. >>> >>> >>> >>> Will do. Thanks. >>> >>> >>> >>> BR >>> >>> Raju >>> >>> >>> >>> *From:* Bo Burman [mailto:bo.burman@ericsson.com] >>> *Sent:* Monday, March 13, 2017 6:30 AM >>> *To:* Makaraju, Raju (Nokia - US) >> >; mmusic (mmusic@ietf.org >>> ) > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Hi Raju, >>> >>> >>> >>> Regarding: >>> >>> 9) In Appendix A.1: Why are two paragraphs starting with “For data >>> channels negotiated” indented compared to other text? Is it supposed to >>> be some kind of note? >>> >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or change >>> to some other style?/* >>> >>> >>> >>> It was a bit unclear if it was some kind of quote from somewhere, which >>> is also commonly indicated by such indentation. I suggest just making it >>> explicit that it is a note, starting the first line with “Note: ”. >>> >>> >>> >>> /Bo >>> >>> >>> >>> *From:* Makaraju, Raju (Nokia - US) [mailto:raju.makaraju@nokia.com] >>> *Sent:* den 13 mars 2017 02:52 >>> *To:* Bo Burman >> >; mmusic (mmusic@ietf.org >>> ) > >>> *Subject:* RE: [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Hi Bo Burman, Christian Groves, Paul Kyzivat, >>> >>> >>> >>> Thank you so much for your time in making this document better, we >>> appreciate it. Sorry for the extended delay. >>> >>> I accepted all the comments. >>> >>> Please see my comments inserted below. >>> >>> >>> >>> Thanks again >>> >>> Raju >>> >>> >>> >>> >>> >>> *From:* mmusic [mailto:mmusic-bounces@ietf.org] *On Behalf Of *Bo Burman >>> *Sent:* Tuesday, February 28, 2017 10:11 AM >>> *To:* mmusic (mmusic@ietf.org ) >> > >>> *Subject:* [ALU] [MMUSIC] Shepherd's review >>> ofdraft-ietf-mmusic-data-channel-sdpneg-11 >>> >>> >>> >>> Authors, WG, >>> >>> >>> >>> I think this document is getting ready for publication request. As part >>> of making the shepherd’s write-up, I have the following comments, to be >>> addressed in an updated document: >>> >>> >>> >>> Issues: >>> >>> 1) In section 1: add that also BFCP (Binary Floor Control >>> Protocol) is used in the same way as MSRP in examples. >>> >>> */[Raju] Will add BFCP./* >>> >>> 2) In 5.1.1.1, dcmap-stream-id = 1*DIGIT allows infinite length of >>> this identifier, which seems inappropriate. I suggest providing a >>> maximum length, maybe matching this to the unsigned 16 bit integer in >>> SCTP (RFC 4960), in which case 1*5DIGIT should be sufficient. >>> >>> */[Raju] Will change as suggested./* >>> >>> 3) In 5.1.1.1, quoted-visible ABNF syntax is incorrect, missing “x” >>> after “%” when defining hex characters. Change to: >>> quoted-visible = %x21 / %x23-24 / %x26-7E ; VCHAR without " or % >>> >>> */[Raju] Will change as suggested./* >>> >>> 4) In 5.1.2.1, text below the example makes reference to MSRP >>> subprotocol, but the example does not explicitly include any MSRP. The >>> single example line uses “accept-types”, which is admittedly related to >>> MSRP, but I think this should be clarified to avoid confusion for >>> readers not familiar with MSRP. >>> >>> */[Raju] Will change “Example” to “Example (other MSRP related SDP >>> attributes are omitted for brevity):”/* >>> >>> 5) In 5.2.2: It is unclear why you differentiate handling of offers >>> and answers that contain both “max-retr” and “max-time”, mandating to >>> reject the offer but allowing it in the answer. I think allowing this >>> asymmetry should either be motivated, or handling should be aligned >>> between offer and answer. >>> >>> */[Raju] I think it was thought giving a bit of flexibility to offerer >>> while receiving answer is probably good but I see your point on aligning >>> both. Will change text to align both./* >>> >>> 6) In section 6: several examples uses IP addresses that are not >>> aligned with RFC 6890 (10.10.10.x), which must be changed. >>> Allowed ranges are 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 >>> (TEST-NET-2), or 203.0.113.0/24 (TEST-NET-3). >>> >>> */[Raju] Will change as suggested. /* >>> >>> 7) In Appendix A: same IP address issue as above, change from >>> 79.97.215.79 to an address in the allowed range. >>> >>> */[Raju] Will change as suggested. /* >>> >>> >>> >>> Nits: >>> >>> 1) The date line in the document header is one character too long >>> (beyond column 72) >>> >>> */[Raju] Good catch! Hmmm… not sure how it is getting messed up as the >>> it is supposed to be an auto generated line. Anyway, I just checked the >>> new updated draft at /*https://xml2rfc.tools.ietf.org*/and output looks >>> good./* >>> >>> 2) In section 1: s/In future data channels could/In the future, >>> data channels could/ >>> >>> */[Raju] Will change as suggested. /* >>> >>> 3) In section 3: s/sending and receive data/sending and >>> receiving data/ >>> >>> */[Raju] Will change as suggested. /* >>> >>> 4) At the very end of section 5.1.2.1: s/in the same document, >>> which registers/in the same document that registers/ >>> >>> */[Raju] Will change as suggested. /* >>> >>> 5) In 5.2.4: s/other data channels which are now not included/other >>> data channels that are now not included/ >>> >>> */[Raju] Will change as suggested./* >>> >>> 6) In 5.2.5: s/channels are expected be closed now/channels are >>> expected to be closed now/ >>> >>> */[Raju] Will change as suggested./* >>> >>> 7) In 8.3: s/dcsa usage level only shall use/dcsa usage level only >>> SHALL use/ >>> >>> */[Raju] Will change as suggested./* >>> >>> 8) In Appendix A.1: s/either pass to the data channel stack the >>> stream identifier to assign/either pass the stream identifier to the >>> data channel stack to assign/ >>> >>> */[Raju] Will change as suggested./* >>> >>> 9) In Appendix A.1: Why are two paragraphs starting with “For data >>> channels negotiated” indented compared to other text? Is it supposed to >>> be some kind of note? >>> >>> */[Raju] Yes, meant to be a note. Need to change indentation? Or change >>> to some other style?/* >>> >>> >>> >>> Comments from others that are not addressed in -11: >>> >>> 1) Christian Groves commented on Jan 20 that the example in >>> Appendix A should contain an “a=dtls-id:…” attribute as per other >>> examples in the draft. >>> >>> */[Raju] Will add a=dtls-id./* >>> >>> 2) Paul Kyzivat commented on Jan 21 that a bullet in section 5.2.3 >>> should be changed to: >>> o For accepted data channels, the agent MUST create peer instances >>> for the data channels using the SCTP stream identifiers and >>> channel parameters contained in the SDP offer. >>> >>> */[Raju] Will change as suggested./* >>> >>> */ /* >>> >>> */Thanks/* >>> >>> */raju/* >>> >>> >>> >>> Cheers, >>> >>> /Bo >>> >>> MMUSIC co-chair >>> >>> >>> >>> >>> >>> _______________________________________________ >>> mmusic mailing list >>> mmusic@ietf.org >>> https://www.ietf.org/mailman/listinfo/mmusic >>> >> >> . >> > > From nobody Sun Apr 23 16:09:04 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 044B2126C0F for ; Sun, 23 Apr 2017 16:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 Hm_5mkOchcgU for ; Sun, 23 Apr 2017 16:09:01 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 967421201F2 for ; Sun, 23 Apr 2017 16:09:00 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id t144so65501297lff.1 for ; Sun, 23 Apr 2017 16:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bugvBMZ/o3PSOChSRGegmVcXNBL7BO7MXUzdrpy90s8=; b=Qhr4mrzRwjp8JlQDeC4JZ6j/PVOcZnw4efDMoMc2dA0kSuEFzXA662lMM0D9+jpMvV 7p3BF2NMDOWAMUTs4FaDm9vj9nKkMY6pL5Ibv626ed/S0Kkng59WzU8khXfsiPv3T7s4 2bkukvZOXd1hHKzZftgXy0zQaYk4c7CehhMe5IrG4NY0wOOOnuPX8z+9l+Dz54/MZpS5 8K9CZiL8q32wibNkZ0w5ARlnOO4aThZ6f7ZOnm+1kqgybpoY9xfH+vn16gfmthBwdv5f hdyc4dtSuA9NuqyuvIJ3qOJGuJQV61otChLA10Wwf1SMxfA+Bo+gIcWYxqxSl48eVUtM h/pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bugvBMZ/o3PSOChSRGegmVcXNBL7BO7MXUzdrpy90s8=; b=kmkDw7sqcJ4VKrD2HFTLietGBef9gVPX+uB7OuYzOiOnF20CrOlfjAba6OnIdwenio 89CCchTaqm5EmlxdaNPgJyCHbxh/3HYUdK0ycYOgfLiDLLrxGwlFPWRd8Z+e3NQx0wzz AAYTaQbDO/bdatBQGuPQZhf3b5Toak2eYoiMRmZuiG1c0UzfPU1uxavzpRryqddRZolg 7uToNL2N2licDbSCAli2jLIXgy5ZA4kMtpH3mGwDDHbzceO6OtP7jM4r6h/aDTrG+696 O3QZIHBdjriFvlGLbHfFfzaxXJzaAiSlnzd6L6wgKs4PlWhvlLrho1zwpknwXcf4QaUo yrVg== X-Gm-Message-State: AN3rC/7Dt5C29Gf76OUPMnQNwZloSnVE2Vv1OFciUs1JTztGV4IDXBda pDz3TppCbiWWkJr3N19VTCR41oQYNnRM X-Received: by 10.25.31.14 with SMTP id f14mr10516lff.43.1492988938690; Sun, 23 Apr 2017 16:08:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Sun, 23 Apr 2017 16:08:58 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Mon, 24 Apr 2017 09:08:58 +1000 Message-ID: To: Roman Shpount Cc: "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Apr 2017 23:09:02 -0000 On 22 April 2017 at 03:44, Roman Shpount wrote: > I have already mentioned that I prefer not to call this extension > sdp_tls_id. Since this extension applies to Jingle and ORTC, this extension > is not SDP specific. It should be called simply tls_id or tls_helo_id. I apologize for missing this. I've updated my copy of the draft. I've named it external_session_id/ExternalSessionId so that it can be used in some other context without issues. Making this generic means that this document needs to either define how the attribute is used generically, or it needs to state that things other than SDP aren't in scope. I've chosen to limit this to SDP. If another protocol wants to fix this problem, then they need to define the a=tls-id equivalent anyway; they can define the hook into using this extension at the same time. From nobody Mon Apr 24 03:25:02 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1311F12EC70 for ; Mon, 24 Apr 2017 03:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 EOC6sRe-PWpx for ; Mon, 24 Apr 2017 03:24:56 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C44512EC6E for ; Mon, 24 Apr 2017 03:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GwUdmc8h3UI1aq2rdM26WUpC0MfqCXStH3eMZYi5KY0=; b=RpE9kvEUX6YOmIXocuoRXstsirAbEnCxd4r2lJfcDYhcN9Dff6wc52vVDcWoPoeEQPqPfK4gSmtzcvtjYC+CONG+zYJqVtHi8pnuR6D7b3QJM2cveQAe57ikhMjFsbJQjLlVCamPiI2FJNGt+w8iq3THl/6jsvi2tceG+/DbVcU= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0049.outbound.protection.outlook.com [207.46.163.49]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-117-fYBkQNm1PvWJvE-Nk9l_YQ-1; Mon, 24 Apr 2017 06:24:49 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 10:24:46 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1047.019; Mon, 24 Apr 2017 10:24:46 +0000 From: "Asveren, Tolga" To: "mmusic@ietf.org" Thread-Topic: draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AdK84uo3tsu2tVOaS3WF8mONNFoXpQ== Date: Mon, 24 Apr 2017 10:24:45 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:8Py6QqRo17+k9wcs2rGB3icEk2uRHI75vn6avHKpmLkw7MsYInDZMrtQFA+5djsUpL9ycC6GY0Y0Ffst4aejoE6+/R9V3u2jQhhiD9KmfZl7bXhc+qNLpYb+LFN4o96XZZGU77Axy9HmhOZN/Kz3E3qqzECkfvAy4MMkdpevyDpudGFSVZbtl8MXGNHp9j/UzBpR9cESo7GrONiNKl/50eJhNtilzng36r8BiQRpZQ4xYZbAfFBzntBp/ehuxGLNz/ZIa+QW+rY/teCS/1jJzd9TxodXtvEbIyIo+TqepXfC56CBkSQoW9T1Y9SRgBSI61K8veOefN5VvTMp9j7uWg==; 20:/Jwfy+yYtsx0I3B3/vfDu/T0oQ9UPOvFT+noURZRNlGArvfJDCWcha3JM45bIQUoRtE70ELj+oYcJN8yxse/yQgWVMaUFNu6Rm5/V8+RuaYrwadwftHWJVBODbl+bSKfgL8kd+LHA8DfMhzwC864c1e2fAOXVuCNqSQPa7yZC9Y= x-ms-office365-filtering-correlation-id: 352c19bb-da4c-4038-785f-08d48afc2143 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2352; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39830400002)(39400400002)(102836003)(6116002)(790700001)(3846002)(5660300001)(7696004)(230783001)(66066001)(189998001)(2900100001)(74316002)(9686003)(99286003)(55016002)(53936002)(5630700001)(2501003)(86362001)(110136004)(38730400002)(54896002)(6306002)(81166006)(6436002)(1730700003)(6506006)(2906002)(33656002)(54356999)(3660700001)(3280700002)(5640700003)(50986999)(122556002)(25786009)(7736002)(8676002)(8936002)(2351001)(77096006)(6916009); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 10:24:45.8642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: fYBkQNm1PvWJvE-Nk9l_YQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235098F90A4FE233C39AE604B21F0SN2PR03MB2350namp_" Archived-At: Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:25:00 -0000 --_000_SN2PR03MB235098F90A4FE233C39AE604B21F0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling ... When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the "receipt properties" t= herefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP mu= ltiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an't determine whether multiplexing is not supported at all or whether B wa= nts to use it in a unidirectional way. Thanks, Tolga --_000_SN2PR03MB235098F90A4FE233C39AE604B21F0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

It seems draft-ietf-mmusic-mux-exclusive-11 assumes = that mux support will be always bidirectional. OTOH, I think RFC5761 allows= unidirectional semantics:

 

5.1.1. SDP Signaling

…

 

   When SDP is used in a declarative manner, the= presence of an "a=3Drtcp-

   mux" attribute signals that the sender w= ill multiplex RTP and RTCP on

   the same port.  The receiver MUST be pre= pared to receive RTCP packets

   on the RTP port, and any resource reservation= needs to be made

   including the RTCP bandwidth.

 

Actually this part of RFC5761 sounds a bit odd as in= declarative mode I thought an attribute would convey information about the= “receipt properties” therefore “rtcp-mux” would me= an that the sender wants to receive RTP/RTCP multiplexed on the same port.

 

It could be good to explicitly state in draft-ietf-m= music-mux-exclusive that unidirectional multiplexing with declarative mode = is not supported.

 

Example scenario:

A sends rtcp-mux/rtcp-mux-only

B does not support rtcp-mux-only and ignores it. It = interprets rtcp-mux in declarative mode and is ready to receive RTP/RTCP on= the same port. OTOH, it does not want to send multiplexed RTP/RTCP hence d= oes not include rtcp-mux in the reply.

A terminates the session because the answer does not= contain rtcp-mux. It can’t determine whether multiplexing is not sup= ported at all or whether B wants to use it in a unidirectional way.

 

Thanks,

Tolga

--_000_SN2PR03MB235098F90A4FE233C39AE604B21F0SN2PR03MB2350namp_-- From nobody Mon Apr 24 03:48:26 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D396F12EC4B for ; Mon, 24 Apr 2017 03:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 3rwrnQ88qPoJ for ; Mon, 24 Apr 2017 03:48:23 -0700 (PDT) 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 9CFDA12F268 for ; Mon, 24 Apr 2017 03:48:22 -0700 (PDT) X-AuditID: c1b4fb3a-9397998000006079-b9-58fdd7f4279e Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 7E.1C.24697.4F7DDF85; Mon, 24 Apr 2017 12:48:20 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Mon, 24 Apr 2017 12:46:20 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJA== Date: Mon, 24 Apr 2017 10:46:20 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_D523B2CC1B92Cchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZGbFdRffL9b8RBst3W1lMXf6YxWJ253sm ByaPJUt+Mnlc+vyfPYApissmJTUnsyy1SN8ugSuj8983loLXXhV//09kaWD86NDFyMkhIWAi sfP2eqYuRi4OIYH1jBJT339nB0kICSxhlLhxUriLkYODTcBCovufNkhYRCBY4nnDDyYQW1gg SOL2mumMMPFri/YzgpSLCOhJNL+LBgmzCKhKXDrQywJi8wpYS2x+cpEZxGYUEJP4fmoN2Bhm AXGJW0/mM0GcIyCxZM95ZghbVOLl43+sILYo0Mh9/76yQcQVJa5OXw7VmyAx9cBlqPmCEidn PmGZwCg0C8nYWUjKZiEpg4gbSLw/N58ZwtaWWLbwNZStL7Hxy1lGCNtaYnLDezZkNQsYOVYx ihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbOwS2/rXYwHnzueIhRgINRiYf3gfLfCCHWxLLi ytxDjBIczEoivN0rgEK8KYmVValF+fFFpTmpxYcYpTlYlMR5HfZdiBASSE8sSc1OTS1ILYLJ MnFwSjUw+gtxzihUsJpTX2xpwr7J/veyw1+2iPb/27u2p9xJS/Wn2BKW1LSLM6atSPN0tPOS e2YX2PPwmOlcbkG7gqj9JuImz6+u32phveuN8KuzziduWE6+XLda8fTRQ69D7SdYpFWHsXll v/dlXbfqiOgF1ULvMwzcxneCCxf80NF4XFMdZVHyrSxCiaU4I9FQi7moOBEADzhroJkCAAA= Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 10:48:25 -0000 --_000_D523B2CC1B92Cchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling =85 When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the =93receipt properties= =94 therefore =93rtcp-mux=94 would mean that the sender wants to receive RT= P/RTCP multiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an=92t determine whether multiplexing is not supported at all or whether B = wants to use it in a unidirectional way. Thanks, Tolga --_000_D523B2CC1B92Cchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we c= larify that negotiated mux is always bidirectional.

   "This document updates RFC=
 5761 [RFC5761] by clarifying that an
   answerer can only include an "a=3Drtcp-mux" attribute in an an=
swer if
   the associated offer contained the attribute.  It also clarifies that
   the negotiation of RTP and RTCP multiplexing is for usage in both
   directions."

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga= Asveren <tasveren@sonusnet.com= >
Date: Monday 24 April 2017 at 13:24=
To: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic= -mux-exclusive-11 / always bidirectional?

It seems draft-ietf-mmusic-mux-exclusive-11 assumes = that mux support will be always bidirectional. OTOH, I think RFC5761 allows= unidirectional semantics:

 

5.1.1. SDP Signaling

=85

 

   When SDP is used in a declarative manner, the= presence of an "a=3Drtcp-

   mux" attribute signals that the sender w= ill multiplex RTP and RTCP on

   the same port.  The receiver MUST be pre= pared to receive RTCP packets

   on the RTP port, and any resource reservation= needs to be made

   including the RTCP bandwidth.

 

Actually this part of RFC5761 sounds a bit odd as in= declarative mode I thought an attribute would convey information about the= =93receipt properties=94 therefore =93rtcp-mux=94 would mean that the send= er wants to receive RTP/RTCP multiplexed on the same port.

 

It could be good to explicitly state in draft-ietf-m= music-mux-exclusive that unidirectional multiplexing with declarative mode = is not supported.

 

Example scenario:

A sends rtcp-mux/rtcp-mux-only

B does not support rtcp-mux-only and ignores it. It = interprets rtcp-mux in declarative mode and is ready to receive RTP/RTCP on= the same port. OTOH, it does not want to send multiplexed RTP/RTCP hence d= oes not include rtcp-mux in the reply.

A terminates the session because the answer does not= contain rtcp-mux. It can=92t determine whether multiplexing is not support= ed at all or whether B wants to use it in a unidirectional way.

 

Thanks,

Tolga

 --_000_D523B2CC1B92Cchristerholmbergericssoncom_-- From nobody Mon Apr 24 11:29:31 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57DD813191A for ; Mon, 24 Apr 2017 11:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 1WFserLkstQd for ; Mon, 24 Apr 2017 11:29:27 -0700 (PDT) Received: from us-smtp-delivery-126.mimecast.com (us-smtp-delivery-126.mimecast.com [216.205.24.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2A081317F8 for ; Mon, 24 Apr 2017 11:29:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/YlRFCrW8MGUOfZUgH6Kxs6ODPfeBrchlhHOFi8YIKE=; b=QHpfCwI15n8qxoUQNYWt8IvBd9BsVaIS6QIC/5/5POl3274MgMYGpcZpfJGJbPU+TQUXZw7R+t//YWGa5E1oURAKdUve+tUNbyo+6hv/fx31rk2bedIwzVdDwbOzqs2yYfeIiB793q+RIOcnyDN8Q8ZIEjtp9BGtUXmG0tCxCSo= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0088.outbound.protection.outlook.com [207.46.163.88]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-119--yabQWVQP2aUIbo-BfwoRA-1; Mon, 24 Apr 2017 14:29:21 -0400 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1047.13; Mon, 24 Apr 2017 18:29:20 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.1047.019; Mon, 24 Apr 2017 18:29:19 +0000 From: "Asveren, Tolga" To: Christer Holmberg , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1A Date: Mon, 24 Apr 2017 18:29:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:BXAWMVtQ2jCmnTZGWdc0vjv7wXlriYsyoTDrGpKf2s6aL9yCvxX0+G6O98Hh8puDEJ+FMt9A1A1b5aSiDvuMX7aJ64Amd5oulVzraxGcz+2gTal5Ou8cVRr/+PVWZIp+krKlZp9F+cK9iCflXLdqa4BIA6R1eHeYIKuaZtQDHaMiMJY7HrXKTW2rL7G0k5+9p7O0/3lUyuqmHwwgq+h2x9+9cwiDgOnJRxcoURIG3gBoMBEuT0c6oXuhY6C/pUxovQaVohTkcUpV4tpO5G36cqDgBK9SlA5JTFonOCk5s8j68DGUdGkKvVdIpRSt4/hBS3DnMC0g5lOjpR1dfW6OTw==; 20:F87MSIc8xmJWJsCv8D6q5BR2ERql8eFSgGcQ7eUBRqKLnF+oUdgwQscRZkD5CnY1pjqkHLOvTlyJ47Iptbx6LzMsdWGmLzW3ZZqvQTPjlIt17veSZnmpkw6c6RFa5GUNNkMj+H1sVU4qFWDkLPk2hCY3PMuCpexXRifhpn3fbac= x-ms-office365-filtering-correlation-id: 7bff1050-7619-4d9f-d086-08d48b3fd28d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:SN2PR03MB2349; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(6072148); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 0287BBA78D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400002)(39410400002)(39450400003)(39400400002)(377454003)(8676002)(50986999)(76176999)(33656002)(54356999)(6246003)(8936002)(2950100002)(122556002)(81166006)(790700001)(6306002)(7906003)(54896002)(236005)(3846002)(9686003)(77096006)(102836003)(99286003)(3280700002)(5660300001)(7736002)(55016002)(3660700001)(6116002)(53936002)(38730400002)(74316002)(25786009)(7696004)(189998001)(53546009)(86362001)(66066001)(229853002)(606005)(2900100001)(2501003)(6436002)(2906002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2017 18:29:19.5780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: -yabQWVQP2aUIbo-BfwoRA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB23509F7E18D7E5CF379CA054B21F0SN2PR03MB2350namp_" Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 18:29:29 -0000 --_000_SN2PR03MB23509F7E18D7E5CF379CA054B21F0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that "rtcp-mux-only" is bid= irectional as "rtcp-mux" per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga ; mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling ... When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the "receipt properties" t= herefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP mu= ltiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an't determine whether multiplexing is not supported at all or whether B wa= nts to use it in a unidirectional way. Thanks, Tolga --_000_SN2PR03MB23509F7E18D7E5CF379CA054B21F0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Thanks for pointing this out. The issue still would = be applicable for already deployed RFC5761 compliant/RFC8035 non-compliant = entities. Therefore IMHO it could be a good idea to explicitly mention that= “rtcp-mux-only” is bidirectional as “rtcp-mux” per RFC8035.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holm= berg@ericsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasveren@sonusnet.com>; mmusic@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

&n= bsp;

RFC 576= 1 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that = negotiated mux is always bidirectional.

&n= bsp;

  =
 "This document updates RFC 5761 [RFC5761] by clarifying that an<=
/o:p>
   answerer can only include an =
"a=3Drtcp-mux" attribute in an answer if
   the associated offer containe=
d the attribute.  It also clarifies that
   the negotiation of RTP and RT=
CP multiplexing is for usage in both
   directions."<=
/span>

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

&n= bsp;

It seems draft-ietf-mmus= ic-mux-exclusive-11 assumes that mux support will be always bidirectional. = OTOH, I think RFC5761 allows unidirectional semantics:

 =

5.1.1. SDP Signaling

…

 =

   When SDP is used in a declarative= manner, the presence of an "a=3Drtcp-

   mux" attribute signals that = the sender will multiplex RTP and RTCP on

   the same port.  The receiver= MUST be prepared to receive RTCP packets

   on the RTP port, and any resource= reservation needs to be made=

   including the RTCP bandwidth.

 =

Actually this part of RF= C5761 sounds a bit odd as in declarative mode I thought an attribute would = convey information about the “receipt properties” therefore = 220;rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

 =

It could be good to expl= icitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multipl= exing with declarative mode is not supported.

 =

Example scenario:

A sends rtcp-mux/rtcp-mu= x-only

B does not support rtcp-= mux-only and ignores it. It interprets rtcp-mux in declarative mode and is = ready to receive RTP/RTCP on the same port. OTOH, it does not want to send = multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A terminates the session= because the answer does not contain rtcp-mux. It can’t determine whe= ther multiplexing is not supported at all or whether B wants to use it in a= unidirectional way.

 =

Thanks,

Tolga<= /p>

--_000_SN2PR03MB23509F7E18D7E5CF379CA054B21F0SN2PR03MB2350namp_-- From nobody Mon Apr 24 15:04:16 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 347F613194B for ; Mon, 24 Apr 2017 15:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.589 X-Spam-Level: X-Spam-Status: No, score=-2.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 Bl9cBlvlSIq7 for ; Mon, 24 Apr 2017 15:04:12 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 94C5A120227 for ; Mon, 24 Apr 2017 15:04:12 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id y11so119703234oie.0 for ; Mon, 24 Apr 2017 15:04:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IY+Cdsp+hjaBRZC4e75dzoP993m+fknOYe9qk8wUeZM=; b=jqLr3LJmyWwKqBnTpc4lwNxW95oGDrzHULMJjYZ/otvbO3O+/eay7e63TrDzrM0tXK kJuv8aloUvzV7dm29+1Xv81D11mZ5TXtV454Shk8fyie70Lk/5c5OFs247qcCmJ3IdRH 4qS97/AV/ukH0ryxE+5Fz9V37qLUVXN8ISrWl3jux4hqmh/Xde3aJz815TQ5jTIEuKip n/CTPJ37HxxrFuHOIb+FhN4NHOB6HJqbwM/GUIXtVaCFXOygugHOatWvuXMhwHvlI+Lc UN81C33L+2ejB2hrfkx6kacMEPGTDfPk31pjWkbcCDcoxqEYCnFLhnn7ljTtNhv2AbaE cEjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IY+Cdsp+hjaBRZC4e75dzoP993m+fknOYe9qk8wUeZM=; b=oZ1kUb709pkXIJV7OUMSUd+pjwbGwGo+6PdkSWMfZJF0fETs67fH2dXT1PdJ0aqZn/ Bn4VQ+wtV+IaImTRn9Cya/FWlfZKn3Xk4zRMIpS75NzT55G/17RtJfY+3GqZ2AcznCcc I25NVFEK7h9vpyOQJq+lGMc56Ug8463wSa+i6AOu2Z4YOGp8Hfcq0YXGbTA9xyn5L52u vd55Caxbd7YgOCM8xwTM/0N8UG+SG+2yi+g4istFfGw3/HJL1OeDOq96VHBXcBQllYNf jIcQDg3J1Wi8hM7PAnI8QkIRGfKuKkOeCRJBtchrEpRyd+XEoHUtGaI+D/0B4m63SDaK FpSw== X-Gm-Message-State: AN3rC/7+YWclXa99PzGIQKxESqGaBQL2tDtMkQMHaxjiBq5CzmsJaC+T zOBxzGoDgkjeeQrb X-Received: by 10.202.4.211 with SMTP id 202mr8049263oie.41.1493071451900; Mon, 24 Apr 2017 15:04:11 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com. [209.85.218.49]) by smtp.gmail.com with ESMTPSA id 64sm1867586ots.58.2017.04.24.15.04.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Apr 2017 15:04:11 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id x184so152726051oia.1 for ; Mon, 24 Apr 2017 15:04:11 -0700 (PDT) X-Received: by 10.202.76.78 with SMTP id z75mr14273892oia.142.1493071451082; Mon, 24 Apr 2017 15:04:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.22.237 with HTTP; Mon, 24 Apr 2017 15:04:10 -0700 (PDT) In-Reply-To: References: From: Roman Shpount Date: Mon, 24 Apr 2017 18:04:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Martin Thomson Cc: "mmusic@ietf.org" Content-Type: multipart/alternative; boundary=001a11c167ae775a66054df0c9a3 Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Apr 2017 22:04:14 -0000 --001a11c167ae775a66054df0c9a3 Content-Type: text/plain; charset=UTF-8 On Sun, Apr 23, 2017 at 7:08 PM, Martin Thomson wrote: > On 22 April 2017 at 03:44, Roman Shpount wrote: > > I have already mentioned that I prefer not to call this extension > > sdp_tls_id. Since this extension applies to Jingle and ORTC, this > extension > > is not SDP specific. It should be called simply tls_id or tls_helo_id. > > I apologize for missing this. I've updated my copy of the draft. > I've named it external_session_id/ExternalSessionId so that it can be > used in some other context without issues. > > Making this generic means that this document needs to either define > how the attribute is used generically, or it needs to state that > things other than SDP aren't in scope. > > I've chosen to limit this to SDP. If another protocol wants to fix > this problem, then they need to define the a=tls-id equivalent anyway; > they can define the hook into using this extension at the same time. > I think we can say that this document is limited to SDP with other protocols out of scope. ORT and Jingle can define how to signal tls-id in separate documents. Regards, _____________ Roman Shpount --001a11c167ae775a66054df0c9a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Apr 23, 2017 at 7:0= 8 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
On 22 April 2017 at 03:44, Roman Shpount <roman@telurix.com> wrote:
> I have already mentioned that I prefer not to call this extension
> sdp_tls_id. Since this extension applies to Jingle and ORTC, this exte= nsion
> is not SDP specific. It should be called simply tls_id or tls_helo_id.=

I apologize for missing this.=C2=A0 I've updated my copy of the = draft.
I've named it external_session_id/ExternalSessionId so that it can= be
used in some other context without issues.

Making this generic means that this document needs to either define
how the attribute is used generically, or it needs to state that
things other than SDP aren't in scope.

I've chosen to limit this to SDP.=C2=A0 If another protocol wants to fi= x
this problem, then they need to define the a=3Dtls-id equivalent anyway; they can define the hook into using this extension at the same time.

I think we can say = that this document is limited to SDP with other protocols out of scope. ORT= and Jingle can define how to signal tls-id in separate documents.

Regards,
=
____________= _
Roman Shpount

--001a11c167ae775a66054df0c9a3-- From nobody Mon Apr 24 23:17:54 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 997051319BF for ; Mon, 24 Apr 2017 23:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0W1FQQocfvDR for ; Mon, 24 Apr 2017 23:17:51 -0700 (PDT) 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 CFA971319D5 for ; Mon, 24 Apr 2017 23:17:50 -0700 (PDT) X-AuditID: c1b4fb2d-c616898000004c5d-f1-58feea0cf369 Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by (Symantec Mail Security) with SMTP id 7C.29.19549.C0AEEF85; Tue, 25 Apr 2017 08:17:48 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0339.000; Tue, 25 Apr 2017 08:15:40 +0200 From: Christer Holmberg To: Roman Shpount , Martin Thomson CC: "mmusic@ietf.org" Thread-Topic: [MMUSIC] New version of SDP UKS draft Thread-Index: AQHSucQtLLUtJKLc50K9G9/NZEEaQKHP+OEAgAN/PACAAYA6AIAAvOqA Date: Tue, 25 Apr 2017 06:15:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D524C4DE1B9BEchristerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCIsWRmVeSWpSXmKPExsUyM2J7lC7Pq38RBo27FCyunfnHaDF1+WMW ixkXpjI7MHvsnHWX3WPJkp9MHremFAQwR3HZpKTmZJalFunbJXBl/F+tULDNqOLBr36mBsY+ 7S5GTg4JAROJhu0/mLoYuTiEBNYzSuz7t4UdwlnCKLFt+0+gDAcHm4CFRPc/sAYRgSCJ59Pn g4WZBdQlri4OAgkLCxhJ/DzxkxGixFhi56+J7BC2m8Tbh4/B4iwCqhJvrrSCxXkFrCWO35zB BrFqKZNE18/PrCAJToFAibsfOtlAbEYBMYnvp9YwgdjMAuISt57MZ4I4WkBiyZ7zzBC2qMTL x//AekUF9IDu/8oGEVeS+LHhEgtEb4LE4uf9TBCLBSVOznzCMoFRdBaSsbOQlM1CUgYRN5B4 f24+M4StLbFs4WsoW19i45ezjBC2tcT1x89ZkdUsYORYxShanFpcnJtuZKyXWpSZXFycn6eX l1qyiREYlwe3/Nbdwbj6teMhRgEORiUe3gcs/yKEWBPLiitzDzFKcDArifBeAgnxpiRWVqUW 5ccXleakFh9ilOZgURLnddh3IUJIID2xJDU7NbUgtQgmy8TBKdXAmPZWRvnVjGWLFZUUGa+o PZwdvmmbmNAktX/cVU90uLvVuQUvTE159jDby6Y7fF9Qp4Hm8Tn9Un7PTn+d9n1hz4e2pWxh DOGrTFY/SuX3lFgbuMmk82BfweSanHX/HFNVPj+00bLara37aHNmZ0vlzaKV+VxxXyw2XZk+ w9Cib+Vko8fCi9lDlViKMxINtZiLihMBrRM6/8cCAAA= Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:17:53 -0000 --_000_D524C4DE1B9BEchristerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I agree with Roman. I suggest splitting the draft into two main parts: one parts which describe= s the concept in general, and another =93Usage with SDP Offer/Answer=94 par= t which describes the SDP specific parts. It then makes it easier for others to reference the generic part, and then = add their =93Usage with ORTC/Jingle/H.323/whatever=94 part. Regards, Christer From: mmusic > on b= ehalf of Roman Shpount > Date: Tuesday 25 April 2017 at 01:04 To: Martin Thomson > Cc: "mmusic@ietf.org" > Subject: Re: [MMUSIC] New version of SDP UKS draft On Sun, Apr 23, 2017 at 7:08 PM, Martin Thomson > wrote: On 22 April 2017 at 03:44, Roman Shpount > wrote: > I have already mentioned that I prefer not to call this extension > sdp_tls_id. Since this extension applies to Jingle and ORTC, this extensi= on > is not SDP specific. It should be called simply tls_id or tls_helo_id. I apologize for missing this. I've updated my copy of the draft. I've named it external_session_id/ExternalSessionId so that it can be used in some other context without issues. Making this generic means that this document needs to either define how the attribute is used generically, or it needs to state that things other than SDP aren't in scope. I've chosen to limit this to SDP. If another protocol wants to fix this problem, then they need to define the a=3Dtls-id equivalent anyway; they can define the hook into using this extension at the same time. I think we can say that this document is limited to SDP with other protocol= s out of scope. ORT and Jingle can define how to signal tls-id in separate = documents. Regards, _____________ Roman Shpount --_000_D524C4DE1B9BEchristerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4760D3801FA91149A75D99DCEB8C864A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Roman.

I suggest splitting the draft into two main parts: one parts which des= cribes the concept in general, and another =93Usage with SDP Offer/Answer= =94 part which describes the SDP specific parts.

It then makes it easier for others to reference the generic part, and = then add their =93Usage with ORTC/Jingle/H.323/whatever=94 part.

Regards,

Christer

From: mmusic <mmusic-bounces@ietf.org> on behalf of Roman= Shpount <roman@telurix.com>=
Date: Tuesday 25 April 2017 at 01:0= 4
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "mmusic@ietf.org" <= mmusic@ietf.org>
Subject: Re: [MMUSIC] New version o= f SDP UKS draft


On Sun, Apr 23, 2017 at 7:08 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
On 22 April 2017 at 03:44, Roman Shpount <roman@telurix.com> wrote:
> I have already mentioned that I prefer not to call this extension
> sdp_tls_id. Since this extension applies to Jingle and ORTC, this exte= nsion
> is not SDP specific. It should be called simply tls_id or tls_helo_id.=

I apologize for missing this.  I've updated my copy of the draf= t.
I've named it external_session_id/ExternalSessionId so that it can be<= br> used in some other context without issues.

Making this generic means that this document needs to either define
how the attribute is used generically, or it needs to state that
things other than SDP aren't in scope.

I've chosen to limit this to SDP.  If another protocol wants to fix this problem, then they need to define the a=3Dtls-id equivalent anyway; they can define the hook into using this extension at the same time.

I think we can say that this document is limited= to SDP with other protocols out of scope. ORT and Jingle can define how to= signal tls-id in separate documents.

Regards,
_____________
Roman Shpount

 --_000_D524C4DE1B9BEchristerholmbergericssoncom_-- From nobody Mon Apr 24 23:35:24 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F1F1319E6 for ; Mon, 24 Apr 2017 23:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZXNqBX1vz0c for ; Mon, 24 Apr 2017 23:35:20 -0700 (PDT) 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 84A561319E0 for ; Mon, 24 Apr 2017 23:35:19 -0700 (PDT) X-AuditID: c1b4fb25-2b64e98000004efc-ad-58feee253227 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by (Symantec Mail Security) with SMTP id 64.E0.20220.52EEEF85; Tue, 25 Apr 2017 08:35:17 +0200 (CEST) Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0339.000; Tue, 25 Apr 2017 08:34:13 +0200 From: Christer Holmberg To: "Asveren, Tolga" , "mmusic@ietf.org" Thread-Topic: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? Thread-Index: AQHSvOgCNt6Dk7x2uEaNj1LXZRgEJKHUeB1AgAE8CwA= Date: Tue, 25 Apr 2017 06:34:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.2.170228 x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_D524C79E1B9D8christerholmbergericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyM2J7uK7qu38RBms/q1lMXf6YxWJ253sm ByaPJUt+Mnlc+vyfPYApissmJTUnsyy1SN8ugSvjz8ZlzAWPqis2fPZrYHyV08XIySEhYCKx d8kpti5GLg4hgfWMEi+6nrJDOEsYJc5PecDSxcjBwSZgIdH9TxukQUQgWOJ5ww8mEFtYIEji 9prpjDDxa4v2M4KUiwhYSfz5kg8SZhFQlXi26R9YOa+AtcTXiRugdvUxStx594wNJMEpECux b/YbFhCbUUBM4vupNWANzALiEreezGeCOFRAYsme88wQtqjEy8f/WEFsUQE9iX3/vrJBxJUk fmy4BHYys0CCxP7viRB7BSVOznzCMoFRZBaSqbMQqmYhqYIoMZB4f24+M4StLbFs4WsoW19i 45ezjBC2tcSxg9PZkdUsYORYxShanFqclJtuZKyXWpSZXFycn6eXl1qyiREYaQe3/FbdwXj5 jeMhRgEORiUe3gcs/yKEWBPLiitzDzFKcDArifBeAgnxpiRWVqUW5ccXleakFh9ilOZgURLn ddx3IUJIID2xJDU7NbUgtQgmy8TBKdXAGHtmcfLbPwJtHprn+DbOWb9sivA+rnMyArw1hy9J XmhIP3lYeaern8KijltxtmGF7Lv2ujFU+uc98bmUrdZ7h39NsIwE+27VYDvJDcukOHgvf115 wE5nyR7tttpIj/8P/578YadtlPyle9JynnmRq52EBAr67Y4auCYrWphJSXpw/1+lwayvxFKc kWioxVxUnAgAWjgFFbACAAA= Archived-At: Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional? X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2017 06:35:22 -0000 --_000_D524C79E1B9D8christerholmbergericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, When taking a look, I realised that both RFC8035 and draft-mux-exclusive up= date the same text in RFC5761, which causes confusion. So, as RFC 8035 updates the whole section 5.1.1 of RFC5671, I assume that w= hatever updates need to be done in draft-mix-exclusive should be done based= on the text in RFC8035. Regards, Christer From: Tolga Asveren > Date: Monday 24 April 2017 at 21:29 To: Christer Holmberg >, "mmusic@ietf.org" > Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Thanks for pointing this out. The issue still would be applicable for alrea= dy deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMH= O it could be a good idea to explicitly mention that =93rtcp-mux-only=94 is= bidirectional as =93rtcp-mux=94 per RFC8035. Thanks, Tolga From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] Sent: Monday, April 24, 2017 6:46 AM To: Asveren, Tolga >; m= music@ietf.org Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirecti= onal? Hi, RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.t= xt), where we clarify that negotiated mux is always bidirectional. "This document updates RFC 5761 [RFC5761] by clarifying that an answerer can only include an "a=3Drtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions." Regards, Christer From: mmusic > on b= ehalf of Tolga Asveren = > Date: Monday 24 April 2017 at 13:24 To: "mmusic@ietf.org" > Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional= ? It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will b= e always bidirectional. OTOH, I think RFC5761 allows unidirectional semanti= cs: 5.1.1. SDP Signaling =85 When SDP is used in a declarative manner, the presence of an "a=3Drtcp- mux" attribute signals that the sender will multiplex RTP and RTCP on the same port. The receiver MUST be prepared to receive RTCP packets on the RTP port, and any resource reservation needs to be made including the RTCP bandwidth. Actually this part of RFC5761 sounds a bit odd as in declarative mode I tho= ught an attribute would convey information about the =93receipt properties= =94 therefore =93rtcp-mux=94 would mean that the sender wants to receive RT= P/RTCP multiplexed on the same port. It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive tha= t unidirectional multiplexing with declarative mode is not supported. Example scenario: A sends rtcp-mux/rtcp-mux-only B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in = declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, i= t does not want to send multiplexed RTP/RTCP hence does not include rtcp-mu= x in the reply. A terminates the session because the answer does not contain rtcp-mux. It c= an=92t determine whether multiplexing is not supported at all or whether B = wants to use it in a unidirectional way. Thanks, Tolga --_000_D524C79E1B9D8christerholmbergericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

When taking a look, I realised that both RFC8035 and draft-mux-exclusi= ve update the same text in RFC5761, which causes confusion.

So, as RFC 8035 updates the whole section 5.1.1 of RFC5671, I assume t= hat whatever updates need to be done in draft-mix-exclusive should be done = based on the text in RFC8035.

Regards,

Christer

From: Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 21:29=
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" = <mmusic@ietf.org>
Subject: RE: [MMUSIC] draft-ietf-mm= usic-mux-exclusive-11 / always bidirectional?

Thanks for pointing this out. The issue still would = be applicable for already deployed RFC5761 compliant/RFC8035 non-compliant = entities. Therefore IMHO it could be a good idea to explicitly mention that= =93rtcp-mux-only=94 is bidirectional as =93rtcp-mux=94 per RFC8035.

 

Thanks,

Tolga

 

From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; mmusic@ietf.org
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bi= directional?

 

Hi,

&n= bsp;

RFC 576= 1 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that = negotiated mux is always bidirectional.

&n= bsp;

  =
 "This document updates RFC 5761 [RFC5761] by clarifying that an<=
/o:p>
   answerer can only include an =
"a=3Drtcp-mux" attribute in an answer if
   the associated offer containe=
d the attribute.  It also clarifies that
   the negotiation of RTP and RT=
CP multiplexing is for usage in both
   directions."<=
/span>

&n= bsp;

Regards= ,

&n= bsp;

Christe= r

&n= bsp;

From: mmusic <mmusic-bounces@ietf.org> on behalf of Tolga Asveren <tasveren@sonusnet.com>
Date: Monday 24 April 2017 at 13:24
To: "mmusic@ietf.org&quo= t; <mmusic@ietf.org>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidire= ctional?

&n= bsp;

It seems draft-ietf-mmus= ic-mux-exclusive-11 assumes that mux support will be always bidirectional. = OTOH, I think RFC5761 allows unidirectional semantics:

 =

5.1.1. SDP Signaling

=85

 =

   When SDP is used in a declarative= manner, the presence of an "a=3Drtcp-

   mux" attribute signals that = the sender will multiplex RTP and RTCP on

   the same port.  The receiver= MUST be prepared to receive RTCP packets

   on the RTP port, and any resource= reservation needs to be made=

   including the RTCP bandwidth.

 =

Actually this part of RF= C5761 sounds a bit odd as in declarative mode I thought an attribute would = convey information about the =93receipt properties=94 therefore =93rtcp-mux= =94 would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

 =

It could be good to expl= icitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multipl= exing with declarative mode is not supported.

 =

Example scenario:

A sends rtcp-mux/rtcp-mu= x-only

B does not support rtcp-= mux-only and ignores it. It interprets rtcp-mux in declarative mode and is = ready to receive RTP/RTCP on the same port. OTOH, it does not want to send = multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.

A terminates the session= because the answer does not contain rtcp-mux. It can=92t determine whether= multiplexing is not supported at all or whether B wants to use it in a uni= directional way.

 =

Thanks,

Tolga<= /p>

--_000_D524C79E1B9D8christerholmbergericssoncom_-- From nobody Tue Apr 25 23:13:14 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74500129416 for ; Tue, 25 Apr 2017 23:13:12 -0700 (PDT) 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 9AwaF7VCJLH1 for ; Tue, 25 Apr 2017 23:13:11 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 E5A6F126C25 for ; Tue, 25 Apr 2017 23:13:10 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id 75so101988152lfs.2 for ; Tue, 25 Apr 2017 23:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vc1NebMvStpiqjApGgCvbsGSjiaUx0M1o8ONNTRRcyA=; b=R9TprVxF2ox2SgIAaUZE4PIx51khjN1iizfCKQwFOQiZQV8DUovWwpIprkBAIKyNAG iyV9HHPS7qMzhYBddhB5bvQNMZjmV1Ln9cwzTgEUQUeTXlo48LYMyXfRvMgAtiUPGEcz YNUPtXcDysCalgeuFwTzJPosBE73nIm5eY9RCwkJzOf44fJaaCkbrqKlxCu+P/qL9RTm yHU2yOWPOJHXYF92ilf2yRBKqMKKbagPP7P96O8UV51IAHRwXdz/vxDA2MOPbtt/frui bWj6sNIED043FWduy8Z7h00mVKSSP8LI/L9GTUdsZG8PUC2g+7QOG7VD4TFiPZznYV9d jB5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vc1NebMvStpiqjApGgCvbsGSjiaUx0M1o8ONNTRRcyA=; b=KdHOioZvxxvzsLu1vmk0QCyiTvMI97yKnY6gVythOtzU+tqn6V8FXyRZcpYJsulAPz nZqxzlkV0naKCG31AefWIUbqqCoSWAWzqdVfBxL4vypKgOZlMT54OeOKT/zP3gqAJAxX PG3u9rkmAzly6PksNp9kEhdwxyXYKx9iHQyV2YrIpl0IdrivB8ZaSagrLb+JISfSJXSl AoHpEDcTF0VgZaTY3WX6r7nuX8rnUsyYHTwpYHlJbpzhEKilCasn4NPotM7Grba6ovL2 8kxNtQ53hNsOzlDG6Znm2NoZtclwWw9xu6u8dWSw+VszjAiju90SIAzyWfJ5itgQN1Bh z6Rw== X-Gm-Message-State: AN3rC/5lv1fAcF9Bo6/ai4EhBFt8upLQ0y8jbvjO1kGYHbIusZyMf32O xE+a5A+LnmgZwYLbJAR8uHCjvpgya0Lf X-Received: by 10.25.212.19 with SMTP id l19mr1450910lfg.169.1493187189161; Tue, 25 Apr 2017 23:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.83.2 with HTTP; Tue, 25 Apr 2017 23:13:08 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 26 Apr 2017 16:13:08 +1000 Message-ID: To: Christer Holmberg Cc: Roman Shpount , "mmusic@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [MMUSIC] New version of SDP UKS draft X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 06:13:12 -0000 On 25 April 2017 at 16:15, Christer Holmberg wrote: > I suggest splitting the draft into two main parts: one parts which descri= bes > the concept in general, and another =E2=80=9CUsage with SDP Offer/Answer= =E2=80=9D part which > describes the SDP specific parts. I'll look at doing that in the next version. From nobody Wed Apr 26 10:04:07 2017 Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7C8913151E for ; Wed, 26 Apr 2017 10:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 23sGBklx7eRv for ; Wed, 26 Apr 2017 10:03:54 -0700 (PDT) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 803B8131508 for ; Wed, 26 Apr 2017 10:03:54 -0700 (PDT) Received: by mail-pg0-x233.google.com with SMTP id 63so3023763pgh.0 for ; Wed, 26 Apr 2017 10:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jgyD4z1F81WXdIsTwfIepByKNpUFbK0Lr4Z7/Btvom0=; b=ZLVJKmGZByzm9GV1X+N7Ey0f4VsGKHZwa2cF4BqsGabAslJ6PXpz6YVoCN08Qzi+gZ Rpng2OxRRbd9lqIhy9RTkrxdkZB3ZmHtIFhEC13kOPAI0D8FQPomoFYvNUtlT+vLlVto pfEobPAqjzxP7VPnaJTSGDhdRsKK5VlKXqSDRCCuGQvfX7o4n6w2rVwWKtEJlhSYE0BV 6VdgEdnghdTrU5VlW4bAg9kcXb6K888Lel1T/GSDbtBfq3PcFTqkaE7RRgMB+PVm6FBm 1mGFGaoq6h4tGhb5/t+6RV/OYmKtPUAc0mduAm6Rkq/xzO3IJVDJxUSAYQY2L0pOGNRn WvUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jgyD4z1F81WXdIsTwfIepByKNpUFbK0Lr4Z7/Btvom0=; b=f7tPmw0z8ASjUw5yBw+NzZBr0Tl2qd2trDE8cCXXPwWTVuNCycDAikekGTAibsnTLH 3/z38oZ7FUUyzX61YrJqDpeNlBv1xwkvJtBimqXVEK53SEbQIUMX/2+3G3rB5qJeRe2Q 4U8ucEqg0nHqR7VJQLizUotwWFcXjiayw45YhC3G2o2nYXaZdoowwL7lZD1xxkGyrRxX /2jYAQobHrxrdQnD2ErCXL/Evgi0HGY4IJDkLe8Fl7vTA2oMTfD75nEMMVwjBZ2F+PNA XS5qmk6ZxSyKQYyARTj0eSTKwjFhL4RLv+7fT2zwVbm2A/NnHYnUz0WohPe++i2R3Z58 Xp8w== X-Gm-Message-State: AN3rC/5HOziUI+LhCY+oMVqQE5toHPJpFcVTzMG4lmNBQ3x125phKV3u uaMlmydzr/uuDw== X-Received: by 10.98.147.202 with SMTP id r71mr858726pfk.43.1493226233978; Wed, 26 Apr 2017 10:03:53 -0700 (PDT) Received: from mail-pg0-f43.google.com (mail-pg0-f43.google.com. [74.125.83.43]) by smtp.gmail.com with ESMTPSA id s65sm1205940pgb.34.2017.04.26.10.03.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Apr 2017 10:03:53 -0700 (PDT) Received: by mail-pg0-f43.google.com with SMTP id v1so2994039pgv.1; Wed, 26 Apr 2017 10:03:53 -0700 (PDT) X-Received: by 10.98.85.6 with SMTP id j6mr852497pfb.31.1493226232844; Wed, 26 Apr 2017 10:03:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.145.151 with HTTP; Wed, 26 Apr 2017 10:03:52 -0700 (PDT) In-Reply-To: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com> References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com> From: Roman Shpount Date: Wed, 26 Apr 2017 13:03:52 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Flemming Andreasen Cc: mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0cc6dc2d9bd5054e14d3cb Archived-At: Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Apr 2017 17:03:57 -0000 --94eb2c0cc6dc2d9bd5054e14d3cb Content-Type: text/plain; charset=UTF-8 I have several comments regarding the document: 1. I would like to add justification for tls-id to the introduction and change: The SDP 'tls-id' attribute can also be used for negotiating a TLS connection, using the procedures in this document in conjunction with the procedures in [RFC5763] and [RFC8122]. The TLS specific considerations are described in Section 8. to: The SDP 'tls-id' attribute can be specified when negotiating a TLS connection, using the procedures in this document in conjunction with the procedures in [RFC5763] and [RFC8122]. The unique combination of SDP 'tls-id' attribute values can be used to identity the negotiate TLS connection. The unique value can be used, for example, within TLS protocol extensions to differentiate between multiple TLS connections and correlate those connections with specific offer/answer exchanges. The TLS specific considerations are described in Section 8. 2. In section 8 "mulitple" should be "multiple" 3. I think in section 10 RFC Updates it would look better if the title of the section would be formatted like "10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel" and then "OLD TEXT:/NEW TEXT:" sections without titles or section numbers. This way section numbers from previous RFC will not interrupt section flow of the current document. Also, "RFC 5763 Section 5" should reference to section 5 of RFC 5763, not to the unexciting section number in the current draft. 4. I think there is a lot of confusion on the list about handling of ClientHello before the answer is received. Should we add the following text to section 5.2 or 5.4: If DTLS ClientHello message is received before the answer is received ClientHello message MUST be cached, but not processed. When the answer is received and if SDP 'setup' attribute in the answer is 'passive', then DTLS handshake MUST proceed by procssing the cached DTLS ClientHello message. If SDP 'setup' attribute in the answer is 'active', the cached DTLS ClientHello message must be discarded and offerer MUST initiate a new DTLS handshake by sending a DTLS ClientHello message towards the answerer. NOTE: DTLS handshake cannot proceed before the answer is received since before this point remote address, ICE candidates, and ICE ufrag and password are not known and DTLS ServerHello message cannot be sent to the answerer. Since DTLS handshake does not proceed until server answer is received, unlike TLS, it is impossible to receive data over DTLS association before remote fingerprints are received and verified. Regards, _____________ Roman Shpount On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen wrote: > Greetings MMUSIC > > Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on > the changes from -22 to -24, i.e.: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-dtls-sdp > -22&url2=draft-ietf-mmusic-dtls-sdp-24 > > If you have any comments on the changes, please provide those by Friday, > April 28. Comments should be sent to the document authors and the MMUSIC WG > list. > > Thanks > > -- Flemming (as MMUSIC co-chair) > > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic > --94eb2c0cc6dc2d9bd5054e14d3cb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have several comments regarding the document:

1. I would like to add justification for tls-id to the introduction and= change:

The SDP 'tls-id' attribute can also be used for negotiating a = TLS connection, using the procedures in this document in conjunction with t= he procedures in [RFC5763] and [RFC8122].=C2=A0 The TLS specific=C2=A0consi= derations are described in Section 8.
to:

The SDP= 'tls-id' attribute can be specified when negotiating a TLS connect= ion, using the procedures in this document in conjunction with the procedur= es in [RFC5763] and [RFC8122].=C2=A0 The=C2=A0unique combination of SDP = 9;tls-id' attribute values can be used to=C2=A0identity the negotiate T= LS connection.=C2=A0 The unique value can be used, for example, within TLS = protocol extensions to differentiate between multiple TLS=C2=A0connections = and correlate those connections with specific offer/answer exchanges.=C2=A0= The TLS specific=C2=A0considerations are described in Section 8.

2. In section 8 "mulitple" should be "multiple"

<= /font>
3. I think in section 10 RFC Updates it would look better if the title of= the section would be formatted like=C2=A0"10.2.1. Updat= e to RFC 5763 Section 5: Establishing a Secure Channel" and then "= ;OLD TEXT:/NEW TEXT:" sections without titles or section numbers. This= way section numbers from previous RFC will not interrupt section flow of t= he current document. Also, "RFC 5763 Section 5" should reference = to section 5 of RFC 5763, not to the unexciting section number in the curre= nt draft.

4. I think there is a lot of confusion o= n the list about handling of ClientHello before the answer is received. Sho= uld we add the following text to section 5.2 or 5.4:

If DTLS = ClientHello message is received before the answer is received ClientHello m= essage MUST be cached, but not processed. When the answer is received and i= f SDP 'setup' attribute in the answer is 'passive', then DT= LS handshake MUST proceed by procssing the cached DTLS ClientHello message.= If SDP 'setup' attribute in the answer is 'active', the ca= ched DTLS ClientHello message must be discarded and offerer MUST initiate a= new DTLS handshake by sending a DTLS ClientHello message towards the answe= rer.

NOTE: DTLS handshake cannot proceed before th= e answer is received since before this point remote address, ICE candidates= , and ICE ufrag and password are not known and DTLS ServerHello message can= not be sent to the answerer. Since DTLS handshake does not proceed until se= rver answer is received, unlike TLS, it is impossible to receive data over = DTLS association before remote fingerprints are received and verified.

Regards,

_____________Roman Shpount


On Fri, Apr 21, 2017 at 9:08 AM, Flemming An=
dreasen <fandreas@cisco.com> wrote:
Greetings MMUSIC



Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on t=
he changes from -22 to -24, i.e.:



https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-22&url2=3Ddraft-ietf-mmusic-dtls-sdp-24



If you have any comments on the changes, please provide those by Friday, Ap=
ril 28. Comments should be sent to the document authors and the MMUSIC WG l=
ist.



Thanks



-- Flemming (as MMUSIC co-chair)





_______________________________________________

mmusic mailing list

mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic




--94eb2c0cc6dc2d9bd5054e14d3cb--


From nobody Wed Apr 26 22:49:02 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 910F61315AE; Wed, 26 Apr 2017 22:49:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VBcHoY6PqfsD; Wed, 26 Apr 2017 22:48:59 -0700 (PDT)
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 AFCCF126DCA; Wed, 26 Apr 2017 22:48:58 -0700 (PDT)
X-AuditID: c1b4fb2d-b25ff7000000196b-41-59018647ed8a
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 83.2A.06507.74681095; Thu, 27 Apr 2017 07:48:56 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 07:48:54 +0200
From: Christer Holmberg 
To: Roman Shpount , Flemming Andreasen 
CC: mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" 
Thread-Topic: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
Thread-Index: AQHSuqBQpUS/reyYTkmSRPXLKwFJlKHXx2EAgAEJXoA=
Date: Thu, 27 Apr 2017 05:48:54 +0000
Message-ID: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.18]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <1532FC75FBE9994CB900B2B714129F31@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLIsWRmVeSWpSXmKPExsUyM2K7iq5HG2OkwfLp+hb/J85ntXh/Qddi 6vLHLBYzLkxldmDxmPJ7I6vHkiU/mTxuTSkIYI7isklJzcksSy3St0vgyviyVL5gvWxF58Ze 9gbG1+JdjJwcEgImEs8ufmHpYuTiEBI4wijxYdkFVghnCaNE67kPjF2MHBxsAhYS3f+0QRpE BPwk7p+9zQxiMwtkS0w7s4MNxBYWCJY4vGkFE0RNiMSGS3eYIWwriZOPvjOC2CwCqhIXdk1g B7F5BawlXiw7wAyxq5lRovnxPLAEp0CgxKltnWBDGQXEJL6fWsMEsUxc4taT+UwQVwtILNlz nhnCFpV4+fgfK4gtKqAnse/fVzaIuKLEx1f7GCF69SRuTJ3CBmFbSxyadRTqAW2JZQtfM0Mc JChxcuYTlgmM4rOQrJuFpH0WkvZZSNpnIWlfwMi6ilG0OLW4ODfdyFgvtSgzubg4P08vL7Vk EyMwEg9u+a27g3H1a8dDjAIcjEo8vAoPGCKFWBPLiitzDzFKcDArifCmFzJGCvGmJFZWpRbl xxeV5qQWH2KU5mBREud12HchQkggPbEkNTs1tSC1CCbLxMEp1cDov/vu5a2rBA56T58SuCv0 /B4R24eZnTWXvjbWyIirCLdp3/uyyWDWyu+X506TWHvUzeRGimnW/KhDWdcSJigus2n7GLu0 Str3qfFrZ3mGKaw77tw6vOZMf16A14G5y2c95XqfFnyo8Wu0/INk1Qcmkx/HJEtNe7U+co/k 3YvaswI+TfS5o7CsV4mlOCPRUIu5qDgRAL2JLvvAAgAA
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 05:49:01 -0000

Hi,

>1. I would like to add justification for tls-id to the introduction and
>change:
>
>The SDP 'tls-id' attribute can also be used for negotiating a TLS
>connection, using the procedures
>in this document in conjunction with the procedures in [RFC5763] and
>[RFC8122].  The TLS specific considerations
>are described in Section 8.
>
>to:
>
>The SDP 'tls-id' attribute can be specified when negotiating a TLS
>connection, using the procedures in this
>document in conjunction with the procedures in [RFC5763] and [RFC8122].
>The unique combination of SDP 'tls-id=B9
>attribute values can be used to identity the negotiate TLS connection.
>The unique value can be used, for example,
>within TLS protocol extensions to differentiate between multiple TLS
>connections and correlate those connections
>with specific offer/answer exchanges.  The TLS specific considerations
>are described in Section 8.

Ok, I can add that.

>2. In section 8 "mulitple" should be "multiple"

Will fix.


>3. I think in section 10 RFC Updates it would look better if the title of
>the section would be formatted like
>"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel=B2 an=
d
>then "OLD TEXT:/NEW TEXT:" sections without
>titles or section numbers. This way section numbers from previous RFC
>will not interrupt section flow of the current
>document. Also, "RFC 5763 Section 5" should reference to section 5 of RFC
>5763, not to the unexciting section number in the current draft.

How would you fix section 10.3.1, where the old text refers to multiple
sections (4., 4.1., etc)?


>4. I think there is a lot of confusion on the list about handling of
>ClientHello before the answer is received. Should we
>add the following text to section 5.2 or 5.4:
>
> If DTLS ClientHello message is received before the answer is received
>ClientHello message MUST be cached, but not
> processed. When the answer is received and if SDP 'setup' attribute in
>the answer is 'passive', then DTLS handshake
> MUST proceed by processing the cached DTLS ClientHello message. If SDP
>'setup' attribute in the answer is 'active=B9,
> the cached DTLS ClientHello message must be discarded and offerer MUST
>initiate a new DTLS handshake by sending a
> DTLS ClientHello message towards the answerer.

Is that supported by DTLS? Shouldn=B9t it be considered an error if you
receive a ClientHello that you shouldn=B9t receive?

Also, has the WG community agreed on the procedure you suggest? This WGLC
is not about adding new functionality that has not been discussed.

Regards,

Christer


> NOTE: DTLS handshake cannot proceed before the answer is received since
>before this point remote address, ICE candidates,
> and ICE ufrag and password are not known and DTLS ServerHello message
>cannot be sent to the answerer. Since DTLS handshake
> does not proceed until server answer is received, unlike TLS, it is
>impossible to receive data over DTLS association
> before remote fingerprints are received and verified.





On Fri, Apr 21, 2017 at 9:08 AM, Flemming Andreasen
 wrote:

Greetings MMUSIC

Following the recent changes in dtls-sdp, we are issuing a 1-week WGLC on
the changes from -22 to -24, i.e.:

https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-mmusic-dtls-sdp-22&url2=3Ddr=
aft-
ietf-mmusic-dtls-sdp-24

If you have any comments on the changes, please provide those by Friday,
April 28. Comments should be sent to the document authors and the MMUSIC
WG list.

Thanks

-- Flemming (as MMUSIC co-chair)


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






From nobody Wed Apr 26 23:29:15 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A721243F6; Wed, 26 Apr 2017 23:29:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 FVFzJUBeIz2C; Wed, 26 Apr 2017 23:29:12 -0700 (PDT)
Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (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 05CF11250B8; Wed, 26 Apr 2017 23:29:12 -0700 (PDT)
Received: by mail-lf0-x232.google.com with SMTP id c80so11811875lfh.3; Wed, 26 Apr 2017 23:29:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=X2VRDx8nLWE3Vqt+DXIfqiOW4jICmLg3t/EQzLlQASY=; b=ZBP1EmRhHNAflixSFu1L3+VxGBgxzMFaE1tmKE9UgBR/cSEwJJ4OQnmOnJvyPowD8S /WwxfWZ8200SrWdBXtLLbziCt/xA+WOkF7MhaCc6vTX35WVQV+DRYV/XF5s56IicLSTc UngReyltcw5+MJCWG291hLJ/RBqEHgUYJ3m9MDLcXq1ZEXqxlTRlTfAAnWUTiAinfh8p knjfqxuOKkIkBTmZBwXRgFC3oyXY9HWAMBI7nqgmfU9g9ogGeQXGjVRpHbIYcFm9MVFp snyKckhRM6RHzMKKeFpxwn3g3OM4xXC/9BOG8Uz/7tCCNFvLFT+ok+3s9AZGhTXJ4aQU LLUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=X2VRDx8nLWE3Vqt+DXIfqiOW4jICmLg3t/EQzLlQASY=; b=Drdz7KjG2q/3xLVXazE1X7saT2hlMb+OURTqw2LZo1j/0ZrVn0OrDpFigRqEiy8aUT 926BtT7ONgT4VOVyIoDv2sh8gjHfOwx6iv/vUaobUDylJ0GjNArKaIExrGeBm30exiVN XmxUgivUGwG4R4BY4gUpKJngNO9ndl53RA+jiN1VFRMgDwYB40LyLtdfL4bXeVk9grbV 3agW9Didv009nrWK/sEnfo8xJQT6+OUnc3apQ/5OhSF5/Mot1Osae3uryr9xLh1DAtzZ PDhxj7gLZ57ZZYYM3Y6fYy06JDNDdDY/5KrzD9YVlTuCcwx2wUhC73QLOYPomdz3qXQv aGew==
X-Gm-Message-State: AN3rC/7+7UyIcpyOiRRWqe1YAOZBDnyeWFKjN195MmAbr4zv94q+UDJG sSb0Ci/8aWTahdkbO7/r50M3HKew+A==
X-Received: by 10.46.21.2 with SMTP id s2mr1428957ljd.50.1493274550330; Wed, 26 Apr 2017 23:29:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Wed, 26 Apr 2017 23:29:09 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>  
From: Martin Thomson 
Date: Thu, 27 Apr 2017 16:29:09 +1000
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 06:29:14 -0000

On 27 April 2017 at 15:48, Christer Holmberg
 wrote:
> Is that supported by DTLS? Shouldn=C2=B9t it be considered an error if yo=
u
> receive a ClientHello that you shouldn=C2=B9t receive?

DTLS can handle all sorts of abuse, but I think that Christer is right
in that we shouldn't tolerate a ClientHello if the answer contains
'passive'.

The question as to whether we should mandate this is a tougher one.
All the discussion about unauthenticated media and so forth has
convinced me that the best we get here is an optimization.  I would
prefer to keep any recommendations about how to optimize out of the
specifications.

DTLS will re-send the ClientHello.  The only risk here is that the
DTLS client will give up before the answer arrives.  Frankly, that
doesn't seem particularly likely unless the answerer has insane delays
and glacial signaling.  I really don't want to cater to this to the
extent of mandating special behaviour for handling this corner case.

I'd be OK with a suggestion.  With ICE, it can't send the ServerHello
until it has an ICE password, so the process stalls there.  An offerer
could save a ClientHello and process it when it receives the answer.
That saves some time.

If we want to acknowledge the absence of ICE as well, we could say
that it could allow the handshake to complete, but delay reporting
success until it can validate the remote certificate.


From nobody Thu Apr 27 03:30:27 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C34E4126C89; Thu, 27 Apr 2017 03:30:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxF2xVXIWQ-I; Thu, 27 Apr 2017 03:30:24 -0700 (PDT)
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 28C4A12896F; Thu, 27 Apr 2017 03:30:23 -0700 (PDT)
X-AuditID: c1b4fb2d-eff839a00000196b-f3-5901c83dac57
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 73.AE.06507.D38C1095; Thu, 27 Apr 2017 12:30:21 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 12:30:10 +0200
From: Christer Holmberg 
To: Martin Thomson 
CC: Roman Shpount , Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Thread-Topic: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
Thread-Index: AQHSuqBQpUS/reyYTkmSRPXLKwFJlKHXx2EAgAEJXoD//9eggIAAdvWA
Date: Thu, 27 Apr 2017 10:30:09 +0000
Message-ID: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <48711F92F0ED634781C862E4F3C49B59@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBIsWRmVeSWpSXmKPExsUyM2K7iq7tCcZIgzWfbCz+T5zPavH+gq7F tTP/GC2mLn/MYjHjwlRmB1aPKb83snrsnHWX3WPJkp9MHremFASwRHHZpKTmZJalFunbJXBl LPzdzV4wRbji+swO9gbGK0JdjJwcEgImEhfvfGLpYuTiEBI4wijx/kUjE4SzhFFixvPF7F2M HBxsAhYS3f+0QRpEBHQlFp19wA5Swyywk1Hi6N+1TCAJYYFgicObVjBBFIVIbLh0hxmkV0TA TWLfU0mQMIuAqkT/vdVsIDavgLXEm2+TWSF2/WGUeHjsF1gvp0CgxIwJd8GKGAXEJL6fWgMW ZxYQl7j1ZD4TxNUCEkv2nGeGsEUlXj7+xwpiiwroSez795UNIq4o0f60gRGiV0viy499bBC2 tcTLjpvsELaixJTuh+wQBwlKnJz5hGUCo/gsJOtmIWmfhaR9FpL2WUjaFzCyrmIULU4tLs5N NzLWSy3KTC4uzs/Ty0st2cQIjM+DW37r7mBc/drxEKMAB6MSD6/CA4ZIIdbEsuLK3EOMEhzM SiK8kjsZI4V4UxIrq1KL8uOLSnNSiw8xSnOwKInzOuy7ECEkkJ5YkpqdmlqQWgSTZeLglGpg TFuxJsxbQmvZ2TTDcFfpshM37gZ2M79LitoSNpO/vs9oylq+/bsTmFhdo5kvOHGwrhBf5vD7 SEvCm4ytPHvEOG+L+3yM+Pm9TFZtY+OX6oyzUyQKrnprrpa4JfJlZk+jbOvTF0K5fA/PrWaV vLsyvkvlko9Q5gyHjq9fDP6dXBe9+K6bxO1YJZbijERDLeai4kQAREg9tssCAAA=
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 10:30:26 -0000

SGksDQoNCkkgYW0gYWxzbyBub3Qgc3VyZSB3aGV0aGVyIEkgd291bGQgbGlrZSB0byBtYW5kYXRl
IHByb2NlZHVyZXMuDQoNCldlIENPVUxEIHNheSB0aGF0IHRoZSBvZmZlcmVyIE1VU1QgTk9UIHBy
b2Nlc3MgdGhlIENsaWVudEhlbGxvIGJlZm9yZSBpdA0KaGFzIHJlY2VpdmVkIHRoZSBhbnN3ZXIs
IGJ1dCBJIGFtIG5vdCBzdXJlIHdlIHNheSBtb3JlIHRoYW4gdGhhdKGmDQoNClJlZ2FyZHMsDQoN
CkNocmlzdGVyDQoNCg0KDQpPbiAyNy8wNC8xNyAwOToyOSwgIk1hcnRpbiBUaG9tc29uIiA8bWFy
dGluLnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCg0KPk9uIDI3IEFwcmlsIDIwMTcgYXQgMTU6
NDgsIENocmlzdGVyIEhvbG1iZXJnDQo+PGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4g
d3JvdGU6DQo+PiBJcyB0aGF0IHN1cHBvcnRlZCBieSBEVExTPyBTaG91bGRuqfZ0IGl0IGJlIGNv
bnNpZGVyZWQgYW4gZXJyb3IgaWYgeW91DQo+PiByZWNlaXZlIGEgQ2xpZW50SGVsbG8gdGhhdCB5
b3Ugc2hvdWxkbqn2dCByZWNlaXZlPw0KPg0KPkRUTFMgY2FuIGhhbmRsZSBhbGwgc29ydHMgb2Yg
YWJ1c2UsIGJ1dCBJIHRoaW5rIHRoYXQgQ2hyaXN0ZXIgaXMgcmlnaHQNCj5pbiB0aGF0IHdlIHNo
b3VsZG4ndCB0b2xlcmF0ZSBhIENsaWVudEhlbGxvIGlmIHRoZSBhbnN3ZXIgY29udGFpbnMNCj4n
cGFzc2l2ZScuDQo+DQo+VGhlIHF1ZXN0aW9uIGFzIHRvIHdoZXRoZXIgd2Ugc2hvdWxkIG1hbmRh
dGUgdGhpcyBpcyBhIHRvdWdoZXIgb25lLg0KPkFsbCB0aGUgZGlzY3Vzc2lvbiBhYm91dCB1bmF1
dGhlbnRpY2F0ZWQgbWVkaWEgYW5kIHNvIGZvcnRoIGhhcw0KPmNvbnZpbmNlZCBtZSB0aGF0IHRo
ZSBiZXN0IHdlIGdldCBoZXJlIGlzIGFuIG9wdGltaXphdGlvbi4gIEkgd291bGQNCj5wcmVmZXIg
dG8ga2VlcCBhbnkgcmVjb21tZW5kYXRpb25zIGFib3V0IGhvdyB0byBvcHRpbWl6ZSBvdXQgb2Yg
dGhlDQo+c3BlY2lmaWNhdGlvbnMuDQo+DQo+RFRMUyB3aWxsIHJlLXNlbmQgdGhlIENsaWVudEhl
bGxvLiAgVGhlIG9ubHkgcmlzayBoZXJlIGlzIHRoYXQgdGhlDQo+RFRMUyBjbGllbnQgd2lsbCBn
aXZlIHVwIGJlZm9yZSB0aGUgYW5zd2VyIGFycml2ZXMuICBGcmFua2x5LCB0aGF0DQo+ZG9lc24n
dCBzZWVtIHBhcnRpY3VsYXJseSBsaWtlbHkgdW5sZXNzIHRoZSBhbnN3ZXJlciBoYXMgaW5zYW5l
IGRlbGF5cw0KPmFuZCBnbGFjaWFsIHNpZ25hbGluZy4gIEkgcmVhbGx5IGRvbid0IHdhbnQgdG8g
Y2F0ZXIgdG8gdGhpcyB0byB0aGUNCj5leHRlbnQgb2YgbWFuZGF0aW5nIHNwZWNpYWwgYmVoYXZp
b3VyIGZvciBoYW5kbGluZyB0aGlzIGNvcm5lciBjYXNlLg0KPg0KPkknZCBiZSBPSyB3aXRoIGEg
c3VnZ2VzdGlvbi4gIFdpdGggSUNFLCBpdCBjYW4ndCBzZW5kIHRoZSBTZXJ2ZXJIZWxsbw0KPnVu
dGlsIGl0IGhhcyBhbiBJQ0UgcGFzc3dvcmQsIHNvIHRoZSBwcm9jZXNzIHN0YWxscyB0aGVyZS4g
IEFuIG9mZmVyZXINCj5jb3VsZCBzYXZlIGEgQ2xpZW50SGVsbG8gYW5kIHByb2Nlc3MgaXQgd2hl
biBpdCByZWNlaXZlcyB0aGUgYW5zd2VyLg0KPlRoYXQgc2F2ZXMgc29tZSB0aW1lLg0KPg0KPklm
IHdlIHdhbnQgdG8gYWNrbm93bGVkZ2UgdGhlIGFic2VuY2Ugb2YgSUNFIGFzIHdlbGwsIHdlIGNv
dWxkIHNheQ0KPnRoYXQgaXQgY291bGQgYWxsb3cgdGhlIGhhbmRzaGFrZSB0byBjb21wbGV0ZSwg
YnV0IGRlbGF5IHJlcG9ydGluZw0KPnN1Y2Nlc3MgdW50aWwgaXQgY2FuIHZhbGlkYXRlIHRoZSBy
ZW1vdGUgY2VydGlmaWNhdGUuDQoNCg==


From nobody Thu Apr 27 03:36:46 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9A0128A32; Thu, 27 Apr 2017 03:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, URIBL_BLOCKED=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 poF5JcTH51eN; Thu, 27 Apr 2017 03:36:44 -0700 (PDT)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (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 0DF3D124217; Thu, 27 Apr 2017 03:36:44 -0700 (PDT)
Received: by mail-lf0-x22d.google.com with SMTP id 88so15010940lfr.0; Thu, 27 Apr 2017 03:36:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2NWItvFPQK+OejpAexGQNsXu9epL4qabgkVV+S/QYnk=; b=bmbhcoWNQEL1NaSCTjtjHy3fz+FWFanOw++nrTHqqPq3ZP7eAO3l5ItBpZCfovuqmb NCbC3wMiNtT6Fg66IL4QCsqkNWQxy3TulRpuC2May+02rYppU9Rt+p76TfCy0piv6BaA /y7QL4f51yvg0M60Bp43fg1/jkkoDUvKTNJ557OTefXRWq5isovR8jkVq0DzB/d2bRPH 7+K2dEyNXDTQm4NxSIIwEBNZI5tUZdfBOkr86jrB34orG8GOMbBZp3V5mTOuWAEp8DUf i7+hZIio6uit1V3Hvy8bAeG7B9Wno8qcmfLekxRWslYedwgigYNUigv3nkFm46Eaafl4 2UCw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2NWItvFPQK+OejpAexGQNsXu9epL4qabgkVV+S/QYnk=; b=YZXal/sQnNP4WllfGVgUn5TYxDBVQHp+TTX4pEoDOEmkLUbPUuNta+clK3Wvj5gqcV WR3x5vNGKaMIyC06Gjs9PiZCZgjX2RfKNTHxijHpFXu47WOVRaT61QFoAgzTNbGLkq7j QnV83ThdXBS2RPcyKysTEAq3JvToijG+M57QUZ8YiBzD1KOxhmWKlIhyMtb6XKzILzmh lZgvaMutcP9QFkx5a4bgZjs2QecYVBCC7QX5wtOijvst26oiTMdS+eX12DUA8YzGAL+S mEpWo6/RxxSXHWESZtpVIPwY6m8mvqL/dAHWHxbF9mm3TbTS6ewW+XEW3GLRHbOET+6Q ospA==
X-Gm-Message-State: AN3rC/7YFoK0nDjVi//RXncV2bud9Ypvhb5jmjpcQ0W/Yfc6PUjp9DjI hJ3AHv9vk0dZ3gyH7Rx7gFxybIPsCQ==
X-Received: by 10.46.21.2 with SMTP id s2mr1859996ljd.50.1493289402290; Thu, 27 Apr 2017 03:36:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Thu, 27 Apr 2017 03:36:41 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    
From: Martin Thomson 
Date: Thu, 27 Apr 2017 20:36:41 +1000
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 10:36:45 -0000

On 27 April 2017 at 20:30, Christer Holmberg
 wrote:
> We COULD say that the offerer MUST NOT process the ClientHello before it
> has received the answer, but I am not sure we say more than that=E2=80=A6

I wouldn't do that; the real gate here is that they not call the
handshake done and proceed to exchange data.  Frankly, you could even
complete the handshake and buffer incoming data without any real
exposure.

Sending is not a good idea and playing out what you receive is equally
unwise.  Those are what you need to safeguard.  (Fluffy might
disagree; #include other threads regarding W3C liaison).


From nobody Thu Apr 27 04:38:44 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD11127ABE; Thu, 27 Apr 2017 04:38:44 -0700 (PDT)
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 l69G-zliI0Mk; Thu, 27 Apr 2017 04:38:42 -0700 (PDT)
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 6005C124D68; Thu, 27 Apr 2017 04:38:42 -0700 (PDT)
X-AuditID: c1b4fb30-af94d9a000001047-9c-5901d8409c37
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id D8.44.04167.048D1095; Thu, 27 Apr 2017 13:38:40 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 13:38:31 +0200
From: Christer Holmberg 
To: Martin Thomson 
CC: Roman Shpount , Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Thread-Topic: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
Thread-Index: AQHSuqBQpUS/reyYTkmSRPXLKwFJlKHXx2EAgAEJXoD//9eggIAAdvWA///ONICAAETlAA==
Date: Thu, 27 Apr 2017 11:38:30 +0000
Message-ID: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>     
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <11F5A607C7744A41B913B2A686DFF5C7@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM2K7ga7DDcZIg94bshb/J85ntXh/Qdfi 2pl/jBZTlz9msZhxYSqzA6vHlN8bWT12zrrL7rFkyU8mj1tTCgJYorhsUlJzMstSi/TtErgy 9j1axlxwjq3i7Kw/rA2MC1m7GDk4JARMJI4e1u5i5OIQEjjCKPFx5gdmCGcJo8Si1bdYQIrY BCwkuv8BFXFyiAjoSiw6+4AdpIZZYCejxNG/a5lAEsICwRKHN61ggigKkdhw6Q4zhB0msWnp NzCbRUBV4u6qWcwgM3kFrCU+dTiAhIUEvjJJ7NzrD2JzCgRK9P2ZCjaGUUBM4vupNWA2s4C4 xK0n88FsCQEBiSV7zjND2KISLx//YwWxRQX0JPb9+8oG8ZeSxLStaRCtBhLvz81nhrCtJY48 vgZla0ssW/gazOYVEJQ4OfMJywRG8VlIts1C0j4LSfssJO2zkLQvYGRdxShanFqclJtuZKSX WpSZXFycn6eXl1qyiREYmQe3/DbYwfjyueMhRgEORiUeXoUHDJFCrIllxZW5hxglOJiVRHgz rzBGCvGmJFZWpRblxxeV5qQWH2KU5mBREud13HchQkggPbEkNTs1tSC1CCbLxMEp1cBodf1u 1Kw1Qv8OzLjx8GXNUasVp5bov+QXLH9puFqm9TRX6oqfK47sdTe6xjfl7sF6y3MrBVZLnrKP d2ZrXC0b4OO0VohBr+A047G5h22PCmbM+7z8fc5GFn8NT7u8nX53BI0nWUxxrQqwmP/64VuO P442y1wPmH6bWeNvrTC/voJHqHgzj+5kJZbijERDLeai4kQAwx07JsgCAAA=
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 11:38:44 -0000

Hi,

>>We COULD say that the offerer MUST NOT process the ClientHello before it
>> has received the answer, but I am not sure we say more than that=8A
>
>I wouldn't do that; the real gate here is that they not call the
>handshake done and proceed to exchange data.  Frankly, you could even
>complete the handshake and buffer incoming data without any real
>exposure.
>
>Sending is not a good idea and playing out what you receive is equally
>unwise.  Those are what you need to safeguard.  (Fluffy might
>disagree; #include other threads regarding W3C liaison).

Fair enough. So, do we want to say that the offerer may complete the
handshake, and buffer received data, before it has received the answer,
but the offerer shall not process received data, or send data, before it
has received the answer?

Regards,

Christer


From nobody Thu Apr 27 11:21:17 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D710129BEC for ; Thu, 27 Apr 2017 11:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 jcCsVrs9WhYF for ; Thu, 27 Apr 2017 11:21:13 -0700 (PDT)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 E4F28129C04 for ; Thu, 27 Apr 2017 11:17:40 -0700 (PDT)
Received: by mail-pf0-x22b.google.com with SMTP id a188so34294162pfa.0 for ; Thu, 27 Apr 2017 11:17:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2ZPpDop3te7BoPcdcwSRB29tyEJo8iSxR4owqtLItzs=; b=znnDeVPIN5W3eHc7MxnHFVDvaqaBSjHYOHVDQKGvbNXBM2PTMGdWfU4Xw7kFBxUWG1 KZy8+jNfZfH8kxXkjYOVrIxs39N3lXBgoc0XzXS3dJOIgCB6w9sm4eL95Y29pe+TC3Qz HtJ+2QcJpT7y2nbOTmwdSf8VmQqQkYzsuYMZTiYLGpp++zkgLbH/tnHVaFIZs78aKcI4 J6V43EDcwVggp6hQfau+G/aRkFazkJa2WIXcfY1iAlEjiJktRhj8A5SmP4ja9PUJPljk XrRj33iAI1bfdfA8qMkHzZRiZTeJskj/5LQpeGKOtbrGNducJSTfSXzNKdBy5zq81him rjqA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2ZPpDop3te7BoPcdcwSRB29tyEJo8iSxR4owqtLItzs=; b=L+SqullCOQqpSVhkG0Zt4o4HHxfGO5k7auX4xsN0BhKztshXpADbKYAXU7gfzFB7BZ cncqxpJaNpzGLuhUPQmh3sxmd/PeVt5pZAH/psB+Fs9W430O2VwQDJoU8ix8n8LY96+5 VSjnoPdZ8CRMUFS8M9tmAXvSBfjbNT6zsiD2Jwe4/nRGY1VTanHrR3HiRUZ3iFdCSOcz qafzk/IHy9TRDkMzma9xQVBUdrrMjW/WG2QK+/Grgu+yX9Scn/0haiTXHU4jfKY0Z4+z w+pc217WAD+XM7inhy9UhLtOeX4KFtbAMYLynSZbwoYCJQ9QjhGH8S9/xwAHwFNGRnfb Dv2Q==
X-Gm-Message-State: AN3rC/4c96QmqfcTiwK9vo/ypCcF9Of+W8hKrLjJjFNGbihoa6fFzcHk v2idXtMCsyS84x8G
X-Received: by 10.84.131.129 with SMTP id d1mr9408708pld.16.1493317060320; Thu, 27 Apr 2017 11:17:40 -0700 (PDT)
Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com. [209.85.192.180]) by smtp.gmail.com with ESMTPSA id p2sm5966599pfj.93.2017.04.27.11.17.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 11:17:39 -0700 (PDT)
Received: by mail-pf0-f180.google.com with SMTP id v14so34189394pfd.2; Thu, 27 Apr 2017 11:17:39 -0700 (PDT)
X-Received: by 10.84.135.34 with SMTP id 31mr9041291pli.99.1493317059139; Thu, 27 Apr 2017 11:17:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.150 with HTTP; Thu, 27 Apr 2017 11:17:38 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>  
From: Roman Shpount 
Date: Thu, 27 Apr 2017 14:17:38 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , mmusic ,  "draft-ietf-mmusic-dtls-sdp@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c11ac32d8dec3054e29f863
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 18:21:16 -0000

--94eb2c11ac32d8dec3054e29f863
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Christer,

On Thu, Apr 27, 2017 at 1:48 AM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >3. I think in section 10 RFC Updates it would look better if the title o=
f
> >the section would be formatted like
> >"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Channel=C2=
=B2 and
> >then "OLD TEXT:/NEW TEXT:" sections without
> >titles or section numbers. This way section numbers from previous RFC
> >will not interrupt section flow of the current
> >document. Also, "RFC 5763 Section 5" should reference to section 5 of RF=
C
> >5763, not to the unexciting section number in the current draft.
>
> How would you fix section 10.3.1, where the old text refers to multiple
> sections (4., 4.1., etc)?
>

For the section 10.3.1 I would name it "Update to Section 4: SDP
Offerer/Answerer Procedures". I will make sure that "Section 4" points to
the RFC 7345 Section 4, not Section 4 in the current document. Within OLD
TEXT, I would not include "4. SDP Offerer/Answerer Procedures" since it is
already part of the common header and I would list sub-section heading,
such as "General" and Generating The Initial Offer" without section
numbers.  In the NEW TEXT I would put current text without "4. SDP
Offerer/Answerer Procedures".

I know this is not ideal but will remove the section number confusion. The
other options are:

a) Put prefix in front of each subsection such as "RFC 7345: 4.1. General"

b) For this particular update simply put "The content of RFC 7345 Section 4
SDP Offerer/Answerer Procedures is replaced in its entirety with the
following text:" and then put the new text without the heading.

In any case, the references from section names should be fixed to point to
original RFC, not to the current document.


> >4. I think there is a lot of confusion on the list about handling of
> >ClientHello before the answer is received. Should we
> >add the following text to section 5.2 or 5.4:
> >
> > If DTLS ClientHello message is received before the answer is received
> >ClientHello message MUST be cached, but not
> > processed. When the answer is received and if SDP 'setup' attribute in
> >the answer is 'passive', then DTLS handshake
> > MUST proceed by processing the cached DTLS ClientHello message. If SDP
> >'setup' attribute in the answer is 'active=C2=B9,
> > the cached DTLS ClientHello message must be discarded and offerer MUST
> >initiate a new DTLS handshake by sending a
> > DTLS ClientHello message towards the answerer.
>
> Is that supported by DTLS? Shouldn=C2=B9t it be considered an error if yo=
u
> receive a ClientHello that you shouldn=C2=B9t receive?
>
> Also, has the WG community agreed on the procedure you suggest? This WGLC
> is not about adding new functionality that has not been discussed.
>

Let me rephrase this as a more generic question. Section 5.2 currently says=
:

If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
'passive' attribute value, the offerer MUST be prepared to receive a DTLS
ClientHello message (if a new DTLS association is established by the
answerer) from the answerer before the offerer receives the SDP answer.


What does offerer supposed to do with the ClientHello which is received
before the answer? Does it suppose to proceed with the handshake or cache
it? Or do we prefer not to specify?

This is not a theoretical problem, since client will get DTLS ClientHello
before the answer on a large portion of the calls, since DTLS ClientHello
is sent at the same time as an answer. Answer typically needs to got to
signaling server and then back to offerer. ClientHello is sent directly
from answerer to offerer, so it has one less hop to travel. This is a race
condition and ClientHello has a shorter path to travel, especially when two
end points are located on the same local network, but the signaling server
is remote.

The problem with immediately proceeding with DTLS handshake is that in case
of full ICE or "pure" UDP, offerer does not know where to send ServerHello.
In case of full ICE, remote password is not known so consent to send cannot
be obtained. In case of of "pure" UDP, remote address is not known, since
end points do not have to use the same IP:port to send and receive data.

On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP, offerer
can send ServerHello. We can either allow offerer to proceed with DTLS
Handshake in these cases or specify that CleintHello should be cached
anyway and handshake should not be initiated until the answer is received.

Finally, there is the issue on what should be done if multiple ClientHello
messages are received due to either forking (sequential or parallel) or due
to a denial of service attack (if attacker knows that ClientHello can force
end point to initiate connection which will prevent legitimate connection
from running, it can spray the server with fake ClientHello messages). If
ClientHello is cached, then in combination with SDP UKS, cached ClientHello
messages can be correlated with answer SDP and fake ClientHello messages
discarded. Caching ClientHello can also cleanly resolve on what should
happen when answer with setup:passive is received after ClientHello (which
could be due to attack or forking).

I understand this issue should have been brought up earlier, but I have not
thought about it until Bernard brought up the issue of unverified media.
Which brings the question, should this draft propose the solution for the
unverified media issue and can this solution be just caching ClientHello
until answer is received?

Regards,

--94eb2c11ac32d8dec3054e29f863
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Christer,

On Thu, Apr=
 27, 2017 at 1:48 AM, Christer Holmberg <christer.holmberg@er=
icsson.com> wrote:
>3. I think =
in section 10 RFC Updates it would look better if the title of

>the section would be formatted like

>"10.2.1. Update to RFC 5763 Section 5: Establishing a Secure Chann=
el=C2=B2 and

>then "OLD TEXT:/NEW TEXT:" sections without

>titles or section numbers. This way section numbers from previous RFC
>will not interrupt section flow of the current

>document. Also, "RFC 5763 Section 5" should reference to sect=
ion 5 of RFC

>5763, not to the unexciting section number in the current draft.



How would you fix section 10.3.1, where the old text refers to multi=
ple

sections (4., 4.1., etc)?

For the secti=
on 10.3.1 I would name it "Update to Section 4: SDP Offerer/Answerer P=
rocedures". I will make sure that "Section 4" points to the =
RFC 7345 Section 4, not Section 4 in the current document. Within OLD TEXT,=
 I would not include "4. SDP Offerer/Answerer Procedures" since i=
t is already part of the common header and I would list sub-section heading=
, such as "General" and Generating The Initial Offer" withou=
t section numbers.=C2=A0 In the NEW TEXT I would put current text without &=
quot;4. SDP Offerer/Answerer Procedures".

I k=
now this is not ideal but will remove the section number confusion. The oth=
er options are:
=C2=A0
a) Put prefix in front of each s=
ubsection such as "RFC 7345: 4.1. General"

b) For this particular update simply put "The content of RFC 7345=C2=
=A0Section 4 SDP Offerer/Answerer Procedures is replaced in its entirety wi=
th the following text:" and then put the new text without the heading.=


In any case, the refer=
ences from section names should be fixed to point to original RFC, not to t=
he current document.
=C2=A0
>4. I thin=
k there is a lot of confusion on the list about handling of

>ClientHello before the answer is received. Should we

>add the following text to section 5.2 or 5.4:

>

> If DTLS ClientHello message is received before the answer is received<=
br>
>ClientHello message MUST be cached, but not

> processed. When the answer is received and if SDP 'setup' attr=
ibute in

>the answer is 'passive', then DTLS handshake

> MUST proceed by processing the cached DTLS ClientHello message.=
 If SDP

>'setup' attribute i=
n the answer is 'active=C2=B9,

> the cached DTLS ClientHello message must be discarded and offerer MUST=


>initiate a new DTLS handshake by sending a

> DTLS ClientHello message towards the answerer.



Is that supported by DTLS? Shouldn=C2=B9t it be considered an error =
if you

receive a ClientHello that you shouldn=C2=B9t receive?



Also, has the WG community agreed on the procedure you suggest? This WGLC
is not about adding new functionality that has not been discussed.

Let me rephrase this as a more generic question. Section 5.2 cu=
rrently says:

If the offerer inserts the SDP 'setup' attribute with an =
9;actpass' or 'passive' attribute value, the offerer MUST be pr=
epared to receive a DTLS ClientHello message (if a new DTLS association is =
established by the answerer) from the answerer before the offerer receives =
the SDP answer.

What does offerer s=
upposed to do with the ClientHello which is received before the answer? Doe=
s it suppose to proceed with the handshake or cache it? Or do we prefer not=
 to specify?

This is not a theoretical problem, since client will get DTLS Client=
Hello before the answer on a large portion of the calls, since DTLS ClientH=
ello is sent at the same time as an answer. Answer typically needs to got t=
o signaling server and then back to offerer. ClientHello is sent directly f=
rom answerer to offerer, so it has one less hop to travel. This is a race c=
ondition and ClientHello has a shorter path to travel, especially when two =
end points are located on the same local network, but the signaling server =
is remote.

The problem with immediately proceeding with DTLS handshake is that in=
 case of full ICE or "pure" UDP, offerer does not know where to s=
end ServerHello. In case of full ICE, remote password is not known so conse=
nt to send cannot be obtained. In case of of "pure" UDP, remote a=
ddress is not known, since end points do not have to use the same IP:port t=
o send and receive data.

On the other hand, in case of ICE Lite, ICE TCP passive,=
 and SCTP, offerer can send ServerHello. We can either allow offerer to pro=
ceed with DTLS Handshake in these cases or specify that CleintHello should =
be cached anyway and handshake should not be initiated until the answer is =
received.

Finally, there is the issue on what should be done if multiple ClientHe=
llo messages are received due to either forking (sequential or parallel) or=
 due to a denial of service attack (if attacker knows that ClientHello can =
force end point to initiate connection which will prevent legitimate connec=
tion from running, it can spray the server with fake ClientHello messages).=
 If ClientHello is cached, then in combination with SDP UKS, cached ClientH=
ello messages can be correlated with answer SDP and fake ClientHello messag=
es discarded. Caching ClientHello can also cleanly resolve on what should h=
appen when answer with setup:passive is received after ClientHello (which c=
ould be due to attack or forking).

I understand this issue should have been broug=
ht up earlier, but I have not thought about it until Bernard brought up the=
 issue of unverified media. Which brings the question, should this draft pr=
opose the solution for the unverified media issue and can this solution be =
just caching ClientHello until answer is received?

Regards,


--94eb2c11ac32d8dec3054e29f863--


From nobody Thu Apr 27 12:24:21 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E19F129B72; Thu, 27 Apr 2017 12:24:20 -0700 (PDT)
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 sYv13-agSOSj; Thu, 27 Apr 2017 12:24:18 -0700 (PDT)
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 CD1AC129ADE; Thu, 27 Apr 2017 12:20:48 -0700 (PDT)
X-AuditID: c1b4fb30-af94d9a000001047-2e-5902448e110a
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2E.83.04167.E8442095; Thu, 27 Apr 2017 21:20:46 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0339.000; Thu, 27 Apr 2017 21:20:01 +0200
From: Christer Holmberg 
To: Roman Shpount 
CC: Flemming Andreasen , mmusic , "draft-ietf-mmusic-dtls-sdp@ietf.org" 
Thread-Topic: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
Thread-Index: AQHSuqBQpUS/reyYTkmSRPXLKwFJlKHXx2EAgAEJXoCAAJ2TAIAALZIg
Date: Thu, 27 Apr 2017 19:19:59 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>   
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkkeLIzCtJLcpLzFFi42KZGbHdT7fPhSnSYMYPa4v/E+ezWry/oGsx dfljFosZF6YyO7B4TPm9kdVjyZKfTB63phQEMEdx2aSk5mSWpRbp2yVwZbx4M5m1YJZTxYut LawNjAccuhg5OSQETCR233zJ1sXIxSEkcIRRYuKnS1DOEkaJ9Ts3sHYxcnCwCVhIdP/TBmkQ EVCV+Pt9MhNIDbPAFEaJPUtvMYIkhAWCJToWH2ODKAqR2HDpDjOE7Sax7c8lMJsFqHnhyRWs IDavgK/EzYsX2CGW/WGUuLP1LxNIglMgUKL16kZ2EJtRQEzi+6k1YHFmAXGJW0/mM0GcLSCx ZM95ZghbVOLl43+sELaSROOSJ2BHMwtoSqzfpQ/RqigxpfshO8ReQYmTM5+wTGAUnYVk6iyE jllIOmYh6VjAyLKKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzCCDm75bbCD8eVzx0OMAhyM Sjy8CT8ZI4VYE8uKK3MPMUpwMCuJ8CobMUUK8aYkVlalFuXHF5XmpBYfYpTmYFES53XcdyFC SCA9sSQ1OzW1ILUIJsvEwSnVwOhV7t3HyT9Vb4L9wiCRiyyNmt7noyVXnc9e9XVGR/9jhfbd Sd6azlfPbX14yfzsyxOO5xaynT6ZzPajUdv6GutdVd17k+bP4Kjsne77I9eSrfHXA5H1/35J fP18e9l0Z9tvT4STIo8WitgJvGbNOaHmznUsUnH9H4+TPF8Lg0NXBLx8u7t05T4lluKMREMt 5qLiRABXIiOJnAIAAA==
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 19:24:21 -0000

SGksDQoNCj4+My4gSSB0aGluayBpbiBzZWN0aW9uIDEwIFJGQyBVcGRhdGVzIGl0IHdvdWxkIGxv
b2sgYmV0dGVyIGlmIHRoZSB0aXRsZSBvZg0KPj50aGUgc2VjdGlvbiB3b3VsZCBiZSBmb3JtYXR0
ZWQgbGlrZQ0KPj4iMTAuMi4xLiBVcGRhdGUgdG8gUkZDIDU3NjMgU2VjdGlvbiA1OiBFc3RhYmxp
c2hpbmcgYSBTZWN1cmUgQ2hhbm5lbMKyIGFuZA0KPj50aGVuICJPTEQgVEVYVDovTkVXIFRFWFQ6
IiBzZWN0aW9ucyB3aXRob3V0DQo+PnRpdGxlcyBvciBzZWN0aW9uIG51bWJlcnMuIFRoaXMgd2F5
IHNlY3Rpb24gbnVtYmVycyBmcm9tIHByZXZpb3VzIFJGQw0KPj53aWxsIG5vdCBpbnRlcnJ1cHQg
c2VjdGlvbiBmbG93IG9mIHRoZSBjdXJyZW50DQo+PmRvY3VtZW50LiBBbHNvLCAiUkZDIDU3NjMg
U2VjdGlvbiA1IiBzaG91bGQgcmVmZXJlbmNlIHRvIHNlY3Rpb24gNSBvZiBSRkMNCj4+NTc2Mywg
bm90IHRvIHRoZSB1bmV4Y2l0aW5nIHNlY3Rpb24gbnVtYmVyIGluIHRoZSBjdXJyZW50IGRyYWZ0
Lg0KPg0KPkhvdyB3b3VsZCB5b3UgZml4IHNlY3Rpb24gMTAuMy4xLCB3aGVyZSB0aGUgb2xkIHRl
eHQgcmVmZXJzIHRvIG11bHRpcGxlDQo+c2VjdGlvbnMgKDQuLCA0LjEuLCBldGMpPw0KPg0KPkZv
ciB0aGUgc2VjdGlvbiAxMC4zLjEgSSB3b3VsZCBuYW1lIGl0ICJVcGRhdGUgdG8gU2VjdGlvbiA0
OiBTRFAgT2ZmZXJlci9BbnN3ZXJlciBQcm9jZWR1cmVzIi4gSSB3aWxsIG1ha2Ugc3VyZSB0aGF0
ICJTZWN0aW9uIDQiIHBvaW50cyB0byB0aGUgUkZDIDczNDUgU2VjdGlvbiA0LCBub3QgPlNlY3Rp
b24gNCBpbiB0aGUgY3VycmVudCBkb2N1bWVudC4gV2l0aGluIE9MRCBURVhULCBJIHdvdWxkIG5v
dCBpbmNsdWRlICI0LiBTRFAgT2ZmZXJlci9BbnN3ZXJlciBQcm9jZWR1cmVzIiBzaW5jZSBpdCBp
cyBhbHJlYWR5IHBhcnQgb2YgdGhlIGNvbW1vbiBoZWFkZXIgYW5kIEkgd291bGQgPmxpc3Qgc3Vi
LXNlY3Rpb24gaGVhZGluZywgc3VjaCBhcyAiR2VuZXJhbCIgYW5kIEdlbmVyYXRpbmcgVGhlIElu
aXRpYWwgT2ZmZXIiIHdpdGhvdXQgc2VjdGlvbiBudW1iZXJzLg0KPg0KPkkga25vdyB0aGlzIGlz
IG5vdCBpZGVhbCBidXQgd2lsbCByZW1vdmUgdGhlIHNlY3Rpb24gbnVtYmVyIGNvbmZ1c2lvbi4g
VGhlIG90aGVyIG9wdGlvbnMgYXJlOg0KPg0KPmEpIFB1dCBwcmVmaXggaW4gZnJvbnQgb2YgZWFj
aCBzdWJzZWN0aW9uIHN1Y2ggYXMgIlJGQyA3MzQ1OiA0LjEuIEdlbmVyYWwiDQoNCkkgZG9uJ3Qg
bGlrZSB0aGF0LCBzaW5jZSB0aGUgTkVXIFRFWFQgd291bGQgYmUgZW1wdHkuDQoNCj5iKSBGb3Ig
dGhpcyBwYXJ0aWN1bGFyIHVwZGF0ZSBzaW1wbHkgcHV0ICJUaGUgY29udGVudCBvZiBSRkMgNzM0
NcKgU2VjdGlvbiA0IFNEUCBPZmZlcmVyL0Fuc3dlcmVyIFByb2NlZHVyZXMgaXMgcmVwbGFjZWQg
aW4gaXRzIGVudGlyZXR5IHdpdGggdGhlIGZvbGxvd2luZyB0ZXh0OiIgYW5kIHRoZW4gPnB1dCB0
aGUgbmV3IHRleHQgd2l0aG91dCB0aGUgaGVhZGluZy4NCj4NCj5JbiB0aGUgTkVXIFRFWFQgSSB3
b3VsZCBwdXQgY3VycmVudCB0ZXh0IHdpdGhvdXQgIjQuIFNEUCBPZmZlcmVyL0Fuc3dlcmVyIFBy
b2NlZHVyZXMiLg0KDQpJJ2QgcHJlZmVyIHNvbWV0aGluZyBsaWtlIHRoYXQ6IHNpbXBseSBhZGQg
dGV4dCBzYXlpbmcgdGhhdCBzdWItc2VjdGlvbnMgNC4xIC0gNC41IGFyZSByZW1vdmVkLCB3aXRo
b3V0IGFjdHVhbGx5IGluY2x1ZGluZyB0aGUgb2xkIHRleHQgaXRzZWxmLiANCg0KLS0tLS0NCsKg
DQo+Pj40LiBJIHRoaW5rIHRoZXJlIGlzIGEgbG90IG9mIGNvbmZ1c2lvbiBvbiB0aGUgbGlzdCBh
Ym91dCBoYW5kbGluZyBvZg0KPj4+Q2xpZW50SGVsbG8gYmVmb3JlIHRoZSBhbnN3ZXIgaXMgcmVj
ZWl2ZWQuIFNob3VsZCB3ZQ0KPj4+YWRkIHRoZSBmb2xsb3dpbmcgdGV4dCB0byBzZWN0aW9uIDUu
MiBvciA1LjQ6DQo+Pj4NCj4+PiBJZiBEVExTIENsaWVudEhlbGxvIG1lc3NhZ2UgaXMgcmVjZWl2
ZWQgYmVmb3JlIHRoZSBhbnN3ZXIgaXMgcmVjZWl2ZWQNCj4+PkNsaWVudEhlbGxvIG1lc3NhZ2Ug
TVVTVCBiZSBjYWNoZWQsIGJ1dCBub3QNCj4+PiBwcm9jZXNzZWQuIFdoZW4gdGhlIGFuc3dlciBp
cyByZWNlaXZlZCBhbmQgaWYgU0RQICdzZXR1cCcgYXR0cmlidXRlIGluDQo+Pj50aGUgYW5zd2Vy
IGlzICdwYXNzaXZlJywgdGhlbiBEVExTIGhhbmRzaGFrZQ0KPj4+IE1VU1QgcHJvY2VlZCBieSBw
cm9jZXNzaW5nIHRoZSBjYWNoZWQgRFRMUyBDbGllbnRIZWxsbyBtZXNzYWdlLiBJZiBTRFANCj4+
PidzZXR1cCcgYXR0cmlidXRlIGluIHRoZSBhbnN3ZXIgaXMgJ2FjdGl2ZcK5LA0KPj4+IHRoZSBj
YWNoZWQgRFRMUyBDbGllbnRIZWxsbyBtZXNzYWdlIG11c3QgYmUgZGlzY2FyZGVkIGFuZCBvZmZl
cmVyIE1VU1QNCj4+PmluaXRpYXRlIGEgbmV3IERUTFMgaGFuZHNoYWtlIGJ5IHNlbmRpbmcgYQ0K
Pj4+IERUTFMgQ2xpZW50SGVsbG8gbWVzc2FnZSB0b3dhcmRzIHRoZSBhbnN3ZXJlci4NCj4+DQo+
PklzIHRoYXQgc3VwcG9ydGVkIGJ5IERUTFM/IFNob3VsZG7CuXQgaXQgYmUgY29uc2lkZXJlZCBh
biBlcnJvciBpZiB5b3UNCj4+cmVjZWl2ZSBhIENsaWVudEhlbGxvIHRoYXQgeW91IHNob3VsZG7C
uXQgcmVjZWl2ZT8NCj4NCj5BbHNvLCBoYXMgdGhlIFdHIGNvbW11bml0eSBhZ3JlZWQgb24gdGhl
IHByb2NlZHVyZSB5b3Ugc3VnZ2VzdD8gVGhpcyBXR0xDDQo+aXMgbm90IGFib3V0IGFkZGluZyBu
ZXcgZnVuY3Rpb25hbGl0eSB0aGF0IGhhcyBub3QgYmVlbiBkaXNjdXNzZWQuDQo+DQo+PkxldCBt
ZSByZXBocmFzZSB0aGlzIGFzIGEgbW9yZSBnZW5lcmljIHF1ZXN0aW9uLiBTZWN0aW9uIDUuMiBj
dXJyZW50bHkgc2F5czoNCj4+SWYgdGhlIG9mZmVyZXIgaW5zZXJ0cyB0aGUgU0RQICdzZXR1cCcg
YXR0cmlidXRlIHdpdGggYW4gJ2FjdHBhc3MnIG9yICdwYXNzaXZlJyBhdHRyaWJ1dGUgdmFsdWUs
IHRoZSANCj4+b2ZmZXJlciBNVVNUIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgYSBEVExTIENsaWVu
dEhlbGxvIG1lc3NhZ2UgKGlmIGEgbmV3IERUTFMgYXNzb2NpYXRpb24gaXMgDQo+PmVzdGFibGlz
aGVkIGJ5IHRoZSBhbnN3ZXJlcikgZnJvbSB0aGUgYW5zd2VyZXIgYmVmb3JlIHRoZSBvZmZlcmVy
IHJlY2VpdmVzIHRoZSBTRFAgYW5zd2VyLg0KPj4NCj4+V2hhdCBkb2VzIG9mZmVyZXIgc3VwcG9z
ZWQgdG8gZG8gd2l0aCB0aGUgQ2xpZW50SGVsbG8gd2hpY2ggaXMgcmVjZWl2ZWQgYmVmb3JlIHRo
ZSBhbnN3ZXI/IA0KPj5Eb2VzIGl0IHN1cHBvc2UgdG8gcHJvY2VlZCB3aXRoIHRoZSBoYW5kc2hh
a2Ugb3IgY2FjaGUgaXQ/IE9yIGRvIHdlIHByZWZlciBub3QgdG8gc3BlY2lmeT8NCg0KV2UgY2Fu
IHBvaW50IG91dCB0aGF0IGl0IGNhbiBoYXBwZW4sIGJ1dCBJIGRvbid0IHRoaW5rIHdlIHNob3Vs
ZCBzcGVjaWZ5IHByb2NlZHVyZXMgaG93IHRvIGhhbmRsZSBpdC4gDQoNCj5UaGlzIGlzIG5vdCBh
IHRoZW9yZXRpY2FsIHByb2JsZW0sIHNpbmNlIGNsaWVudCB3aWxsIGdldCBEVExTIENsaWVudEhl
bGxvIGJlZm9yZSB0aGUgYW5zd2VyIG9uIGEgbGFyZ2UgcG9ydGlvbg0KPm9mIHRoZSBjYWxscywg
c2luY2UgRFRMUyBDbGllbnRIZWxsbyBpcyBzZW50IGF0IHRoZSBzYW1lIHRpbWUgYXMgYW4gYW5z
d2VyLiBBbnN3ZXIgdHlwaWNhbGx5IG5lZWRzIHRvIGdvdCB0bw0KPnNpZ25hbGluZyBzZXJ2ZXIg
YW5kIHRoZW4gYmFjayB0byBvZmZlcmVyLiBDbGllbnRIZWxsbyBpcyBzZW50IGRpcmVjdGx5IGZy
b20gYW5zd2VyZXIgdG8gb2ZmZXJlciwgc28gaXQgaGFzIG9uZQ0KPmxlc3MgaG9wIHRvIHRyYXZl
bC4gVGhpcyBpcyBhIHJhY2UgY29uZGl0aW9uIGFuZCBDbGllbnRIZWxsbyBoYXMgYSBzaG9ydGVy
IHBhdGggdG8gdHJhdmVsLCBlc3BlY2lhbGx5IHdoZW4gdHdvDQo+ZW5kIHBvaW50cyBhcmUgbG9j
YXRlZCBvbiB0aGUgc2FtZSBsb2NhbCBuZXR3b3JrLCBidXQgdGhlIHNpZ25hbGluZyBzZXJ2ZXIg
aXMgcmVtb3RlLg0KPg0KPlRoZSBwcm9ibGVtIHdpdGggaW1tZWRpYXRlbHkgcHJvY2VlZGluZyB3
aXRoIERUTFMgaGFuZHNoYWtlIGlzIHRoYXQgaW4gY2FzZSBvZiBmdWxsIElDRSBvciAicHVyZSIg
VURQLCANCj5vZmZlcmVyIGRvZXMgbm90IGtub3cgd2hlcmUgdG8gc2VuZCBTZXJ2ZXJIZWxsby4g
SW4gY2FzZSBvZiBmdWxsIElDRSwgcmVtb3RlIHBhc3N3b3JkIGlzIG5vdCBrbm93biBzbyANCj5j
b25zZW50IHRvIHNlbmQgY2Fubm90IGJlIG9idGFpbmVkLiBJbiBjYXNlIG9mIG9mICJwdXJlIiBV
RFAsIHJlbW90ZSBhZGRyZXNzIGlzIG5vdCBrbm93biwgc2luY2UgZW5kIA0KPnBvaW50cyBkbyBu
b3QgaGF2ZSB0byB1c2UgdGhlIHNhbWUgSVA6cG9ydCB0byBzZW5kIGFuZCByZWNlaXZlIGRhdGEu
DQo+DQo+T24gdGhlIG90aGVyIGhhbmQsIGluIGNhc2Ugb2YgSUNFIExpdGUsIElDRSBUQ1AgcGFz
c2l2ZSwgYW5kIFNDVFAsIG9mZmVyZXIgY2FuIHNlbmQgU2VydmVySGVsbG8uIFdlIGNhbg0KPmVp
dGhlciBhbGxvdyBvZmZlcmVyIHRvIHByb2NlZWQgd2l0aCBEVExTIEhhbmRzaGFrZSBpbiB0aGVz
ZSBjYXNlcyBvciBzcGVjaWZ5IHRoYXQgQ2xlaW50SGVsbG8gc2hvdWxkDQo+YmUgY2FjaGVkIGFu
eXdheSBhbmQgaGFuZHNoYWtlIHNob3VsZCBub3QgYmUgaW5pdGlhdGVkIHVudGlsIHRoZSBhbnN3
ZXIgaXMgcmVjZWl2ZWQuDQoNCldpdGggSUNFLCBkb24ndCB5b3UgaGF2ZSB0byBkbyBhdCBsZWFz
dCBvbmUgc3VjY2Vzc2Z1bCBjb25uZWN0aXZpdHkgY2hlY2sgYmVmb3JlIHlvdSBjYW4gc2VuZCBh
bnl0aGluZz8NCg0KPkZpbmFsbHksIHRoZXJlIGlzIHRoZSBpc3N1ZSBvbiB3aGF0IHNob3VsZCBi
ZSBkb25lIGlmIG11bHRpcGxlIENsaWVudEhlbGxvIG1lc3NhZ2VzIGFyZSByZWNlaXZlZCBkdWUg
dG8gZWl0aGVyDQo+Zm9ya2luZyAoc2VxdWVudGlhbCBvciBwYXJhbGxlbCkgb3IgZHVlIHRvIGEg
ZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrIChpZiBhdHRhY2tlciBrbm93cyB0aGF0IENsaWVudEhl
bGxvIGNhbiBmb3JjZQ0KPmVuZCBwb2ludCB0byBpbml0aWF0ZSBjb25uZWN0aW9uIHdoaWNoIHdp
bGwgcHJldmVudCBsZWdpdGltYXRlIGNvbm5lY3Rpb24gZnJvbSBydW5uaW5nLCBpdCBjYW4gc3By
YXkgdGhlIHNlcnZlcg0KPndpdGggZmFrZSBDbGllbnRIZWxsbyBtZXNzYWdlcykuIElmIENsaWVu
dEhlbGxvIGlzIGNhY2hlZCwgdGhlbiBpbiBjb21iaW5hdGlvbiB3aXRoIFNEUCBVS1MsIGNhY2hl
ZCBDbGllbnRIZWxsbw0KPm1lc3NhZ2VzIGNhbiBiZSBjb3JyZWxhdGVkIHdpdGggYW5zd2VyIFNE
UCBhbmQgZmFrZSBDbGllbnRIZWxsbyBtZXNzYWdlcyBkaXNjYXJkZWQuIENhY2hpbmcgQ2xpZW50
SGVsbG8gY2FuDQo+YWxzbyBjbGVhbmx5IHJlc29sdmUgb24gd2hhdCBzaG91bGQgaGFwcGVuIHdo
ZW4gYW5zd2VyIHdpdGggc2V0dXA6cGFzc2l2ZSBpcyByZWNlaXZlZCBhZnRlciBDbGllbnRIZWxs
byAod2hpY2gNCj5jb3VsZCBiZSBkdWUgdG8gYXR0YWNrIG9yIGZvcmtpbmcpLg0KDQpJIHRoaW5r
IE1hcnRpbidzIGRyYWZ0IGNvdWxkIHNheSB0aGF0IFNEUCBVS1MgY2FuIGJlIHVzZWQgdG8gZGV0
ZWN0IGZha2UgQ2xpZW50SGVsbG8gbWVzc2FnZXMuDQoNCj5JIHVuZGVyc3RhbmQgdGhpcyBpc3N1
ZSBzaG91bGQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAgZWFybGllciwgYnV0IEkgaGF2ZSBub3QgdGhv
dWdodCBhYm91dCBpdCB1bnRpbCBCZXJuYXJkDQo+YnJvdWdodCB1cCB0aGUgaXNzdWUgb2YgdW52
ZXJpZmllZCBtZWRpYS4gV2hpY2ggYnJpbmdzIHRoZSBxdWVzdGlvbiwgc2hvdWxkIHRoaXMgZHJh
ZnQgcHJvcG9zZSB0aGUgc29sdXRpb24NCj5mb3IgdGhlIHVudmVyaWZpZWQgbWVkaWEgaXNzdWUg
YW5kIGNhbiB0aGlzIHNvbHV0aW9uIGJlIGp1c3QgY2FjaGluZyBDbGllbnRIZWxsbyB1bnRpbCBh
bnN3ZXIgaXMgcmVjZWl2ZWQ/DQoNCkFzIE1hcnRpbiBzYWlkLCB0aGUgQ2xpZW50SGVsbG8gd2ls
bCBiZSByZS10cmFuc21pdHRlZCwgc28gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgbWFuZGF0ZSBj
YWNoaW5nLiBBcyBJIHNhaWQgYWJvdmUsIHdlIGNhbiBwb2ludCBvdXQgdGhhdCBpdCBjYW4gb2Nj
dXIsIGFuZCBpdCB3aWxsIHRoZW4gYmUgYW4gaW1wbGVtZW50YXRpb24gaXNzdWUgaG93IHRvIGhh
bmRsZSBpdC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg==


From nobody Thu Apr 27 12:56:21 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B047D129C07 for ; Thu, 27 Apr 2017 12:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level: 
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 eiJIFaP1QLev for ; Thu, 27 Apr 2017 12:56:14 -0700 (PDT)
Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 0CE42129C06 for ; Thu, 27 Apr 2017 12:53:02 -0700 (PDT)
Received: by mail-pf0-x236.google.com with SMTP id c198so36392738pfc.1 for ; Thu, 27 Apr 2017 12:53:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5pFm9U9TcQsY5toT2fkJrnjrppDzC1jcgNdiBcBf0o4=; b=KPBMk+0gOyivOx3OGdNOVKj8917O9mPG8w9mxwN9raAQHpJAXSkns8YzgNJl9pwl8d XNI7rJWDhJhkcV9K2f7b6Fr0pGVwev75nmpqw9S6l3CnPWn7fdfMIPeV946mnMdJEFcy eqj2kapv3CUZTFKQipTlrnWC7wDKtvJ4pH3QsaIjxDipUkPbTFa0/H87Q++AeON7qGAR O945q5QHNErFXlv7camvGlRX/IqeHUqHExxti798Mpinrm7eFGczm/Abm9JnIwOmPoJS /uBMYXRbryzey+RcsXmQGr7uhQ5gnbf52E8bAo0KxwnaMut5koQ7aSVfkDYKa9iJ6N1C otPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5pFm9U9TcQsY5toT2fkJrnjrppDzC1jcgNdiBcBf0o4=; b=p/nXgQiLD7vYhwos0tmEK+OYqv4PhOHbDpjCtjmPBOeVfkZpx22B/Fb8CsQsXhIOHE wIZtybqKKYDhloqiv6uMI98otGaG1A1DmzIVkeRGclM2cdTgbMh7ZFQ+rzoYuI7UXTd7 z0jHocdcJeeiHQGxOLKiKXyc0mopwQHS4ai3l6xS2Ffr9tQAmNMUGxpUOL946GNYU8Ax YO47E/9VySZ1wtU8YbzBVdZa1SxttDDAwMS0PjaQvzkC2o5rhRCs41SQ1GjZd2Dwc5eX ZJxEG2cy28B4hNJzQ7UvmDY4A94M3ykyCBTrAEMC/cdTOOJrnYrusC3Ofqdt2aXDbSOD GX2w==
X-Gm-Message-State: AN3rC/59I7zI4DrK2KXuf4NeEXz6HQbFU5RCDIbLEOnUfRoigcm/3Mvc eiGSxyat8wrW/g==
X-Received: by 10.99.167.71 with SMTP id w7mr7999374pgo.138.1493322781451; Thu, 27 Apr 2017 12:53:01 -0700 (PDT)
Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com. [209.85.192.176]) by smtp.gmail.com with ESMTPSA id f6sm6357920pfe.57.2017.04.27.12.53.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 12:53:00 -0700 (PDT)
Received: by mail-pf0-f176.google.com with SMTP id a188so36389110pfa.0; Thu, 27 Apr 2017 12:53:00 -0700 (PDT)
X-Received: by 10.99.97.209 with SMTP id v200mr7749912pgb.52.1493322780449; Thu, 27 Apr 2017 12:53:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.150 with HTTP; Thu, 27 Apr 2017 12:52:59 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>
From: Roman Shpount 
Date: Thu, 27 Apr 2017 15:52:59 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Christer Holmberg 
Cc: Flemming Andreasen , mmusic ,  "draft-ietf-mmusic-dtls-sdp@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c0cae32dd26d9054e2b4db6
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 27 Apr 2017 19:56:20 -0000

--94eb2c0cae32dd26d9054e2b4db6
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 27, 2017 at 3:19 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> >b) For this particular update simply put "The content of RFC 7345 Section
> 4 SDP Offerer/Answerer Procedures is replaced in its entirety with the
> following text:" and then >put the new text without the heading.
> >
> >In the NEW TEXT I would put current text without "4. SDP Offerer/Answerer
> Procedures".
>
> I'd prefer something like that: simply add text saying that sub-sections
> 4.1 - 4.5 are removed, without actually including the old text itself.
>

I do prefer this option since excessive quoting of now irrelevant text
makes the document harder to read.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

> >>Let me rephrase this as a more generic question. Section 5.2 currently
> says:
> >>If the offerer inserts the SDP 'setup' attribute with an 'actpass' or
> 'passive' attribute value, the
> >>offerer MUST be prepared to receive a DTLS ClientHello message (if a new
> DTLS association is
> >>established by the answerer) from the answerer before the offerer
> receives the SDP answer.
> >>
> >>What does offerer supposed to do with the ClientHello which is received
> before the answer?
> >>Does it suppose to proceed with the handshake or cache it? Or do we
> prefer not to specify?
>
> We can point out that it can happen, but I don't think we should specify
> procedures how to handle it.
>

The text in section 5.2 already says that client MUST be prepared to
receive DTLS ClientHello, so it is should be obvious that this can happen.
What the text does not do is say what should be done with this ClientHello.
I guess you are suggesting this can be left unspecified.


> >This is not a theoretical problem, since client will get DTLS ClientHello
> before the answer on a large portion
> >of the calls, since DTLS ClientHello is sent at the same time as an
> answer. Answer typically needs to got to
> >signaling server and then back to offerer. ClientHello is sent directly
> from answerer to offerer, so it has one
> >less hop to travel. This is a race condition and ClientHello has a
> shorter path to travel, especially when two
> >end points are located on the same local network, but the signaling
> server is remote.
> >
> >The problem with immediately proceeding with DTLS handshake is that in
> case of full ICE or "pure" UDP,
> >offerer does not know where to send ServerHello. In case of full ICE,
> remote password is not known so
> >consent to send cannot be obtained. In case of of "pure" UDP, remote
> address is not known, since end
> >points do not have to use the same IP:port to send and receive data.
> >
> >On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP,
> offerer can send ServerHello. We can
> >either allow offerer to proceed with DTLS Handshake in these cases or
> specify that CleintHello should
> >be cached anyway and handshake should not be initiated until the answer
> is received.
>
> With ICE, don't you have to do at least one successful connectivity check
> before you can send anything?
>

With ICE lite end point can send data as soon as it received a connectivity
check, so it is definitely possible to establish a DTLS association before
the answer to an offer from ICE lite end point is received. This is a
security and implementation issue, so it would be nice to specify what
should be done here.


> >Finally, there is the issue on what should be done if multiple
> ClientHello messages are received due to either
> >forking (sequential or parallel) or due to a denial of service attack (if
> attacker knows that ClientHello can force
> >end point to initiate connection which will prevent legitimate connection
> from running, it can spray the server
> >with fake ClientHello messages). If ClientHello is cached, then in
> combination with SDP UKS, cached ClientHello
> >messages can be correlated with answer SDP and fake ClientHello messages
> discarded. Caching ClientHello can
> >also cleanly resolve on what should happen when answer with setup:passive
> is received after ClientHello (which
> >could be due to attack or forking).
>
> I think Martin's draft could say that SDP UKS can be used to detect fake
> ClientHello messages.
>

I agree, we can leave the multiple ClientHello handling for martin's draft.


> >I understand this issue should have been brought up earlier, but I have
> not thought about it until Bernard
> >brought up the issue of unverified media. Which brings the question,
> should this draft propose the solution
> >for the unverified media issue and can this solution be just caching
> ClientHello until answer is received?
>
> As Martin said, the ClientHello will be re-transmitted, so I don't think
> we should mandate caching. As I said above, we can point out that it can
> occur, and it will then be an implementation issue how to handle it.


If ClientHello is not cached, connection setup will be delayed by 5 sec
(DTLS re-transmit timer). This is quite noticeable and produces negative
client experience. So, caching or immediate handling is desired. If
ClientHello is cached, this will work with full ICE and will prevent
unverified media.

Regards,
______________
Roman Shpount

--94eb2c0cae32dd26d9054e2b4db6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



On Thu, Apr 27, 2017 at 3:19 PM, Christer Holmberg <c=
hrister.holmberg@ericsson.com> wrote:
>b) For this particular update simply put &q=
uot;The content of RFC 7345=C2=A0Section 4 SDP Offerer/Answerer Procedures =
is replaced in its entirety with the following text:" and then >put=
 the new text without the heading.

>

>In the NEW TEXT I would put current text withou=
t "4. SDP Offerer/Answerer Procedures".



I'd prefer something like that: simply add text saying that sub-=
sections 4.1 - 4.5 are removed, without actually including the old text its=
elf.

I do prefer this option since exce=
ssive quoting of now irrelevant text makes the document harder to read.
=C2=A0
=C2=A0
++++++++++++++++++++++++++++++++++=
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++=
++++++++++++++++
>&=
gt;Let me rephrase this as a more generic question. Section 5.2 currently s=
ays:

>>If the offerer inserts the SDP 'setup' attribute with an &#=
39;actpass' or 'passive' attribute value, the

>>offerer MUST be prepared to receive a DTLS ClientHello message (if =
a new DTLS association is

>>established by the answerer) from the answerer before the offerer r=
eceives the SDP answer.

>>

>>What does offerer supposed to do with the ClientHello which is rece=
ived before the answer?

>>Does it suppose to proceed with the handshake or cache it? Or do we=
 prefer not to specify?



We can point out that it can happen, but I don't think we should=
 specify procedures how to handle it.

T=
he text in section 5.2 already says that client MUST be prepared to receive=
 DTLS ClientHello, so it is should be obvious that this can happen. What th=
e text does not do is say what should be done with this ClientHello. I gues=
s you are suggesting this can be left unspecified.
=C2=A0
>This is not a theoretical=
 problem, since client will get DTLS ClientHello before the answer on a lar=
ge portion

>of the calls, since DTLS ClientHello is sent at the same time as an ans=
wer. Answer typically needs to got to

>signaling server and then back to offerer. ClientHello is sent directly=
 from answerer to offerer, so it has one

>less hop to travel. This is a race condition and ClientHello has a shor=
ter path to travel, especially when two

>end points are located on the same local network, but the signaling ser=
ver is remote.

>

>The problem with immediately proceeding with DTLS handshake is that in =
case of full ICE or "pure" UDP,

>offerer does not know where to send ServerHello. In case of full ICE, r=
emote password is not known so

>consent to send cannot be obtained. In case of of "pure" UDP,=
 remote address is not known, since end

>points do not have to use the same IP:port to send and receive data.
>

>On the other hand, in case of ICE Lite, ICE TCP passive, and SCTP, offe=
rer can send ServerHello. We can

>either allow offerer to proceed with DTLS Handshake in these cases or s=
pecify that CleintHello should

>be cached anyway and handshake should not be initiated until the answer=
 is received.



With ICE, don't you have to do at least one successful connectiv=
ity check before you can send anything?

With ICE lite end point can send data as soon as it received a connectivit=
y check, so it is definitely possible to establish a DTLS association befor=
e the answer to an offer from ICE lite end point is received. This is a sec=
urity and implementation issue, so it would be nice to specify what should =
be done here.
=C2=A0
>Finally, there is the issue on what should be done if multiple=
 ClientHello messages are received due to either

>forking (sequential or parallel) or due to a denial of service attack (=
if attacker knows that ClientHello can force

>end point to initiate connection which will prevent legitimate connecti=
on from running, it can spray the server

>with fake ClientHello messages). If ClientHello is cached, then in comb=
ination with SDP UKS, cached ClientHello

>messages can be correlated with answer SDP and fake ClientHello message=
s discarded. Caching ClientHello can

>also cleanly resolve on what should happen when answer with setup:passi=
ve is received after ClientHello (which

>could be due to attack or forking).



I think Martin's draft could say that SDP UKS can be used to det=
ect fake ClientHello messages.

I agree,=
 we can leave the multiple ClientHello handling for martin's draft.
=C2=A0
>I un=
derstand this issue should have been brought up earlier, but I have not tho=
ught about it until Bernard

>brought up the issue of unverified media. Which brings the question, sh=
ould this draft propose the solution

>for the unverified media issue and can this solution be just caching Cl=
ientHello until answer is received?



As Martin said, the ClientHello will be re-transmitted, so I don'=
;t think we should mandate caching. As I said above, we can point out that =
it can occur, and it will then be an implementation issue how to handle it.=


If ClientHello is not cached, connection s=
etup will be delayed by 5 sec (DTLS re-transmit timer). This is quite notic=
eable and produces negative client experience. So, caching or immediate han=
dling is desired. If ClientHello is cached, this will work with full ICE an=
d will prevent unverified media.=C2=A0

Regards,
______________
Roman Shpount=C2=A0


--94eb2c0cae32dd26d9054e2b4db6--


From nobody Thu Apr 27 17:44:55 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2107F129C0B; Thu, 27 Apr 2017 17:44:53 -0700 (PDT)
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 Tq5ZUkgHOdNz; Thu, 27 Apr 2017 17:44:51 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 8AA3B12871F; Thu, 27 Apr 2017 17:42:12 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id t144so26093467lff.1; Thu, 27 Apr 2017 17:42:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uW8mIorGQe+iiAFcqkW6QnZeRYb4mV2h+4AqrqqJRQA=; b=Lg33Ur33kRc6W/olPfrPRx8MOdzJvpo80Rc6qqAZ8CgBB6W1EvVyZpSmqMfC78HcMp YEcIRItftOkcklasCHBc6GDQ7BCVF9VsJf+hY1yRtpQGSfoMgvxcRsXRyOxUi6lft9JM axRQZmx7/BrdCKzLTg3Anm3uroCURooXO1arW5fdipKx68EHgWKOY+XAOqZL08OANVlm rw1yIJzia2yK4Xp7cn+Fg0W/U+tvfBLus2/xxyUrolQjM4ijPS7vM8qBG0NTlf+/s0Rp 0TpQlaewEYgLOgqnNw5poxCQPKS9cHb0cScegINXAnwE7WSBQdWrMDmhBC09RGy+m9Mn HDyQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uW8mIorGQe+iiAFcqkW6QnZeRYb4mV2h+4AqrqqJRQA=; b=D0G2V8qur3uZJW6/G2i3jllU2I0On3JAScxw5dUY5JVow1ccBYM79LXL3i3BcN0R6d Kc4R2ixK4FhdMLX3AlErGYF3Lbp3N3xN6roXi/58Biu6woGwTlueio8NKyKzu5vtIxFN IOpMnq+1kHsvelw/dFvvgigflvjPx2jrlieLs6ti8EYVcgAy3xfEJDD+BjSS8LCukfik k9phmdfQbo3vDlF0c3Ncj1rZG35mpZk9eIta2XkXLRCDK9Fbd5s0AJ7l44xXa1scsvtq 7DwouZ9CO7fvMASmbvfjXASVLGtBL3XG6yYKJzfgGuQsolI0k0Xn4Xzdtpvw1f0OI5ZC Amqg==
X-Gm-Message-State: AN3rC/5UN/qjzktzRaXVPgXtHUGfwyvOJPW/eqlPG3g1K3fhhr9j3p++ WNPgWVtEa+BnBxYKY5IZdXq1VDiueQ==
X-Received: by 10.25.79.27 with SMTP id d27mr2649678lfb.76.1493340130753; Thu, 27 Apr 2017 17:42:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Thu, 27 Apr 2017 17:42:09 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>      
From: Martin Thomson 
Date: Fri, 28 Apr 2017 10:42:09 +1000
Message-ID: 
To: Christer Holmberg 
Cc: Roman Shpount , Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 00:44:53 -0000

On 27 April 2017 at 21:38, Christer Holmberg
 wrote:
>
> Fair enough. So, do we want to say that the offerer may complete the
> handshake, and buffer received data, before it has received the answer,
> but the offerer shall not process received data, or send data, before it
> has received the answer?

"MAY buffer received packets" might be better.  As the later
discussion shows, processing the ClientHello risks skipping the UKS
checks, so that would be unwise.  And Roman points out assymmetric
paths (I suppose that could happen; though it seems unwise that never
stopped anyone before).


From nobody Thu Apr 27 17:47:43 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213E4129B89; Thu, 27 Apr 2017 17:47:42 -0700 (PDT)
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 9cU4Yo98P8wt; Thu, 27 Apr 2017 17:47:41 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 8F684129C00; Thu, 27 Apr 2017 17:44:52 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id c80so26032659lfh.3; Thu, 27 Apr 2017 17:44:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OUp0+VfvJ3v75e3aun8R1Qy6j/FxjbpBqHM40oOaF7s=; b=kDQiMjvfa8ti9IU+jDcgVB4DmSJbwOhQpvHJIzq3YPcIH/UBLoeFwxparJXAZjIJmh KdkkOQDUcmrSyXSRaTFOFpz/wrECQYeaWBFvHyPthEB1396vsvryTORJ1p2BafPFpv/V SVz1NgJjIUBKsV272OuLKywEHSmPpxwECbW40tyin3aaxbRJYaKtBBCDpgsCA0fxC1xt N2OIfmOuBwp7pfa7ph1IWvMx0CHPVupDRe3iAbpVcSQI/kLQM7YhLy1YrvQTN5xm+C4Z JNCR2ClEOW257gFkF/8LC/drKABWlVp5y+GaM9B4l8i3Rn2i6iiSh2ev4UMuXCk+AwwH JsrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OUp0+VfvJ3v75e3aun8R1Qy6j/FxjbpBqHM40oOaF7s=; b=PCopm3iInWVMDUOBY5RlrOFEo1V8GDITfXQaLqHuI6jUHiHVaMm9Yv80uI9tiMRSEa 3NIKTs8V+Ukze6wunhUwjbjtqjFyqfjJau0IH5V+iEtpmPDCgxbncE/suuhaIwSKxjDb MVasvjgzncLXaH7qFS/v1FYmMBSfpdXTgJMF5NCjfi5626AhYOwmgSiHTE+ELwaPu2XL vj+u7hyZb0TdIk5I53F1xgxNJVOn4FDb/ndw+g/C6b8PfihlQwBGiqktuP/3qxp6/3MF TJG+TlBJRa3mGNaDZSBXFxGCpaMff6hquuXeaqS6nZ6pzzgVMdbMVjIJQNSweta9uvhP yLzA==
X-Gm-Message-State: AN3rC/4yLW+eBOQ+/4qivq5legWdNzb09IjDSgs4emkeUTofoIMyfJxE z4q+AHuxpzlmZELhPaaqgwsRv826QA==
X-Received: by 10.25.160.147 with SMTP id j141mr2635554lfe.19.1493340290937; Thu, 27 Apr 2017 17:44:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Thu, 27 Apr 2017 17:44:50 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se> 
From: Martin Thomson 
Date: Fri, 28 Apr 2017 10:44:50 +1000
Message-ID: 
To: Roman Shpount 
Cc: Christer Holmberg , Flemming Andreasen ,  "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 00:47:42 -0000

On 28 April 2017 at 05:52, Roman Shpount  wrote:
> If ClientHello is not cached, connection setup will be delayed by 5 sec
> (DTLS re-transmit timer). This is quite noticeable and produces negative
> client experience. So, caching or immediate handling is desired. If
> ClientHello is cached, this will work with full ICE and will prevent
> unverified media.

If you are retransmitting ClientHello at 5 seconds, you are going to
have a really bad time.  NSS is a tad aggressive, but our first
retransmit is at 50ms (QUIC recommends 200ms I think).  Even TCP isn't
that slow.  Packet loss happens and 5 seconds is well beyond the point
that users give up.

In general, I agree that caching is going to give better performance.
We can recommend it, but I wouldn't mandate it.


From nobody Thu Apr 27 17:51:23 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC89127275 for ; Thu, 27 Apr 2017 17:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level: 
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-com.20150623.gappssmtp.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 OjYHUML7ExH6 for ; Thu, 27 Apr 2017 17:51:20 -0700 (PDT)
Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (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 433F3129487 for ; Thu, 27 Apr 2017 17:48:20 -0700 (PDT)
Received: by mail-pf0-x22a.google.com with SMTP id i4so4282649pfc.0 for ; Thu, 27 Apr 2017 17:48:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aIAedTGYWa3IS+hA7/xVTSofc3pfwuUDK954jFvwwLg=; b=sRqLHZk5RM3rwSxGC9yM/7IOt0KtI2TyNhx12SyRUhyxHD9ijTrA39SYin/df+ia8z 5aqCGeouf/W2nZ0Zzyj2uUV8e7hymW2kvl+IGJHJsstQ6vbjYPtYBF85x/Py0QBRHwFT S30jGX9jM2FO0RoKABOnMr1a/ZM1M1RIQ/mPExEI3LaX6FFR7NQtVa9MAWrPrOhms8nN kt4YXke6yATIktMkfCpzNWX/+S2FfzgcDaCm0szKaniEREYxuEC9gdWH9/gq0EDx70Zk Vq+H+uWsz/TccD9AjG+bUyVD0RLCYqe9WVUSQrKkJjaOZ+KB7+s8vYf1Zbp4c/DjjU3s ZuKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aIAedTGYWa3IS+hA7/xVTSofc3pfwuUDK954jFvwwLg=; b=NFjuHE+IDynv6I53vzOD3D/+wXzMfjWX2sz1axt9SVEJKW/sEkRQnPqJnglGJ5TBEf AqiEmhOTe/aAs0CG2xj99zYQXwkqGyo/7bA0L+w5UEiUF6hjQL8wbAa0hAgsKZAMV4is 8tVI7G6L10hOra/3oPicZjZ2RS1/zp+d/94+YxK1iJybXhjvLEp2K5nrDe2bOpR4DHen Yw0F67sMKpN77pshxgsk8tEPX1fVhlIzO2lBXAgFJwctd9wLxglAyUOyf5H8vSOemh61 eC30EeWlX8+wiLn0AFRTTLgxL6MiJmlOkap/ZmqTzkNDofLyz8vCFNfNAZM3lL2p8GQG /zJA==
X-Gm-Message-State: AN3rC/6kc5b8ytEOOEzys3vd84kBaXHYjqHruNLKOHiqz1zJK2mexaMd XLObdTENWrn8OQ==
X-Received: by 10.84.192.129 with SMTP id c1mr11108690pld.170.1493340499822; Thu, 27 Apr 2017 17:48:19 -0700 (PDT)
Received: from mail-pg0-f49.google.com (mail-pg0-f49.google.com. [74.125.83.49]) by smtp.gmail.com with ESMTPSA id x9sm7322166pff.98.2017.04.27.17.48.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Apr 2017 17:48:19 -0700 (PDT)
Received: by mail-pg0-f49.google.com with SMTP id y4so986630pge.0; Thu, 27 Apr 2017 17:48:18 -0700 (PDT)
X-Received: by 10.98.252.72 with SMTP id e69mr8843621pfh.247.1493340498745; Thu, 27 Apr 2017 17:48:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.130.150 with HTTP; Thu, 27 Apr 2017 17:48:18 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>  
From: Roman Shpount 
Date: Thu, 27 Apr 2017 20:48:18 -0400
X-Gmail-Original-Message-ID: 
Message-ID: 
To: Martin Thomson 
Cc: Christer Holmberg , Flemming Andreasen ,  "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: multipart/alternative; boundary=001a1141f7dcf4e75f054e2f6def
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 00:51:22 -0000

--001a1141f7dcf4e75f054e2f6def
Content-Type: text/plain; charset=UTF-8

On Thu, Apr 27, 2017 at 8:44 PM, Martin Thomson 
wrote:

> On 28 April 2017 at 05:52, Roman Shpount  wrote:
> > If ClientHello is not cached, connection setup will be delayed by 5 sec
> > (DTLS re-transmit timer). This is quite noticeable and produces negative
> > client experience. So, caching or immediate handling is desired. If
> > ClientHello is cached, this will work with full ICE and will prevent
> > unverified media.
>
> If you are retransmitting ClientHello at 5 seconds, you are going to
> have a really bad time.  NSS is a tad aggressive, but our first
> retransmit is at 50ms (QUIC recommends 200ms I think).  Even TCP isn't
> that slow.  Packet loss happens and 5 seconds is well beyond the point
> that users give up.
>

I think 5 sec is default for opensips, but I might be wrong.

In general, I agree that caching is going to give better performance.
> We can recommend it, but I wouldn't mandate it.
>

I would suggest that we say that ClientHello may be cached, but DTLS
handshake MUST NOT start until answer is received.

Regards,
_____________
Roman Shpount

--001a1141f7dcf4e75f054e2f6def
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On Thu, Apr 27, 2017 at 8:44 PM, Martin Thomson <=
martin.thomso=
n@gmail.com> wrote:
O=
n 28 April 2017 at 05:52, Roman Shpount <roman@telurix.com> wrote:

> If ClientHello is not cached, connection setup will be delayed by 5 se=
c

> (DTLS re-transmit timer). This is quite noticeable and produces negati=
ve

> client experience. So, caching or immediate handling is desired. If
> ClientHello is cached, this will work with full ICE and will prevent
> unverified media.



If you are retransmitting ClientHello at 5 seconds, you are going to=


have a really bad time.=C2=A0 NSS is a tad aggressive, but our first

retransmit is at 50ms (QUIC recommends 200ms I think).=C2=A0 Even TCP isn&#=
39;t

that slow.=C2=A0 Packet loss happens and 5 seconds is well beyond the point=


that users give up.
=C2=A0
I think 5 sec is =
default for opensips, but I might be wrong.

In general, I agree that caching is =
going to give better performance.

We can recommend it, but I wouldn't mandate it.



I would suggest tha=
t we say that ClientHello may be cached, but DTLS handshake MUST NOT start =
until answer is received.

Regards,
_____________
Roman Shpount



--001a1141f7dcf4e75f054e2f6def--


From nobody Thu Apr 27 17:52:38 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D071129454; Thu, 27 Apr 2017 17:52:37 -0700 (PDT)
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 f2nGs1OjcFhb; Thu, 27 Apr 2017 17:52:35 -0700 (PDT)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (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 4290A1294A9; Thu, 27 Apr 2017 17:49:30 -0700 (PDT)
Received: by mail-lf0-x236.google.com with SMTP id c80so26064365lfh.3; Thu, 27 Apr 2017 17:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dHsco1iumD95Q8DvJVlTD0sIlQfhoRltt/rkDS5TCzI=; b=FFz4gT0Sg07q9qzXi+YMHPd+cAagZzrghBulugXCM9ylm6Nw+E5vR5SxSwrFbxS1pR HmJZJe/fZwfq5i3O5HC67tYP1zi9xLIbcdQWWYwZCJ4Nrp0mev/od7FLqfMAIfQa3Ufn XeWm7AXMVuCl+WrHwTxihihZviuTup4awfeJ/MSRZWkwR/DAA0mB/opcS1YoalYWFpiU MCXhqscdC5zQCeKj23REV4/jO/0fZ2hBV/wEowlm+eUDf62vEyOahW+Egt7ONfqxYvX3 DES8+suYFVUoGcjZ9AQ2lEK+zykwhqhe6LzYHbXoa6NAlywSahUMw/MbXhcWh6YjGv0S dGzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dHsco1iumD95Q8DvJVlTD0sIlQfhoRltt/rkDS5TCzI=; b=oBpp+QBkPqLyepCWAq726hxa5UeTBtj2SfECtBnKt7PYZQyhZ4CtWIGHJTuKttjoIZ zRuktEXDz762SV50WUku6DzJnlH2mliaOKYYruB3peZ9h9YVuxEYmTAz44nHXQc8HTvI JOp4g1Bq0r9GqF28fmBJ9IueuAzvEsLHJXimlfs6w+dJUVdCuYrEnSOk2xcyffxETibV bzspbVkNETvF5bfu6Su/RCX8/LbbaxXUR4u+SRXG25Vgs6A6f6T3qK6vH8pyeUWnky+u VaHd0a9rEbPcdw9RyBtgO4SBGfUGZsJMc681EWhcTS1/YVRgxetVCh6T/AMgZnl2LDNc VY8A==
X-Gm-Message-State: AN3rC/4hWyNYw+VXGgWBEpI2zViASYsmVeawDXTg5uUk/JgSFQu0jV6f eyRqZ+pdIblqKpwjJA76F0b2lhxACQ==
X-Received: by 10.25.76.6 with SMTP id z6mr2957431lfa.172.1493340568664; Thu, 27 Apr 2017 17:49:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.46.83.2 with HTTP; Thu, 27 Apr 2017 17:49:28 -0700 (PDT)
In-Reply-To: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>   
From: Martin Thomson 
Date: Fri, 28 Apr 2017 10:49:28 +1000
Message-ID: 
To: Roman Shpount 
Cc: Christer Holmberg , Flemming Andreasen ,  "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 00:52:37 -0000

On 28 April 2017 at 10:48, Roman Shpount  wrote:
> I would suggest that we say that ClientHello may be cached, but DTLS
> handshake MUST NOT start until answer is received.

SGTM.


From nobody Fri Apr 28 00:38:44 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2973129BBD; Fri, 28 Apr 2017 00:38:42 -0700 (PDT)
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 63i5Jx6ym9th; Fri, 28 Apr 2017 00:38:41 -0700 (PDT)
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 48A3A129C6D; Fri, 28 Apr 2017 00:35:38 -0700 (PDT)
X-AuditID: c1b4fb2d-b25ff7000000196b-cf-5902f0c64912
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.AE.06507.6C0F2095; Fri, 28 Apr 2017 09:35:36 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0339.000; Fri, 28 Apr 2017 09:35:34 +0200
From: Christer Holmberg 
To: Martin Thomson , Roman Shpount 
CC: Flemming Andreasen , "draft-ietf-mmusic-dtls-sdp@ietf.org" , mmusic 
Thread-Topic: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
Thread-Index: AQHSuqBQpUS/reyYTkmSRPXLKwFJlKHXx2EAgAEJXoCAAJ2TAIAALZIg///tEoCAAFGLAIAAAPgAgAAAUwCAAKUXgA==
Date: Fri, 28 Apr 2017 07:35:33 +0000
Message-ID: 
References: <580940e1-4248-2903-b6e0-9ea440d83867@cisco.com>    <7594FB04B1934943A5C02806D1A2204B4CB893FA@ESESSMB109.ericsson.se>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="us-ascii"
Content-ID: 
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOIsWRmVeSWpSXmKPExsUyM2K7ou6JD0yRBu2PRC3+T5zPavH+gq7F tTP/GC2mLn/MYjHjwlRmB1aPKb83snrsnHWX3WPJkp9MHremFASwRHHZpKTmZJalFunbJXBl 3Fx0k7WghblibuNjpgbGXUxdjJwcEgImEqsvz2fvYuTiEBI4wihxYe8nFghnCaPE7rMLWbsY OTjYBCwkuv9pgzSICARJPHz4GKyGWWAao8SUjzsYQRLCAsEShzetYIIoCpHYcOkOM4SdJfH0 1it2EJtFQFVi845bYDW8AtYSh3e/gFp2h0Xicf9EsAZOgUCJr2cnsoDYjAJiEt9PrQFrYBYQ l7j1ZD7U2QISS/acZ4awRSVePv7HCmKLCuhJ7Pv3lQ0irijR/rSBEaJXR2LB7k9sIM8wAy2+ 8zAKIqwtsWzha2aIewQlTs58wjKBUXwWkm2zkHTPQuiehaR7FpLuBYysqxhFi1OLi3PTjYz1 Uosyk4uL8/P08lJLNjECo/Pglt+6OxhXv3Y8xCjAwajEw5vwkzFSiDWxrLgy9xCjBAezkgiv ZCJTpBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFeh30XIoQE0hNLUrNTUwtSi2CyTBycUg2MSQ+X Sh87GsftwjQ58s0rZ7c7pz0iljydJrh7neSHg2mlnkY3HeKqEzwNg/TE+j5y1jRmOsVMi0l5 sj/r+EL2g4p6xhVbV4QcbjrwUbKa7XpVp+Wxi89YGE58u7HdebfomqAK9UPfN1Vu5koTEfo6 s2my/43oCbwGra8bJO2PqkWIvhM+KPtLiaU4I9FQi7moOBEAIthSQ8oCAAA=
Archived-At: 
Subject: Re: [MMUSIC] 1-week WGLC on recent changes in draft-ietf-mmusic-dtls-sdp
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 07:38:43 -0000

Pull request created:

https://github.com/cdh4u/draft-dtls-sdp/pull/31


Regards,

Christer


On 28/04/17 03:49, "Martin Thomson"  wrote:

>On 28 April 2017 at 10:48, Roman Shpount  wrote:
>> I would suggest that we say that ClientHello may be cached, but DTLS
>> handshake MUST NOT start until answer is received.
>
>SGTM.


From nobody Fri Apr 28 02:59:55 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98F68129464 for ; Fri, 28 Apr 2017 02:59:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level: 
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 A6hNsaQTBkol for ; Fri, 28 Apr 2017 02:59:53 -0700 (PDT)
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 0F3BA129450 for ; Fri, 28 Apr 2017 02:57:13 -0700 (PDT)
X-AuditID: c1b4fb2d-eff839a00000196b-66-590311f87eb3
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 80.52.06507.8F113095; Fri, 28 Apr 2017 11:57:12 +0200 (CEST)
Received: from ESESSMB109.ericsson.se ([169.254.9.104]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0339.000; Fri, 28 Apr 2017 11:56:46 +0200
From: Christer Holmberg 
To: "mmusic@ietf.org" 
Thread-Topic: RFC 5761 updated by both draft-mux-exclusive and RFC 8035
Thread-Index: AQHSwAW/bFONqGwgCkelI/jotUkR9A==
Date: Fri, 28 Apr 2017 09:56:45 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.7.2.170228
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_D528EDAA1BDBDchristerholmbergericssoncom_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2K7ru4PQeZIgyOL+S2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKX/PjEV7PStWHVAq4Fxk0MXIyeHhICJxM9ft9lBbCGBI4wS N8+7dTFyAdlLGCV+TLsIlODgYBOwkOj+pw1SIyKgLvF1bw8ziC0s4CQxc+ojZoi4u0TL0sWM ELaexMvlb8DiLAKqEq3zNrOB2LwC1hJ/Tt4Eq2EUEJP4fmoNE4jNLCAucevJfCaIewQkluw5 zwxhi0q8fPyPFcQWBZq5799XNoi4osTV6cuhehMkLh1ZywgxX1Di5MwnLBMYhWYhGTsLSdks JGUQcR2JBbs/sUHY2hLLFr5mhrHPHHgM1Wst8f38ShZkNQsYOVYxihanFhfnphsZ66UWZSYX F+fn6eWllmxiBMbJwS2/dXcwrn7teIhRgINRiYc34SdjpBBrYllxZe4hRgkOZiUR3s4/TJFC vCmJlVWpRfnxRaU5qcWHGKU5WJTEeR32XYgQEkhPLEnNTk0tSC2CyTJxcEo1MJbxvZnA9Vw8 qe+swISmf7PPXFh06YHDc7Uyi212F1X8ehQManksH/XfM9OpW/0qNvnXp2uTl8bpfNJP+t6+ ujp5a3VV2/3GMok4j4SG2aqtQpdez11Rsebrr/2r23bv+nVyfsL8vvdndwfJVnHefPC5XETH +q7MjiX3JvQW9LQd+XTaqDvGQ02JpTgj0VCLuag4EQDAbb8fjwIAAA==
Archived-At: 
Subject: [MMUSIC] RFC 5761 updated by both draft-mux-exclusive and RFC 8035
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 28 Apr 2017 09:59:54 -0000

--_000_D528EDAA1BDBDchristerholmbergericssoncom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

draft-mux-exclusive updates section 5.1.1 of RFC 5761. Now, RFC 8035 also u=
pdates section 5.1.1 of RFC 8035.

draft-mux-exclusive keeps the existing text, and adds some new (=
).


Update to 4th paragraph of section 5.1.1


OLD TEXT (RFC 5761):

   If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=3Drtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=3Drtcp-mux"
   attribute.



NEW TEXT (RFC 8035):

   If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=3Drtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=3Drtcp-mux"
   attribute.


As we can see, the original text is identical in 5761 and 8035. So, there i=
s no clash. So far so good.

draft-mux-exclusive keeps the existing text, and adds some new (=
).


NEW TEXT (draft-mux-exclusive):

   If the answer does not contain an "a=3Drtcp-mux" attribute, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signaled port
   if the "a=3Drtcp:" attribute [10] is also included).  This will occur
   when talking to a peer that does not understand the "a=3Drtcp-mux"
   attribute.  However, if the offerer indicated in the offer that it =
is
   not able to send and receive RTCP on a separate port, the offerer
   MUST disable the media streams associated with the attribute. The
   mechanism for indicating that the offerer is not able to send and
   receive RTCP on a separate port is outside the scope of this
   specification.


Now, the issue is that, following the update in RFC 8035, the text is no lo=
nger within the 4th paragraph of section 5.1.1. So, should we:

1) within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 are=
 updated; or
2) within draft-mux-exclusive, add a note indicating which paragraph is aff=
ected following the update in RFC 8035
3) within draft-mux-exclusive, ONLY update RFC 8035; or
4) o nothing

My first reaction would be to go for option 2), as there IMO is no reason t=
o formally update the text in RFC 8035.

Regards,

Christer



--_000_D528EDAA1BDBDchristerholmbergericssoncom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <5435EE87478F30428CC4AD610B4FC047@ericsson.com>
Content-Transfer-Encoding: quoted-printable









Hi,


<=
font face=3D"Courier">draft-mux-exclusive updates section 5.1.1 of RFC 5761=
. Now, RFC 8035 also updates section 5.1.1 of RFC 8035.


draft-mux-exclusive keeps the existing text, and=
 adds some new (<new></new>).









Update to =
4th paragraph of section 5.1.1


OLD TEXT (RFC 5761):

   If the answer does not contain an "a=3Drtcp-mux" attribute, th=
e offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=3Drtcp:" attribute [10] is also included).  This wil=
l occur
   when talking to a peer that does not understand the "a=3Drtcp-mux&q=
uot;
   attribute.






NEW TEXT (RFC 8035):


   If the answer does not contain an "a=3Drtcp-mux" attribut=
e, the offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signalled port
   if the "a=3Drtcp:" attribute [10] is also included).  This wil=
l occur
   when talking to a peer that does not understand the "a=3Drtcp-mux&q=
uot;
   attribute.





As we can see=
, the original text is identical in 5761 and 8035. So, there is no clash. S=
o far so good.


draft-mux-exc=
lusive keeps the existing text, and adds some new (<new></new>)=
.





NEW TEXT (draft-=
mux-exclusive):

   If the answer does not contain an "a=3Drtcp-mux" attribute, th=
e offerer
   MUST NOT multiplex RTP and RTCP packets on a single port.  Instead,
   it should send and receive RTCP on a port allocated according to the
   usual port-selection rules (either the port pair, or a signaled port
   if the "a=3Drtcp:" attribute [10] is also included).  This wil=
l occur
   when talking to a peer that does not understand the "a=3Drtcp-mux&q=
uot;
   attribute. <new> However, if the offerer i=
ndicated in the offer that it is
   not able to send and receive RTCP on a separate port, the offerer
   MUST disable the media streams associated with the attribute. The
   mechanism for indicating that the offerer is not able to send and
   receive RTCP on a separate port is outside the scope of this
   specification.</new>


Now, the issue is that, following the update in RFC 8035, the =
text is no longer within the 4th paragraph of section 5.1.1. So, should we:=


1)	within draft-mux-exclusive, indicate that both RFC 5761 and RFC 8035 a=
re updated; or
2) 	within draft-mux-exclusive=
, add a note indicating which paragraph is affected following the update in=
 RFC 8035
3)	within draft-mux-exclusive, ONLY=
 update RFC 8035; or
4)	o nothing

My first reaction would be to go for option 2), as there IMO is no reason =
to formally update the text in RFC 8035. 

Regards,

=
Christer








--_000_D528EDAA1BDBDchristerholmbergericssoncom_--


From nobody Sun Apr 30 07:51:56 2017
Return-Path: 
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2293129401; Sun, 30 Apr 2017 07:51:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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=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 JXzVdrutivmu; Sun, 30 Apr 2017 07:51:51 -0700 (PDT)
Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (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 115FE1293E4; Sun, 30 Apr 2017 07:49:49 -0700 (PDT)
Received: by mail-yb0-x229.google.com with SMTP id s22so24152077ybe.3; Sun, 30 Apr 2017 07:49:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iFYIM0QPWAZd2pL0QGL0GcOxmVRB5MaQhVtewod4xvo=; b=C/eNOHtel/MnnK45gjIecsi0G12jB0eSxJDFxtH4xom0bNkrxsvjtdsmNcWyJSfwge mwItTrqJcM6N9WtkUOZD8fLluWidxionnvgs1bBxE0MegKNCxOL8jLgTPZlpC9avZprZ NdEDnM+haCqSRJ2PgAWdAEIj5FPHXp57QQwTGyowO8VGcjD1lYUxwb+7DTs2oGd1ktkz 1ahRvfFIr5+AsNR7xe33ZMFHBrl1Xc/abwW7ws1gV8beao9hhEg1gmOR7soIjYz5rJs9 wEC6F2wUbYPBQADhkMtXu39kUTvaU99l1dFmNw2DLbgciTRNVSIS495Y8q6pplWBKb2Y Io0A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iFYIM0QPWAZd2pL0QGL0GcOxmVRB5MaQhVtewod4xvo=; b=ndBSEw/oWgQfpobC4vOteIpZV7vWBJNCYCLE1ZswgYr2GBeJwWFkyrgsYhviMKII89 qFIxT9R1GRAAsMJzvU5Pq6AQ+BkuVhqshVjVGtINwP0CyPQbZyEDLP65shVkFw3XbsQg VtIZNIZcF/LfhV5bUygAdgKxxagVxBBDH4Pmf2FdJl//Z/1PhjbtPou400A4bm6x5uOY j37QMc8cyxu4EXO3+JOsQNBg3JEiKnlqHk/o+bygik3yMENTuBAHQOYy7PwoeVslujBD y03rIual5i15mafAgDpPxQBIr22jxZ6MN+l2D/iqT8yAbDSiF3MKeOHIeWeVt/gNpTFw 2glA==
X-Gm-Message-State: AN3rC/5zPoWyrbQOzvMgWSb+NBjHjKOfbxfytDO83NqVLuqvR9Uye3ow 97fSIOWMz/iiQ2Xuap2Gx5P5+d5ZDA==
X-Received: by 10.37.171.194 with SMTP id v60mr16719079ybi.100.1493563788198;  Sun, 30 Apr 2017 07:49:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.46.18 with HTTP; Sun, 30 Apr 2017 07:49:47 -0700 (PDT)
In-Reply-To: 
References:       
From: =?UTF-8?Q?Miguel_Par=C3=ADs_D=C3=ADaz?= 
Date: Sun, 30 Apr 2017 16:49:47 +0200
Message-ID: 
To: "Mo Zanaty (mzanaty)" 
Cc: Jonathan Lennox , "avtext@ietf.org" ,  mmusic 
Content-Type: multipart/alternative; boundary=001a11487c560b8cfc054e636b4a
Archived-At: 
Subject: Re: [MMUSIC] [avtext] framemarking: add frame size info
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 30 Apr 2017 14:51:54 -0000

--001a11487c560b8cfc054e636b4a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the pointer Mo,
I couldn't assist to the IETF in Chicago,so I appreciate so much your
response ;).

Best!!

2017-03-27 17:10 GMT+02:00 Mo Zanaty (mzanaty) :

> Hi Miguel,
>
> This was discussed in IETF 97 during the AVTEXT session on Frame Marking.
> See the slides and minutes.
> https://datatracker.ietf.org/meeting/97/session/avtext
>
> The recommended and agreed solution was to use RID rather than add frame
> size
> in the Frame Marking header extension.
>
> Thanks,
> Mo
>
>
> From: mmusic  on behalf of Miguel Par=C3=ADs D=
=C3=ADaz <
> mparisdiaz@gmail.com>
> Date: Monday, March 27, 2017 at 3:43 AM
> To: Jonathan Lennox 
> Cc: "avtext@ietf.org" , "mmusic@ietf.org" <
> mmusic@ietf.org>
> Subject: Re: [MMUSIC] [avtext] framemarking: add frame size info
>
> Hello again,
> is there anybody considering this proposal, or nobody see the benefits?
>
> Kind regards!!
>
> 2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D=C3=ADaz :
>
>> Hello,
>> in the new draft of sdp-simulcast an "RTP Aspect" section [1] has been
>> added, which explains how the media is handled on RTP level.
>>
>> Specifically, In the Media-Switching Mixer section [2] the same thoughts
>> I exposed are said:
>>
>>    This section discusses the behavior in cases where the RTP middlebox
>>    behaves like the Media-Switching Mixer (Section 3.6.2 ) in RTP
>>    Topologies [RFC7667 ].  The fund=
amental aspect here is that the media
>>    sources delivered from the middlebox will be the mixer's conceptual
>>    or functional ones.  For example, one media source may be the main
>>    speaker in high resolution video, while a number of other media
>>    sources are thumbnails of each participant.
>>
>>    The above results in that the RTP stream produced by the mixer is one
>>    that switches between a number of received incoming RTP streams for
>>    different media sources and in different simulcast versions.  The
>>    mixer selects the media source to be sent as one of the RTP streams,
>>    and then selects among the available simulcast streams for the most
>>    appropriate one.  The selection criteria include available bandwidth
>>    on the mixer to receiver path and restrictions based on the
>>    functional usage of the RTP stream delivered to the receiver.  An
>>    example of the latter, is that it is unnecessary to forward a full HD
>>    video to a receiver if the display area is just a thumbnail.  Thus,
>>    restrictions may exist to not allow some simulcast streams to be
>>    forwarded for some of the mixer's media sources.
>>
>>
>> In our case to provide this feature, currently we have to depay the RTP
>> packets, and apply different types of parses (depending on the codec) to
>> read the frame size, which reduces the scalability of the system and hin=
der
>> the implementation a lot.
>> Because of that, I think that having frame size (width and height) info
>> in the Frame Marking RTP header extension is quite interesting to implem=
ent
>> this kind of use cases in a easy and efficient way (the same that an
>> audio-level extension header is provided to avoid analysing it in the
>> middlebox side).
>>
>> I am adding MMUSIC group in the thread, because I think that this also
>> should be discussed in the context of the simulcast case.
>>
>> Best!!
>>
>> Refs
>> [1] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-
>> 06#section-7.2
>> [2] https://tools.ietf.org/html/draft-ietf-mmusic-sdp-simulcast-
>> 06#section-7.2.1
>>
>>
>> 2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=C3=ADaz :
>>
>>> I assume that the media distributor has the information from the SDP (i=
t
>>> performs the SDP negotiation which each "client"), but the point is tha=
t
>>> encoders may change the video size depending on the available bandwidth=
,
>>> the complexivity of the video source, etc., unless the sender forces th=
e
>>> encoders' configuration with a fix frame size...
>>>
>>>
>>> 2016-08-26 19:07 GMT+02:00 Jonathan Lennox :
>>>
>>>> (As an individual.)
>>>>
>>>> In the latest version of simulcast the media distributor would need th=
e
>>>> RID values, not the PT values, but the idea is the same =E2=80=94 it n=
eeds the SDP.
>>>>
>>>> Note that if the media distributor doesn=E2=80=99t have information fr=
om the
>>>> SDP it can=E2=80=99t reliably identify the frame marking header extens=
ion at all,
>>>> since header extension IDs are negotiated. So I=E2=80=99m not sure how=
 much benefit
>>>> there is to putting the size in the header extension.
>>>>
>>>> That said, if we envision a scenario where encoders might be frequentl=
y
>>>> changing their video size (in response to available network bandwidth,=
 or
>>>> the like), it might be useful for encoders to be able to indicate the
>>>> current size they=E2=80=99re encoding without needing to send updated =
SDP all the
>>>> time.
>>>>
>>>> On Aug 26, 2016, at 12:52 PM, Paul E. Jones 
>>>> wrote:
>>>>
>>>> Miguel,
>>>>
>>>> You make the assumption that the media distributor will not see the
>>>> SDP, I suppose.  While certainly a valid model, I'll admit that I had
>>>> personally assumed any media forwarding function would see the SDP (or=
 at
>>>> least be told the PT values and any relevant flow information similar =
to
>>>> what RFC 6236 provides) and would thus know which PT values correspond=
 to
>>>> what video resolutions if simulcast is employed.
>>>>
>>>> Paul
>>>>
>>>> ------ Original Message ------
>>>> From: "Miguel Par=C3=ADs D=C3=ADaz" 
>>>> To: avtext@ietf.org
>>>> Sent: 8/25/2016 10:12:48 AM
>>>> Subject: [avtext] framemarking: add frame size info
>>>>
>>>> Hello,
>>>> it would be great having frame size (width and height) info in the
>>>> Frame Marking RTP header extension [1].
>>>>
>>>> Why?
>>>> For example, in the case of using simulcast in an SFU, selecting the
>>>> stream by the size would ease the application development and improve =
the
>>>> experience of the users.
>>>> Application developers don't usually have deep knowledge about media
>>>> like bitrate, etc., but they know which video size has to be rendered =
in
>>>> the GUI, which may depend on the client where the app is running: a mo=
bile,
>>>> a PC with a 13"=C2=B7 screen, a PC with 27" screen, etc.
>>>>
>>>> In this way and taking a videoconference app as example, if a
>>>> participant select another participant to be rendered as main video, t=
he
>>>> app could ask the SFU to select the video quality that better matches =
to
>>>> 800x600 size.
>>>>
>>>> What do you think about this idea?
>>>>
>>>> Thanks and best regards!!
>>>>
>>>> Refs
>>>> [1] https://tools.ietf.org/html/draft-ietf-avtext-framemarking-02
>>>>
>>>> --
>>>> Miguel Par=C3=ADs D=C3=ADaz
>>>> ------------------------------------------------------------
>>>> ------------
>>>> Computer/Software engineer.
>>>> Researcher and architect in http://www.kurento.org
>>>> http://twitter.com/mparisdiaz
>>>> ------------------------------------------------------------
>>>> ------------
>>>>
>>>> _______________________________________________
>>>> avtext mailing list
>>>> avtext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/avtext
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Miguel Par=C3=ADs D=C3=ADaz
>>> -----------------------------------------------------------------------=
-
>>> Computer/Software engineer.
>>> Researcher and architect in http://www.kurento.org
>>> http://twitter.com/mparisdiaz
>>> -----------------------------------------------------------------------=
-
>>>
>>
>>
>>
>> --
>> Miguel Par=C3=ADs D=C3=ADaz
>> ------------------------------------------------------------------------
>> Computer/Software engineer.
>> Researcher and architect in http://www.kurento.org
>> http://twitter.com/mparisdiaz
>> ------------------------------------------------------------------------
>>
>
>
>
> --
> Miguel Par=C3=ADs D=C3=ADaz
> ------------------------------------------------------------------------
> Computer/Software engineer.
> Researcher and architect in http://www.kurento.org
> http://twitter.com/mparisdiaz
> ------------------------------------------------------------------------
>



--=20
Miguel Par=C3=ADs D=C3=ADaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher and architect in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------

--001a11487c560b8cfc054e636b4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks for the pointer Mo,
I couldn'=
;t assist to the IETF in Chicago,so I appreciate so much your response ;).<=
br>
Best!!

2017-03-27 17:10 GMT+02:00 Mo Zanaty (mzanaty) <mzanaty@cisco.=
com>:







Hi Miguel,







This was discussed in IETF 97 during the AVTEXT session on Frame Marki=
ng.


See the slides and minutes.








The recommended and agreed solution was to use RID rather than add fra=
me size


in the Frame Marking header extension.







Thanks,


Mo














From: mmusic <mmusic-bounces@ietf.org> =
on behalf of Miguel Par=C3=ADs D=C3=ADaz <mparisdiaz@gmail.com>

Date: Monday, March 27, 2017 at 3:4=
3 AM

To: Jonathan Lennox <jonathan@vidyo.com>

Cc: "avtext@ietf.org" <avtext@ietf.org>, "mmusic@ietf.org" <=
;mmusic@ietf.org&g=
t;

Subject: Re: [MMUSIC] [avtext] fram=
emarking: add frame size info

















Hello again,



is there anybody considering this proposal, or nobody see the benefits?





Kind regards!!







2016-11-10 15:18 GMT+01:00 Miguel Par=C3=ADs D=
=C3=ADaz 
<mparisdiaz@gm=
ail.com>:






Hello,

in the new draft of sdp-simulcast an "RTP Aspect" section [1] has=
 been added, which explains how the media is handled on RTP level.





Specifically, In the Media-Switching Mixer section [2] the same thoughts I =
exposed are said:


   =
This section discusses the behavior in cases where the RTP middlebox
   behaves like the Media-Switching Mixer (=
Section 3.6.2) in RTP
   Topologies [RFC7667].  The fundamental a=
spect here is that the media
   sources delivered from the middlebox will be the mixer's conceptual
   or functional ones.  For example, one media source may be the main
   speaker in high resolution video, while a number of other media
   sources are thumbnails of each participant.

   The above results in that the RTP stream produced by the mixer is one
   that switches between a number of received incoming RTP streams for
   different media sources and in different simulcast versions.  The
   mixer selects the media source to be sent as one of the RTP streams,
   and then selects among the available simulcast streams for the most
   appropriate one.  The selection criteria include available bandwidth
   on the mixer to receiver path and restrictions based on the
   functional usage of the RTP stream delivered to the receiver.  An
   example of the latter, is that it is unnecessary to forward a full HD
   video to a receiver if the display area is just a thumbnail.  Thus,
   restrictions may exist to not allow some simulcast streams to be
   forwarded for some of the mixer's media sources.









In our case to provide this feature, currently we have to depay the RT=
P packets, and apply different types of parses (depending on the codec) to =
read the frame size, which reduces the scalability of the system and hinder=
 the implementation a lot.




Because of that, I think that having frame size (width and height) inf=
o in the Frame Marking RTP header extension is quite interesting to impleme=
nt this kind of use cases in a easy and efficient way (the same that an aud=
io-level extension header is provided
 to avoid analysing it in the middlebox side).









I am adding MMUSIC group in the thread, because I think that this also=
 should be discussed in the context of the simulcast case.






Best!!





















2016-08-30 12:37 GMT+02:00 Miguel Par=C3=ADs D=
=C3=ADaz 
<mparisdiaz@gm=
ail.com>:




I assume that the media distributor has the information fr=
om the SDP (it performs the SDP negotiation which each "client"),=
 but the point is that encoders may change the video size depending on the =
available bandwidth, the complexivity of the
 video source, etc., unless the sender forces the encoders' configurati=
on with a fix frame size...













2016-08-26 19:07 GMT+02:00 Jonathan Lennox 
<jonathan@vidyo.=
com>:






(As an individual.)







In the latest version of simulcast the media distributor would need th=
e RID values, not the PT values, but the idea is the same =E2=80=94 it need=
s the SDP.







Note that if the media distributor doesn=E2=80=99t have information fr=
om the SDP it can=E2=80=99t reliably identify the frame marking header exte=
nsion at all, since header extension IDs are negotiated. So I=E2=80=99m not=
 sure how much benefit there is to putting the size in the
 header extension.







That said, if we envision a scenario where encoders might be frequentl=
y changing their video size (in response to available network bandwidth, or=
 the like), it might be useful for encoders to be able to indicate the curr=
ent size they=E2=80=99re encoding without
 needing to send updated SDP all the time.












On Aug 26, 2016, at 12:52 PM, Paul E. Jones <paulej@packetizer.com> wrote:














Miguel,









You make the assumption that the media distributor will not see the SDP, I =
suppose.=C2=A0 While certainly a valid model, I'll admit that I had per=
sonally assumed any media forwarding function would see the SDP (or at leas=
t be told the PT values and any relevant
 flow information similar to what RFC 6236 provides) and would thus know wh=
ich PT values correspond to what video resolutions if simulcast is employed=
.









Paul









------ Original Message ------



From: "Miguel Par=C3=ADs D=C3=ADaz" <mparisdiaz@gmail.com>




Sent: 8/25/2016 10:12:48 AM



Subject: [avtext] framemarking: add frame size info
















Hello,




it would be great having frame size (width and height) info in the Fra=
me Marking RTP header extension [1].






Why?




For example, in the case of using simulcast in an SFU, selecting the s=
tream by the size would ease the application development and improve the ex=
perience of the users.




Application developers don't usually have deep knowledge about med=
ia like bitrate, etc., but they know which video size has to be rendered in=
 the GUI, which may depend on the client where the app is running: a mobile=
, a PC with a 13"=C2=B7 screen, a PC with
 27" screen, etc.









In this way and taking a videoconference app as example, if a particip=
ant select another participant to be rendered as main video, the app could =
ask the SFU to select the video quality that better matches to 800x600 size=
.









What do you think about this idea?







Thanks and best regards!!



Refs

[1]=C2=A0https://tools.ietf.org/html/dra=
ft-ietf-avtext-framemarking-02





--=C2=A0




Miguel Par=C3=ADs D=C3=ADaz

-----------------------------------------------------------------=
-------

Computer/Software engineer.

Researcher and architect in=C2=A0http://www.kurento.org

http://twitter.=
com/mparisdiaz

-----------------------------------------------------------------=
-------



















_______________________________________________

avtext mailing list

avtext@ietf.org

https://www.ietf.org/mailman/listinfo/avtext



















-- 




Miguel Par=C3=ADs D=C3=ADaz

-----------------------------------------------------------------=
-------

Computer/Software engineer.

Researcher and architect in http://www.kurento.org

http://twitter.=
com/mparisdiaz

-----------------------------------------------------------------=
-------





















-- 




Miguel Par=C3=ADs D=C3=ADaz

-----------------------------------------------------------------=
-------

Computer/Software engineer.

Researcher and architect in http://www.kurento.org

http://twitter.=
com/mparisdiaz

-----------------------------------------------------------------=
-------





















-- 




Miguel Par=C3=ADs D=C3=ADaz

-----------------------------------------------------------------=
-------

Computer/Software engineer.

Researcher and architect in http://www.kurento.org

http://twitter.=
com/mparisdiaz

-----------------------------------------------------------------=
-------




















-- 
Miguel Par=C3=
=ADs D=C3=ADaz
---------------------------------------------------------=
---------------
Computer/Software engineer.
Researcher and architect =
in http://www.kurento.=
org
http=
://twitter.com/mparisdiaz
------------------------------------------=
------------------------------




--001a11487c560b8cfc054e636b4a--