Subject: Re: [MMUSIC] Publication has been requested for draft-ietf-mmusic-msrp-usage-data-channel-20

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 5 Jul 2020 23:54:42 -0700

Sorry for the delay in getting this reviewed.  I've gone through it and
found a few small things to fix that won't hold it up, but there's one
larger thing I need to understand before I send it to Last Call:

Should Section 2 use the newer BCP 14 boilerplate?  You don't have to,
strictly speaking, but it's common practice these days.

The sole sentence in Section 4 is missing a period.

The bottom paragraph of Section 4.1 seems like it should be broken into
more sentences.

In Section 9.2:

OLD:

    This document adds a reference to the...

NEW:

    A reference to this document is added to the ...

Section 9.3 seems like the biggest area of concern to me.  Maybe I'm
misreading what it says, but:

1) The second paragraph of Section 9.3 makes it sound like you want IANA to
add these things only when they are used a certain way.  If I'm right about
that, it probably needs to be reworded, and maybe that protocol-specific
prose moved elsewhere, perhaps the referenced Section 4.4.

2) Also, since the full registry entries are all there, do we need that
bulleted list?

3) Finally, in looking at the current SDP Parameters registry (
https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml), I
don't understand what Section 9.3 is asking for.  Is it supposed to create
a new sub-registry, or a collection of them, or make entries in an existing
one?  None of the existing sub-registries on that page look like these
templates (e.g., only one of them has a "Usage Level" column, but the
templates are all missing the MUX details).  How does this reconcile
against the current registries (registered per RFC 4566), or Section 8.2 of
draft-ietf-mmusic-rfc4566bis?

Thanks for all the work you've put into this already!

-MSK

On Tue, Jun 30, 2020 at 8:25 AM Bo Burman via Datatracker <[email-masked]>
wrote:

> Bo Burman has requested publication of
> draft-ietf-mmusic-msrp-usage-data-channel-20 as Proposed Standard on behalf
> of the MMUSIC working group.
>
> Please verify the document's state at
> https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 6 Jul 2020 17:56:44 +0000

Hi Murray,

Please see inline.

>Sorry for the delay in getting this reviewed.  I've gone through it and found a few small things to fix that won't hold it up, but there's one larger thing I need to understand before I send it to Last Call:
>
>Should Section 2 use the newer BCP 14 boilerplate?  You don't have to, strictly speaking, but it's common practice these days.

We will use the newer boilerplate.

---

>The sole sentence in Section 4 is missing a period.

Will fix.

---

>The bottom paragraph of Section 4.1 seems like it should be broken into more sentences.

I suggest to split the sentence at the second comma:

OLD:

   MSRP design provides for new transport bindings, see Section 6 of
   [RFC4975], MSRP implementations are expected to allow unrecognized
   transports for which there is no need to establish a connection to
   the resource described by the URI, as it's the case of data channels
   (Section 4.4).

NEW:

   MSRP design provides for new transport bindings (see Section 6 of
   [RFC4975]). MSRP implementations are expected to allow unrecognized
   transports for which there is no need to establish a connection to
   the resource described by the URI, as it's the case of data channels
   (Section 4.4).

---

>    A reference to this document is added to the ...

Will fix as suggested.

---

>Section 9.3 seems like the biggest area of concern to me.  Maybe I'm misreading what it says, but:
>
>1) The second paragraph of Section 9.3 makes it sound like you want IANA to add these things only when they are used a certain way.  If I'm right about that, it probably needs to
>be reworded, and maybe that protocol-specific prose moved elsewhere, perhaps the referenced Section 4.4.
>
>2) Also, since the full registry entries are all there, do we need that bulleted list?
>
>3) Finally, in looking at the current SDP Parameters registry (https://www.iana.org/assignments/sdp-parameters/sdp-parameters.xml), I don't understand what Section 9.3 is asking for.
>Is it supposed to create a new sub-registry, or a collection of them, or make entries in an existing one?  None of the existing sub-registries on that page look like these templates (e.g., only
>one of them has a "Usage Level" column, but the templates are all missing the MUX details).  How does this reconcile against the current registries (registered per RFC 4566), or
>Section 8.2 of draft-ietf-mmusic-rfc4566bis?

We are not creating a new sub-registry.

We previously agreed to add “dcsa(<protocol>)” to the ‘Usage Level’ column for SDP attributes that can be used together with SDP ‘dcsa’ attributes.

We are using the same terminology as in https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-14.txt (Sections 9.2., 9.3. and 9.4), and in the registry you can see that ‘dcsa(t140)’ has been added to the ‘Usage Level’ column for SDP attributes that can be used together with an SDP dcsa attribute associated with a T.140 data channel.

Having said that, I do agree that the “adds a reference” text in the second paragraph might be confusing. I suggest to modify the text, and combine the 2 first paragraphs into a single paragraph:

OLD:

   This document modifies the usage of the SDP setup attribute, if this
   attribute is included in an SDP 'dcsa' attribute associated to an
   MSRP data channel.  The modified usage is described in Section 4.5.

   This document also adds a reference to the following attributes in
   the Session Description Protocol (SDP) Parameters registry, if these
   attributes are included in SDP 'dcsa' attributes associated to an
   MSRP data channel.  Usage of these attributes is described in section
   Section 4.4:

NEW:

   This document modifies the usage of a set of SDP attributes, if any of those
   attributes is included in an SDP ‘dsca’ attribute associated with an
   MSRP data channel. The modified usage of the SDP ‘setup’ attribute is
   described in Section 4.5. The usage of the other SDP attributes is described
   in Section 4.4.

Regards,

Christer

On Tue, Jun 30, 2020 at 8:25 AM Bo Burman via Datatracker <[email-masked]<mailto:[email-masked]>> wrote:
Bo Burman has requested publication of draft-ietf-mmusic-msrp-usage-data-channel-20 as Proposed Standard on behalf of the MMUSIC working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 6 Jul 2020 22:17:38 -0700

On Mon, Jul 6, 2020 at 10:56 AM Christer Holmberg <
[email-masked]> wrote:

> We previously agreed to add “dcsa(<protocol>)” to the ‘Usage Level’ column
> for SDP attributes that can be used together with SDP ‘dcsa’ attributes.
>
>
>
> We are using the same terminology as in
> https://www.ietf.org/id/draft-ietf-mmusic-t140-usage-data-channel-14.txt
> (Sections 9.2., 9.3. and 9.4), and in the registry you can see that
> ‘dcsa(t140)’ has been added to the ‘Usage Level’ column for SDP attributes
> that can be used together with an SDP dcsa attribute associated with a
> T.140 data channel.
>
>
>
> Having said that, I do agree that the “adds a reference” text in the
> second paragraph might be confusing. I suggest to modify the text, and
> combine the 2 first paragraphs into a single paragraph:
>
>
>
> OLD:
>
>
>

Yes, this is better, thank you!  It might help further to mention
specifically that you're updating the "att-field" sub-registry of the
Session Description Protocol (SDP) Parameters registry.

With that and the minor other things all cleared up, I'm going to go
prepare the Last Call request.  Please post a revision update at your
convenience.

-MSK

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Jul 2020 09:00:42 +0000

Hi,

Version -21 submitted.

Regards,

Christer

From: Murray S. Kucherawy <[email-masked]>
Sent: tiistai 7. heinäkuuta 2020 8.18
To: Christer Holmberg <[email-masked]>
Cc: Bo Burman <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Publication has been requested for draft-ietf-mmusic-msrp-usage-data-channel-20

On Mon, Jul 6, 2020 at 10:56 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
We previously agreed to add “dcsa(<protocol>)” to the ‘Usage Level’ column for SDP attributes that can be used together with SDP ‘dcsa’ attributes.

OLD:

NEW:

Yes, this is better, thank you!  It might help further to mention specifically that you're updating the "att-field" sub-registry of the Session Description Protocol (SDP) Parameters registry.

With that and the minor other things all cleared up, I'm going to go prepare the Last Call request.  Please post a revision update at your convenience.

-MSK