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

[Christer Holmberg <[e-mail]>]

Hi Benjamin,

Thank You for the review! Please see inline.

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

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.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

>   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.

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

>   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 
> 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

>   +-----------------------+-------------------------------------------+
>   | Contact name:         | IESG                                      |
>   | Contact email:        | [e-mail]                             |
>   | 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"?

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