Message Session Relay Protocol (MSRP) over Data Channels
Note: This ballot was opened for revision 23 and is now closed.
Murray Kucherawy Yes
(Deborah Brungard) No Objection
(Alissa Cooper) No Objection
Roman Danyliw No Objection
Comment (2020-08-12 for -23)
Thank you for making changes in response to the SECDIR review (and thank you to Alexey Melnikov for doing the review).
Martin Duke No Objection
Benjamin Kaduk No Objection
Comment (2020-08-10 for -23)
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@example.com | | 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.
Erik Kline No Objection
Warren Kumari No Objection
Comment (2020-08-11 for -23)
Like Rob, I thank Al Morton for the OpsDir review...
(Barry Leiba) No Objection
Alvaro Retana No Objection
Éric Vyncke No Objection
Comment (2020-08-03 for -23)
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?
Robert Wilton No Objection
Comment (2020-08-10 for -23)
Thanks Al Morton for the Opsdir review and heads up.