[MMUSIC] draft-holmberg-mmusic-sdp-dtls-00

[Paul Kyzivat <[e-mail]>]

(Resending. I initially sent to wrong address.)

Christer, I'm glad that you have submitted this document - it is needed. 
I have a few comments.

Section 5.1 starts out talking about the 'connection' attribute, but 
gives no reference. There should be a reference to RFC4145.

In section 6.3:

In the 2nd sentence ("The same...'new'...) *that* occurrence of 'new' 
should be 'existing'.

Then the following paragraph:

    If the answerer does not accept the establishment (or re-
    establishment) of the DTLS association, it MUST reject the offer
    [RFC3264].

isn't right. The answerer may reject the m-line while still accepting 
the offer. (I expect that is what was intended, but it doesn't say that.)

I'd also like to dig a bit more into forking. As noted in section 4.5, 
if forking occurs, then separate DTLS associations will be made with 
each callee. In this case, those distinct DTLS associations will share 
common host candidates. (Can they also end up sharing some relay 
candidates?) Yet the 5-tuples will differ.

Now, suppose that the same endpoint then needs to make a change. For 
instance, maybe it needs to change its fingerprint. In this case it 
needs to create new DTLS associations. In that case it must also use new 
host candidates. Is it permitted to use the same (new) candidates to 
recreate *both* DTLS associations? I can't see any reason why not. I 
also don't see any specific prohibition in the text. But it would be 
good to be explicit about it.

	Thanks,
	Paul