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

["Charles Eckel (eckelcu)" <[e-mail]>]

I see. As this is a moving target, perhaps where we reference RFC 5763 we
can add a note for the RFC editor that draft-ietf-mmusic-dtls-sdp is
expected to add clarifications and make changes to RFC 5763 that should be
considered prior to publication of rfc4583bis.

Cheers,
Charles

On 9/21/15, 11:23 AM, "Christer Holmberg" <[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.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
>