Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
Tom Kristensen <tomkrist@cisco.com> Mon, 02 November 2015 07:45 UTC
Return-Path: <tomkrist@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 87DCD1B33F8 for <bfcpbis@ietfa.amsl.com>; Sun, 1 Nov 2015 23:45:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 0mbjAob6mDgK for <bfcpbis@ietfa.amsl.com>; Sun, 1 Nov 2015 23:45:29 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33071B3430 for <bfcpbis@ietf.org>; Sun, 1 Nov 2015 23:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47277; q=dns/txt; s=iport; t=1446450328; x=1447659928; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pf4CC/cdxOTKS8Ksv1qQ2qjl9aBB0tJ69W1f481JPcM=; b=WYKSlJy7yt1taQQaQ9mHBczhXru/DpaxPaUPr5vS309vZTYi5gzoAr8a L/7sH9wDIyJiN8XQ6y9d+gVFZ/DkifHhh4ukj/1M5GWXSOLded5LqKvoK E3Nug7YkauXLGO7wMNPzVIfSqSSFDUHNWX9CvOvgKF5QZMbY+Jtp9UA4u c=;
X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="scan'208";a="607916935"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Nov 2015 07:45:26 +0000
Received: from [10.54.90.26] (dhcp-10-54-90-26.cisco.com [10.54.90.26]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA27jPBU009254; Mon, 2 Nov 2015 07:45:25 GMT
Message-ID: <56371495.7080105@cisco.com>
Date: Mon, 02 Nov 2015 08:45:25 +0100
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/ke_VX93afebmAwUo_6BeEto1SEs>
Cc: Ben Campbell <ben@nostrum.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>
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: Mon, 02 Nov 2015 07:45:36 -0000
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] > Sent: 28 September 2015 18:50 > To: Christer Holmberg<christer.holmberg@ericsson.com>; Tom Kristensen (tomkrist)<tomkrist@cisco.com> > Cc: Alissa Cooper<alissa@cooperw.in>; bfcpbis@ietf.org; draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo Camarillo<gonzalo.camarillo@ericsson.com>; Ben Campbell<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 on behalf of 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> >> 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> >>> 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] >>>> Sent: 22. syyskuuta 2015 17:05 >>>> To: Christer Holmberg; Tom Kristensen (tomkrist) >>>> Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; 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> >>>> 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> >>>>> 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 on behalf of >>>>>> 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> >>>>>>> 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] >>>>>>>>> Sent: 11. syyskuuta 2015 13:25 >>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo; >>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben Campbell; >>>>>>>>> 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> >>>>>>>>>> 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> >>>>>>>>>>> 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] >>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07 >>>>>>>>>>>>> To: Charles Eckel (eckelcu) >>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist); >>>>>>>>>>>>> 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> >>>>>>>>>>>>> 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> >>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>> 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> >>>>>>>>>>>>>>>> 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> 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>> >>>>>>>>>>>>>>>>>>> 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>> >>>>>>>>>>>>>>>>>>>>> *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>> >>>>>>>>>>>>>>>>>>>>> *Cc: *"bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" >>>>>>>>>>>>>>>>>>>>> <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>> 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>> >>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM >>>>>>>>>>>>>>>>>>>>>> To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>" >>>>>>>>>>>>>>>>>>>>>> <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> >>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> bfcpbis mailing list >>>>>>> bfcpbis@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis >>>>>>> >>>>>> >>>>> >>>> >>> >> _______________________________________________ >> bfcpbis mailing list >> bfcpbis@ietf.org >> https://www.ietf.org/mailman/listinfo/bfcpbis >> >
- 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
- [bfcpbis] Status update on draft-ietf-mmusic-dtls… Christer Holmberg
- 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-… 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)