Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's substantive comments
Ben Campbell <ben@nostrum.com> Tue, 14 March 2017 20:12 UTC
Return-Path: <ben@nostrum.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 D67761298A9; Tue, 14 Mar 2017 13:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.019
X-Spam-Level:
X-Spam-Status: No, score=0.019 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 cQzVoDpd6b4E; Tue, 14 Mar 2017 13:12:28 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA961296F7; Tue, 14 Mar 2017 13:12:28 -0700 (PDT)
Received: from [10.0.1.51] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v2EKCOGQ067602 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Mar 2017 15:12:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.51]
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: Ben Campbell <ben@nostrum.com>
X-Mailer: iPad Mail (14D27)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se>
Date: Tue, 14 Mar 2017 15:12:24 -0500
Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>, mmusic <mmusic@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <BD1D36AF-2632-4804-92EE-832E4ACA535E@nostrum.com>
References: <D4ED70C3.19689%christer.holmberg@ericsson.com> <87576B8B-DD3A-4DC6-8A75-265728BF477A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B4CB0D18D@ESESSMB109.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/WpEy_wgGpdXAT--TgMvLQEORKII>
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 20:12:30 -0000
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 >
- Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-d… Christer Holmberg
- Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-d… Ben Campbell
- Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-d… Christer Holmberg
- Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-d… Ben Campbell
- Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-d… Christer Holmberg