Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Fri, 26 February 2016 21:08 UTC
Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 893CF1B3060 for <bfcpbis@ietfa.amsl.com>; Fri, 26 Feb 2016 13:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.54
X-Spam-Level:
X-Spam-Status: No, score=-2.54 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_BODY=1.157, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham
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 YGTkSFiMiF71 for <bfcpbis@ietfa.amsl.com>; Fri, 26 Feb 2016 13:08:29 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212E71B2AC1 for <bfcpbis@ietf.org>; Fri, 26 Feb 2016 13:08:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=289424; q=dns/txt; s=iport; t=1456520909; x=1457730509; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jIQ3JaVAVkX3NRRQAk3RcIXA5K12YJcO0JEnlFy2zO8=; b=ZUNoycEVWmDaqNjqD1aCwdVO9qsjR1CFkMpXXimWbvvLtnmNguiC+MI0 HWDJF+wBN9oOZh+1PDOamYgUfP3ywed+joDo71oiu8GvySlf6XL5aUDHS LYBmmpwNwnXRM4+BLNsyyj0upaDIAAT0FkQu9cTG3xlNNqi3H+NYXJTcH 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CfBAAGvtBW/49dJa3KPgICAQI
X-IronPort-AV: E=Sophos; i="5.22,505,1449532800"; d="scan'208,217"; a="75164162"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2016 21:08:28 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u1QL8QhZ016551 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Feb 2016 21:08:26 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 26 Feb 2016 15:08:25 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Fri, 26 Feb 2016 15:08:25 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, Tom Kristensen <2mkristensen@gmail.com>
Thread-Topic: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
Thread-Index: AQHRMp/H3B27oV/7jkaNpW2F7iCWr57DTNgA//9+iICAYuTIAIADm2mAgAFrLACAAWq5AIATC2kA
Date: Fri, 26 Feb 2016 21:08:24 +0000
Message-ID: <D2F5F796.67E81%eckelcu@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <D25D4C6A.5DF22%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> <D262300E.5E485%eckelcu@cisco.com> <D28D93AC.603E7%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37C90AB8@ESESSMB209.ericsson.se> <D28DA7ED.604A2%eckelcu@cisco.com> <CAFHv=r9v2J6-NDi4OSQq12yxgdefEkwvOsw+uWw3OTF88N2ZhQ@mail.gmail.com> <D2E3A191.670FE%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37DE7493@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B37DEAFD3@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37DEAFD3@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.1.160122
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.248.30]
Content-Type: multipart/alternative; boundary="_000_D2F5F79667E81eckelcuciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/dvbdFRbiI1Yc67scrzK0Eh3mmo8>
Cc: Ben Campbell <ben@nostrum.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Feb 2016 21:08:44 -0000
Comments inline, as an individual From: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> Date: Sunday, February 14, 2016 at 2:18 AM To: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>, Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>, Tom Kristensen <2mkristensen@gmail.com<mailto:2mkristensen@gmail.com>> Cc: Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>>, "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>, Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com<mailto:Gonzalo.Camarillo@ericsson.com>>, Tom Kristensen <tomkrist@cisco.com<mailto:tomkrist@cisco.com>> Subject: RE: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] Hi, A few more comments. As I said earlier, the mux category is needed in the IANA considerations. In addition, Flemming has told me that there should be normative text regarding the mux category, AND the source-specific applicability (i.e. if/how an attribute can be associated with a specific source, using the 'ssrc' attribute). Christer, can you provide text that you should be added to address this? Regards, Christer Sent from my Windows Phone ________________________________ From: Christer Holmberg<mailto:christer.holmberg@ericsson.com> Sent: 13/02/2016 18:25 To: Charles Eckel (eckelcu)<mailto:eckelcu@cisco.com>; Tom Kristensen<mailto:2mkristensen@gmail.com> Cc: Ben Campbell<mailto:ben@nostrum.com>; bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; Alissa Cooper<mailto:alissa@cooperw.in>; Gonzalo Camarillo<mailto:gonzalo.camarillo@ericsson.com>; Tom Kristensen (tomkrist)<mailto:tomkrist@cisco.com> Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] Hi, A few comments. Q1: The text in section 9 says: “When SIP is used to perform an offer/answer exchange,…” I think that is misleading. SIP is not used for offer/answer – SDP is. SIP is used to carry the SDP, though. True. How about we change to “When SDP is used …” Q2: In the first paragraph of section 10.5, I think the text should reference [13] (i.e. draft-dtls-sdp) on how to determine the TLS client. Reference [10] does not define the role determination for DTLS. [13] references [10] for the TLS/DTLS role determination, and [13] is referenced later in section 10.5, so I think its okay as written. I also think it would be okay to reference [13] only, which is what I believe you are suggesting, but then the exercise is left to the reader to following the reference in [13] to [10]. Q3: Section 10, and its subsections, does not describe the usage of the ‘dtls-connection’ attribute for DTLS (the attribute is later shown in the examples, though). So, text should either be added – OR I would again suggest to have a statement saying that the generic offer/answer procedures for DTLS are defined in [13], and that section 10 defines the BFCP specific parts. Sounds good to me. Cheers, Charles I know we have discussed a dependency on draft-dtls-sdp before :) But, draft-dtls-sdp is currently in its second week of WGLC (the WGLC ends February 19th), so unless something unexpected comes up (so far the comments have been more or less editorial) I don’t think such dependency would delay draft-bfcpbis. And, draft-bfcpbis already refers to draft-dtls-sdp for when a new DTLS connection has to be created, so the dependency is already there :) Regards, Christer From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] Sent: 13 February 2016 01:36 To: Tom Kristensen <2mkristensen@gmail.com<mailto:2mkristensen@gmail.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Tom Kristensen (tomkrist) <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>; bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>; Gonzalo Camarillo <gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] (as chair) I request that the working group take a look within the next week and share whether they are okay with the changes, and if not, what specific changes are needed. Cheers, Charles From: Tom Kristensen <2mkristensen@gmail.com<mailto:2mkristensen@gmail.com>> Date: Tuesday, February 9, 2016 at 11:55 PM To: Charles Eckel <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> Cc: Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>, Tom Kristensen <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>" <draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>>, "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>, Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>, Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com<mailto:Gonzalo.Camarillo@ericsson.com>>, Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis] Draft updated accordingly and submitted just now. Cf. https://tools.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-13.txt -- Tom On 9 December 2015 at 18:43, Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> wrote: On 12/9/15, 9:26 AM, "bfcpbis on behalf of Christer Holmberg" <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org> on behalf of christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: >I didn't know there was an "actress" value for the setup attribute ;) Argh, autocorrect strikes again. > >I guess the following statement: > > "are as the same defined for DTLS-SRTP in [13]." > >...should be: > > "are the same as defined for DTLS-SRTP in [13]." Yep, thanks. > >Regards, > >Christer Cheers, Charles > > >-----Original Message----- >From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>] >Sent: 09 December 2015 18:37 >To: Charles Eckel (eckelcu) <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>; Christer Holmberg ><christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Tom Kristensen (tomkrist) ><tomkrist@cisco.com<mailto:tomkrist@cisco.com>> >Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; >Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>; Gonzalo Camarillo ><gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> >Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: >draft-ietf-bfcpbis-rfc4583bis] > >Christer and I discussed this offline and now I’d like to bring the >proposal for moving forward to the list. > >draft-ietf-mmusic-dtls-sdp WILL update RFC 5763 (see >https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-03) to include >support for the new 'dtls-connection’ attribute. The proposed changes to >accommodate this in draft-ietf-bfcpbis-rfc4583bis are as follows: > > >1) Update last paragraph of section 10.5 > >OLD: > > The conditions under which endpoints MUST establish a new DTLS > connection are as the same defined for DTLS-SRTP in [13]. > > >NEW > The condition above, and additional conditions under which > endpoints MUST establish a new DTLS connection, are as the > same defined for DTLS-SRTP in [13]. > >Where [13] is a reference to RFC 5763. > >2) Update the DTLS example in section 11 to include the dtls-connection >attribute as follows: > > m=application 50000 UDP/TLS/BFCP * > a=setup:actress >a=dtls-connection:new > a=fingerprint:SHA-1 \ > 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB > a=floorctrl:c-only s-only > a=confid:4321 > a=userid:1234 > a=floorid:1 mstrm:10 > a=floorid:2 mstrm:11 > a=bfcpver:2 > m=audio 50002 RTP/AVP 0 > a=label:10 > m=video 50004 RTP/AVP 31 > a=label:11 > > The following is the answer returned by the server. > > m=application 55000 UDP/TLS/BFCP * > a=setup:active >a=dtls-connection:new > > a=fingerprint:SHA-1 \ > 3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21 > a=floorctrl:s-only > a=confid:4321 > a=userid:1234 > a=floorid:1 mstrm:10 > a=floorid:2 mstrm:11 > a=bfcpver:2 > m=audio 55002 RTP/AVP 0 > m=video 55004 RTP/AVP 31 > >Christer, please review and correct my usage of dtls-connection attribute. >Everyone, please comment as to whether or not you agree with this path >forward. > >Cheers, >Charles > > > > > >On 11/6/15, 10:51 AM, "bfcpbis on behalf of Charles Eckel (eckelcu)" ><bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org> on behalf of eckelcu@cisco.com<mailto:eckelcu@cisco.com>> wrote: > >>Christer, >> >>Has the MMUSIC working group decided that draft-ietf-mmusic-dtls-sdp will >>NOT update RFC 5763? It currently references it extensively, but >>according >>to the boilerplate it does not explicitly update RFC 5763. >> >>The draft now includes better backward compatibility with respect to RFC >>5763, which is good to see. I think we should be able to word things such >>that we recommend using the new dtls-connection attribute while also >>requiring support the absence of this attribute for backward >>compatibility. This would be very straightforward if >>draft-ietf-mmusic-dtls-sdp updates RFC 5763. >> >>Cheers, >>Charles >> >>On 11/2/15, 7:39 PM, "Christer Holmberg" <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>wrote: >> >>>Just a question for clarification: will the draft now adopt the >>>'dtls-connection' attribute defined in the DTLS-SDP draft? >>> >>>Regards, >>> >>>Christer >>> >>>-----Original Message----- >>>From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>] >>>Sent: 02 November 2015 10:26 >>>To: Tom Kristensen (tomkrist) <tomkrist@cisco.com<mailto:tomkrist@cisco.com>>; Christer Holmberg >>><christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>Cc: Alissa Cooper <alissa@cooperw.in<mailto:alissa@cooperw.in>>; bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; >>>draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; Gonzalo Camarillo >>><gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>; Ben Campbell <ben@nostrum.com<mailto:ben@nostrum.com>> >>>Subject: Re: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] >>>draft-ietf-bfcpbis-rfc4583bis] >>> >>>Great, thanks Tom. I look forward to seeing the update posted before the >>>end of this week. >>> >>>Cheers, >>>Charles >>> >>>On 11/2/15, 4:45 PM, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com<mailto:tomkrist@cisco.com>> >>>wrote: >>> >>>>Perfect! I'll update and polish the draft as discussed and agreed upon >>>>below and submit. >>>> >>>>-- Tom >>>> >>>>On 11/02/2015 08:04 AM, Christer Holmberg wrote: >>>>> Hi, >>>>> >>>>> draft-ietf-mmusic-dtls-sdp was discussed at MMUSIC today. >>>>> >>>>> At this moment there are no technical open issues. The plan is to add >>>>>some editorial work, based on comments received during the session, >>>>>and the add text regarding DTLS-usage drafts/specs that the draft >>>>>updates. >>>>>After that, unless something unexpected comes up, the draft should be >>>>>ready for WGLC. >>>>> >>>>> Regards, >>>>> >>>>> Christer >>>>> >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>] >>>>> Sent: 28 September 2015 18:50 >>>>> To: Christer Holmberg<christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>>; Tom Kristensen >>>>>(tomkrist)<tomkrist@cisco.com<mailto:tomkrist@cisco.com>> >>>>> Cc: Alissa Cooper<alissa@cooperw.in<mailto:alissa@cooperw.in>>; bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; >>>>>draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; Gonzalo >>>>>Camarillo<gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>; Ben >>>>>Campbell<ben@nostrum.com<mailto:ben@nostrum.com>> >>>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis >>>>> >>>>> Thanks Christer. >>>>> >>>>> Tom, can you please post the corresponding update to the draft? >>>>> >>>>> Cheers, >>>>> Charles >>>>> >>>>> On 9/28/15, 3:07 AM, "bfcpbis on behalf of Christer Holmberg" >>>>> <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org> on behalf of >>>>> christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>> wrote: >>>>> >>>>> >>>>>> Hi, >>>>>> >>>>>> >>>>>>> In that case, I prefer Tom’s original suggestion, >>>>>>> >>>>>>> What if we keep the text and adds this as an additional reference >>>>>>> in the two new text passages proposed by Charles: "... [13], and >>>>>>> the clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...". >>>>>>> >>>>>>> Where [13] is a reference to RFC 5763. >>>>>>> >>>>>> If that's something people can agree to, then can live with such >>>>>> compromise :) >>>>>> >>>>>> Regards, >>>>>> >>>>>> Christer >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> If it turns out that draft-ietf-mmusic-dtls-sdp updates RFC 5763, >>>>>>then there is some redundancy. But that is better than having a hole >>>>>>when it comes to backward compatibility with existing >>>>>>implementations, which is what we will have today if we reference >>>>>>draft-ietf-mmusic-dtls-sdp only. >>>>>> >>>>>> Cheers, >>>>>> Charles >>>>>> >>>>>> >>>>>> >>>>>> On 9/25/15, 2:21 AM, "Christer Holmberg" >>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>> wrote: >>>>>> >>>>>> >>>>>>> Hi Charles, >>>>>>> >>>>>>> >>>>>>>> As a simple example, we currently refer to rfc4582bis instead of >>>>>>>> the eventual RFC. Assuming rfc4582bis does become an RFC, we would >>>>>>>> want the RFC editor to update references to it and to RFCxxxx with >>>>>>>> the actual RFC number. >>>>>>>> Similar here, we would want them to check with authors/chairs/ADs >>>>>>>> on the state of draft-ietf-mmusic-dtls-sdp to see if we want to >>>>>>>> replace our reference to RFC 5763 with a reference to it. This way >>>>>>>> we can move forward while draft-ietf-mmusic-dtls-sdp continues to >>>>>>>> progress as well. >>>>>>>> >>>>>>> I don't think it's the same thing. First you talk about a draft, >>>>>>> where the draft name will be replaced with the to-be-assigned RFC >>>>>>> number. In the case of DTLS-SDP we are talking about two separate >>>>>>>specifications. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Christer >>>>>>> >>>>>>> >>>>>>> On 9/24/15, 2:53 AM, "Christer Holmberg" >>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>>> Hi Charles, >>>>>>>> >>>>>>>> I am still not sure I understand your suggestion: what is meant by >>>>>>>> "as determined prior to publication"? When/where/who? :) >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Christer >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>] >>>>>>>> Sent: 22. syyskuuta 2015 17:05 >>>>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist) >>>>>>>> Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; >>>>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>; Alissa Cooper; Gonzalo Camarillo; Ben Campbell >>>>>>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis >>>>>>>> >>>>>>>> I view referring to draft-ietf-mmusic-dtls-sdp now instead of RFC >>>>>>>> 5763 to be like writing a blank check. Debate is actively >>>>>>>> occurring on the list, the normative language in RFC 5763 is >>>>>>>> expected to be updated in multiple ways, and backward >>>>>>>> compatibility with the the normative language provide in previous >>>>>>>> version of rfc4583bis is not fully addressed. It seems more >>>>>>>> appropriate to me at this stage to continue to refer to RFC 5763 >>>>>>>> with a note regarding updating or replacing that reference with >>>>>>>> one to draft-ietf-mmusic-dtls-sdp, as determined prior to >>>>>>>>publication. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Charles >>>>>>>> >>>>>>>> On 9/21/15, 11:48 PM, "Christer Holmberg" >>>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>>> I see. As this is a moving target, perhaps where we reference >>>>>>>>>> RFC >>>>>>>>>> 5763 we can add a note for the RFC editor that >>>>>>>>>> draft-ietf-mmusic-dtls-sdp is expected to add clarifications and >>>>>>>>>> make changes to RFC 5763 that should be considered prior to >>>>>>>>>> publication of rfc4583bis. >>>>>>>>>> >>>>>>>>> I am not sure I understand. I don't think it's up to the RFC >>>>>>>>> editor to make a decision whether the draft should reference >>>>>>>>>DTLS-SDP. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Christer >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 9/21/15, 11:23 AM, "Christer Holmberg" >>>>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> RFC 5763, which is currently required for BFCP with DTLS reads: >>>>>>>>>>> >>>>>>>>>>> o The endpoint MUST NOT use the connection attribute >>>>>>>>>>>defined in >>>>>>>>>>> [RFC4145<https://tools.ietf.org/html/rfc4145>] >>>>>>>>>>> >>>>>>>>>> Correct. >>>>>>>>>> >>>>>>>>>> And, IF we decide to use define usage of the 'connection' >>>>>>>>>> attribute for DTLS, we would change that. >>>>>>>>>> >>>>>>>>>> However, a few days ago we sent an e-mail to the MMUSIC list, >>>>>>>>>>suggesting that we should NOT use the 'connection' attribute for >>>>>>>>>>DTLS. >>>>>>>>>> Instead we should define a new attribute (for more details, >>>>>>>>>>please see the MMUSIC list). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Section 5.1 of draft-ietf-mmusic-dtls-sdp reads: >>>>>>>>>>> >>>>>>>>>>> When used with DTLS, there is no default value defined for >>>>>>>>>>>the >>>>>>>>>>> attribute. Implementations that wish to use the attribute >>>>>>>>>>>MUST >>>>>>>>>>> explicitly include it in SDP offers and answers. If an >>>>>>>>>>>offer or >>>>>>>>>>> answer does not contain an attribute, other means needs to >>>>>>>>>>>be used in >>>>>>>>>>> order for endpoints to determine whether an offer or answer >>>>>>>>>>>is >>>>>>>>>>> associated with an event that requires the DTLS association >>>>>>>>>>>to be >>>>>>>>>>> re- >>>>>>>>>>> established. >>>>>>>>>>> >>>>>>>>>>> I suppose if draft-ietf-mmusic-dtls-sdp pulls in enough from >>>>>>>>>>> RFC >>>>>>>>>>> 5763 to make it clear how the DTLS establishment and >>>>>>>>>>> re-establishment works for the case of which the connection >>>>>>>>>>> attribute is not used, then we can change the reference from >>>>>>>>>>> RFC >>>>>>>>>>> 5763 to draft-ietf-mmusic-dtls-sdp. >>>>>>>>>>> >>>>>>>>>>> The last several updates of draft-ietf-bfcpbis-rfc4583bis have >>>>>>>>>>> removed supporting text from the draft in favor of pointing to >>>>>>>>>>> RFC >>>>>>>>>>> 5763 as the source of truth. I fear that >>>>>>>>>>> draft-ietf-mmusic-dtls-sdp in its current state does not serve >>>>>>>>>>> that need for draft-ietf-bfcpbis-rfc4583bis. I value >>>>>>>>>>> Christer’s thoughts and welcome the opinion of others, >>>>>>>>>>> especially those who have or are implementing BFCP with DTLS >>>>>>>>>>>and >>>>>>>>>>>ICE, which I have not. >>>>>>>>>>> >>>>>>>>>> Please note that DTLS-SDP does not only define usage of the >>>>>>>>>> 'connection' >>>>>>>>>> attribute, it also does other things. Maybe more important, it >>>>>>>>>> does not state that an address change by default requires a new >>>>>>>>>> DTLS association >>>>>>>>>> - which is a another 5763 modification. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> >>>>>>>>>> Christer >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 9/21/15, 9:32 AM, "bfcpbis on behalf of Christer Holmberg" >>>>>>>>>> <bfcpbis-bounces@ietf.org<mailto:bfcpbis-bounces@ietf.org> on behalf of >>>>>>>>>> christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Hi Charles, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> The problem I see with this is that it is not just a matter of >>>>>>>>>>>> changing the reference, it is also a matter of changing the >>>>>>>>>>>> normative behavior. >>>>>>>>>>>> For DTLS with BFCP, we never required the use of >>>>>>>>>>>>the>“connection” >>>>>>>>>>>> attribute. >>>>>>>>>>>> If we are to start requiring it, we would need add text to >>>>>>>>>>>> describe how to address backward compatibility in cases in >>>>>>>>>>>> which the connection attribute is not specified. >>>>>>>>>>>> >>>>>>>>>>> The intention is to cover backward compatibility in the draft. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Are there plans for this within RFC 5763bis draft? If so, >>>>>>>>>>>> Tom’s recommendation of continuing to point to RFC 5763 for >>>>>>>>>>>> now may be the best approach. >>>>>>>>>>>> >>>>>>>>>>> I am not familiar with the 5763bis draft. But, even if the >>>>>>>>>>>DTLS-SDP draft makes updates to 5763, it won't become a 5763bis >>>>>>>>>>>draft. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> >>>>>>>>>>> Christer >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On 9/11/15, 1:11 PM, "Christer Holmberg" >>>>>>>>>>> <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Hmm, yes maybe an idea if it's fine proceeding with referring >>>>>>>>>>>>>a work-in-progress draft here. >>>>>>>>>>>>> What if we keep the text and adds this as an additional >>>>>>>>>>>>>reference in the two new text passages proposed by Charles: >>>>>>>>>>>>>"... >>>>>>>>>>>>> [13], and the clarifications defined in >>>>>>>>>>>>>[draft-ietf-mmusic-dtls-sdp], ...". >>>>>>>>>>>>> >>>>>>>>>>>>> Where [13] is a reference to RFC 5763. >>>>>>>>>>>>> >>>>>>>>>>>> My suggestion is to *only* refer the new dtls-sdp draft. >>>>>>>>>>>> Because, one of the ideas with the new draft is to also update >>>>>>>>>>>> RFC 5763 to reference the new dtls-sdp draft. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Anyway, I'd still prefer to keep the text in >>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to >>>>>>>>>>>>> the rfc5763bis, that eventually then will obsolete (or >>>>>>>>>>>>> extend?) RFC 5763. >>>>>>>>>>>>> >>>>>>>>>>>> The new dtls-sdp draft will not become 5763bis (eventhough it >>>>>>>>>>>> MAY update some parts of 5763). It's a generic document, which >>>>>>>>>>>> *any* DTLS usage can then reference. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> >>>>>>>>>>>> Christer >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 09/11/2015 01:25 PM, Christer Holmberg wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> My suggestion would actually be to refer to the new >>>>>>>>>>>>> draft-ietf-mmusic-dtls-sdp, which is going to clarify the >>>>>>>>>>>>> DTLS-SRTP rules regarding when a new DTLS association must be >>>>>>>>>>>>> established. >>>>>>>>>>>>> >>>>>>>>>>>>> Regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Christer >>>>>>>>>>>>> >>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>> From: Tom Kristensen [mailto:tomkrist@cisco.com<mailto:tomkrist@cisco.com>] >>>>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25 >>>>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; >>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; Ben Campbell; >>>>>>>>>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> >>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>>>>>> >>>>>>>>>>>>> Pointing to the DTLS-SRTP (and by that any updates of it) is >>>>>>>>>>>>> a simple, safe and straigt-forward solution. >>>>>>>>>>>>> >>>>>>>>>>>>> The only change in the new version of rfc4583bis just >>>>>>>>>>>>>submitted. >>>>>>>>>>>>> And as Charles says, this should be the last missing fix for >>>>>>>>>>>>> this draft until next stages in the process at least. >>>>>>>>>>>>> >>>>>>>>>>>>> -- Tom >>>>>>>>>>>>> >>>>>>>>>>>>> On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> Picking up on this old thread regarding >>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis. >>>>>>>>>>>>>> I think this is the only outstanding item with respect to >>>>>>>>>>>>>> the current version of the draft. Unless anyone has an >>>>>>>>>>>>>> issue with the proposed resolution, I request we update the >>>>>>>>>>>>>> draft accordingly and then use it as the basis for Mary, >>>>>>>>>>>>>> the document shepherd, to provide a proto writeup. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> Charles >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 4/20/15, 10:39 AM, "Charles Eckel >>>>>>>>>>>>>> (eckelcu)"<eckelcu@cisco.com<mailto:eckelcu@cisco.com>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi Christer, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I reread the current draft and went through the following >>>>>>>>>>>>>>> MMUSIC thread on this subject: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg14631 >>>>>>>>>>>>>>>. >>>>>>>>>>>>>>> h >>>>>>>>>>>>>>> t >>>>>>>>>>>>>>> m >>>>>>>>>>>>>>> l >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As a result, I better understand the issue you are >>>>>>>>>>>>>>>addressing. >>>>>>>>>>>>>>> I suggest the following changes to be consistent with what >>>>>>>>>>>>>>> is being proposed in >>>>>>>>>>>>>>> MMUSIC: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> ------------ >>>>>>>>>>>>>>> Section 9: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OLD: >>>>>>>>>>>>>>> Endpoints that use the offer/answer model to establish a >>>>>>>>>>>>>>>DTLS >>>>>>>>>>>>>>> association MUST support the 'setup' attribute, as >>>>>>>>>>>>>>> defined in [7]. >>>>>>>>>>>>>>> When DTLS is used with UDP, the 'setup' attribute indicates >>>>>>>>>>>>>>> which of the endpoints (client or floor control server) >>>>>>>>>>>>>>> initiates the DTLS association setup. The requirements for >>>>>>>>>>>>>>> the offer/answer exchange specified in [13], Section 5 of >>>>>>>>>>>>>>> [13] MUST be followed when using DTLS. >>>>>>>>>>>>>>> Offer/answer considerations are described in Section 10.5. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>> When DTLS is used with UDP, the requirements specified in >>>>>>>>>>>>>>> Section >>>>>>>>>>>>>>> 5 of [13] MUST be followed. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Section 10.5 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> OLD >>>>>>>>>>>>>>> If the transport parameters or the key fingerprints >>>>>>>>>>>>>>> change, the >>>>>>>>>>>>>>> endpoints MUST establish a new DTLS connection. In >>>>>>>>>>>>>>> such case the >>>>>>>>>>>>>>> 'active/passive' status of the endpoints will again be >>>>>>>>>>>>>>> determined >>>>>>>>>>>>>>> following the procedures in [7], and the new status >>>>>>>>>>>>>>> will be used to >>>>>>>>>>>>>>> determine the TLS roles associated with the new DTLS >>>>>>>>>>>>>>> connection. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Informational note: The procedure above is >>>>>>>>>>>>>>> identical to the one >>>>>>>>>>>>>>> defined for DTLS-SRTP in [13]. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Note: A new DTLS connection needs to be established >>>>>>>>>>>>>>> if the >>>>>>>>>>>>>>> transport parameters or the key fingerprints >>>>>>>>>>>>>>>change. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> NEW: >>>>>>>>>>>>>>> The conditions under which endpoints MUST establish a new >>>>>>>>>>>>>>> DTLS connection are as the same defined for DTLS-SRTP in >>>>>>>>>>>>>>>[13]. >>>>>>>>>>>>>>> ———————— >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This way we avoid any potential conflicts with the intent >>>>>>>>>>>>>>> of RFC 5763, and when clarifications to RFC 5763 are made, >>>>>>>>>>>>>>> they will be picked up by the BFCP spec. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 4/18/15, 2:01 PM, "Christer >>>>>>>>>>>>>>> Holmberg"<christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> [adding bfcppbis list] >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi Christer, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Thanks for your review and comments. In the BFCP usage, >>>>>>>>>>>>>>>>> the DTLS connection is dedicated to the BFCP stream it >>>>>>>>>>>>>>>>>contains. >>>>>>>>>>>>>>>>> As I understand it, the complications around DTLS >>>>>>>>>>>>>>>>> re-establishement discussed in MMUSIC result from use of >>>>>>>>>>>>>>>>> a single DTLS connection for multiple RTP and/or SCTP >>>>>>>>>>>>>>>>>streams. >>>>>>>>>>>>>>>>> Those complications do not exist with the BFCP usage, so >>>>>>>>>>>>>>>>> I think it is sufficient to continue to reference RFC >>>>>>>>>>>>>>>>> 5763 and not use the SDP connection attribute. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> The complications do not result from use of a single DTLS >>>>>>>>>>>>>>>> connection for multiple streams - it mainly results from >>>>>>>>>>>>>>>> the usage of ICE. And, as far as I know, ICE can be used >>>>>>>>>>>>>>>> also for BFCP. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> And, even without ICE we intend to add text saying that a >>>>>>>>>>>>>>>> DTLS connection is only re-established if the underlying >>>>>>>>>>>>>>>> transport changes. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> First, I want to apologize for not providing my review >>>>>>>>>>>>>>>>> earlier. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As far as the BFCP specifics are concerned, I am ok with >>>>>>>>>>>>>>>>> the latest version of the draft. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> However, there is an issue regarding the DTLS >>>>>>>>>>>>>>>>> considerations (section 10.5). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The text says: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "Once a DTLS connection has been established, if the >>>>>>>>>>>>>>>>> 'active/passive' >>>>>>>>>>>>>>>>> status of the endpoints change during a session, a >>>>>>>>>>>>>>>>> new DTLS >>>>>>>>>>>>>>>>> connection MUST be established." >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> There is currently an ongoing discussion in MMUSIC about >>>>>>>>>>>>>>>>> when a DTLS connection is to be re-established. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The discussion is still ongoing, but the outcome will >>>>>>>>>>>>>>>>> most likely NOT be aligned with the text above. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> For example, there has been a suggestion (by myself) to >>>>>>>>>>>>>>>>> use the SDP connection attribute to explicitly indicate >>>>>>>>>>>>>>>>> that a new DTLS connection needs to be established. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The draft also says: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "If the transport parameters or the key fingerprints >>>>>>>>>>>>>>>>> change, the >>>>>>>>>>>>>>>>> endpoints MUST establish a new DTLS connection." >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This is related to the earlier issue. There is the >>>>>>>>>>>>>>>>> discussion about ICE "virtual connections", and that a >>>>>>>>>>>>>>>>> single DTLS connection would apply to all ICE candidates >>>>>>>>>>>>>>>>> associated with an >>>>>>>>>>>>>>>>> m- line. So, even if a candidate changes (read: transport >>>>>>>>>>>>>>>>> parameter changes), it would not automatically trigger a >>>>>>>>>>>>>>>>> new DTLS connection. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The issues above are also holding up the SCTP-SDP draft, >>>>>>>>>>>>>>>>> so it doesn't only affect BFCPbis :) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Christer >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>>> From: Alissa Cooper [mailto:alissa@cooperw.in<mailto:alissa@cooperw.in>] >>>>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07 >>>>>>>>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist); >>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org<mailto:draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>; Ben >>>>>>>>>>>>>>>>> Campbell; Christer Holmberg >>>>>>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Adding Christer to this thread. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Apr 7, 2015, at 12:44 PM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>> <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Christer (cc’d) and I discussed some of the changes >>>>>>>>>>>>>>>>>> offlist in Dallas, and he is to come back to the list >>>>>>>>>>>>>>>>>> with comments after Dallas >>>>>>>>>>>>>>>>>> - which is now :) >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 4/7/15, 10:26 AM, "Alissa Cooper"<alissa@cooperw.in<mailto:alissa@cooperw.in>> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Checking in on this — has Christer been prompted to >>>>>>>>>>>>>>>>>>> review the latest rev of draft-ietf-bfcpbis-rfc4583bis? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Feb 25, 2015, at 9:14 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>>>> <eckelcu@cisco.com<mailto:eckelcu@cisco.com>> >>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Most of the changes I this recent update to rfc4583bis >>>>>>>>>>>>>>>>>>>> were inspired by comments and suggested text provided >>>>>>>>>>>>>>>>>>>> by Christer. >>>>>>>>>>>>>>>>>>>> He is in the process of reviewing. If all goes well >>>>>>>>>>>>>>>>>>>> with that, we are ready to proceed with proto writeup >>>>>>>>>>>>>>>>>>>> (Mary) and AD review. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 2/25/15, 7:01 AM, "Alissa >>>>>>>>>>>>>>>>>>>> Cooper"<alissa@cooperw.in<mailto:alissa@cooperw.in>> >>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> rfc4583 has not had an AD review yet. Richard can >>>>>>>>>>>>>>>>>>>>> hopefully take care of that while I¹m on leave >>>>>>>>>>>>>>>>>>>>> (starting today, actually). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Feb 25, 2015, at 2:56 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>>>>>> <gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Hi Alissa, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I have noted that while rfc4582bis in on the agenda >>>>>>>>>>>>>>>>>>>>>> of the March 5th telechat (thanks for handling >>>>>>>>>>>>>>>>>>>>>> that!), rfc4583bis isn't. Tom revised rfc4583bis on >>>>>>>>>>>>>>>>>>>>>> February 20th. Should rfc4583bis be on the agenda of >>>>>>>>>>>>>>>>>>>>>> the telechat as well or there is still something >>>>>>>>>>>>>>>>>>>>>> left for Tom to take care of? >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On 18/02/2015 9:28 PM, Alissa Cooper wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Pinging on this. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> March 5 will likely be my last telechat before >>>>>>>>>>>>>>>>>>>>>>> going on leave, so it would be great to get this >>>>>>>>>>>>>>>>>>>>>>> scheduled on that one. To do that, the rev needs >>>>>>>>>>>>>>>>>>>>>>> to be posted today. >>>>>>>>>>>>>>>>>>>>>>> The updates are pretty minimal and are all >>>>>>>>>>>>>>>>>>>>>>> basically written up in Charles¹ response to my AD >review. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Feb 15, 2015, at 9:13 AM, Gonzalo Camarillo >>>>>>>>>>>>>>>>>>>>>>> <gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com> >>>>>>>>>>>>>>>>>>>>>>> <mailto:gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>> >>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> I have talked offline with the other authors and >>>>>>>>>>>>>>>>>>>>>>>> Tom is holding the pen. Tom, do you think you can >>>>>>>>>>>>>>>>>>>>>>>> meet the time frame below? >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Gonzalo >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent from my mobile >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> ---- Alissa Cooper wrote ---- >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Just wanted to see if this rev might get done in >>>>>>>>>>>>>>>>>>>>>>>> the next couple of days. If so, we could get it >>>>>>>>>>>>>>>>>>>>>>>> on the next telechat agenda (March 5). >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Begin forwarded message: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> *From: *Alissa Cooper<alissa@cooperw.in<mailto:alissa@cooperw.in> >>>>>>>>>>>>>>>>>>>>>>>>> <mailto:alissa@cooperw.in<mailto:alissa@cooperw.in>>> >>>>>>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12* >>>>>>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST >>>>>>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)"<eckelcu@cisco.com<mailto:eckelcu@cisco.com> >>>>>>>>>>>>>>>>>>>>>>>>> <mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>>> >>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *"bfcpbis@ietf.org<mailto:bfcpbis@ietf.org><mailto:bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>" >>>>>>>>>>>>>>>>>>>>>>>>> <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> <mailto:bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi Charles, >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu) >>>>>>>>>>>>>>>>>>>>>>>>> <eckelcu@cisco.com<mailto:eckelcu@cisco.com><mailto:eckelcu@cisco.com<mailto:eckelcu@cisco.com>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> HI Alissa, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts >>>>>>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper<alissa@cooperw.in<mailto:alissa@cooperw.in> >>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:alissa@cooperw.in<mailto:alissa@cooperw.in>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM >>>>>>>>>>>>>>>>>>>>>>>>>> To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org><mailto:bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>" >>>>>>>>>>>>>>>>>>>>>>>>>> <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org><mailto:bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: [bfcpbis] AD evaluation: >>>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12 >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I have reviewed this draft in preparation for IETF >LC. >>>>>>>>>>>>>>>>>>>>>>>>>>> Overall the document appears in good shape. I >>>>>>>>>>>>>>>>>>>>>>>>>>> have a few questions and comments I¹d like to >>>>>>>>>>>>>>>>>>>>>>>>>>> discuss before issuing the IETF last call. I¹ve >>>>>>>>>>>>>>>>>>>>>>>>>>> also included some editorial nits that should >>>>>>>>>>>>>>>>>>>>>>>>>>> be addressed together with any last call comments. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Comments and questions: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = "If an endpoint receives a >>>>>>>>>>>>>>>>>>>>>>>>>>> message with an unsupported version field >>>>>>>>>>>>>>>>>>>>>>>>>>> value, the receiving server MUST send an Error >>>>>>>>>>>>>>>>>>>>>>>>>>> message with parameter value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> This seems a little misleading since RFC 4582 >>>>>>>>>>>>>>>>>>>>>>>>>>> didn¹t specify what to do upon receipt of a >>>>>>>>>>>>>>>>>>>>>>>>>>> message with a version other than 1. >>>>>>>>>>>>>>>>>>>>>>>>>>> Implementations that do not get upgraded to be >>>>>>>>>>>>>>>>>>>>>>>>>>> compliant with 4582bis (which could certainly >>>>>>>>>>>>>>>>>>>>>>>>>>> account for some of those that will not >>>>>>>>>>>>>>>>>>>>>>>>>>> support version 2) will therefore never send >>>>>>>>>>>>>>>>>>>>>>>>>>> the error specified here. >>>>>>>>>>>>>>>>>>>>>>>>>>> This seems like it should at least be noted >>>>>>>>>>>>>>>>>>>>>>>>>>> given the MUST-level requirement. The same >>>>>>>>>>>>>>>>>>>>>>>>>>> applies in Section 13.7. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Good point. I believe we made this a MUST >>>>>>>>>>>>>>>>>>>>>>>>>> because we were thinking in terms of >>>>>>>>>>>>>>>>>>>>>>>>>> implementations compliant with this bis version. >>>>>>>>>>>>>>>>>>>>>>>>>> Adding >>>>>>>>>>>>>>>>>>>>>>>>>> your suggested note about rfc 4582 >>>>>>>>>>>>>>>>>>>>>>>>>> implementations here and in section 13.7 seems useful >>to me. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Ok >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 7 = >>>>>>>>>>>>>>>>>>>>>>>>>>> "BFCP entities MUST support, at a minimum, the >>>>>>>>>>>>>>>>>>>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I realize this requirement comes from RFC 4582, >>>>>>>>>>>>>>>>>>>>>>>>>>> but I¹d like to understand why it has not been >>>>>>>>>>>>>>>>>>>>>>>>>>> updated to be consistent with more current >>>>>>>>>>>>>>>>>>>>>>>>>>> guidance on cipher suite selection (e.g., >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-uta-tls- >>>>>>>>>>>>>>>>>>>>>>>>>>> bc >>>>>>>>>>>>>>>>>>>>>>>>>>> p >>>>>>>>>>>>>>>>>>>>>>>>>>> - >>>>>>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> 8 >>>>>>>>>>>>>>>>>>>>>>>>>>> # >>>>>>>>>>>>>>>>>>>>>>>>>>> s >>>>>>>>>>>>>>>>>>>>>>>>>>> e >>>>>>>>>>>>>>>>>>>>>>>>>>> c >>>>>>>>>>>>>>>>>>>>>>>>>>> tion >>>>>>>>>>>>>>>>>>>>>>>>>>> -4) >>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> How about we keep this minimum requirement, and >>>>>>>>>>>>>>>>>>>>>>>>>> add a reference to draft-ietf-uta-tls-bcp along >>>>>>>>>>>>>>>>>>>>>>>>>> with a recommendation to adhere to the best >>>>>>>>>>>>>>>>>>>>>>>>>> practices it outlines in section 4? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA >>>>>>>>>>>>>>>>>>>>>>>>> for backwards compatibility and SHOULD support >>>>>>>>>>>>>>>>>>>>>>>>> the ones listed in the UTA drafts would be ok. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the >>>>>>>>>>>>>>>>>>>>>>>>>>> transaction ID requirements regarding >>>>>>>>>>>>>>>>>>>>>>>>>>> non-reuse/monotonically increasing IDs are >>>>>>>>>>>>>>>>>>>>>>>>>>> re-stated multiple times across these three >>>>>>>>>>>>>>>>>>>>>>>>>>> sections, in slightly different ways, to the >>>>>>>>>>>>>>>>>>>>>>>>>>> point where it¹s not clear exactly what they are. >>>>>>>>>>>>>>>>>>>>>>>>>>> It seems like they are: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>>>>>> ID is >>>>>>>>>>>>>>>>>>>>>>>>>>> 0 >>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated >>>>>>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction: >>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in >>>>>>>>>>>>>>>>>>>>>>>>>>> another message from the client until a >>>>>>>>>>>>>>>>>>>>>>>>>>> response >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >from the server is received for the >>>>>>>>>>>>>>>>>>>>>>>>>> >transaction, >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> but need not be monotonically increasing (e.g., >>>>>>>>>>>>>>>>>>>>>>>>>>> a lower, recently used ID could be re-used once >>>>>>>>>>>>>>>>>>>>>>>>>>> a response is >>>>>>>>>>>>>>>>>>>>>>>>>>> received) >>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated >>>>>>>>>>>>>>>>>>>>>>>>>>> transaction: >>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for >>>>>>>>>>>>>>>>>>>>>>>>>>> wrap-around) >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1? >>>>>>>>>>>>>>>>>>>>>>>>>>> If so, why not just require IDs in all >>>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions to be >>>>>>>>>>>>>>>>>>>>>>>>>>> monotonically increasing? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Agree we can and should simplify this. Sections >>>>>>>>>>>>>>>>>>>>>>>>>> 8.1 and >>>>>>>>>>>>>>>>>>>>>>>>>> 8.2 cover the client behavior and server >>>>>>>>>>>>>>>>>>>>>>>>>> behavior in detail. As such, the transaction ID >>>>>>>>>>>>>>>>>>>>>>>>>> related information at the start of Section 8 is >>superfluous. >>>>>>>>>>>>>>>>>>>>>>>>>> I recommend reducing the text in Section 8 to >>>>>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> follow: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 8. Protocol Transactions >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> In BFCP, there are two types of transactions: >>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions and >>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Client-initiated transactions consist of a >>>>>>>>>>>>>>>>>>>>>>>>>> request from a client to a floor control server >>>>>>>>>>>>>>>>>>>>>>>>>> and a response from the floor control server to the >>client. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions have different >>>>>>>>>>>>>>>>>>>>>>>>>> behavior depending on underlying transport: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> When using a reliable transport, >>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>>>>>> consist of a single message from a floor >>>>>>>>>>>>>>>>>>>>>>>>>> control server to a >>>>>>>>>>>>>>>>>>>>>>>>>> client (notifications). They do not >>>>>>>>>>>>>>>>>>>>>>>>>> trigger any response. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> When using an unreliable transport, >>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions >>>>>>>>>>>>>>>>>>>>>>>>>> consist of a request from a floor control >>>>>>>>>>>>>>>>>>>>>>>>>> server to a client and a >>>>>>>>>>>>>>>>>>>>>>>>>> response from the client to the floor >>>>>>>>>>>>>>>>>>>>>>>>>> control server. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, >>>>>>>>>>>>>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST >>>>>>>>>>>>>>>>>>>>>>>>>> be used for all requests until the transaction >>>>>>>>>>>>>>>>>>>>>>>>>> is completed. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Then in section 8.1, we add the important >>>>>>>>>>>>>>>>>>>>>>>>>> details removed from section 8. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 8.1.1 Client Behavior >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> A client starting a client-initiated transaction >>>>>>>>>>>>>>>>>>>>>>>>>> MUST set the Conference ID in the common header >>>>>>>>>>>>>>>>>>>>>>>>>> of the message to the Conference ID for the >>>>>>>>>>>>>>>>>>>>>>>>>> conference that the client obtained previously. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The client MUST set the Transaction ID value in >>>>>>>>>>>>>>>>>>>>>>>>>> the common header to a number that is different >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >from 0 and that MUST NOT be reused in another >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> message from the client until a response from >>>>>>>>>>>>>>>>>>>>>>>>>> the server is received for the transaction. >>>>>>>>>>>>>>>>>>>>>>>>>> The client uses the Transaction ID value to >>>>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the >>>>>>>>>>>>>>>>>>>>>>>>>> floor control server. >>>>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, it >>>>>>>>>>>>>>>>>>>>>>>>>> is important to choose a Transaction ID value >>>>>>>>>>>>>>>>>>>>>>>>>> that lets the receiver distinguish the reception >>>>>>>>>>>>>>>>>>>>>>>>>> of the next message in a sequence of BFCP >>>>>>>>>>>>>>>>>>>>>>>>>> messages from a retransmission of a previous >>>>>>>>>>>>>>>>>>>>>>>>>> message. Therefore, BFCP entities using an >>>>>>>>>>>>>>>>>>>>>>>>>> unreliable transport MUST use monotonically >>>>>>>>>>>>>>>>>>>>>>>>>> increasing Transaction ID values (except for >>wrap-around). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> A client receiving a server-initiated >>>>>>>>>>>>>>>>>>>>>>>>>> transaction over an unreliable transport MUST >>>>>>>>>>>>>>>>>>>>>>>>>> copy the Transaction ID from the request >>>>>>>>>>>>>>>>>>>>>>>>>> received from the server into the response. >>>>>>>>>>>>>>>>>>>>>>>>>> [Question: is there a need to copy the >>>>>>>>>>>>>>>>>>>>>>>>>> Conference ID and User ID, if present?] >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> 8.2. Server Behavior >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> A floor control server sending a response within >>>>>>>>>>>>>>>>>>>>>>>>>> a client-initiated transaction MUST copy the >>>>>>>>>>>>>>>>>>>>>>>>>> Conference ID, the Transaction ID, and the User >>>>>>>>>>>>>>>>>>>>>>>>>> ID >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >from the request received from the client into >>>>>>>>>>>>>>>>>>>>>>>>> >the >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> response. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions MUST contain a >>>>>>>>>>>>>>>>>>>>>>>>>> Transaction ID equal to >>>>>>>>>>>>>>>>>>>>>>>>>> 0 when BFCP is used over a reliable transport. >>>>>>>>>>>>>>>>>>>>>>>>>> Over an unreliable transport, the Transaction ID >>>>>>>>>>>>>>>>>>>>>>>>>> shall have the same properties as for >>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions. >>>>>>>>>>>>>>>>>>>>>>>>>> The server uses the Transaction ID value to >>>>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the >>>>>>>>>>>>>>>>>>>>>>>>>> floor participant or floor chair. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, this is better. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = >>>>>>>>>>>>>>>>>>>>>>>>>>> "BFCP clients SHOULD authenticate the floor >>>>>>>>>>>>>>>>>>>>>>>>>>> control server before sending any BFCP message >>>>>>>>>>>>>>>>>>>>>>>>>>> to it or accepting any BFCP message from it. >>>>>>>>>>>>>>>>>>>>>>>>>>> Similarly, floor control servers SHOULD >>>>>>>>>>>>>>>>>>>>>>>>>>> authenticate a client before accepting any BFCP >>>>>>>>>>>>>>>>>>>>>>>>>>> message from it or sending any BFCP message to it. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication >>>>>>>>>>>>>>>>>>>>>>>>>>> between clients and floor control servers, as >>>>>>>>>>>>>>>>>>>>>>>>>>> specified in Section 9.1. >>>>>>>>>>>>>>>>>>>>>>>>>>> This is the RECOMMENDED authentication >>>>>>>>>>>>>>>>>>>>>>>>>>> mechanism in BFCP.² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> What are the cases where clients and servers do >>>>>>>>>>>>>>>>>>>>>>>>>>> not need to be authenticating each other? I >>>>>>>>>>>>>>>>>>>>>>>>>>> know this requirement and the other >>>>>>>>>>>>>>>>>>>>>>>>>>> SHOULD-level requirements around use of >>>>>>>>>>>>>>>>>>>>>>>>>>> TLS/DTLS are carried over from RFC 4582, but >>>>>>>>>>>>>>>>>>>>>>>>>>> I¹m concerned that they aren¹t as strong as they >>should be. >>>>>>>>>>>>>>>>>>>>>>>>>>> For a conference where the signaling traffic is >>>>>>>>>>>>>>>>>>>>>>>>>>> authenticated and confidentiality and integrity >>>>>>>>>>>>>>>>>>>>>>>>>>> protected, why is it ok for the floor control >>>>>>>>>>>>>>>>>>>>>>>>>>> traffic not to be? Could these requirements be >>>>>>>>>>>>>>>>>>>>>>>>>>> adjusted to require use of TLS/DTLS at least in >>>>>>>>>>>>>>>>>>>>>>>>>>> cases where the signaling is also protected? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but again, this would be at the expense of >>>>>>>>>>>>>>>>>>>>>>>>>> adding a non backward compatible change from rfc >>>>>>>>>>>>>>>>>>>>>>>>>> 4582. How about saying TLS/DTLS MUST be used for >>>>>>>>>>>>>>>>>>>>>>>>>> BFCP in such cases, while pointing out the rfc >>>>>>>>>>>>>>>>>>>>>>>>>> 4582 >>>>>>>>>>>>>>>>>>>>>>>>>> based implementations may not comply (similar to >>>>>>>>>>>>>>>>>>>>>>>>>> what we did with the version field). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Works for me. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Feel free to make all of these changes and submit >>>>>>>>>>>>>>>>>>>>>>>>> a rev and I¹ll issue the IETF LC. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>> Alissa >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>>>>>> See the point above about ciphersuites. >>>>>>>>>>>>>>>>>>>>>>>>>>> ³Non-null encryption² is not a sufficient >>>>>>>>>>>>>>>>>>>>>>>>>>> minimum baseline, and if the requirements >>>>>>>>>>>>>>>>>>>>>>>>>>> change in Section 7 they should be reflected here as >>well. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Yep. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Editorial nits to be resolved with LC comments: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = ³The version field MUST be set >>>>>>>>>>>>>>>>>>>>>>>>>>> to 1 when using BFCP over a reliable transport, >>>>>>>>>>>>>>>>>>>>>>>>>>> i.e. as in [2].² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I find it a little odd to reference the spec >>>>>>>>>>>>>>>>>>>>>>>>>>> you¹re obsoleting in this sentence, especially >>>>>>>>>>>>>>>>>>>>>>>>>>> since BFCP over a reliable transport is >>>>>>>>>>>>>>>>>>>>>>>>>>> completely specified in this bis document. I >>>>>>>>>>>>>>>>>>>>>>>>>>> would suggest dropping >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>> the i.e. >>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> clause. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Good catch. This is a carry over from before >>>>>>>>>>>>>>>>>>>>>>>>>> this draft was adopted as a bis version of rfc4582. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using >>>>>>>>>>>>>>>>>>>>>>>>>>> BFCP over an unreliable transport with the >>>>>>>>>>>>>>>>>>>>>>>>>>> extensions specified in this document.² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> The bit about ³with the extensions specified in >>>>>>>>>>>>>>>>>>>>>>>>>>> this document² is extraneous and should be removed. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an >>>>>>>>>>>>>>>>>>>>>>>>>>> unsupported version field value, the receiving >>>>>>>>>>>>>>>>>>>>>>>>>>> server MUST send an Error message with >>>>>>>>>>>>>>>>>>>>>>>>>>> parameter value 12 (Unsupported >>>>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Use of the word ³server² here makes it sound as >>>>>>>>>>>>>>>>>>>>>>>>>>> if only servers could receive headers with >>>>>>>>>>>>>>>>>>>>>>>>>>> unsupported versions. >>>>>>>>>>>>>>>>>>>>>>>>>>> Should this be ³the receiving endpoint²? >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 6.2.4 = "[23], Section 6.7 provides >>>>>>>>>>>>>>>>>>>>>>>>>>> useful recommendations Š² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> The links in the references are not quite right. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 8.3.2 = s/when fires/when fired/ >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 = >>>>>>>>>>>>>>>>>>>>>>>>>>> s/high-jack/hijack/ >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> = Section B.1 = "situation where multiple >>>>>>>>>>>>>>>>>>>>>>>>>>> different and non-interoperable would >>>>>>>>>>>>>>>>>>>>>>>>>>> co- >>>>>>>>>>>>>>>>>>>>>>>>>>> exist in the market.² >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> There is a word missing after ³non-interoperable." >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This should read ³non-interoperable implementations². >>>>>>>>>>>>>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP >>>>>>>>>>>>>>>>>>>>>>>>>> were already used² should read ³BFCP over UDP is >>>>>>>>>>>>>>>>>>>>>>>>>> already being used². >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>>>>>>>>>>>> Charles >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>>>>>>>>>>>>>>> bfcpbis mailing list >>>>>>>>>>>>>>>>>>>>>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org><mailto:bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>> >>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> bfcpbis mailing list >>>>>>>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> >>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> bfcpbis mailing list >>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>> >>>>> >>>> >>> >> >>_______________________________________________ >>bfcpbis mailing list >>bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> >>https://www.ietf.org/mailman/listinfo/bfcpbis > >_______________________________________________ >bfcpbis mailing list >bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> >https://www.ietf.org/mailman/listinfo/bfcpbis _______________________________________________ bfcpbis mailing list bfcpbis@ietf.org<mailto:bfcpbis@ietf.org> https://www.ietf.org/mailman/listinfo/bfcpbis -- # Cisco | http://www.cisco.com/telepresence/ ## tomkrist@cisco.com<mailto:tomkrist@cisco.com> | http://www.tandberg.com ### | http://folk.uio.no/tomkri/
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen (tomkrist)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen (tomkrist)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen
- [bfcpbis] Status update on draft-ietf-mmusic-dtls… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Christer Holmberg
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Charles Eckel (eckelcu)
- Re: [bfcpbis] Status update on draft-ietf-mmusic-… Tom Kristensen (tomkrist)