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

Both work for me.

Thanks!
Ben.

> On Mar 14, 2017, at 3:07 PM, Christer Holmberg <[email protected]> wrote:
> 
> Hi,
> 
> 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.
>> 
>> You would still get a sentence of the form "If not foo, then not foo." 
>> Perhaps the predicate clause could be recast as the consequences or (high level) receiver behavior 
>> when dtls-id not being present? Does the absence mean that the session is not setup? That the receiver assumes 
>> the sender is a legacy implementation?
> 
> That the receiver assumes the sender is a legacy implementation.
> 
> Maybe something like:
> 
>   "No default value is defined for the SDP 'dtls-id' attribute.
>   Implementations that wish to use the attribute MUST explicitly
>   include it in SDP offers and answers.  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), unless there is
>   another mechanism to explicitly indicate that a new DTLS association
>   is to be established, a modification of one or more of the following
>   characteristics MUST be treated as an indication that an endpoint
>   wants to establish a new DTLS association:" 
> 
> ...
> 
>>>> -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 scanned 5763 for the references to see if we could reasonably say that all references should be updated. 
>> But there's some text on the limitations of identity for phone numbers that might become obsolete if we did that.
>> SO I can be convinced to leave that out of scope for this update. But it's still a bit unfortunate :-)
>> 
>> Would it make sense for this document to contain a paragraph somewhere mentioning that, since the publication 
>> of 5763, RFC4474 is being updated to address some of those issues, and that implementors should at least consider 
>> moving to it? The reason I push on this is that I have hopes that 4474bis can enable the dtls-srtp framework to be 
>> used in a more secure fashion that typical for now, since we have such limited deployment of 4474.
> 
> "NOTE: Since the publication of RFC 5763, RFC 4474 has been obsoleted by draft-ietf-stir-4474bis. The updating of the references (and the
> associated procedures) within RFC 5763 is outside the scope of this document. However, implementers of RFC 5763 applications are 
> encouraged to implement draft-ietf-stir-4474bis instead of RFC 4474."
> 
> Feel free to modify, if you e.g., want to give more background etc about 4474bis.
> 
> Regards,
> 
> Christer
> 

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic