[MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20
"Ben Campbell" <ben@nostrum.com> Tue, 14 March 2017 03:58 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 BC959129622; Mon, 13 Mar 2017 20:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 mTHGcmwDOo7O; Mon, 13 Mar 2017 20:58:27 -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 289C512948A; Mon, 13 Mar 2017 20:58:27 -0700 (PDT)
Received: from [10.0.1.39] (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 v2E3wPOj066611 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 13 Mar 2017 22:58: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.39]
From: Ben Campbell <ben@nostrum.com>
To: draft-ietf-mmusic-dtls-sdp.all@ietf.org, mmusic <mmusic@ietf.org>
Date: Mon, 13 Mar 2017 22:58:25 -0500
Message-ID: <9EB253C7-ED36-4D00-BCC7-20EC6E4441B4@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/_Ytm-55O09oXGh4Sl88CAuyz5ko>
Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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 03:58:29 -0000
Hi, This is my AD Evaluation of draft-ietf-mmusic-dtls-sdp-20. I'd like to resolve my substantive comments and questions prior to IETF last call. Thanks! Ben. --------------------- 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? -8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a scenario where it would make sense to not follow them? -9.2, new text for section 5, 5th paragraph: Since we are touching this section, shouldn't we update the 4474 reference to 4474bis, and update the language about what gets signed in 4474bis? And can we take this opportunity for a MUST level requirement for some kind of integrity protection of fingerprints, even if not 4474/4474bis? (At least when not considering opportunistic crypto cases.) -- 4th paragraph from end of new text: should "the certificate fingerprint" say "a certificate fingerprint"? (Since you can have multiple fingerprints now...) -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. Editorial Comments: - Throughout the document, I found it confusing whether a "new" association means an initial association or a replacement association. In some places it doesn't matter (and I was happy to see that it really doesn't matter for much of the normative guidance), but for example 5.4 talks about replacing an old association even though IIUC the section talks about the answer to an initial offer. If the intent is for new to mean "initial or replacement" in all cases, then a sentence to that effect early in the document would be helpful. - 3.1, "A new DOTLS association MUST be estlablished ...": Established by what? (Please consider active voice.) Also, that MUST seems redundant to the 2119 language in the much more detailed procedure sections that follow; maybe this should be lower case? "The intent to establish a new DTLS association is explicitly signaled ...": Likewise, signaled by what? - 3.2: Are the 2119 keywords here redundant with those in the more detailed procedure sections that follow? - 3.2, paragraph 2: I don't think the word "explicitly" constrains anything. Also, s/"... to span ..." / "... from spanning ..." - 4: "a modification of one or more of the following characteristics MUST be treated as an indication": Treated as an indication by what? (Please consider active voice when using 2119 keywords.) - 5.1, paragraph 4: "a new transport (3-tuple) MUST be allocated by at least one of the end points so that DTLS packets can be de-multiplexed.": That seems redundant with the more detailed procedures that follow. Please consider it descriptively here, and saving the 2119 words for the more detailed procedures. -6, 2nd paragraph: Can you offer a citation for the deprecation of aggressive nomination? -- 3rd paragraph: "at least one of the endpoints MUST allocate": I suspect that's redundant to 2119 language in the detailed procedures. But if it's not, please restate with specific procedure for the offerer and answer. It's vague to assign a 2119 MUST to "at least one". -8, first paragraph: "If forking occurs, separate DTLS associations MUST be established between the caller and each callee.": This seems like a statement of fact. That is, how could they _not_ establish a separate association, since I assume you would end up with a unique 5-tuple for each branch. -9.2, paragraph 5: "The SIP message containing the offer SHOULD be sent to the offerer’s SIP proxy over an integrity protected channel": This seems redundant with a previous statement 2 sentences back. (Yes, this was in the original text...) -- Last paragraph in new text for section 5: Do you intend for "RFCXXXX" to refer to _this_ document? If so, a note to the RFC editor to that effect would be helpful. (There are multiple occurrences.)
- [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-… Ben Campbell