Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis

[Christer Holmberg <[e-mail]>]

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.html
>>>>>
>>>>> As a result, I better understand the issue you are addressing. I 
>>>>> suggest the following changes to be consistent with what is being 
>>>>> proposed in
>>>>> MMUSIC:
>>>>>
>>>>> ------------
>>>>> Section 9:
>>>>>
>>>>> OLD:
>>>>> Endpoints that use the offer/answer model to establish a DTLS
>>>>>     association MUST support the 'setup' attribute, as defined in 
>>>>>[7].
>>>>> When DTLS is used with UDP, the 'setup' attribute indicates which  
>>>>>of the endpoints (client or floor control server) initiates the  
>>>>>DTLS association setup. The requirements for the offer/answer  
>>>>>exchange specified in [13], Section 5 of [13] MUST be followed when 
>>>>>using DTLS.
>>>>> Offer/answer considerations are described in Section 10.5.
>>>>>
>>>>> NEW:
>>>>> When DTLS is used with UDP, the requirements specified in Section 
>>>>> 5 of [13] MUST be followed.
>>>>>
>>>>>
>>>>> Section 10.5
>>>>>
>>>>> OLD
>>>>>     If the transport parameters or the key fingerprints change, the
>>>>>     endpoints MUST establish a new DTLS connection.  In such case the
>>>>>     'active/passive' status of the endpoints will again be determined
>>>>>     following the procedures in [7], and the new status will be 
>>>>>used to
>>>>>     determine the TLS roles associated with the new DTLS connection.
>>>>>
>>>>>        Informational note: The procedure above is identical to the 
>>>>>one
>>>>>        defined for DTLS-SRTP in [13].
>>>>>
>>>>>        Note: A new DTLS connection needs to be established if the
>>>>>        transport parameters or the key fingerprints change.
>>>>>
>>>>>
>>>>>
>>>>> NEW:
>>>>> The conditions under which endpoints MUST establish a new DTLS 
>>>>> connection are as the same defined for DTLS-SRTP in [13].
>>>>> ————————
>>>>>
>>>>> This way we avoid any potential conflicts with the intent of RFC 
>>>>> 5763, and when clarifications to RFC 5763 are made, they will be 
>>>>> picked up by the BFCP spec.
>>>>>
>>>>> Cheers,
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 4/18/15, 2:01 PM, "Christer
>>>>> Holmberg"<[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-bcp-08#
>>>>>>>>>>>>>>>>> s
>>>>>>>>>>>>>>>>> e
>>>>>>>>>>>>>>>>> c
>>>>>>>>>>>>>>>>> tion
>>>>>>>>>>>>>>>>> -4)
>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> How about we keep this minimum requirement, and add a 
>>>>>>>>>>>>>>>> reference to draft-ietf-uta-tls-bcp along with a 
>>>>>>>>>>>>>>>> recommendation to adhere to the best practices it 
>>>>>>>>>>>>>>>> outlines in section 4?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA for 
>>>>>>>>>>>>>>> backwards compatibility and SHOULD support the ones 
>>>>>>>>>>>>>>> listed in the UTA drafts would be ok.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the transaction 
>>>>>>>>>>>>>>>>> ID requirements regarding non-reuse/monotonically 
>>>>>>>>>>>>>>>>> increasing IDs are re-stated multiple times across 
>>>>>>>>>>>>>>>>> these three sections, in slightly different ways, to 
>>>>>>>>>>>>>>>>> the point where it¹s not clear exactly what they are.
>>>>>>>>>>>>>>>>> It seems like they are:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction:
>>>>>>>>>>>>>>>>> ID is
>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated transaction:
>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for
>>>>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction:
>>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in another 
>>>>>>>>>>>>>>>>> message from the client until a response from the 
>>>>>>>>>>>>>>>>> server is received for the transaction, but need not 
>>>>>>>>>>>>>>>>> be monotonically increasing (e.g., a lower, recently 
>>>>>>>>>>>>>>>>> used ID could be re-used once a response is
>>>>>>>>>>>>>>>>> received)
>>>>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated transaction:
>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for
>>>>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1?
>>>>>>>>>>>>>>>>> If so, why not just require IDs in all 
>>>>>>>>>>>>>>>>> client-initiated transactions to be monotonically increasing?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> Agree we can and should simplify this. Sections 8.1 and
>>>>>>>>>>>>>>>> 8.2 cover the client behavior and server behavior in 
>>>>>>>>>>>>>>>> detail. As such, the transaction ID related information 
>>>>>>>>>>>>>>>> at the start of Section 8 is superfluous. I recommend 
>>>>>>>>>>>>>>>> reducing the text in Section 8 to the
>>>>>>>>>>>>>>>> follow:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 8. Protocol Transactions
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> In BFCP, there are two types of transactions:
>>>>>>>>>>>>>>>> client-initiated transactions and server-initiated 
>>>>>>>>>>>>>>>> transactions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Client-initiated transactions consist of a request from 
>>>>>>>>>>>>>>>> a client to a floor control server and a response from 
>>>>>>>>>>>>>>>> the floor control server to the client.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Server-initiated transactions have different behavior 
>>>>>>>>>>>>>>>> depending on underlying transport:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      When using a reliable transport, server-initiated 
>>>>>>>>>>>>>>>>transactions
>>>>>>>>>>>>>>>>      consist of a single message from a floor control 
>>>>>>>>>>>>>>>>server to a
>>>>>>>>>>>>>>>>      client (notifications).  They do not trigger any 
>>>>>>>>>>>>>>>>response.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>      When using an unreliable transport, 
>>>>>>>>>>>>>>>> server-initiated transactions
>>>>>>>>>>>>>>>>      consist of a request from a floor control server 
>>>>>>>>>>>>>>>> to a client and a
>>>>>>>>>>>>>>>>      response from the client to the floor control server.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, 
>>>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST be used 
>>>>>>>>>>>>>>>> for all requests until the transaction is completed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Then in section 8.1, we add the important details 
>>>>>>>>>>>>>>>> removed from section 8.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 8.1.1 Client Behavior
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A client starting a client-initiated transaction MUST 
>>>>>>>>>>>>>>>> set the Conference ID in the common header of the 
>>>>>>>>>>>>>>>> message to the Conference ID for the conference that 
>>>>>>>>>>>>>>>> the client obtained previously.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The client MUST set the Transaction ID value in the 
>>>>>>>>>>>>>>>>common header to a number that is different from 0 and 
>>>>>>>>>>>>>>>>that MUST NOT be reused in another message from the 
>>>>>>>>>>>>>>>>client until a response from the server is received for 
>>>>>>>>>>>>>>>>the transaction.
>>>>>>>>>>>>>>>> The client uses the Transaction ID value to match this 
>>>>>>>>>>>>>>>>message with the response from the floor control server.
>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, it is 
>>>>>>>>>>>>>>>>important to choose a Transaction ID value that lets the 
>>>>>>>>>>>>>>>>receiver distinguish the reception of the next message 
>>>>>>>>>>>>>>>>in a sequence of BFCP messages from a retransmission of 
>>>>>>>>>>>>>>>>a previous message.  Therefore, BFCP entities using an 
>>>>>>>>>>>>>>>>unreliable transport MUST use monotonically increasing 
>>>>>>>>>>>>>>>>Transaction ID values (except for wrap-around).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A client receiving a server-initiated transaction over  
>>>>>>>>>>>>>>>>an unreliable transport MUST copy the Transaction ID  
>>>>>>>>>>>>>>>>from the request received from the server into the 
>>>>>>>>>>>>>>>>response.
>>>>>>>>>>>>>>>> [Question: is there a need to copy the Conference ID 
>>>>>>>>>>>>>>>>and  User ID, if present?]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 8.2. Server Behavior
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> A floor control server sending a response within a 
>>>>>>>>>>>>>>>> client-initiated transaction MUST copy the Conference 
>>>>>>>>>>>>>>>> ID, the Transaction ID, and the User ID from the 
>>>>>>>>>>>>>>>> request received from the client into the response.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Server-initiated transactions MUST contain a 
>>>>>>>>>>>>>>>>Transaction ID equal to
>>>>>>>>>>>>>>>> 0 when BFCP is used over a reliable transport.  Over an 
>>>>>>>>>>>>>>>>unreliable transport, the Transaction ID shall have the 
>>>>>>>>>>>>>>>>same properties as for client-initiated transactions. 
>>>>>>>>>>>>>>>>The server uses the Transaction ID value to match this 
>>>>>>>>>>>>>>>>message with the response from the floor participant or 
>>>>>>>>>>>>>>>>floor chair.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> Thanks, this is better.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = "BFCP 
>>>>>>>>>>>>>>>>>clients  SHOULD authenticate the floor control server 
>>>>>>>>>>>>>>>>>before  sending any BFCP message to it or accepting any 
>>>>>>>>>>>>>>>>>BFCP message from it.
>>>>>>>>>>>>>>>>> Similarly, floor control servers SHOULD authenticate a 
>>>>>>>>>>>>>>>>>client before accepting any BFCP message from it or 
>>>>>>>>>>>>>>>>>sending any BFCP message to it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication between 
>>>>>>>>>>>>>>>>>clients and floor control servers, as specified in 
>>>>>>>>>>>>>>>>>Section 9.1.
>>>>>>>>>>>>>>>>> This is the RECOMMENDED authentication mechanism in 
>>>>>>>>>>>>>>>>>BFCP.²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What are the cases where clients and servers do not 
>>>>>>>>>>>>>>>>>need  to be authenticating each other? I know this 
>>>>>>>>>>>>>>>>>requirement  and the other SHOULD-level requirements 
>>>>>>>>>>>>>>>>>around use of  TLS/DTLS are carried over from RFC 4582, 
>>>>>>>>>>>>>>>>>but I¹m  concerned that they aren¹t as strong as they 
>>>>>>>>>>>>>>>>>should be.
>>>>>>>>>>>>>>>>> For a conference where the signaling traffic is 
>>>>>>>>>>>>>>>>>authenticated and confidentiality and integrity 
>>>>>>>>>>>>>>>>>protected, why is it ok for the floor control traffic 
>>>>>>>>>>>>>>>>>not to be? Could these requirements be adjusted to 
>>>>>>>>>>>>>>>>>require use of TLS/DTLS at least in cases where the 
>>>>>>>>>>>>>>>>>signaling is also protected?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> Yes, but again, this would be at the expense of adding 
>>>>>>>>>>>>>>>> a non backward compatible change from rfc 4582. How 
>>>>>>>>>>>>>>>> about saying TLS/DTLS MUST be used for BFCP in such 
>>>>>>>>>>>>>>>> cases, while pointing out the rfc
>>>>>>>>>>>>>>>> 4582
>>>>>>>>>>>>>>>> based implementations may not comply (similar to what 
>>>>>>>>>>>>>>>> we did with the version field).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> Works for me.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Feel free to make all of these changes and submit a rev 
>>>>>>>>>>>>>>> and I¹ll issue the IETF LC.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>>>>>> See the point above about ciphersuites. ³Non-null 
>>>>>>>>>>>>>>>>> encryption² is not a sufficient minimum baseline, and 
>>>>>>>>>>>>>>>>> if the requirements change in Section 7 they should be 
>>>>>>>>>>>>>>>>> reflected here as well.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> Yep.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>> Editorial nits to be resolved with LC comments:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> = Section 5.1 =
>>>>>>>>>>>>>>>>> ³The version field MUST be set to 1 when using BFCP 
>>>>>>>>>>>>>>>>> over a reliable transport, i.e. as in [2].²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I find it a little odd to reference the spec you¹re 
>>>>>>>>>>>>>>>>> obsoleting in this sentence, especially since BFCP 
>>>>>>>>>>>>>>>>> over a reliable transport is completely specified in 
>>>>>>>>>>>>>>>>> this bis document. I would suggest dropping the i.e. clause.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> Good catch. This is a carry over from before this draft 
>>>>>>>>>>>>>>>> was adopted as a bis version of rfc4582.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using BFCP 
>>>>>>>>>>>>>>>>> over an unreliable transport with the extensions 
>>>>>>>>>>>>>>>>> specified in this document.²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The bit about ³with the extensions specified in this 
>>>>>>>>>>>>>>>>> document² is extraneous and should be removed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an unsupported 
>>>>>>>>>>>>>>>>> version field value, the receiving server MUST send an 
>>>>>>>>>>>>>>>>> Error message with parameter value 12 (Unsupported
>>>>>>>>>>>>>>>>> Version) to indicate this.²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Use of the word ³server² here makes it sound as if 
>>>>>>>>>>>>>>>>> only servers could receive headers with unsupported versions.
>>>>>>>>>>>>>>>>> Should this be ³the receiving endpoint²?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> = Section 6.2.4 =
>>>>>>>>>>>>>>>>> "[23], Section 6.7 provides useful recommendations Š²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The links in the references are not quite right.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> = Section 8.3.2 =
>>>>>>>>>>>>>>>>> s/when fires/when fired/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>>>>>> s/high-jack/hijack/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> = Section B.1 =
>>>>>>>>>>>>>>>>> "situation where multiple different and 
>>>>>>>>>>>>>>>>> non-interoperable would
>>>>>>>>>>>>>>>>> co-
>>>>>>>>>>>>>>>>> exist in the market.²
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There is a word missing after ³non-interoperable."
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>> This should read ³non-interoperable implementations².
>>>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP were 
>>>>>>>>>>>>>>>>already used² should read ³BFCP over UDP is already 
>>>>>>>>>>>>>>>>being used².
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>> bfcpbis mailing list
>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>
>>>>>>>>>>>>>      
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>
>>>>>>>>>>>        
>>>>>>>>>>
>>>>>>>>>>         
>>>>>>>>>
>>>>>>>>>          
>>>>>>>>
>>>>>>>>           
>>>>>>>
>>>>>>>            
>>>>>>
>>>>>>          
>>>>
>>>>      
>>>    
>>
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bfcpbis