Message Session Relay Protocol (MSRP) over Data Channels
draft-ietf-mmusic-msrp-usage-data-channel-24

Thank you for making changes in response to the SECDIR review (and thank you to Alexey Melnikov for doing the review).

Like Rob, I thank Al Morton for the OpsDir review...

Thank you for the work put into this document esp. for the new authors as it appears that this document had a rough ride.

Please find below a couple of non-blocking COMMENTs.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

-- Section 1 --
"Compared to WebSockets, which provide...", I found no references to back up all claims about WebRTC (e.g., nothing about "telemetry"). Adding some informative references would help the reader.

-- Section 4.1 --
Out of curiosity, what does "dc" stands for ? Data-channel ? While not required, a short explanation would be nice to the reader.

-- Section 4.8 --
It is nice to have an example but using IPv4 in an example in 2020... humm.... a little bit outdated ? ;-)

-- Section 5.4 --
The rest of the document is about 'data channel' but this section uses 'SCTP stream'. AFAIK, they are the same in the WebRTC world but some consistent language would be better (as I am not a WebRTC expert, I can be wrong). Should SCTP be an informative reference?

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:        | iesg@ietf.org                             |
   | 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.

Thanks Al Morton for the Opsdir review and heads up.