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

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

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#section
>>>>>>>>>>>>>-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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>
>>