Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 02 November 2015 10:39 UTC

Return-Path: <christer.holmberg@ericsson.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 871961A1BCF for <bfcpbis@ietfa.amsl.com>; Mon, 2 Nov 2015 02:39:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 VaP-C3aD3pI0 for <bfcpbis@ietfa.amsl.com>; Mon, 2 Nov 2015 02:39:46 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3417A1A1BC8 for <bfcpbis@ietf.org>; Mon, 2 Nov 2015 02:39:45 -0800 (PST)
X-AuditID: c1b4fb2d-f79626d000004282-82-56373d6ee265
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CE.F2.17026.E6D37365; Mon, 2 Nov 2015 11:39:43 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Mon, 2 Nov 2015 11:39:39 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Thread-Topic: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis]
Thread-Index: AdEVPGtzePVeqGKXRT2MOxuY5KEVyP//+0SAgAALUID//8n3gA==
Date: Mon, 02 Nov 2015 10:39:39 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <D25D4C6A.5DF22%eckelcu@cisco.com>
In-Reply-To: <D25D4C6A.5DF22%eckelcu@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyM+JvrW6+rXmYwasONovpZ/4yWszvPM1u 8W/dUSaLW+tvs1hsmvWFzeLKkV9sDmweU35vZPX48uQlk8eSJT+ZPGbtfMLi8eXyZ7YA1igu m5TUnMyy1CJ9uwSujP9/prIV7OpgqdjwfilLA2PPb+YuRk4OCQETiTOnp7JB2GISF+6tB7K5 OIQEjjBKXDm/nBHCWcwosfviUqAODg42AQuJ7n/aIA0iAqkSJxZ2sILYzAKtTBKHOr1ASoQF MiU23iyEKMmSaJwNMV9EwEli3cOJYHtZBFQkDq7ZxAhSzivgK7HzUD3Epn5GibM3NjOBxDkF 9CWWXVIAKWcEOu37qTVMEJvEJW49mc8EcbKAxJI956FeEZV4+fgfK4StJLHo9mewMcwCmhLr d+lDtCpKTOl+yA5i8woISpyc+YRlAqPYLCRTZyF0zELSMQtJxwJGllWMosWpxcW56UbGeqlF mcnFxfl5enmpJZsYgRF4cMtv3R2Mq187HmIU4GBU4uE1SDQLE2JNLCuuzD3EKMHBrCTCG6Jl HibEm5JYWZValB9fVJqTWnyIUZqDRUmct4XpQaiQQHpiSWp2ampBahFMlomDU6qBcfX/XzNl gw+7msbH26eeVmpe68DdI3b385WGju9vG1myrPTDOW93Ge09L8AucOVeY7h2s9u0qjc3fDm1 C4+Zmrt0/9if5P8rpfzExcNpQb8yNQwdzBgSp60xuaHNt+56zFr7cok3Eun7/G9olEpPTTd8 O5np+CanNdwtZ5KOLlTPPOCZnfNHiaU4I9FQi7moOBEAot6Xw7wCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/NqKURNZcJYol9l-ftXExy1xVa5Q>
Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Ben Campbell <ben@nostrum.com>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Nov 2015 10:39:53 -0000

Just a question for clarification: will the draft now adopt the 'dtls-connection' attribute defined in the DTLS-SDP draft?

Regards,

Christer

-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] 
Sent: 02 November 2015 10:26
To: Tom Kristensen (tomkrist) <tomkrist@cisco.com>; Christer Holmberg <christer.holmberg@ericsson.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: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis]

Great, thanks Tom. I look forward to seeing the update posted before the end of this week.

Cheers,
Charles

On 11/2/15, 4:45 PM, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
wrote:

>Perfect! I'll update and polish the draft as discussed and agreed upon 
>below and submit.
>
>-- Tom
>
>On 11/02/2015 08:04 AM, Christer Holmberg wrote:
>> Hi,
>>
>> draft-ietf-mmusic-dtls-sdp was discussed at MMUSIC today.
>>
>> At this moment there are no technical open issues. The plan is to add 
>>some editorial work, based on comments received during the session, 
>>and the add text regarding DTLS-usage drafts/specs that the draft updates.
>>After that, unless something unexpected comes up, the draft should be 
>>ready for WGLC.
>>
>> Regards,
>>
>> Christer
>>
>>
>>
>> -----Original Message-----
>> From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com]
>> 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
>>>      
>>    
>