Subject: [MMUSIC] Benjamin Kaduk's No Objection on draft-ietf-mmusic-msrp-usage-data-channel-23: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 17:53:08 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mmusic-msrp-usage-data-channel-23: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-msrp-usage-data-channel/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this easy read even for an MSRP neophyte; a relatively small
number of comments from me :)

Section 4.4

   An offerer and answerer SHALL include a dcsa attribute for each of
   the following MSRP-specific SDP attributes:

   o  defined in [RFC4975]: "path".

   o  defined in [RFC6714]: "msrp-cema".

   o  defined in [RFC6135]: "setup".  See Section 4.5

Some discussion of why "msrp-cema" and "setup" are mandatory for all
MSRP data-channel usage (noting that neither RFC 6714 nor RFC 6135 has
an "Updates:" relationship to RFC 4975, which might suggest that they
are independent extensions) might be helpful.  I see strong "MUST always
include an explicit a=setup attribute" in RFC 6135, with some
justification, but RFC 6714 is only using language like "attribute,
'msrp-cema', that MSRP endpoints use to indicate support of the CEMA
extension", which suggests that the extension is seen as an optional
thing.  (Is the CEMA requirement just to allow transparent use of a
gateway to a non-data-channel peer?  I guess the IANA considerations
mention "the routing of MSRP messages transported on a data channel is
more similar to the MSRP CEMA mechanism than the legacy MSRP routing
mechanism", which is reasonably compelling.)

Section 4.8

[obligatory griping about IPv4, SHA-1, date two years in the past, etc.]

Is there value in showing a corresponding SDP answer?

Do we want to say anything about backslash-wrapping of long lines for
readability (and/or reference draft-ietf-netmod-artwork-folding)?

Section 5.4

   message.  Therefore all sent MSRP chunks including the MSRP chunk
   header SHALL have lengths of less than or equal to the value of the
   peer's "a=max-message-size" attribute, which is associated with the
   data channel's SCTP association.

nit: perhaps the "including the MSRP chunk header" is better off being
applied to the lengths that are less than the message-size rather than
being indicated as a type of chunk.

Section 8

   Note that discussion in [RFC4975] on MSRP message attribution to
   remote identities applies to data channel transport.

nit: the phrase "message attribution" does not appear in RFC 4975,
though I do see just a single usage of "attribution" in Section 14.5
"Other Security Concerns", which seems like it matches up to what's
being discussed here.  Would a section reference in RFC 4975 help the
reader to locate the intended discussion?

Section 9.3

   +-----------------------+-------------------------------------------+
   | Contact name:         | IESG                                      |
   | Contact email:        | [email-masked]                             |
   | Attribute name:       | file-date                                 |
   | Usage level:          | dcsa(msrp)                                |
   | Purpose:              | Indicate a date related to the file in an |
   |                       | MSRP file transfer negotiation.           |
   | Reference:            | RFCXXXX                                   |
   +-----------------------+-------------------------------------------+

nit(?): should this be "one or more dates"?

Section 12.1

draft-ietf-rtcweb-data-protocols appears unreferenced other than the
changelog (which presumably is not normative, though I expect the RFC
Editor to just remove it entirely during publication).

We don't actually cite draft-ietf-mmusic-sctp-sdp anywhere that looks
like a normative manner, though the changelog says that this is
normative for use of the a=max-message-size attribute lines, so maybe
another citation or two is in order?

RFC 7977 is only mentioned in the Introduction as a thing that MSRP was
previously specified for, which hardly seems normative.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Aug 2020 13:45:23 +0000

Hi Benjamin,

Thank You for the review! Please see inline.

Section 4.4

> Some discussion of why "msrp-cema" and "setup" are mandatory for all MSRP data-channel usage (noting that neither RFC 6714 nor RFC 6135 has an "Updates:" relationship to RFC 4975, 
> which might suggest that they are independent extensions) might be helpful.  I see strong "MUST always include an explicit a=setup attribute" in RFC 6135, with some justification, but
> RFC 6714 is only using language like "attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension", which suggests that the extension is seen as an optional
> thing.  (Is the CEMA requirement just to allow transparent use of a gateway to a non-data-channel peer?  I guess the IANA considerations mention "the routing of MSRP messages transported
> on a data channel is more similar to the MSRP CEMA mechanism than the legacy MSRP routing mechanism", which is reasonably compelling.)

Section 4.4 does mention CEMA:

   "The MSRP data channel is established using the SDP offer/answer procedures defined
   in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel.
   This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714].

I guess I could enhance that, and say something like:

   "The MSRP data channel is established using the SDP offer/answer procedures defined
   in [I-D.ietf-mmusic-data-channel-sdpneg], and the MSRP messages are then transported on that data channel.
   This is different from legacy MSRP [RFC4975] but similar to MSRP CEMA [RFC6714]. Because of this, a dcsa embedded
   "msrp-cema" attribute is mandated for MSRP sessions over data channels.

I think Section 4.5 covers "setup":

   "As described in Section 4.4, the usage of a dsca embedded setup
   attribute is mandated for MSRP sessions over data channels.  It is
   used to negotiate which MSRP session endpoint assumes the active role
   as per Section 4.2.2 of [RFC6135] and Section 5.4 of [RFC4975]."

(Note to self: Quotes shall be added to setup: s/setup/"setup")

---

Section 4.8

> [obligatory griping about IPv4, SHA-1,

I will change it to IPv6.

> date two years in the past, etc.]

A reminder of how long we have been working with the draft... :)

I will update that date.

> Is there value in showing a corresponding SDP answer?

Well, at least it doesn't hurt, so I can add an SDP answer :)

>Do we want to say anything about backslash-wrapping of long lines for readability (and/or reference draft-ietf-netmod-artwork-folding)?

I can do that.

---

Section 5.4

> nit: perhaps the "including the MSRP chunk header" is better off being applied to the lengths that are less than the message-size rather than being indicated as a type of chunk.

RFC 4975 describes what an MSRP chunk is, so I suggest to remove "including the MSRP chunk header" part.

NEW:

    "Therefore all sent MSRP chunks SHALL have lengths of less than or equal to the value of the
     peer's "a=max-message-size" attribute, which is associated with the
     data channel's SCTP association."

---

Section 8

> nit: the phrase "message attribution" does not appear in RFC 4975, though I do see just a single usage of "attribution" in Section 14.5 "Other Security Concerns", which seems 
> ike it matches up to what's being discussed here.  Would a section reference in RFC 4975 help the reader to locate the intended discussion?

I can add a section reference.

NEW:

     "Note that discussion in Section 14.5 of [RFC4975] on MSRP message attribution to
      remote identities applies to data channel transport."

----

Section 9.3

Yes. Will fix as suggested.

---

Section 12.1

>draft-ietf-rtcweb-data-protocols appears unreferenced other than the changelog (which presumably is not normative, though I expect the RFC Editor to just remove it entirely during publication).

Yes, the change logs will be removed.

>We don't actually cite draft-ietf-mmusic-sctp-sdp anywhere that looks like a normative manner, though the changelog says that this is normative for use of the a=max-message-size attribute lines, so maybe another citation or two is in order?

First, draft-ietf-mmusic-sctp-sdp is already indirectly a normative reference, via the normative reference to draft-ietf-mmusic-data-channel-sdpneg.

Second, I could add a reference to draft-ietf-mmusic-sctp-sdp in Section 5.4:

   "SHALL have lengths of less than or equal to the value of the peer's "a=max-message-size" attribute [I-D.ietf-mmusic-sctp-sdp]"

(Note to self: s/"a=max-message-size attribute"/max-message-size attribute)

>RFC 7977 is only mentioned in the Introduction as a thing that MSRP was previously specified for, which hardly seems normative.

Well, RFC 7977 does define the WebSocket subprotocol value ('msrp'), which we also use for the MSRP data channel.

---

Regards,

Christer