Re: [MMUSIC] Draft new version: draft-ietf-mmusic-dtls-sdp-02

[Martin Thomson <[e-mail]>]

The conditions for " modification requires a new DTLS association"
might need to be more clearly spelled out.  I think that this is based
on some sort of local constraint, but you should say as much.

Section 2 can be removed.

I think that the definition of fingerprint change is problematic.  I
think that you should require that a partial change to the set of
fingerprints is also accompanied by signaling rather than mandating a
new DTLS connection.  If - for example - a fingerprint that is not in
use is removed, then I think that some existing implementations will
expect to continue.

I don't like the cipher suite requirements.  They don't match those
for WebRTC for starters.  I'd prefer to see them excised.  I'd be OK
with a recommendation to prefer forward secrecy or even to require it.

I don't mind the fingerprint requirements (SHA-256 and the must match
rule).  I'm not sure how others feel about restating 5763
requirements, though I think that this is OK.

"It is considered an error case if the answer contains a
'dtls-connection' attribute with an 'existing' value, and a DTLS
association does not exist." -- What do you expect someone to do in
this case?

You missed the most important consideration: when running a second
DTLS association over the same transport, it is difficult to
distinguish between the first and second association because DTLS
packets don't identify themselves externally [4].  This point is
important enough to include in the intro in my opinion, though I would
also add a sub-section to Section 4 explaining this in more detail.

I'm not sure about 8.1.  I think that a key insight here is that the
connection-oriented transport might not be end-to-end.  That suggests
that multiple DTLS associations can be established.  Based on that,
you might suggest that connection-oriented transports are no different
to any other transport.

I found Section 10 basically impossible to parse: patches like this
are very hard to read and it's half the document!  I'd rather have a
short statement identifying the nature of the changes.  I think that
the 5245 change is incorrect though because it loses some important
details.

Nits:
In 6.3: "and determines (based on the criteria for establishing a new
DTLS association)" needs a reference.

In 6.4: "if the offerer becomes DTLS client, the offerer MUST
establish a DTLS association." Might be worth mentioning that this is
based on a=setup.

[4] Unless you are lucky enough to have different epochs, but don't do
that.  Ever.

On 8 December 2015 at 18:48, Christer Holmberg
<[e-mail]> wrote:
> Hi,
>
>
>
> A new version (-02) of draft-ietf-mmusic-dtls-sdp-02 has been submitted.
>
>
>
> Note that this version now suggests updates to RFC 5763 (SRTP-DTLS) and RFC
> 7341 (UDPTL-DTLS), so I encourage people to take a look.
>
>
>
> In addition, there is some new text about re-using connection-oriented
> (read: acknowledged packet delivery) for establishing a new DTLS
> association.
>
>
>
> You can also find the document on github:
> https://github.com/cdh4u/draft-dtls-sdp
>
>
>
> (NOTE: This is my personal repo, as I am not aware of any “official” MMUSIC
> repo)
>
>
>
> Regards,
>
>
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>