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

[Christer Holmberg <[e-mail]>]

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-bcp
>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>> 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
>>>>
>>>
>>
>