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

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