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

[Benjamin Kaduk via Datatracker <[e-mail]>]

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:        | [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"?

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.