Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 21 September 2015 18:51 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 4CEBB1B33F4 for <bfcpbis@ietfa.amsl.com>; Mon, 21 Sep 2015 11:51:00 -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 4uLxzmOj27_p for <bfcpbis@ietfa.amsl.com>; Mon, 21 Sep 2015 11:50:55 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9F6E1B341D for <bfcpbis@ietf.org>; Mon, 21 Sep 2015 11:50:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46226; q=dns/txt; s=iport; t=1442861454; x=1444071054; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=KGjEvswJPseA2bVHT3DoedmNMzJ9c6uHbx1sX9BS2g8=; b=SYe2FPtYf9UtqUacwS3iSV/AWZQLpxGBZftSzbw/tKyuWe2I4pka1SyG rbMZrU++zSHxnh+6GuFE7ShgpS4eEqNhXLr6GIVDYofQ5PYzEUuMHG0hY na6L+sWoINwwIIxsMm4EThn7ALBdxk0PbXLGkxOberblwD3l61YwRlmzP w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AVAgAzUQBW/4wNJK1dgyRUaQa9QwENgXEKhS9KAhyBHDgUAQEBAQEBAYEKhCQBAQEEAQEBFwEIETMBBgYFDAQCAQYCEQMBAQEBAgIRAREDAgICJQsUAQgIAgQBDQUJEogTDZpKnSuTbAEBAQEBAQEBAQEBAQEBAQEBAQEBAReBIolIgQaEOwEBBQknGwcGBAkMgkqBQwWHNIpygz4BhRCCboUIgU2ENYMhdIhKhEyDbAEfAQFCghEcgVRxAYgmBxcjgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,568,1437436800"; d="scan'208";a="189835396"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-4.cisco.com with ESMTP; 21 Sep 2015 18:50:43 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t8LIoXIo010279 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 21 Sep 2015 18:50:43 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 21 Sep 2015 13:50:34 -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; Mon, 21 Sep 2015 13:50:34 -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///nPgA=
Date: Mon, 21 Sep 2015 18:50:34 +0000
Message-ID: <D2259E02.5992C%eckelcu@cisco.com>
References: <D2258CEC.598F0%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37AC7C92@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37AC7C92@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.79.68]
Content-Type: text/plain; charset="utf-8"
Content-ID: <0A84466798E0004DAB8CAA33ED3ECE28@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/Jsmn0ltgHzgwPwI2E4fm-z4LynE>
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: Mon, 21 Sep 2015 18:51:00 -0000
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. Cheers, Charles 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.html >>>>>> >>>>>> 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-08# >>>>>>>>>>>>>>>>>> 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)