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

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

All good points, Christer.

Unless there is someone on the list that wants to propose a usage of BFCP with bundling, I suggest we proceed by stating that MUXing of BFCP m-lines is NOT RECOMMENDED and a reference be added to the draft. Anyone wanting to define such a usage for BFCP is free to do so in another draft.

I checked with the MMUSIC chairs, and Bo stated he was not aware of the term “source specific” ever being used in any other SDP context than RTP SSRC, which means it should simply be “not applicable” for BFCP “m=” lines. A reference to this draft should be added as well.

Cheers,
Charles (as an individual)

From: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, April 27, 2016 at 8:15 AM
To: Charles Eckel <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Cc: Ben Campbell <[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]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Hi,

First, if you want to allow mixing of a BFCP m-line with ANYTHING (no matter whether it’s audio, video or another BFCP m- line) you need to describe how the receiver can distinguish the received packets. You would need to have a “BUNDLE considerations” section, or something like that.

Second, as you haven’t specified how to MUX two or more BFCP m-lines I would assume “NOT RECOMMENDED” is the correct one, as there are no “NOT APPLICABLE” or “NOT SPECIFIED” options.

Third, I agree that the attribute is not source specific. Now, since source is not applicable to BFCP to begin with, I’d suggest you ask the MMUSIC chairs whether you need to say anything about source.

Regards,

Christer

From: Charles Eckel <[e-mail]<mailto:[e-mail]>>
Date: Wednesday 27 April 2016 at 18:02
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Cc: Ben Campbell <[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]>>, Gonzalo Camarillo <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Trying to wrap up this thread. Please see inline.

From: Charles Eckel <[e-mail]<mailto:[e-mail]>>
Date: Friday, February 26, 2016 at 11:08 PM
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Cc: Ben Campbell <[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]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Comments inline, as an individual

From: Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Date: Sunday, February 14, 2016 at 2:18 AM
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, Charles Eckel <[e-mail]<mailto:[e-mail]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Cc: Ben Campbell <[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]>>, Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Subject: RE: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Hi,

A few more comments.

As I said earlier, the mux category is needed in the IANA considerations.

In addition, Flemming has told me that there should be normative text regarding the mux category, AND the source-specific applicability (i.e. if/how an attribute can be associated with a specific source, using the 'ssrc' attribute).

Christer, can you provide text that you should be added to address this?

Regarding the MUX category, its okay to MUX a BFCP m-line with one or more audio/video m-lines, but its not okay to MUX multiple BFCP m-lines together. If I understand MUX categories correctly, this equates to “NOT RECOMMENDED”.

Regarding ssrc, I think this attribute is not applicable to BFCP.

Cheers,
Charles




Regards,

Christer

Sent from my Windows Phone
________________________________
From: Christer Holmberg<mailto:[e-mail]>
Sent: ‎13/‎02/‎2016 18:25
To: Charles Eckel (eckelcu)<mailto:[e-mail]>; Tom Kristensen<mailto:[e-mail]>
Cc: Ben Campbell<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Alissa Cooper<mailto:[e-mail]>; Gonzalo Camarillo<mailto:[e-mail]>; Tom Kristensen (tomkrist)<mailto:[e-mail]>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]

Hi,

A few comments.

Q1:

The text in section 9 says:

“When SIP is used to perform an offer/answer exchange,…”

I think that is misleading. SIP is not used for offer/answer – SDP is. SIP is used to carry the SDP, though.

True. How about we change to “When SDP is used …”



Q2:

In the first paragraph of section 10.5, I think the text should reference [13] (i.e. draft-dtls-sdp) on how to determine the TLS client. Reference [10] does not define the role determination for DTLS.

[13] references [10] for the TLS/DTLS role determination, and [13] is referenced later in section 10.5, so I think its okay as written. I also think it would be okay to reference [13] only, which is what I believe you are suggesting, but then the exercise is left to the reader to following the reference in [13] to [10].




Q3:

Section 10, and its subsections, does not describe the usage of the ‘dtls-connection’ attribute for DTLS (the attribute is later shown in the examples, though).

So, text should either be added – OR I would again suggest to have a statement saying that the generic offer/answer procedures for DTLS are defined in [13], and that section 10 defines the BFCP specific parts.

Sounds good to me.

Cheers,
Charles


I know we have discussed a dependency on draft-dtls-sdp before :) But, draft-dtls-sdp is currently in its second week of WGLC (the WGLC ends February 19th), so unless something unexpected comes up (so far the comments have been more or less editorial) I don’t think such dependency would delay draft-bfcpbis. And, draft-bfcpbis already refers to draft-dtls-sdp for when a new DTLS connection has to be created, so the dependency is already there :)


Regards,

Christer



From: Charles Eckel (eckelcu) [mailto:[e-mail]]
Sent: 13 February 2016 01:36
To: Tom Kristensen <[e-mail]<mailto:[e-mail]>>
Cc: Christer Holmberg <[e-mail]<mailto:[e-mail]>>; Tom Kristensen (tomkrist) <[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]

(as chair)

I request that the working group take a look within the next week and share whether they are okay with the changes, and if not, what specific changes are needed.

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/