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

[Paul Kyzivat <[e-mail]>]

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.

* 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;

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

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

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

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

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

That is all I found. I think it is almost done.

	Thanks,
	Paul

> On 2/5/16 11:29 AM, Flemming Andreasen wrote:
>> Greetings MMUSIC
>>
>> This is to announce a 2 week WGLC on the  draft:
>>
>>       https://www.ietf.org/id/draft-ietf-mmusic-dtls-sdp-06.txt
>>
>> as Proposed Standard. Please review and provide any comments you may
>> have on the document by Friday, February 19, 2016. Comments should be
>> sent to the document authors and the MMUSIC WG list. If you review the
>> document but do not have any comments, please send a note to that
>> effect as well.
>>
>> Thanks
>>
>> -- Flemming (MMUSIC co-chair)
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>> .
>>
>
>