Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 14 March 2017 21:40 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68EDD129B4F; Tue, 14 Mar 2017 14:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.321
X-Spam-Level:
X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uQsdRDbIHFAp; Tue, 14 Mar 2017 14:40:05 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27662129B4D; Tue, 14 Mar 2017 14:40:04 -0700 (PDT)
X-AuditID: c1b4fb25-0b71498000002d78-6c-58c863336e6c
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by (Symantec Mail Security) with SMTP id 9B.9B.11640.33368C85; Tue, 14 Mar 2017 22:40:03 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 22:38:54 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ben Campbell <ben@nostrum.com>
CC: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>, mmusic <mmusic@ietf.org>
Thread-Topic: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
Thread-Index: AQHSnKFIZPUXLA+RFUGrIb2KhDlggqGUWYsAgABUfLCAAAaJAIAAKKag
Date: Tue, 14 Mar 2017 21:38:53 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B4CB0D37C@ESESSMB109.ericsson.se>
References: <D4ED70C3.19689%christer.holmberg@ericsson.com> <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se> <BD1D36AF-2632-4804-92EE-832E4ACA535E@nostrum.com>
In-Reply-To: <BD1D36AF-2632-4804-92EE-832E4ACA535E@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyM2K7hK5x8okIg5tr5C3md55mt9hxdweb xdTlj1kcmD2WLPnJ5DFr5xOWAKYoLpuU1JzMstQifbsEroxvWx+yFLQZVTyYv4O9gfGBQRcj J4eEgInE5GO7WEFsIYF1jBLX5op0MXIB2YsZJU4e3M7UxcjBwSZgIdH9TxukRkRASeJ581YW EJtZoFhi+bcvYL3CAlESCx8fYoSoiZa4dxYiLiLgJjH96DKwOIuAqsTk1/OZQUbyCvhK7Fvt CbH2JaPEnGMaIDangL3EnX+fwcoZBcQkvp9awwSxSlzi1pP5TBAnC0gs2XOeGcIWlXj5+B8r hK0k0bjkCSvIeGYBTYn1u/QhWhUlpnQ/ZAexeQUEJU7OfMIygVF0FpKpsxA6ZiHpmIWkYwEj yypG0eLU4qTcdCNjvdSizOTi4vw8vbzUkk2MwEg5uOW36g7Gy28cDzEKcDAq8fAWsJ6IEGJN LCuuzD3EKMHBrCTC+5oBKMSbklhZlVqUH19UmpNafIhRmoNFSZzXbOX9cCGB9MSS1OzU1ILU IpgsEwenVAPjpGz9YpM/9/rmsn3zOBf2e0LbyfmBWTxM22MuuSxWfKfymucA90qLP59jrleU Xzgr0Ps+cOe3F6VJ1fxzDp1aoX/Q5MmGFXt9Wz6xlNrfbSyS37CoKP6b/w2WjwJb/Ras07vG Kft8acv2VaJr438/fBC8Je+C60yDv9P516S6bNpn5OykpOXircRSnJFoqMVcVJwIAKFsoQWQ AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xG3_lPsSdRFo0AMlrMMZkNdeca8>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Mar 2017 21:40:07 -0000

Hi Ben,

I've created a pull request with all the changes based on your comments (substantive and editorial). Please take a look.

https://github.com/cdh4u/draft-dtls-sdp/pull/25

Regards,

Christer

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: 14 March 2017 22:12
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: draft-ietf-mmusic-dtls-sdp.all@ietf.org; mmusic <mmusic@ietf.org>
Subject: Re: AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments

Both work for me.

Thanks!
Ben.

> On Mar 14, 2017, at 3:07 PM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
> 
> Hi,
> 
> Substantive Comments:
> 
>>>> - section 4: "If an offer or answer does not
>>>>   contain a ¹dtls-id¹ attribute (this could happen if the offerer or
>>>>   answerer represents an existing implementation that has not been
>>>>   updated to support the ¹dtls-id¹ attribute), the offer or answer 
>>>>   MUST be treated as if no ¹dtls-id¹ attribute is included. "
>>>> 
>>>> That seems to say that if dtls-id is not included, the offer or 
>>>> answer must be treated as if it's not included. Since that's 
>>>> tautologically true, I suspect you meant to say something more?
>>> 
>>> This is related to the first sentence, saying that there is no 
>>> default value defined for the attribute.
>>> 
>>> I could say "Hence, if an offer or answer does not contain", if it 
>>> makes the text more clear.
>> 
>> You would still get a sentence of the form "If not foo, then not foo." 
>> Perhaps the predicate clause could be recast as the consequences or 
>> (high level) receiver behavior when dtls-id not being present? Does 
>> the absence mean that the session is not setup? That the receiver assumes the sender is a legacy implementation?
> 
> That the receiver assumes the sender is a legacy implementation.
> 
> Maybe something like:
> 
>   "No default value is defined for the SDP 'dtls-id' 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 a 'dtls-id' attribute (this could happen if the offerer or
>   answerer represents an existing implementation that has not been
>   updated to support the 'dtls-id' attribute), unless there is
>   another mechanism to explicitly indicate that a new DTLS association
>   is to be established, a modification of one or more of the following
>   characteristics MUST be treated as an indication that an endpoint
>   wants to establish a new DTLS association:" 
> 
> ...
> 
>>>> -10:
>>>> 
>>>> If you accept my suggestion to move from 4474 to 4474bis in the 
>>>> updated text for 5763, that will create changes that should 
>>>> probably be mentioned here. For example, 4474bis signatures cover 
>>>> fewer things than do 4474 signatures. The hope that 4474bis may be 
>>>> more deployable than 4474, and therefore really used, may also be 
>>>> worth a mention here.
>>> 
>>> RFC 5763 contains 20+ references to RFC 4474, in a number of 
>>> different sections.
>>> 
>>> We would have to update all of those sections (at least the 
>>> reference, possibly also normative text), because I don¹t think we 
>>> should mix
>>> 4474 and 4474bis. In my opinion, that should be done as a separate task.
>> 
>> I scanned 5763 for the references to see if we could reasonably say that all references should be updated. 
>> But there's some text on the limitations of identity for phone numbers that might become obsolete if we did that.
>> SO I can be convinced to leave that out of scope for this update. But 
>> it's still a bit unfortunate :-)
>> 
>> Would it make sense for this document to contain a paragraph 
>> somewhere mentioning that, since the publication of 5763, RFC4474 is 
>> being updated to address some of those issues, and that implementors 
>> should at least consider moving to it? The reason I push on this is that I have hopes that 4474bis can enable the dtls-srtp framework to be used in a more secure fashion that typical for now, since we have such limited deployment of 4474.
> 
> "NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted 
> by draft-ietf-stir-4474bis. The updating of the references (and the 
> associated procedures) within RFC 5763 is outside the scope of this document. However, implementers of RFC 5763 applications are encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474."
> 
> Feel free to modify, if you e.g., want to give more background etc about 4474bis.
> 
> Regards,
> 
> Christer
>