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

[Tom Kristensen <[e-mail]>]

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]>
wrote:

> On 12/9/15, 9:26 AM, "bfcpbis on behalf of Christer Holmberg"
> <[e-mail] on behalf of [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]]
> >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
> >
> >_______________________________________________
> >bfcpbis mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/bfcpbis
>
> _______________________________________________
> bfcpbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>



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