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

"Ben Campbell" <ben@nostrum.com> Tue, 14 March 2017 15:29 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 3394D129549; Tue, 14 Mar 2017 08:29:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.881
X-Spam-Level:
X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8oN6hhXTZ2S8; Tue, 14 Mar 2017 08:29: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 28F6F128DF6; Tue, 14 Mar 2017 08:29:28 -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 v2EFTOZ8037975 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 14 Mar 2017 10:29:24 -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: "Christer Holmberg" <christer.holmberg@ericsson.com>
Cc: "draft-ietf-mmusic-dtls-sdp.all@ietf.org" <draft-ietf-mmusic-dtls-sdp.all@ietf.org>, mmusic <mmusic@ietf.org>
Date: Tue, 14 Mar 2017 10:29:23 -0500
Message-ID: <4A0126D3-FF95-4B84-96A5-2DE8B03CFD68@nostrum.com>
In-Reply-To: <D4ED7EA0.1977A%christer.holmberg@ericsson.com>
References: <D4ED7EA0.1977A%christer.holmberg@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/-rofRMDyqeAK21AW-0sixBuF36U>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-dtls-sdp-20 - Ben's editorial comments
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.21
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 15:29:29 -0000

Thanks Christer, this all looks good to me.

Ben.

On 14 Mar 2017, at 7:01, Christer Holmberg wrote:

> Hi,
>
> 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.
>
> In general, the procedures apply both to initial and replacement.
>
> However, in some sentences (e.g, section 5.4) the text explicitly talks
> about replacing an existing association.
>
> I could add the following text to the beginning of section 3.1.
>
> ³In this document, a ³new DTLS association² between two endpoints refers
> to either an initial DTLS association (when no DTLS association is
> currently established between the endpoints) or an DTLS association
> replacing a previously established DTLS association."
>
>> - 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?
>
> I can use lower case.
>
> And, I could say ³must be established between two endpoints².
>
>> "The intent to establish a new DTLS association is explicitly signaled
>> ...": Likewise, signaled by what?
>
> I could say ³explicitly signaled with SDP, using theŠ"
>
> ----
>
>> - 3.2: Are the 2119 keywords here redundant with those in the more
>> detailed procedure sections that follow?
>
> I can s/MUST/must.
>
>> - 3.2, paragraph 2: I don't think the word "explicitly" constrains
>> anything. Also, s/"... to span ..." / "... from spanning ..."
>
> I can remove ³explicitly² and 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.)
>
> Indication by the peer.
>
> I could re-write the sentence e.g., in the following way:
>
> OLD:
>
> "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:²
>
> NEW:
>
> ³Unless there is another mechanism to explicitly indicate that a new DTLS
> association is to be established, if an endpoint modifies one or more of
> the following characteristics in an offer or answer the peer MUST treat
> it as indication that the endpoint wants to establish a new DTLS
> association."
>
> ----
>
>
>> - 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.
>
> I can s/MUST/must.
>
> ----
>
>> -6, 2nd paragraph: Can you offer a citation for the deprecation of
>> aggressive nomination?
>
> I guess I could add a reference to 5245bis, because it contains a note
> which talks about the deprecation.
>
>> -- 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".
>
> I don¹t think specific procedures is needed in this case, because the text
> only says that at least one
> endpoint needs to allocate a new set of candidates.
>
> ----
>
>>
>> -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.
>
> I could say ³will be² instead of ³MUST be².
>
> ----
>
>> -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...)
>
> I can remove the sentence from the new 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.)
>
> RFCXXXX refers to this document. I will add a note.
>
>
> Regards,
>
> Christer