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

[Christer Holmberg <[e-mail]>]

Hi,

>I have to study the latest version of draft-ietf-mmusic-dtls-sdp to 
>tell, but as of know I think we may need a new section similar to "8.1.  
>TCP Connection Management" for DTLS/UDP, where amongst other things the 
>'dtls-connection' will be mentioned.

The issue is that the text we agreed upon talks about "clarifications". 

But, draft-dtls-sdp is more than clarifications - it is also new stuff (e.g. the 'dtls-connection' attribute) - so it needs to be clear whether that is included or not.

Regards,

Christer
 

On 11/02/2015 11:39 AM, Christer Holmberg wrote:
> Just a question for clarification: will the draft now adopt the 'dtls-connection' attribute defined in the DTLS-SDP draft?
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Charles Eckel (eckelcu) [mailto:[e-mail]]
> Sent: 02 November 2015 10:26
> To: Tom Kristensen (tomkrist)<[e-mail]>; Christer Holmberg<[e-mail]>
> Cc: Alissa Cooper<[e-mail]>; [e-mail]; [e-mail]; Gonzalo Camarillo<[e-mail]>; Ben Campbell<[e-mail]>
> 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)"<[e-mail]>
> 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:[e-mail]]
>>> Sent: 28 September 2015 18:50
>>> To: Christer Holmberg<[e-mail]>; Tom Kristensen
>>> (tomkrist)<[e-mail]>
>>> Cc: Alissa Cooper<[e-mail]>; [e-mail];
>>> [e-mail]; Gonzalo
>>> Camarillo<[e-mail]>; Ben
>>> Campbell<[e-mail]>
>>> 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"
>>> <[e-mail] on behalf of
>>> [e-mail]>
>>> 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"
>>>> <[e-mail]>
>>>> 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"
>>>>> <[e-mail]>
>>>>> 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:[e-mail]]
>>>>>> Sent: 22. syyskuuta 2015 17:05
>>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist)
>>>>>> Cc: [e-mail];
>>>>>> [e-mail]; 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"
>>>>>> <[e-mail]>
>>>>>> 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"
>>>>>>> <[e-mail]>
>>>>>>> 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"
>>>>>>>> <[e-mail] on behalf of
>>>>>>>> [e-mail]>
>>>>>>>> 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"
>>>>>>>>> <[e-mail]>
>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25
>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo;
>>>>>>>>>>> [e-mail]; Ben Campbell;
>>>>>>>>>>> [e-mail]
>>>>>>>>>>> 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)"<[e-mail]>
>>>>>>>>>>>> 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"<[e-mail]>
>>>>>>>>>>>>> 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:[e-mail]]
>>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07
>>>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist);
>>>>>>>>>>>>>>> [e-mail]; 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)
>>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>>> 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"<[e-mail]>
>>>>>>>>>>>>>>>> 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)
>>>>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>>>>> 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"<[e-mail]>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> <[e-mail]>     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
>>>>>>>>>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>> 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<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation:
>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12*
>>>>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST
>>>>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)"<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>> *Cc: *"[e-mail]<mailto:[e-mail]>"
>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Charles,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>     wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>>> HI Alissa,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts
>>>>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>>>>>>>>>>>>>>>> To: "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>                                          
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                        
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                      
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                                    
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                                
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                              
>>>>>>>>>>>>
>>>>>>>>>>>>                          
>>>>>>>>>>>
>>>>>>>>>>>                        
>>>>>>>>>>
>>>>>>>>>>                      
>>>>>>>>> _______________________________________________
>>>>>>>>> bfcpbis mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>
>>>>>>>>>                    
>>>>>>>>
>>>>>>>>                  
>>>>>>>
>>>>>>>                
>>>>>>
>>>>>>              
>>>>>
>>>>>            
>>>> _______________________________________________
>>>> bfcpbis mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>
>>>>          
>>>
>>>        
>>      
>