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

[Christer Holmberg <[e-mail]>]

I didn't know there was an "actress" value for the setup attribute ;)

I guess the following statement:

	"are as the same defined for DTLS-SRTP in [13]."

...should be:

	"are the same as defined for DTLS-SRTP in [13]."

Regards,

Christer


-----Original Message-----
From: Charles Eckel (eckelcu) [mailto:[e-mail]] 
Sent: 09 December 2015 18:37
To: Charles Eckel (eckelcu) <[e-mail]>; Christer Holmberg <[e-mail]>; Tom Kristensen (tomkrist) <[e-mail]>
Cc: [e-mail]; [e-mail]; Alissa Cooper <[e-mail]>; Gonzalo Camarillo <[e-mail]>; Ben Campbell <[e-mail]>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Christer and I discussed this offline and now I’d like to bring the
proposal for moving forward to the list.

draft-ietf-mmusic-dtls-sdp WILL update RFC 5763 (see
https://tools.ietf.org/html/draft-ietf-mmusic-dtls-sdp-03) to include
support for the new 'dtls-connection’ attribute. The proposed changes to
accommodate this in draft-ietf-bfcpbis-rfc4583bis are as follows:


1) Update last paragraph of section 10.5

OLD:

   The conditions under which endpoints MUST establish a new DTLS
   connection are as the same defined for DTLS-SRTP in [13].


NEW 
   The condition above, and additional conditions under which
   endpoints MUST establish a new DTLS connection, are as the
   same defined for DTLS-SRTP in [13].

Where [13] is a reference to RFC 5763.

2) Update the DTLS example in section 11 to include the dtls-connection
attribute as follows:

   m=application 50000 UDP/TLS/BFCP *
   a=setup:actress
a=dtls-connection:new
   a=fingerprint:SHA-1 \
        4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
   a=floorctrl:c-only s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:2
   m=audio 50002 RTP/AVP 0
   a=label:10
   m=video 50004 RTP/AVP 31
   a=label:11

   The following is the answer returned by the server.

   m=application 55000 UDP/TLS/BFCP *
   a=setup:active
a=dtls-connection:new

   a=fingerprint:SHA-1 \
        3D:B4:7B:E3:CC:FC:0D:1B:5D:31:33:9E:48:9B:67:FE:68:40:E8:21
   a=floorctrl:s-only
   a=confid:4321
   a=userid:1234
   a=floorid:1 mstrm:10
   a=floorid:2 mstrm:11
   a=bfcpver:2
   m=audio 55002 RTP/AVP 0
   m=video 55004 RTP/AVP 31

Christer, please review and correct my usage of dtls-connection attribute.
Everyone, please comment as to whether or not you agree with this path
forward.

Cheers,
Charles





On 11/6/15, 10:51 AM, "bfcpbis on behalf of Charles Eckel (eckelcu)"
<[e-mail] on behalf of [e-mail]> wrote:

>Christer,
>
>Has the MMUSIC working group decided that draft-ietf-mmusic-dtls-sdp will
>NOT update RFC 5763? It currently references it extensively, but according
>to the boilerplate it does not explicitly update RFC 5763.
>
>The draft now includes better backward compatibility with respect to RFC
>5763, which is good to see. I think we should be able to word things such
>that we recommend using the new dtls-connection attribute while also
>requiring support the absence of this attribute for backward
>compatibility. This would be very straightforward if
>draft-ietf-mmusic-dtls-sdp updates RFC 5763.
>
>Cheers,
>Charles
>
>On 11/2/15, 7:39 PM, "Christer Holmberg" <[e-mail]>
>wrote:
>
>>Just a question for clarification: will the draft now adopt the
>>'dtls-connection' attribute defined in the DTLS-SDP draft?
>>
>>Regards,
>>
>>Christer
>>
>>-----Original Message-----
>>From: Charles Eckel (eckelcu) [mailto:[e-mail]]
>>Sent: 02 November 2015 10:26
>>To: Tom Kristensen (tomkrist) <[e-mail]>; Christer Holmberg
>><[e-mail]>
>>Cc: Alissa Cooper <[e-mail]>; [e-mail];
>>[e-mail]; Gonzalo Camarillo
>><[e-mail]>; Ben Campbell <[e-mail]>
>>Subject: Re: Status update on draft-ietf-mmusic-dtls-sdp [was: [bfcpbis]
>>draft-ietf-bfcpbis-rfc4583bis]
>>
>>Great, thanks Tom. I look forward to seeing the update posted before the
>>end of this week.
>>
>>Cheers,
>>Charles
>>
>>On 11/2/15, 4:45 PM, "Tom Kristensen (tomkrist)" <[e-mail]>
>>wrote:
>>
>>>Perfect! I'll update and polish the draft as discussed and agreed upon
>>>below and submit.
>>>
>>>-- Tom
>>>
>>>On 11/02/2015 08:04 AM, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> draft-ietf-mmusic-dtls-sdp was discussed at MMUSIC today.
>>>>
>>>> At this moment there are no technical open issues. The plan is to add
>>>>some editorial work, based on comments received during the session,
>>>>and the add text regarding DTLS-usage drafts/specs that the draft
>>>>updates.
>>>>After that, unless something unexpected comes up, the draft should be
>>>>ready for WGLC.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Charles Eckel (eckelcu) [mailto:[e-mail]]
>>>> Sent: 28 September 2015 18:50
>>>> To: Christer Holmberg<[e-mail]>; Tom Kristensen
>>>>(tomkrist)<[e-mail]>
>>>> Cc: Alissa Cooper<[e-mail]>; [e-mail];
>>>>[e-mail]; Gonzalo
>>>>Camarillo<[e-mail]>; Ben
>>>>Campbell<[e-mail]>
>>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
>>>>
>>>> Thanks Christer.
>>>>
>>>> Tom, can you please post the corresponding update to the draft?
>>>>
>>>> Cheers,
>>>> Charles
>>>>
>>>> On 9/28/15, 3:07 AM, "bfcpbis on behalf of Christer Holmberg"
>>>> <[e-mail] on behalf of
>>>> [e-mail]>
>>>> wrote:
>>>>
>>>>    
>>>>> Hi,
>>>>>
>>>>>      
>>>>>> In that case, I prefer Tom’s original suggestion,
>>>>>>
>>>>>>   What if we keep the text and adds this as an additional reference
>>>>>> in the two new text passages proposed by Charles: "... [13], and
>>>>>> the clarifications defined in [draft-ietf-mmusic-dtls-sdp], ...".
>>>>>>
>>>>>>   Where [13] is a reference to RFC 5763.
>>>>>>        
>>>>> If that's something people can agree to, then can live with such
>>>>> compromise :)
>>>>>
>>>>> Regards,
>>>>>
>>>>> Christer
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> If it turns out that draft-ietf-mmusic-dtls-sdp updates RFC 5763,
>>>>>then  there is some redundancy. But that is better than having a hole
>>>>>when it  comes to backward compatibility with existing
>>>>>implementations, which is  what we will have today if we reference
>>>>>draft-ietf-mmusic-dtls-sdp only.
>>>>>
>>>>> Cheers,
>>>>> Charles
>>>>>
>>>>>
>>>>>
>>>>> On 9/25/15, 2:21 AM, "Christer Holmberg"
>>>>> <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>      
>>>>>> Hi Charles,
>>>>>>
>>>>>>        
>>>>>>> As a simple example, we currently refer to rfc4582bis instead of
>>>>>>> the eventual RFC. Assuming rfc4582bis does become an RFC, we would
>>>>>>> want the RFC editor to update references to it and to RFCxxxx with
>>>>>>> the actual RFC number.
>>>>>>> Similar here, we would want them to check with authors/chairs/ADs
>>>>>>> on the state of draft-ietf-mmusic-dtls-sdp to see if we want to
>>>>>>> replace our reference to RFC 5763 with a reference to it. This way
>>>>>>> we can move forward while draft-ietf-mmusic-dtls-sdp continues to
>>>>>>> progress as well.
>>>>>>>          
>>>>>> I don't think it's the same thing. First you talk about a draft,
>>>>>> where the draft name will be replaced with the to-be-assigned RFC
>>>>>> number. In the case of DTLS-SDP we are talking about two separate
>>>>>>specifications.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>>
>>>>>> On 9/24/15, 2:53 AM, "Christer Holmberg"
>>>>>> <[e-mail]>
>>>>>> wrote:
>>>>>>
>>>>>>        
>>>>>>> Hi Charles,
>>>>>>>
>>>>>>> I am still not sure I understand your suggestion: what is meant by
>>>>>>> "as determined prior to publication"? When/where/who? :)
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Christer
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Charles Eckel (eckelcu) [mailto:[e-mail]]
>>>>>>> Sent: 22. syyskuuta 2015 17:05
>>>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist)
>>>>>>> Cc: [e-mail];
>>>>>>> [e-mail]; Alissa Cooper; Gonzalo Camarillo; Ben Campbell
>>>>>>> Subject: Re: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
>>>>>>>
>>>>>>> I view referring to draft-ietf-mmusic-dtls-sdp now instead of RFC
>>>>>>> 5763 to be like writing a blank check. Debate is actively
>>>>>>> occurring on the list, the normative language in RFC 5763 is
>>>>>>> expected to be updated in multiple ways, and backward
>>>>>>> compatibility with the the normative language provide in previous
>>>>>>> version of rfc4583bis is not fully addressed. It seems more
>>>>>>> appropriate to me at this stage to continue to refer to RFC 5763
>>>>>>> with a note regarding updating or replacing that reference with
>>>>>>> one to draft-ietf-mmusic-dtls-sdp, as determined prior to
>>>>>>>publication.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Charles
>>>>>>>
>>>>>>> On 9/21/15, 11:48 PM, "Christer Holmberg"
>>>>>>> <[e-mail]>
>>>>>>> wrote:
>>>>>>>
>>>>>>>          
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>>           
>>>>>>>>> I see. As this is a moving target, perhaps where we reference
>>>>>>>>> RFC
>>>>>>>>> 5763 we can add a note for the RFC editor that
>>>>>>>>> draft-ietf-mmusic-dtls-sdp is expected to add clarifications and
>>>>>>>>> make changes to RFC 5763 that should be considered prior to
>>>>>>>>> publication of rfc4583bis.
>>>>>>>>>          
>>>>>>>> I am not sure I understand. I don't think it's up to the RFC
>>>>>>>> editor to make a decision whether the draft should reference
>>>>>>>>DTLS-SDP.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Christer
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 9/21/15, 11:23 AM, "Christer Holmberg"
>>>>>>>> <[e-mail]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>           
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>          
>>>>>>>>>> RFC 5763, which is currently required for BFCP with DTLS reads:
>>>>>>>>>>
>>>>>>>>>>    o  The endpoint MUST NOT use the connection attribute
>>>>>>>>>>defined in
>>>>>>>>>>      [RFC4145<https://tools.ietf.org/html/rfc4145>].
>>>>>>>>>>         
>>>>>>>>> Correct.
>>>>>>>>>
>>>>>>>>> And, IF we decide to use define usage of the 'connection'
>>>>>>>>> attribute for DTLS, we would change that.
>>>>>>>>>
>>>>>>>>> However, a few days ago we sent an e-mail to the MMUSIC list,
>>>>>>>>>suggesting that we should NOT use the 'connection' attribute for
>>>>>>>>>DTLS.
>>>>>>>>> Instead we should define a new attribute (for more details,
>>>>>>>>>please  see the MMUSIC list).
>>>>>>>>>
>>>>>>>>>          
>>>>>>>>>> Section 5.1 of draft-ietf-mmusic-dtls-sdp reads:
>>>>>>>>>>
>>>>>>>>>>    When used with DTLS, there is no default value defined for
>>>>>>>>>>the
>>>>>>>>>>    attribute.  Implementations that wish to use the attribute
>>>>>>>>>>MUST
>>>>>>>>>>    explicitly include it in SDP offers and answers.  If an
>>>>>>>>>>offer or
>>>>>>>>>>    answer does not contain an attribute, other means needs to
>>>>>>>>>>be  used in
>>>>>>>>>>    order for endpoints to determine whether an offer or answer
>>>>>>>>>>is
>>>>>>>>>>    associated with an event that requires the DTLS association
>>>>>>>>>>to  be
>>>>>>>>>> re-
>>>>>>>>>>    established.
>>>>>>>>>>
>>>>>>>>>> I suppose if draft-ietf-mmusic-dtls-sdp pulls in enough from
>>>>>>>>>> RFC
>>>>>>>>>> 5763 to make it clear how the DTLS establishment and
>>>>>>>>>> re-establishment works for the case of which the connection
>>>>>>>>>> attribute is not used, then we can change the reference from
>>>>>>>>>> RFC
>>>>>>>>>> 5763 to draft-ietf-mmusic-dtls-sdp.
>>>>>>>>>>
>>>>>>>>>> The last several updates of draft-ietf-bfcpbis-rfc4583bis have
>>>>>>>>>> removed supporting text from the draft in favor of pointing to
>>>>>>>>>> RFC
>>>>>>>>>> 5763 as the  source of truth. I fear that
>>>>>>>>>> draft-ietf-mmusic-dtls-sdp in its current state does not serve
>>>>>>>>>> that need for draft-ietf-bfcpbis-rfc4583bis. I value
>>>>>>>>>> Christer’s thoughts and welcome the opinion of others,
>>>>>>>>>> especially those who have or are implementing BFCP with DTLS and
>>>>>>>>>>ICE, which I have not.
>>>>>>>>>>         
>>>>>>>>> Please note that DTLS-SDP does not only define usage of the
>>>>>>>>> 'connection'
>>>>>>>>> attribute, it also does other things. Maybe more important, it
>>>>>>>>> does not state that an address change by default requires a new
>>>>>>>>> DTLS association
>>>>>>>>> - which is a another 5763 modification.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> Christer
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 9/21/15, 9:32 AM, "bfcpbis on behalf of Christer Holmberg"
>>>>>>>>> <[e-mail] on behalf of
>>>>>>>>> [e-mail]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>          
>>>>>>>>>> Hi Charles,
>>>>>>>>>>
>>>>>>>>>>         
>>>>>>>>>>> The problem I see with this is that it is not just a matter of
>>>>>>>>>>> changing the reference, it is also a matter of changing the
>>>>>>>>>>> normative behavior.
>>>>>>>>>>> For DTLS with BFCP, we never required the use of
>>>>>>>>>>>the>“connection”
>>>>>>>>>>> attribute.
>>>>>>>>>>> If we are to start requiring it, we would need add text to
>>>>>>>>>>> describe how to address backward compatibility in cases in
>>>>>>>>>>> which the connection attribute is not specified.
>>>>>>>>>>>        
>>>>>>>>>> The intention is to cover backward compatibility in the draft.
>>>>>>>>>>
>>>>>>>>>>         
>>>>>>>>>>> Are there plans for this within RFC 5763bis draft? If so,
>>>>>>>>>>> Tom’s recommendation of continuing to point to RFC 5763 for
>>>>>>>>>>> now may be the best approach.
>>>>>>>>>>>        
>>>>>>>>>> I am not familiar with the 5763bis draft. But, even if the
>>>>>>>>>>DTLS-SDP draft makes updates to 5763, it won't become a 5763bis
>>>>>>>>>>draft.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> Christer
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 9/11/15, 1:11 PM, "Christer Holmberg"
>>>>>>>>>> <[e-mail]>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>         
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>        
>>>>>>>>>>>> Hmm, yes maybe an idea if it's fine proceeding with referring
>>>>>>>>>>>>a  work-in-progress draft here.
>>>>>>>>>>>> What if we keep the text and adds this as an additional
>>>>>>>>>>>>reference in the two new text passages proposed by Charles:
>>>>>>>>>>>>"...
>>>>>>>>>>>> [13], and the clarifications defined in
>>>>>>>>>>>>[draft-ietf-mmusic-dtls-sdp], ...".
>>>>>>>>>>>>
>>>>>>>>>>>> Where [13] is a reference to RFC 5763.
>>>>>>>>>>>>       
>>>>>>>>>>> My suggestion is to *only* refer the new dtls-sdp draft.
>>>>>>>>>>> Because, one of the ideas with the new draft is to also update
>>>>>>>>>>> RFC 5763 to reference the new dtls-sdp draft.
>>>>>>>>>>>
>>>>>>>>>>>        
>>>>>>>>>>>> Anyway, I'd still prefer to keep the text in
>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis-12 and redirect the readers to
>>>>>>>>>>>> the rfc5763bis, that eventually then will obsolete (or
>>>>>>>>>>>> extend?) RFC 5763.
>>>>>>>>>>>>       
>>>>>>>>>>> The new dtls-sdp draft will not become 5763bis (eventhough it
>>>>>>>>>>> MAY update some parts of 5763). It's a generic document, which
>>>>>>>>>>> *any* DTLS usage can then reference.
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>>
>>>>>>>>>>> Christer
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/11/2015 01:25 PM, Christer Holmberg wrote:
>>>>>>>>>>>        
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> My suggestion would actually be to refer to the new
>>>>>>>>>>>> draft-ietf-mmusic-dtls-sdp, which is going to clarify the
>>>>>>>>>>>> DTLS-SRTP rules regarding when a new DTLS association must be
>>>>>>>>>>>> established.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Christer
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: Tom Kristensen [mailto:[e-mail]]
>>>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25
>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo;
>>>>>>>>>>>> [e-mail]; Ben Campbell;
>>>>>>>>>>>> [e-mail]
>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis
>>>>>>>>>>>>
>>>>>>>>>>>> Pointing to the DTLS-SRTP (and by that any updates of it) is
>>>>>>>>>>>> a simple, safe and straigt-forward solution.
>>>>>>>>>>>>
>>>>>>>>>>>> The only change in the new version of rfc4583bis just
>>>>>>>>>>>>submitted.
>>>>>>>>>>>> And as Charles says, this should be the last missing fix for
>>>>>>>>>>>> this draft until next stages in the process at least.
>>>>>>>>>>>>
>>>>>>>>>>>> -- Tom
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/08/2015 07:48 PM, Charles Eckel (eckelcu) wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>       
>>>>>>>>>>>>> Picking up on this old thread regarding
>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4583bis.
>>>>>>>>>>>>> I think this is the only outstanding item with respect to
>>>>>>>>>>>>> the current  version of the draft. Unless anyone has an
>>>>>>>>>>>>> issue with the proposed  resolution, I request we update the
>>>>>>>>>>>>> draft accordingly and then use it  as the basis for Mary,
>>>>>>>>>>>>> the document shepherd, to provide a proto writeup.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/20/15, 10:39 AM, "Charles Eckel
>>>>>>>>>>>>> (eckelcu)"<[e-mail]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>      
>>>>>>>>>>>>>> Hi Christer,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I reread the current draft and went through the following
>>>>>>>>>>>>>> MMUSIC thread on this subject:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>http://www.ietf.org/mail-archive/web/mmusic/current/msg14631.
>>>>>>>>>>>>>> h
>>>>>>>>>>>>>> t
>>>>>>>>>>>>>> m
>>>>>>>>>>>>>> l
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> As a result, I better understand the issue you are
>>>>>>>>>>>>>>addressing.
>>>>>>>>>>>>>> I suggest the following changes to be consistent with what
>>>>>>>>>>>>>> is being proposed in
>>>>>>>>>>>>>> MMUSIC:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ------------
>>>>>>>>>>>>>> Section 9:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OLD:
>>>>>>>>>>>>>> Endpoints that use the offer/answer model to establish a
>>>>>>>>>>>>>>DTLS
>>>>>>>>>>>>>>      association MUST support the 'setup' attribute, as
>>>>>>>>>>>>>> defined in [7].
>>>>>>>>>>>>>> When DTLS is used with UDP, the 'setup' attribute indicates
>>>>>>>>>>>>>> which of the endpoints (client or floor control server)
>>>>>>>>>>>>>> initiates the DTLS association setup. The requirements for
>>>>>>>>>>>>>> the offer/answer exchange specified in [13], Section 5 of
>>>>>>>>>>>>>> [13] MUST be followed when using DTLS.
>>>>>>>>>>>>>> Offer/answer considerations are described in Section 10.5.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>> When DTLS is used with UDP, the requirements specified in
>>>>>>>>>>>>>> Section
>>>>>>>>>>>>>> 5 of [13] MUST be followed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Section 10.5
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> OLD
>>>>>>>>>>>>>>      If the transport parameters or the key fingerprints
>>>>>>>>>>>>>> change, the
>>>>>>>>>>>>>>      endpoints MUST establish a new DTLS connection.  In
>>>>>>>>>>>>>> such case the
>>>>>>>>>>>>>>      'active/passive' status of the endpoints will again be
>>>>>>>>>>>>>> determined
>>>>>>>>>>>>>>      following the procedures in [7], and the new status
>>>>>>>>>>>>>> will be used to
>>>>>>>>>>>>>>      determine the TLS roles associated with the new DTLS
>>>>>>>>>>>>>> connection.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Informational note: The procedure above is
>>>>>>>>>>>>>> identical to the one
>>>>>>>>>>>>>>         defined for DTLS-SRTP in [13].
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>         Note: A new DTLS connection needs to be established
>>>>>>>>>>>>>> if the
>>>>>>>>>>>>>>         transport parameters or the key fingerprints change.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> NEW:
>>>>>>>>>>>>>> The conditions under which endpoints MUST establish a new
>>>>>>>>>>>>>> DTLS connection are as the same defined for DTLS-SRTP in
>>>>>>>>>>>>>>[13].
>>>>>>>>>>>>>> ————————
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This way we avoid any potential conflicts with the intent
>>>>>>>>>>>>>> of RFC 5763, and when clarifications to RFC 5763 are made,
>>>>>>>>>>>>>> they will be picked up by the BFCP spec.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/18/15, 2:01 PM, "Christer
>>>>>>>>>>>>>> Holmberg"<[e-mail]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>     
>>>>>>>>>>>>>>> Hi Charles,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>> [adding bfcppbis list]
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Christer,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for your review and comments. In the BFCP usage,
>>>>>>>>>>>>>>>> the DTLS connection is dedicated to the BFCP stream it
>>>>>>>>>>>>>>>>contains.
>>>>>>>>>>>>>>>> As I understand it, the complications around DTLS
>>>>>>>>>>>>>>>> re-establishement discussed in MMUSIC result from use of
>>>>>>>>>>>>>>>> a single DTLS connection for multiple RTP and/or SCTP
>>>>>>>>>>>>>>>>streams.
>>>>>>>>>>>>>>>> Those complications do not exist with the BFCP usage, so
>>>>>>>>>>>>>>>> I think it is sufficient to continue to reference RFC
>>>>>>>>>>>>>>>> 5763 and not use the SDP connection attribute.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>> The complications do not result from use of a single DTLS
>>>>>>>>>>>>>>> connection for multiple streams - it mainly results from
>>>>>>>>>>>>>>> the usage of ICE. And, as far as I know, ICE can be used
>>>>>>>>>>>>>>> also for BFCP.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> And, even without ICE we intend to add text saying that a
>>>>>>>>>>>>>>> DTLS connection is only re-established if the underlying
>>>>>>>>>>>>>>> transport changes.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Christer
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    
>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> First, I want to apologize for not providing my review
>>>>>>>>>>>>>>>> earlier.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> As far as the BFCP specifics are concerned, I am ok with
>>>>>>>>>>>>>>>> the latest version of the draft.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> However, there is an issue regarding the DTLS
>>>>>>>>>>>>>>>> considerations (section 10.5).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The text says:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 	"Once a DTLS connection has been established, if the
>>>>>>>>>>>>>>>> 'active/passive'
>>>>>>>>>>>>>>>>      	status of the endpoints change during a session, a
>>>>>>>>>>>>>>>> new DTLS
>>>>>>>>>>>>>>>>      	connection MUST be established."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> There is currently an ongoing discussion in MMUSIC about
>>>>>>>>>>>>>>>> when a DTLS connection is to be re-established.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The discussion is still ongoing, but the outcome will
>>>>>>>>>>>>>>>> most likely NOT be aligned with the text above.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> For example, there has been a suggestion (by myself) to
>>>>>>>>>>>>>>>> use the SDP connection attribute to explicitly indicate
>>>>>>>>>>>>>>>> that a new DTLS connection needs to be established.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The draft also says:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 	"If the transport parameters or the key fingerprints
>>>>>>>>>>>>>>>> change, the
>>>>>>>>>>>>>>>>      	endpoints MUST establish a new DTLS connection."
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This is related to the earlier issue. There is the
>>>>>>>>>>>>>>>> discussion about ICE "virtual connections", and that a
>>>>>>>>>>>>>>>> single DTLS connection would apply to all ICE candidates
>>>>>>>>>>>>>>>> associated with an
>>>>>>>>>>>>>>>> m- line. So, even if a candidate changes (read: transport
>>>>>>>>>>>>>>>> parameter changes), it would not automatically trigger a
>>>>>>>>>>>>>>>> new DTLS connection.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The issues above are also holding up the SCTP-SDP draft,
>>>>>>>>>>>>>>>> so it doesn't only affect BFCPbis :)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Christer
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: Alissa Cooper [mailto:[e-mail]]
>>>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07
>>>>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist);
>>>>>>>>>>>>>>>> [e-mail]; Ben
>>>>>>>>>>>>>>>> Campbell; Christer Holmberg
>>>>>>>>>>>>>>>> Subject: Re: draft-ietf-bfcpbis-rfc4583bis
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Adding Christer to this thread.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Apr 7, 2015, at 12:44 PM, Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>   
>>>>>>>>>>>>>>>>> Christer (cc’d) and I discussed some of the changes
>>>>>>>>>>>>>>>>> offlist in Dallas, and he is to come back to the list
>>>>>>>>>>>>>>>>> with comments after Dallas
>>>>>>>>>>>>>>>>> - which is now :)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/7/15, 10:26 AM, "Alissa Cooper"<[e-mail]>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>  
>>>>>>>>>>>>>>>>>> Checking in on this — has Christer been prompted to
>>>>>>>>>>>>>>>>>> review the latest rev of draft-ietf-bfcpbis-rfc4583bis?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Feb 25, 2015, at 9:14 AM, Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>>> <[e-mail]>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Most of the changes I this recent update to rfc4583bis
>>>>>>>>>>>>>>>>>>> were inspired by comments and suggested text provided
>>>>>>>>>>>>>>>>>>> by Christer.
>>>>>>>>>>>>>>>>>>> He is in the process of reviewing. If all goes well
>>>>>>>>>>>>>>>>>>> with that, we are ready to proceed with proto writeup
>>>>>>>>>>>>>>>>>>> (Mary) and AD review.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 2/25/15, 7:01 AM, "Alissa
>>>>>>>>>>>>>>>>>>> Cooper"<[e-mail]>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> rfc4583 has not had an AD review yet. Richard can
>>>>>>>>>>>>>>>>>>>> hopefully take care of that while I¹m on leave
>>>>>>>>>>>>>>>>>>>> (starting today, actually).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Feb 25, 2015, at 2:56 AM, Gonzalo Camarillo
>>>>>>>>>>>>>>>>>>>> <[e-mail]>    wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Alissa,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I have noted that while rfc4582bis in on the agenda
>>>>>>>>>>>>>>>>>>>>> of the March 5th telechat (thanks for handling
>>>>>>>>>>>>>>>>>>>>> that!), rfc4583bis isn't. Tom revised rfc4583bis on
>>>>>>>>>>>>>>>>>>>>> February 20th. Should rfc4583bis be on the agenda of
>>>>>>>>>>>>>>>>>>>>> the telechat as well or there is still something
>>>>>>>>>>>>>>>>>>>>> left for Tom to take care of?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Gonzalo
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 18/02/2015 9:28 PM, Alissa Cooper wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Pinging on this.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> March 5 will likely be my last telechat before
>>>>>>>>>>>>>>>>>>>>>> going on leave, so  it would be great to get this
>>>>>>>>>>>>>>>>>>>>>> scheduled on that one. To do that,  the rev needs
>>>>>>>>>>>>>>>>>>>>>> to be posted today.
>>>>>>>>>>>>>>>>>>>>>> The updates are pretty minimal  and are all
>>>>>>>>>>>>>>>>>>>>>> basically written up in Charles¹ response to my AD
review.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Feb 15, 2015, at 9:13 AM, Gonzalo Camarillo
>>>>>>>>>>>>>>>>>>>>>> <[e-mail]
>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> I have talked offline with the other authors and
>>>>>>>>>>>>>>>>>>>>>>> Tom is holding the pen. Tom, do you think you can
>>>>>>>>>>>>>>>>>>>>>>> meet the time frame below?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Gonzalo
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sent from my mobile
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> ---- Alissa Cooper wrote ----
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Just wanted to see if this rev might get done in
>>>>>>>>>>>>>>>>>>>>>>> the next couple  of days. If so, we could get it
>>>>>>>>>>>>>>>>>>>>>>> on the next telechat agenda (March 5).
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Begin forwarded message:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> *From: *Alissa Cooper<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation:
>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12*
>>>>>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST
>>>>>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)"<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *"[e-mail]<mailto:[e-mail]>"
>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail] <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Charles,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>    wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> HI Alissa,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts
>>>>>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper<[e-mail]
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>>>>>>>>>>>>>>>>> To: "[e-mail]<mailto:[e-mail]>"
>>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>>> Subject: [bfcpbis] AD evaluation:
>>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I have reviewed this draft in preparation for IETF
LC.
>>>>>>>>>>>>>>>>>>>>>>>>>> Overall the document appears in good shape. I
>>>>>>>>>>>>>>>>>>>>>>>>>> have a few questions and comments I¹d like to
>>>>>>>>>>>>>>>>>>>>>>>>>> discuss before issuing the IETF last call. I¹ve
>>>>>>>>>>>>>>>>>>>>>>>>>> also included some editorial nits that should
>>>>>>>>>>>>>>>>>>>>>>>>>> be addressed together with any last call comments.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Comments and questions:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = "If an endpoint receives a
>>>>>>>>>>>>>>>>>>>>>>>>>> message with an unsupported version field
>>>>>>>>>>>>>>>>>>>>>>>>>> value, the receiving server MUST send an Error
>>>>>>>>>>>>>>>>>>>>>>>>>> message with parameter value 12 (Unsupported
>>>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> This seems a little misleading since RFC 4582
>>>>>>>>>>>>>>>>>>>>>>>>>> didn¹t specify what to do upon receipt of a
>>>>>>>>>>>>>>>>>>>>>>>>>> message with a version other than 1.
>>>>>>>>>>>>>>>>>>>>>>>>>> Implementations that do not get upgraded to be
>>>>>>>>>>>>>>>>>>>>>>>>>> compliant with  4582bis (which could certainly
>>>>>>>>>>>>>>>>>>>>>>>>>> account for some of those that  will not
>>>>>>>>>>>>>>>>>>>>>>>>>> support version 2) will therefore never send
>>>>>>>>>>>>>>>>>>>>>>>>>> the  error specified here.
>>>>>>>>>>>>>>>>>>>>>>>>>> This seems like it should at least be  noted
>>>>>>>>>>>>>>>>>>>>>>>>>> given the MUST-level requirement. The same
>>>>>>>>>>>>>>>>>>>>>>>>>> applies in Section 13.7.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Good point. I believe we made this a MUST
>>>>>>>>>>>>>>>>>>>>>>>>> because we were thinking in terms of
>>>>>>>>>>>>>>>>>>>>>>>>> implementations compliant with this bis version.
>>>>>>>>>>>>>>>>>>>>>>>>> Adding
>>>>>>>>>>>>>>>>>>>>>>>>> your suggested note about rfc 4582
>>>>>>>>>>>>>>>>>>>>>>>>> implementations here and in  section 13.7 seems useful
>to me.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Ok
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 7 =
>>>>>>>>>>>>>>>>>>>>>>>>>> "BFCP entities MUST support, at a minimum, the
>>>>>>>>>>>>>>>>>>>>>>>>>> TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6].²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I realize this requirement comes from RFC 4582,
>>>>>>>>>>>>>>>>>>>>>>>>>> but I¹d like to understand why it has not been
>>>>>>>>>>>>>>>>>>>>>>>>>> updated to be consistent with more current
>>>>>>>>>>>>>>>>>>>>>>>>>> guidance on cipher suite selection (e.g.,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> https://tools.ietf.org/html/draft-ietf-uta-tls-
>>>>>>>>>>>>>>>>>>>>>>>>>> bc
>>>>>>>>>>>>>>>>>>>>>>>>>> p
>>>>>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>>>>>>>>>>> 8
>>>>>>>>>>>>>>>>>>>>>>>>>> #
>>>>>>>>>>>>>>>>>>>>>>>>>> s
>>>>>>>>>>>>>>>>>>>>>>>>>> e
>>>>>>>>>>>>>>>>>>>>>>>>>> c
>>>>>>>>>>>>>>>>>>>>>>>>>> tion
>>>>>>>>>>>>>>>>>>>>>>>>>> -4)
>>>>>>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> How about we keep this minimum requirement, and
>>>>>>>>>>>>>>>>>>>>>>>>> add a reference to draft-ietf-uta-tls-bcp along
>>>>>>>>>>>>>>>>>>>>>>>>> with a recommendation to adhere to the best
>>>>>>>>>>>>>>>>>>>>>>>>> practices it outlines in section 4?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I think MUST support TLS_RSA_WITH_AES_128_CBC_SHA
>>>>>>>>>>>>>>>>>>>>>>>> for backwards compatibility and SHOULD support
>>>>>>>>>>>>>>>>>>>>>>>> the ones listed in the UTA drafts would be ok.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Sections 8, 8.1, 8.2 = It seems like the
>>>>>>>>>>>>>>>>>>>>>>>>>> transaction ID requirements regarding
>>>>>>>>>>>>>>>>>>>>>>>>>> non-reuse/monotonically increasing IDs are
>>>>>>>>>>>>>>>>>>>>>>>>>> re-stated multiple times across these three
>>>>>>>>>>>>>>>>>>>>>>>>>> sections, in slightly different ways, to the
>>>>>>>>>>>>>>>>>>>>>>>>>> point where it¹s not clear exactly what they are.
>>>>>>>>>>>>>>>>>>>>>>>>>> It seems like they are:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> (1) Reliable transport, server-initiated transaction:
>>>>>>>>>>>>>>>>>>>>>>>>>> ID is
>>>>>>>>>>>>>>>>>>>>>>>>>> 0
>>>>>>>>>>>>>>>>>>>>>>>>>> (2) Unreliable transport, server-initiated
>>>>>>>>>>>>>>>>>>>>>>>>>> transaction:
>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for
>>>>>>>>>>>>>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>>>>>>>>>>>>>> (3) Reliable transport, client-initiated transaction:
>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST NOT be 0 and MUST NOT be reused in 
>>>>>>>>>>>>>>>>>>>>>>>>>> another message from the client until a 
>>>>>>>>>>>>>>>>>>>>>>>>>> response
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> >from the server is received for the 
>>>>>>>>>>>>>>>>>>>>>>>>> >transaction,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> but need not be monotonically increasing (e.g., 
>>>>>>>>>>>>>>>>>>>>>>>>>> a lower, recently used ID could be re-used once 
>>>>>>>>>>>>>>>>>>>>>>>>>> a response is
>>>>>>>>>>>>>>>>>>>>>>>>>> received)
>>>>>>>>>>>>>>>>>>>>>>>>>> (4) Unreliable transport, client-initiated
>>>>>>>>>>>>>>>>>>>>>>>>>> transaction:
>>>>>>>>>>>>>>>>>>>>>>>>>> ID MUST be monotonically increasing (except for
>>>>>>>>>>>>>>>>>>>>>>>>>> wrap-around)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Is (3) the correct interpretation of the text in 8.1?
>>>>>>>>>>>>>>>>>>>>>>>>>> If so, why not just require IDs in all 
>>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions to be 
>>>>>>>>>>>>>>>>>>>>>>>>>> monotonically increasing?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Agree we can and should simplify this. Sections
>>>>>>>>>>>>>>>>>>>>>>>>> 8.1 and
>>>>>>>>>>>>>>>>>>>>>>>>> 8.2 cover the client behavior and server 
>>>>>>>>>>>>>>>>>>>>>>>>> behavior in detail. As such, the transaction ID 
>>>>>>>>>>>>>>>>>>>>>>>>> related information at the start of Section 8 is 
>superfluous.
>>>>>>>>>>>>>>>>>>>>>>>>> I recommend reducing the text in Section 8 to 
>>>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>>>> follow:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 8. Protocol Transactions
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> In BFCP, there are two types of transactions:
>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions and 
>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Client-initiated transactions consist of a 
>>>>>>>>>>>>>>>>>>>>>>>>> request from a client to a floor control server 
>>>>>>>>>>>>>>>>>>>>>>>>> and a response from the floor control server to the 
>client.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions have different 
>>>>>>>>>>>>>>>>>>>>>>>>> behavior depending on underlying transport:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>       When using a reliable transport, 
>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions
>>>>>>>>>>>>>>>>>>>>>>>>>       consist of a single message from a floor 
>>>>>>>>>>>>>>>>>>>>>>>>> control server to a
>>>>>>>>>>>>>>>>>>>>>>>>>       client (notifications).  They do not 
>>>>>>>>>>>>>>>>>>>>>>>>> trigger any response.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>       When using an unreliable transport, 
>>>>>>>>>>>>>>>>>>>>>>>>> server-initiated transactions
>>>>>>>>>>>>>>>>>>>>>>>>>       consist of a request from a floor control 
>>>>>>>>>>>>>>>>>>>>>>>>> server to a client and a
>>>>>>>>>>>>>>>>>>>>>>>>>       response from the client to the floor 
>>>>>>>>>>>>>>>>>>>>>>>>> control server.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, 
>>>>>>>>>>>>>>>>>>>>>>>>> retransmission timer T1 (see Section 8.3) MUST 
>>>>>>>>>>>>>>>>>>>>>>>>> be used for all requests until the transaction 
>>>>>>>>>>>>>>>>>>>>>>>>> is completed.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Then in section 8.1, we add the important 
>>>>>>>>>>>>>>>>>>>>>>>>> details removed from section 8.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 8.1.1 Client Behavior
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A client starting a client-initiated transaction 
>>>>>>>>>>>>>>>>>>>>>>>>> MUST set the Conference ID in the common header 
>>>>>>>>>>>>>>>>>>>>>>>>> of the message to the Conference ID for the 
>>>>>>>>>>>>>>>>>>>>>>>>> conference that the client obtained previously.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> The client MUST set the Transaction ID value in 
>>>>>>>>>>>>>>>>>>>>>>>>> the common header to a number that is different
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>> >from 0 and that MUST NOT be reused in another
>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>>> message from the client until a response from 
>>>>>>>>>>>>>>>>>>>>>>>>> the server is received for the transaction.
>>>>>>>>>>>>>>>>>>>>>>>>> The client uses the Transaction ID value to 
>>>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the 
>>>>>>>>>>>>>>>>>>>>>>>>> floor control server.
>>>>>>>>>>>>>>>>>>>>>>>>> When using BFCP over an unreliable transport, it 
>>>>>>>>>>>>>>>>>>>>>>>>> is important to choose a Transaction ID value 
>>>>>>>>>>>>>>>>>>>>>>>>> that lets the receiver distinguish the reception 
>>>>>>>>>>>>>>>>>>>>>>>>> of the next message in a sequence of BFCP 
>>>>>>>>>>>>>>>>>>>>>>>>> messages from a retransmission of a previous 
>>>>>>>>>>>>>>>>>>>>>>>>> message.  Therefore, BFCP entities using an 
>>>>>>>>>>>>>>>>>>>>>>>>> unreliable transport MUST use monotonically 
>>>>>>>>>>>>>>>>>>>>>>>>> increasing Transaction ID values (except for 
>wrap-around).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A client receiving a server-initiated 
>>>>>>>>>>>>>>>>>>>>>>>>> transaction over an unreliable transport MUST 
>>>>>>>>>>>>>>>>>>>>>>>>> copy the Transaction ID from the request 
>>>>>>>>>>>>>>>>>>>>>>>>> received from the server into the response.
>>>>>>>>>>>>>>>>>>>>>>>>> [Question: is there a need to copy the 
>>>>>>>>>>>>>>>>>>>>>>>>> Conference ID and  User ID, if present?]
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> 8.2. Server Behavior
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> A floor control server sending a response within 
>>>>>>>>>>>>>>>>>>>>>>>>> a client-initiated transaction MUST copy the 
>>>>>>>>>>>>>>>>>>>>>>>>> Conference ID, the Transaction ID, and the User 
>>>>>>>>>>>>>>>>>>>>>>>>> ID
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>> >from the request received from the client into 
>>>>>>>>>>>>>>>>>>>>>>>> >the
>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>>> response.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Server-initiated transactions MUST contain a 
>>>>>>>>>>>>>>>>>>>>>>>>> Transaction ID equal to
>>>>>>>>>>>>>>>>>>>>>>>>> 0 when BFCP is used over a reliable transport.
>>>>>>>>>>>>>>>>>>>>>>>>> Over an unreliable transport, the Transaction ID 
>>>>>>>>>>>>>>>>>>>>>>>>> shall have the same properties as for 
>>>>>>>>>>>>>>>>>>>>>>>>> client-initiated transactions.
>>>>>>>>>>>>>>>>>>>>>>>>> The server uses the Transaction ID value to 
>>>>>>>>>>>>>>>>>>>>>>>>> match this message with the response from the 
>>>>>>>>>>>>>>>>>>>>>>>>> floor participant or floor chair.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>> Thanks, this is better.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 9 (impacts Section 14 as well) = 
>>>>>>>>>>>>>>>>>>>>>>>>>> "BFCP clients  SHOULD authenticate the floor 
>>>>>>>>>>>>>>>>>>>>>>>>>> control server before  sending any BFCP message 
>>>>>>>>>>>>>>>>>>>>>>>>>> to it or accepting any BFCP message from it.
>>>>>>>>>>>>>>>>>>>>>>>>>> Similarly, floor control servers SHOULD 
>>>>>>>>>>>>>>>>>>>>>>>>>> authenticate a client before accepting any BFCP 
>>>>>>>>>>>>>>>>>>>>>>>>>> message from it or sending any BFCP message to it.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> BFCP supports TLS/DTLS mutual authentication 
>>>>>>>>>>>>>>>>>>>>>>>>>> between clients and floor control servers, as 
>>>>>>>>>>>>>>>>>>>>>>>>>> specified in Section 9.1.
>>>>>>>>>>>>>>>>>>>>>>>>>> This is the RECOMMENDED authentication 
>>>>>>>>>>>>>>>>>>>>>>>>>> mechanism in BFCP.²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> What are the cases where clients and servers do 
>>>>>>>>>>>>>>>>>>>>>>>>>> not need  to be authenticating each other? I 
>>>>>>>>>>>>>>>>>>>>>>>>>> know this requirement  and the other 
>>>>>>>>>>>>>>>>>>>>>>>>>> SHOULD-level requirements around use of  
>>>>>>>>>>>>>>>>>>>>>>>>>> TLS/DTLS are carried over from RFC 4582, but 
>>>>>>>>>>>>>>>>>>>>>>>>>> I¹m  concerned that they aren¹t as strong as they 
>should be.
>>>>>>>>>>>>>>>>>>>>>>>>>> For a conference where the signaling traffic is 
>>>>>>>>>>>>>>>>>>>>>>>>>> authenticated and confidentiality and integrity 
>>>>>>>>>>>>>>>>>>>>>>>>>> protected, why is it ok for the floor control 
>>>>>>>>>>>>>>>>>>>>>>>>>> traffic not to be? Could these requirements be 
>>>>>>>>>>>>>>>>>>>>>>>>>> adjusted to require use of TLS/DTLS at least in 
>>>>>>>>>>>>>>>>>>>>>>>>>> cases where the signaling is also protected?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>>>> Yes, but again, this would be at the expense of 
>>>>>>>>>>>>>>>>>>>>>>>>> adding a non backward compatible change from rfc 
>>>>>>>>>>>>>>>>>>>>>>>>> 4582. How about saying TLS/DTLS MUST be used for 
>>>>>>>>>>>>>>>>>>>>>>>>> BFCP in such cases, while pointing out the rfc
>>>>>>>>>>>>>>>>>>>>>>>>> 4582
>>>>>>>>>>>>>>>>>>>>>>>>> based implementations may not comply (similar to 
>>>>>>>>>>>>>>>>>>>>>>>>> what we did with the version field).
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>> Works for me.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Feel free to make all of these changes and submit 
>>>>>>>>>>>>>>>>>>>>>>>> a rev and I¹ll issue the IETF LC.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>>>> Alissa
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>>>>>>>>>>>>>>> See the point above about ciphersuites. 
>>>>>>>>>>>>>>>>>>>>>>>>>> ³Non-null encryption² is not a sufficient 
>>>>>>>>>>>>>>>>>>>>>>>>>> minimum baseline, and if the requirements 
>>>>>>>>>>>>>>>>>>>>>>>>>> change in Section 7 they should be reflected here as 
>well.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>>>> Yep.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>>>> Editorial nits to be resolved with LC comments:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 5.1 = ³The version field MUST be set 
>>>>>>>>>>>>>>>>>>>>>>>>>> to 1 when using BFCP over a reliable transport, 
>>>>>>>>>>>>>>>>>>>>>>>>>> i.e. as in [2].²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I find it a little odd to reference the spec 
>>>>>>>>>>>>>>>>>>>>>>>>>> you¹re obsoleting in this sentence, especially 
>>>>>>>>>>>>>>>>>>>>>>>>>> since BFCP over a reliable transport is 
>>>>>>>>>>>>>>>>>>>>>>>>>> completely specified in this bis document. I 
>>>>>>>>>>>>>>>>>>>>>>>>>> would suggest dropping
>>>>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>> the i.e.
>>>>    
>>>>>>>>>>>>>>>>>>>>>>>>>> clause.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>>>> Good catch. This is a carry over from before 
>>>>>>>>>>>>>>>>>>>>>>>>> this draft was adopted as a bis version of rfc4582.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>>>> "The version field MUST be set to 2 when using 
>>>>>>>>>>>>>>>>>>>>>>>>>> BFCP over an unreliable transport with the 
>>>>>>>>>>>>>>>>>>>>>>>>>> extensions specified in this document.²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The bit about ³with the extensions specified in 
>>>>>>>>>>>>>>>>>>>>>>>>>> this document² is extraneous and should be removed.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> "If an endpoint receives a message with an 
>>>>>>>>>>>>>>>>>>>>>>>>>> unsupported version field value, the receiving 
>>>>>>>>>>>>>>>>>>>>>>>>>> server MUST send an Error message with 
>>>>>>>>>>>>>>>>>>>>>>>>>> parameter value 12 (Unsupported
>>>>>>>>>>>>>>>>>>>>>>>>>> Version) to indicate this.²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Use of the word ³server² here makes it sound as 
>>>>>>>>>>>>>>>>>>>>>>>>>> if only servers could receive headers with 
>>>>>>>>>>>>>>>>>>>>>>>>>> unsupported versions.
>>>>>>>>>>>>>>>>>>>>>>>>>> Should this be ³the receiving endpoint²?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 6.2.4 = "[23], Section 6.7 provides 
>>>>>>>>>>>>>>>>>>>>>>>>>> useful recommendations Š²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> The links in the references are not quite right.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 8.3.2 = s/when fires/when fired/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section 14 =
>>>>>>>>>>>>>>>>>>>>>>>>>> s/high-jack/hijack/
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> = Section B.1 = "situation where multiple 
>>>>>>>>>>>>>>>>>>>>>>>>>> different and non-interoperable would
>>>>>>>>>>>>>>>>>>>>>>>>>> co-
>>>>>>>>>>>>>>>>>>>>>>>>>> exist in the market.²
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> There is a word missing after ³non-interoperable."
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>                                                
>>>>>>>>>>>>>>>>>>>>>>>>> This should read ³non-interoperable implementations².
>>>>>>>>>>>>>>>>>>>>>>>>> Earlier in that same sentence, ³BFCP over UDP 
>>>>>>>>>>>>>>>>>>>>>>>>> were already used² should read ³BFCP over UDP is 
>>>>>>>>>>>>>>>>>>>>>>>>> already being used².
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>>> Charles
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                              
>>>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>>>> bfcpbis mailing list 
>>>>>>>>>>>>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>                                          
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>                                        
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>                                      
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>                                    
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                                
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                              
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>                          
>>>>>>>>>>>>>
>>>>>>>>>>>>>                      
>>>>>>>>>>>>
>>>>>>>>>>>>                    
>>>>>>>>>>>                  
>>>>>>>>>> _______________________________________________
>>>>>>>>>> bfcpbis mailing list
>>>>>>>>>> [e-mail]
>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>                
>>>>>>>>>              
>>>>>>>>            
>>>>>>>          
>>>>>>        
>>>>> _______________________________________________
>>>>> bfcpbis mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>      
>>>>    
>>>
>>
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/bfcpbis