AD Evaluation of draft-ietf-mmusic-dtls-sdp-20

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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic