Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Fri, 25 September 2015 22:31 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 D24851A9026 for <bfcpbis@ietfa.amsl.com>; Fri, 25 Sep 2015 15:31:47 -0700 (PDT)
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 tt4qYNMcUPIi for <bfcpbis@ietfa.amsl.com>; Fri, 25 Sep 2015 15:31:41 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8949A1A9022 for <bfcpbis@ietf.org>; Fri, 25 Sep 2015 15:31:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=54506; q=dns/txt; s=iport; t=1443220301; x=1444429901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CKMMggexjywNRDp17QNgSqX/1G/5zbS6Sfi1EdKdNWw=; b=b5UyxG25kjOQZUixpQ+vhqltfDDELQasBC+cTtVyB4jrV0HOsu0BKhuF SDOdrfxzr72CtLsme+xqvZ8kihAjIuR3MUxK+iW3z7xHbw6HCjKJmTY6x RR5UlA/SbjijBKZuZTUhppN5TMbK0J/KripkDJvPVjgmkdPt6wvf9VOMO k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAgABywVW/5NdJa1dgyRUaQaDJLoOAQ2BVxoKhS9KAhyBCjgUAQEBAQEBAYEKhCQBAQEEAQEBFwEIETMBBgYFDAQCAQYCEQMBAQEBAgIRAREDAgICJQsUAQgIAgQBDQUJEogTDZpPnSyUJgEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIolIgQaEOwEBBQkPGBsHBgQJDIJKgUMFhzSFS4Uugz8BhROCboULgU+ENoMhdYhWhFCDbAEfAQFCghEcgVRxAYdaBxcjgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,588,1437436800"; d="scan'208";a="191683649"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP; 25 Sep 2015 22:31:39 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t8PMVdZQ013831 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 25 Sep 2015 22:31:39 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 25 Sep 2015 17:31:38 -0500
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.000; Fri, 25 Sep 2015 17:31:38 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Thread-Topic: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
Thread-Index: AQHQ9JZwfyzUpa4ayECSaB75x694G55HStYQ///nPgCAAOmjMIAAWNgAgAL/3ZCAAER+AIABRHtQgAC7yIA=
Date: Fri, 25 Sep 2015 22:31:38 +0000
Message-ID: <D22B17D1.5A057%eckelcu@cisco.com>
References: <D2258CEC.598F0%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37AC7C92@ESESSMB209.ericsson.se> <D2259E02.5992C%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37ACA75F@ESESSMB209.ericsson.se> <D226AC07.59A4D%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37AD6C84@ESESSMB209.ericsson.se> <D2296A62.59DA1%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37ADD714@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37ADD714@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.5.150821
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.236.217]
Content-Type: text/plain; charset="utf-8"
Content-ID: <D91C56A4A84059499BE4D22A5F2A1CB6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/QlsB7aCYXVv3edXKAUZeLcqlt4U>
Cc: Alissa Cooper <alissa@cooperw.in>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, "draft-ietf-bfcpbis-rfc4582bis@tools.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
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, 25 Sep 2015 22:31:48 -0000
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 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.ht >>>>>>>>> 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-bcp- >>>>>>>>>>>>>>>>>>>>> 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 >>>> >>> >> >
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Christer Holmberg
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Paul Kyzivat
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Christer Holmberg
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Christer Holmberg
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Christer Holmberg
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Christer Holmberg
- Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis Charles Eckel (eckelcu)