Re: Alexey Melnikov's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

Hi Christer,

On Mon, Aug 14, 2017, at 06:15 PM, Christer Holmberg wrote:
> Hi Alexey,
> 
> Thank You for the review! Please see inline.
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> >This is a fine document, but I have one [hopefully easy to answer] question and a couple of other minor ones:
> >
> >In Section 5.1.  General
> >
> >   Endpoints MUST support the cipher suites as defined in [RFC8122].
> >
> >I don't see any ciphers specified in that RFC. Can you clarify what you mean?
> 
> It refers to the text about hash functions in section 5 of 8122.
> 
> Perhaps I should say "hash functions" instead?

Yes, these are different things :-).

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> >8.  TLS Considerations
> >
> >   NOTE: Even though the SDP 'connection' attribute can be used to
> >   indicate whether a new TLS connection is to be established, the
> >   unique combination of SDP 'tls-id' attribute values can be used to
> >   identity a TLS connection.  The unique value can be used e.g., within
> >   TLS protocol extensions to differentiate between multiple TLS
> >   connections and correlate those connections with specific offer/
> >   answer exchanges.
> >
> > Are any such extensions defined or in the process of being standardized?
> 
> Martin T has written the following draft, which was recently WG adopted:
> 
> https://tools.ietf.org/id/draft-ietf-mmusic-sdp-uks-00.txt

I suggest you add an Informative reference to this draft. Such reference
will not delay publication, but might still be useful to readers.

> However, we did not want to create a MISREF by referencing it in
> draft-dtls-sdp.
> 
> >   If an offerer or answerer receives an offer/answer with conflicting
> >   attribute values, the offerer/answerer MUST process the offer/answer
> >   as misformed.
> >
> > I think a pointer to document and section where such handling is specified would be useful here.
> 
> There is no single solution defined (it often depends on the attribute),
> and we normally try to specify such procedures, as they may vary
> depending on implementation, use-case etc.

Ok. I was hoping there was a single prescribed behaviour in this case.

Best Regards,
Alexey