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

Tom Kristensen <tomkrist@cisco.com> Mon, 02 November 2015 07:45 UTC

Return-Path: <tomkrist@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 87DCD1B33F8 for <bfcpbis@ietfa.amsl.com>; Sun, 1 Nov 2015 23:45:36 -0800 (PST)
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 0mbjAob6mDgK for <bfcpbis@ietfa.amsl.com>; Sun, 1 Nov 2015 23:45:29 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E33071B3430 for <bfcpbis@ietf.org>; Sun, 1 Nov 2015 23:45:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47277; q=dns/txt; s=iport; t=1446450328; x=1447659928; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=pf4CC/cdxOTKS8Ksv1qQ2qjl9aBB0tJ69W1f481JPcM=; b=WYKSlJy7yt1taQQaQ9mHBczhXru/DpaxPaUPr5vS309vZTYi5gzoAr8a L/7sH9wDIyJiN8XQ6y9d+gVFZ/DkifHhh4ukj/1M5GWXSOLded5LqKvoK E3Nug7YkauXLGO7wMNPzVIfSqSSFDUHNWX9CvOvgKF5QZMbY+Jtp9UA4u c=;
X-IronPort-AV: E=Sophos;i="5.20,233,1444694400"; d="scan'208";a="607916935"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 02 Nov 2015 07:45:26 +0000
Received: from [10.54.90.26] (dhcp-10-54-90-26.cisco.com [10.54.90.26]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id tA27jPBU009254; Mon, 2 Nov 2015 07:45:25 GMT
Message-ID: <56371495.7080105@cisco.com>
Date: Mon, 02 Nov 2015 08:45:25 +0100
From: Tom Kristensen <tomkrist@cisco.com>
Organization: Cisco
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.15) Gecko/20101027 Fedora/3.0.10-1.fc12 Lightning/1.0b2pre Thunderbird/3.0.10
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B37BC8F7B@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/bfcpbis/ke_VX93afebmAwUo_6BeEto1SEs>
Cc: Ben Campbell <ben@nostrum.com>, "bfcpbis@ietf.org" <bfcpbis@ietf.org>, Alissa Cooper <alissa@cooperw.in>, "Charles Eckel (eckelcu)" <eckelcu@cisco.com>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>, "draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org" <draft-ietf-bfcpbis-rfc4582bis@tools.ietf.org>
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: Mon, 02 Nov 2015 07:45:36 -0000

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