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

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

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic