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

"Charles Eckel (eckelcu)" <eckelcu@cisco.com> Mon, 28 September 2015 15:49 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 907131ACD4D for <bfcpbis@ietfa.amsl.com>; Mon, 28 Sep 2015 08:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, 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 I9HyrU3Uithv for <bfcpbis@ietfa.amsl.com>; Mon, 28 Sep 2015 08:49:35 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE841ACD26 for <bfcpbis@ietf.org>; Mon, 28 Sep 2015 08:49:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=56712; q=dns/txt; s=iport; t=1443455375; x=1444664975; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wo/djVUHWGiV2GzOWKQ5TY1WJ55zq1dZS1AmWHv11p0=; b=OvkLcalGLfatXYNSz+Ve/Bcsm+pA0G/Vh/y+V96olO2wREJUxh75ALK3 jz5786YYrI7lMCXC+3CQvK4ByGDAqNefTel59f0KJF6xP332wORXgqmwi BWcra1IzAcTud42U2Or3FAc6/Ko51tPRvLbTCZp9MLmguATfWvn3Iel7q k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DyAQBdYAlW/40NJK1egyRUaQa9OAENgVcaCoUvSgIcgSg4FAEBAQEBAQGBCoQkAQEBBAEBARcBCBEzAQYGBQwEAgEGAhEDAQEBAQICEQERAwICAiULFAEICAIEAQ0FCRKIEw2ZMJ0slEQBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKJSIEGhDsBAQUJJxsHBgQJDIJKgUMFhzSFS4UuFYMuAYUUgm6FDIFPhDaDI3WIYIRVg2wBHwEBQoIRHIFUcQGHWgcXI4EFAQEB
X-IronPort-AV: E=Sophos;i="5.17,603,1437436800"; d="scan'208";a="191409036"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-2.cisco.com with ESMTP; 28 Sep 2015 15:49:33 +0000
Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t8SFnXLr027252 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 28 Sep 2015 15:49:33 GMT
Received: from xch-aln-018.cisco.com (173.36.7.28) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 28 Sep 2015 10:49:32 -0500
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.000; Mon, 28 Sep 2015 10:49:32 -0500
From: "Charles Eckel (eckelcu)" <eckelcu@cisco.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "Tom Kristensen (tomkrist)" <tomkrist@cisco.com>
Thread-Topic: [bfcpbis] draft-ietf-bfcpbis-rfc4583bis
Thread-Index: AQHQ9JZwfyzUpa4ayECSaB75x694G55HStYQ///nPgCAAOmjMIAAWNgAgAL/3ZCAAER+AIABRHtQgAC7yICABAgdwIAAPoSA
Date: Mon, 28 Sep 2015 15:49:32 +0000
Message-ID: <D22EAEFE.5A165%eckelcu@cisco.com>
References: <D2258CEC.598F0%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37AC7C92@ESESSMB209.ericsson.se> <D2259E02.5992C%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37ACA75F@ESESSMB209.ericsson.se> <D226AC07.59A4D%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37AD6C84@ESESSMB209.ericsson.se> <D2296A62.59DA1%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37ADD714@ESESSMB209.ericsson.se> <D22B17D1.5A057%eckelcu@cisco.com> <7594FB04B1934943A5C02806D1A2204B37ADFF05@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37ADFF05@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.5.150821
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.115.216]
Content-Type: text/plain; charset="utf-8"
Content-ID: <FFC2F9C198971F4AA9E009FF9F9398A7@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/eShKdQJFcJ7pfcqisJVcZPv_Wio>
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] 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: Mon, 28 Sep 2015 15:49:41 -0000

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-bcp
>>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>>> 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