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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Wed, 09 December 2015 17:43 UTC

Return-Path: <eckelcu@cisco.com>
X-Original-To: bfcpbis@ietfa.amsl.com
Delivered-To: bfcpbis@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB201B29E0 for <bfcpbis@ietfa.amsl.com>; Wed, 9 Dec 2015 09:43:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.31
X-Spam-Level:
X-Spam-Status: No, score=-13.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0c70lvkgh57 for <bfcpbis@ietfa.amsl.com>; Wed, 9 Dec 2015 09:43:21 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD841B29DF for <bfcpbis@ietf.org>; Wed, 9 Dec 2015 09:43:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=77114; q=dns/txt; s=iport; t=1449683000; x=1450892600; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PWSBcW6VTDBTOxjSRv/DRuaMhIRJtTuSOO/quak7gI4=; b=WXTIGbUsyTvLmb2bFrgUb1G9DU6WJ64p5Dm7K0RW9gN1l1SvlFmjESGt rPo46zox7KVq+/qp9GW4sctdjwBfIH0J+th273KKrJiDp5OGbJzOdq4dV hKErirKalElbEiXE+aHP6w25M3sB+LmQZ2ufcyRKjaKjbEh3l8wDUyuuH U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ABAgCBZ2hW/4sNJK1cAoM6U24GvUUBDYFiFwqFJEoCHIELOBQBAQEBAQEBgQqENAEBAQQBAQEXAQgRMwEGBgUMBAIBBgIRAwEBAQECAhEBEQMCAgIlCxQBCAgCBAENBQkSiBQNkFadNpFwAQEBAQEBAQEBAQEBAQEBAQEBAQEBGIEBiUuBBoQ7AQEFCSYpCQsBgkiBSQWHVIVZhTmEAwGFMoJxhR+BW4REgyh5iWaEa4NyAR8BAUKCER0WgUByhDEHFyOBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.20,404,1444694400"; d="scan'208";a="52051671"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Dec 2015 17:43:17 +0000
Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id tB9HhH5c025169 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 9 Dec 2015 17:43:17 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 9 Dec 2015 11:43:16 -0600
Received: from xch-aln-018.cisco.com ([173.36.7.28]) by XCH-ALN-018.cisco.com ([173.36.7.28]) with mapi id 15.00.1104.009; Wed, 9 Dec 2015 11:43:16 -0600
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Thread-Topic: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
Thread-Index: AQHRMp/H3B27oV/7jkaNpW2F7iCWr57DTNgA//9+iIA=
Date: Wed, 09 Dec 2015 17:43:16 +0000
Message-ID: <D28DA7ED.604A2%eckelcu@cisco.com>
References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se> <56371495.7080105@cisco.com> <D25D4C6A.5DF22%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37BCD730@ESESSMB209.ericsson.se> <D262300E.5E485%eckelcu@cisco.com> <D28D93AC.603E7%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37C90AB8@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37C90AB8@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.8.151023
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.248.42]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9FE52BF70FB9354AA09250DCF784FEE9@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/cynRl0Tj9QYCy2vVkJyu7CvfiCc>
Cc: "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, Ben Campbell <ben@nostrum.com>
Subject: Re: [bfcpbis] Status update on draft-ietf-mmusic-dtls-sdp [was: draft-ietf-bfcpbis-rfc4583bis]
X-BeenThere: bfcpbis@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BFCPBIS working group discussion list <bfcpbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bfcpbis/>
List-Post: <mailto:bfcpbis@ietf.org>
List-Help: <mailto:bfcpbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bfcpbis>, <mailto:bfcpbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Dec 2015 17:43:28 -0000

On 12/9/15, 9:26 AM, "bfcpbis on behalf of Christer Holmberg"
<bfcpbis-bounces@ietf.org on behalf of christer.holmberg@ericsson.com>
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:eckelcu@cisco.com]
>Sent: 09 December 2015 18:37
>To: Charles Eckel (eckelcu) <eckelcu@cisco.com>; Christer Holmberg
><christer.holmberg@ericsson.com>; Tom Kristensen (tomkrist)
><tomkrist@cisco.com>
>Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; bfcpbis@ietf.org;
>Alissa Cooper <alissa@cooperw.in>; Gonzalo Camarillo
><gonzalo.camarillo@ericsson.com>; Ben Campbell <ben@nostrum.com>
>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)"
><bfcpbis-bounces@ietf.org on behalf of eckelcu@cisco.com> 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" <christer.holmberg@ericsson.com>
>>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:eckelcu@cisco.com]
>>>Sent: 02 November 2015 10:26
>>>To: Tom Kristensen (tomkrist) <tomkrist@cisco.com>; Christer Holmberg
>>><christer.holmberg@ericsson.com>
>>>Cc: Alissa Cooper <alissa@cooperw.in>; bfcpbis@ietf.org;
>>>draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo Camarillo
>>><gonzalo.camarillo@ericsson.com>; Ben Campbell <ben@nostrum.com>
>>>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)" <tomkrist@cisco.com>
>>>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:eckelcu@cisco.com]
>>>>> Sent: 28 September 2015 18:50
>>>>> To: Christer Holmberg<christer.holmberg@ericsson.com>; Tom Kristensen
>>>>>(tomkrist)<tomkrist@cisco.com>
>>>>> Cc: Alissa Cooper<alissa@cooperw.in>; bfcpbis@ietf.org;
>>>>>draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Gonzalo
>>>>>Camarillo<gonzalo.camarillo@ericsson.com>; Ben
>>>>>Campbell<ben@nostrum.com>
>>>>> 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"
>>>>> <bfcpbis-bounces@ietf.org on behalf of
>>>>> christer.holmberg@ericsson.com>
>>>>> 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"
>>>>>> <christer.holmberg@ericsson.com>
>>>>>> 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"
>>>>>>> <christer.holmberg@ericsson.com>
>>>>>>> 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:eckelcu@cisco.com]
>>>>>>>> Sent: 22. syyskuuta 2015 17:05
>>>>>>>> To: Christer Holmberg; Tom Kristensen (tomkrist)
>>>>>>>> Cc: draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org;
>>>>>>>> bfcpbis@ietf.org; 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"
>>>>>>>> <christer.holmberg@ericsson.com>
>>>>>>>> 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"
>>>>>>>>> <christer.holmberg@ericsson.com>
>>>>>>>>> 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"
>>>>>>>>>> <bfcpbis-bounces@ietf.org on behalf of
>>>>>>>>>> christer.holmberg@ericsson.com>
>>>>>>>>>> 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"
>>>>>>>>>>> <christer.holmberg@ericsson.com>
>>>>>>>>>>> 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:tomkrist@cisco.com]
>>>>>>>>>>>>> Sent: 11. syyskuuta 2015 13:25
>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>> Cc: Christer Holmberg; Alissa Cooper; Gonzalo Camarillo;
>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; Ben Campbell;
>>>>>>>>>>>>> bfcpbis@ietf.org
>>>>>>>>>>>>> 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)"<eckelcu@cisco.com>
>>>>>>>>>>>>>> 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"<christer.holmberg@ericsson.com>
>>>>>>>>>>>>>>> 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:alissa@cooperw.in]
>>>>>>>>>>>>>>>>> Sent: 8. huhtikuuta 2015 3:07
>>>>>>>>>>>>>>>>> To: Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>> Cc: Gonzalo Camarillo; Tom Kristensen (tomkrist);
>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org; 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)
>>>>>>>>>>>>>>>>> <eckelcu@cisco.com>
>>>>>>>>>>>>>>>>> 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"<alissa@cooperw.in>
>>>>>>>>>>>>>>>>>> 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)
>>>>>>>>>>>>>>>>>>> <eckelcu@cisco.com>
>>>>>>>>>>>>>>>>>>> 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"<alissa@cooperw.in>
>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>> <gonzalo.camarillo@ericsson.com>    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
>>>>>>>>>>>>>>>>>>>>>>> <gonzalo.camarillo@ericsson.com
>>>>>>>>>>>>>>>>>>>>>>> <mailto:gonzalo.camarillo@ericsson.com>>
>>>>>>>>>>>>>>>>>>>>>>> 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<alissa@cooperw.in
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:alissa@cooperw.in>>
>>>>>>>>>>>>>>>>>>>>>>>>> *Subject: **Re: [bfcpbis] AD evaluation:
>>>>>>>>>>>>>>>>>>>>>>>>> draft-ietf-bfcpbis-rfc4582bis-12*
>>>>>>>>>>>>>>>>>>>>>>>>> *Date: *February 9, 2015 at 3:58:52 PM PST
>>>>>>>>>>>>>>>>>>>>>>>>> *To: *"Charles Eckel (eckelcu)"<eckelcu@cisco.com
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:eckelcu@cisco.com>>
>>>>>>>>>>>>>>>>>>>>>>>>> *Cc: *"bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>"
>>>>>>>>>>>>>>>>>>>>>>>>> <bfcpbis@ietf.org <mailto:bfcpbis@ietf.org>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Charles,
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, some responses inline.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Feb 4, 2015, at 10:40 AM, Charles Eckel (eckelcu)
>>>>>>>>>>>>>>>>>>>>>>>>> <eckelcu@cisco.com<mailto:eckelcu@cisco.com>>
wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> HI Alissa,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thank you for the review. Please see my thoughts
>>>>>>>>>>>>>>>>>>>>>>>>>> on your comments and questions inline.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> From: Alissa Cooper<alissa@cooperw.in
>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:alissa@cooperw.in>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Date: Thursday, January 29, 2015 at 10:19 PM
>>>>>>>>>>>>>>>>>>>>>>>>>> To: "bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>"
>>>>>>>>>>>>>>>>>>>>>>>>>> <bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>>
>>>>>>>>>>>>>>>>>>>>>>>>>> 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 
>>>>>>>>>>>>>>>>>>>>>>>>> bfcpbis@ietf.org<mailto:bfcpbis@ietf.org>
>>>>>>>>>>>>>>>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>                                            
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>                                          
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>                                        
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>                                      
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>                                    
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>                                  
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>                                
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>                              
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>                            
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>                          
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                      
>>>>>>>>>>>>>
>>>>>>>>>>>>>                    
>>>>>>>>>>>>                  
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> bfcpbis mailing list
>>>>>>>>>>> bfcpbis@ietf.org
>>>>>>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>>>>>>                
>>>>>>>>>>              
>>>>>>>>>            
>>>>>>>>          
>>>>>>>        
>>>>>> _______________________________________________
>>>>>> bfcpbis mailing list
>>>>>> bfcpbis@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/bfcpbis
>>>>>>      
>>>>>    
>>>>
>>>
>>
>>_______________________________________________
>>bfcpbis mailing list
>>bfcpbis@ietf.org
>>https://www.ietf.org/mailman/listinfo/bfcpbis
>
>_______________________________________________
>bfcpbis mailing list
>bfcpbis@ietf.org
>https://www.ietf.org/mailman/listinfo/bfcpbis