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

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

(as an individual)

Tom,

Thanks for posting the updated draft. The changes look good to me.

Cheers,
Charles

From: Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, February 9, 2016 at 11:55 PM
To: Charles Eckel <[e-mail]<mailto:[e-mail]>>
Cc: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Alissa Cooper <[e-mail]<mailto:[e-mail]>>, Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>, Ben Campbell <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Draft updated accordingly and submitted just now.
Cf. https://tools.ietf.org/rfcdiff?url2=draft-ietf-bfcpbis-rfc4583bis-13.txt

-- Tom

On 9 December 2015 at 18:43, Charles Eckel (eckelcu) <[e-mail]<mailto:[e-mail]>> wrote:
On 12/9/15, 9:26 AM, "bfcpbis on behalf of Christer Holmberg"
<[e-mail]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[e-mail]>>
wrote:

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

Argh, autocorrect strikes again.

>
>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]."

Yep, thanks.

>
>Regards,
>
>Christer

Cheers,
Charles


>
>
>-----Original Message-----
>From: Charles Eckel (eckelcu) [mailto:[e-mail]<mailto:[e-mail]>]
>Sent: 09 December 2015 18:37
>To: Charles Eckel (eckelcu) <[e-mail]<mailto:[e-mail]>>; Christer Holmberg
><[e-mail]<mailto:[e-mail]>>; Tom Kristensen (tomkrist)
><[e-mail]<mailto:[e-mail]>>
>Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
>Alissa Cooper <[e-mail]<mailto:[e-mail]>>; Gonzalo Camarillo
><[e-mail]<mailto:[e-mail]>>; Ben Campbell <[e-mail]<mailto:[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]<mailto:[e-mail]> on behalf of [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>Sent: 02 November 2015 10:26
>>>To: Tom Kristensen (tomkrist) <[e-mail]<mailto:[e-mail]>>; Christer Holmberg
>>><[e-mail]<mailto:[e-mail]>>
>>>Cc: Alissa Cooper <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
>>>[e-mail]<mailto:[e-mail]>; Gonzalo Camarillo
>>><[e-mail]<mailto:[e-mail]>>; Ben Campbell <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>> Sent: 28 September 2015 18:50
>>>>> To: Christer Holmberg<[e-mail]<mailto:[e-mail]>>; Tom Kristensen
>>>>>(tomkrist)<[e-mail]<mailto:[e-mail]>>
>>>>> Cc: Alissa Cooper<[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
>>>>>[e-mail]<mailto:[e-mail]>; Gonzalo
>>>>>Camarillo<[e-mail]<mailto:[e-mail]>>; Ben
>>>>>Campbell<[e-mail]<mailto:[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]<mailto:[e-mail]> on behalf of
>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>>>>> Sent: 22. syyskuuta 2015 17:05
>>>>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist)
>>>>>>>> Cc: [e-mail]<mailto:[e-mail]>;
>>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]> on behalf of
>>>>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25
>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo;
>>>>>>>>>>>>> [e-mail]<mailto:[e-mail]>; Ben Campbell;
>>>>>>>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>]
>>>>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07
>>>>>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist);
>>>>>>>>>>>>>>>>> [e-mail]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]>
>>>>>>>>>>>>>>>>>>>>>>> <mailto:[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]>
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[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]>
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *"[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>"
>>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]> <mailto:[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]><mailto:[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]>
>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[e-mail]<mailto:[e-mail]>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>>>>>>>>>>>>>>>>>> To: "[e-mail]<mailto:[e-mail]><mailto:[e-mail]<mailto:[e-mail]>>"
>>>>>>>>>>>>>>>>>>>>>>>>>> <[e-mail]<mailto:[e-mail]><mailto:[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]><mailto:[e-mail]<mailto:[e-mail]>>
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> bfcpbis mailing list
>>>>>>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> bfcpbis mailing list
>>>>>> [e-mail]<mailto:[e-mail]>
>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>
>>>>>
>>>>
>>>
>>
>>_______________________________________________
>>bfcpbis mailing list
>>[e-mail]<mailto:[e-mail]>
>>https://www.ietf.org/mailman/listinfo/bfcpbis
>
>_______________________________________________
>bfcpbis mailing list
>[e-mail]<mailto:[e-mail]>
>https://www.ietf.org/mailman/listinfo/bfcpbis

_______________________________________________
bfcpbis mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/bfcpbis



--
# Cisco                         |  http://www.cisco.com/telepresence/
## [e-mail]<mailto:[e-mail]>  |  http://www.tandberg.com
###                               |  http://folk.uio.no/tomkri/