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

Christer Holmberg <christer.holmberg@ericsson.com> Tue, 14 March 2017 12:02 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 3C202129555; Tue, 14 Mar 2017 05:02:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 NBkrW6awlDG3; Tue, 14 Mar 2017 05:02:39 -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 ACD4A12951B; Tue, 14 Mar 2017 05:02:38 -0700 (PDT)
X-AuditID: c1b4fb25-0b71498000002d78-44-58c7dbdc5c3a
Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by (Symantec Mail Security) with SMTP id B4.6F.11640.CDBD7C85; Tue, 14 Mar 2017 13:02:36 +0100 (CET)
Received: from ESESSMB109.ericsson.se ([169.254.9.56]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.03.0319.002; Tue, 14 Mar 2017 13:01:47 +0100
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Ben Campbell <ben@nostrum.com>, "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 editorial comments
Thread-Index: AQHSnLrBauqclGvw5EeBiU2voC55FQ==
Date: Tue, 14 Mar 2017 12:01:47 +0000
Message-ID: <D4ED7EA0.1977A%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.1.161129
x-originating-ip: [153.88.183.146]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6FC384EF01BBA64681F09DA2905FC8E1@ericsson.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZGbFdXffO7eMRBs9vmlrM7zzNbrHj7g42 i6nLH7M4MHssWfKTyWPWzicsAUxRXDYpqTmZZalF+nYJXBknf99iLzisVtF+6Dl7A+MzuS5G Tg4JAROJvVuvsILYQgLrGCWuN3h1MXIB2YsZJaYfmMDexcjBwSZgIdH9TxskLiIwmVGif1cr E0iDsECERNfLRSwgtohApMS/a6eZIWw9iWerG9lAbBYBVYnpL06B1fMKWEvsWHoNLM4oICbx /dQasDizgLjErSfzmSAOEpBYsuc8M4QtKvHy8T+w40SBZi5/vgYqriTxY8MlFoheA4n35+Yz Q9jWEvf/fGeDsLUlli18zQyxV1Di5MwnLBMYRWYhWTcLSfssJO2zkLTPQtK+gJF1FaNocWpx Um66kbFealFmcnFxfp5eXmrJJkZgxBzc8lt1B+PlN46HGAU4GJV4eD9sPhYhxJpYVlyZe4hR goNZSYR3W9PxCCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8ZivvhwsJpCeWpGanphakFsFkmTg4 pRoYWdPWp8u811+5Q19HQ02la+GxucxuytvXBEdPO/uIeWnhlrOnI3Uq/yh/ijrQvPJjX6Hg js6a4xter+3vZGXarFsRKFRQsq0r+9vzRLWs/pmcRZt3nen8NXFPyp4w6Sn1Vd9qc7VCV7zR tTwnkpfANkWWgYG16kfZip/bm7Xj7i3k38YXtdBOiaU4I9FQi7moOBEATStWkpQCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/LVQs67MRXhsCl0io6nvfYgAvw08>
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.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 12:02:40 -0000

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