Re: [MMUSIC] WGLC on draft-ietf-mmusic-dtls-sdp-06.txt

[Christer Holmberg <[e-mail]>]

Hi Paul,

Once again, thank you for a good review. See inline.

>I went through the full draft (-08) again, not just the diffs. I found a few things:
>
>* Intro:
>
> Reading the intro I would jump to the conclusion that the primary reason for this draft is to define the way for 
> explicitly signaling a new association. While this is important, I don't think it is *the* reason. 
> Rather, IIUC, the reason is to centralize DTLS negotiation procedures for many protocols that require it.

We tried to cover that in the first paragraph of the Introduction, but I guess some additional text could be added. E.g.:

   "[RFC5763] defines SDP Offer/Answer procedures for SRTP-DTLS.  [RFC7345]
   defines SDP Offer/Answer procedures for UDPTL-DTLS. This specification
   defines general Offer/Answer procedures for DTLS. Other specifications,
   defining specific DTLS usages, can then reference this specification, in order
   to ensure that the DTLS aspects are common among all usages. Having
   common procedures is essential when multiple usages share the same
   DTLS association [referene-to-BUNDLE]."

--------------------

> * Section 3.1:
>
> The third bullet is:
>
>    o  The establishment of a new DTLS association is explicitly
>       signaled;
>
> ISTM that this isn't quite right. I think it should say:
>
>    o  The desire/intent to establish of a new DTLS association is
>       explicitly signaled;

I'll look into that, but your suggestion seems ok.

--------------------

>* Section 4:
>
>    A 'dtls-connection' attribute value of 'new' indicates that a new
>    DTLS association MUST be established.  A 'dtls-connection' attribute
>    value of 'existing' indicates that a new DTLS association MUST NOT be
>    established.
>
> The 2nd sentence above isn't entirely true. It is contradicted by section 5.3:
>
>    ... or if the answerer receives
>    an offer that contains an 'dtls-connection' attribute with an
>    'existing' value and the answerer determines (based on the criteria
>    for establishing a new DTLS association) that a new DTLS association
>    is to be established, the answerer MUST insert a 'new' value in the
>    associated answer.
>
> IMO 5.3 must prevail here, because the answerer may not agree that there is an existing connection to reuse. So the working in section 4 should change. How about:
>
>    ... A 'dtls-connection' attribute
>    value of 'existing' indicates a preference to reuse an existing
>    association.

I'll look into that, but your suggestion seems ok.

--------------------

>* Section 5.1:
>
>    The certificate received during the DTLS handshake MUST match the
>    fingerprint received in the SDP "fingerprint" attribute.  If the
>    fingerprint does not match the hashed certificate, then the endpoint
>    MUST tear down the media session immediately.  ...
>
> This talks about *the* fingerprint. But, IIUC, multiple fingerprints may be supplied. What is the required processing in that case?

We try to clarify that in section 3.4, which says:

   "It is possible to associate multiple SDP fingerprint attribute values
   to an 'm-' line.  If any of the attribute values associated with an
   'm-' line are removed, or if any new attribute values are added, it
   is considered a fingerprint value change."

--------------------

>* Section 5.3:
>
>If the offer specified 'existing' but the answerer changes to 'new', should the setup attribute settings remain as they had been? (Which then determines which end sends the ClientHello message.)

Not sure I understand. If a new DTLS association is to be established, shouldn't it be allowed to re-negotiate the roles (read: change the value of the 'setup' attribute)?

>What should be done if the offer doesn't contain a setup attribute?

We assume the default value, which is "active" (RFC 4145).

The text says that the setup value is included "according to the procedures in [RFC4145]", but we could always include a note saying what the default value is.

--------------------

> * Section 9.2 (NEW TEXT)
>
>    The far endpoint (answerer) may now establish a DTLS association with
>    the offerer.  Alternately, it can indicate in its answer that the
>    offerer is to initiate the TLS association.  ...
>
> Why does this first say DTLS and then use TLS? IIUC they should both be DTLS.

Correct.

--------------------

NEW COMMMENT:

In addition, I noticed that the document uses "DTLS connection" terminology in a few places, while the intention is to use "DTLS association" (which is also used in the RFCs we update).

The question is whether the name of the SDP attribute should still be "dtls-connection", or whether we should change it to "dtls-association". My personal preference would be to keep the "dtls-connection" name, but I can live with both.


Regards,

Christer