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

Hi Ben,

Thanks for your review! Please see inline.


>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?

This is related to the first sentence, saying that there is no default
value defined for the attribute.

I could say ³Hence, if an offer or answer does not containŠ², if it makes
the text more clear.

----

>-8, 2nd paragraph: Why are the 2 SHOULDs not MUSTs? Can you invision a
>scenario where it would make sense to not follow them?


I can¹t think of any scenario, so I am happy to use MUST.

----

>-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.)

See my reply to your comment on section 10.

----

>-- 4th paragraph from end of new text:
>should "the certificate fingerprint" say "a certificate fingerprint"?
>(Since you can have multiple fingerprints now...)

Yes. I will fix that.

----

>-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.

RFC 5763 contains 20+ references to RFC 4474, in a number of different
sections. 

We would have to update all of those sections (at least the reference,
possibly also normative text), because I don¹t think we should mix 4474
and 4474bis. In my opinion, that should be done as a separate task.


(I will reply to your editorial comments in a separate e-mail)

Regards,

Christer