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

[Paul Kyzivat <[e-mail]>]

Hi Christer,

I do have a few things that should be addressed before or as part of WGLC:

* Section 5.2 ABNF:

I would like to see this formatted following the template from 
rfc4566bis. That seems to call for jiggering the section structuring. E.g.:

    5.  SDP dtls-connection Attribute

    The SDP 'connection' attribute [RFC4145] was originally defined for
    connection-oriented protocols, e.g.  TCP and TLS.  This section
    defines a similar attribute, 'dtls-connection', to be used with DTLS.

       Name: dtls-connection

       Value: conn-value

       Usage Level: media

       Charset Dependent: no

       Syntax:

           conn-value = "new" / "existing"

       Example:

           a=dtls-connection:existing

    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.

    Unlike the SDP 'connection' attribute for TLS, there is no default
    value defined for the 'dtls-connection' 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 an
    attribute, other means needs to be used in order for endpoints to
    determine whether an offer or answer is associated with an event that
    requires the DTLS association to be re-established.

    The SDP Offer/Answer [RFC3264] procedures associated with the
    attribute are defined in Section 6

* Section 6.1 (General O/A procedures)

The 1st note (paragraph 2) seems intended as something temporary. Did 
you intend it to remain? If so, instead of saying "based on" it would be 
better to say "compatible with". Since this draft revises 5763,

    NOTE: The procedures in this section are generalizations of
    procedures first specified in SRTP-DTLS [RFC5763], with the addition
    of usage of the SDP 'dtls-connection' attribute. That document is
    herein revised to make use of these new procedures.

ISTM that the 2nd note:

    NOTE: The SDP 'connection' attribute may be used if the usage is
    associated with another protocol layer, e.g.  SCTP or TCP, used
    together with DTLS.

should not be a note. And the "may" should be changed to MAY, making 
this a normative statement - an exception to the MUST NOT in the prior 
paragraph.

* Section 12 (IANA Considerations)

Since there is only one IANA action, section 12.1 can be collapsed into 
section 12.

	Thanks,
	Paul


On 12/8/15 2:48 AM, Christer Holmberg 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
>