Subject: [MMUSIC] AD Evaluation of draft-ietf-mmusic-rid-13

From: Ben Campbell <[email-masked]>
Date: Sat, 17 Feb 2018 18:52:50 -0600

Hi,

This is my AD evaluation of draft-ietf-mmusic-rid-13.

Thanks for your work on this document. It’s overall clear and readable. I have a few minor comments and nits that I think can be handled along with any IETF LC feedback. I will request the IETF Last Call shortly.

Thanks!

Ben.

————————

Minor Comments:

§11 and subsections: Any chance of at least one example that shows both an offer and the resulting answer?

§6.3:  It seems like step 3 might be better characterized as something to the effect of “The answerer MUST include the “rid-ID” field value that was present in the associated line in the offer.”

§12.2:  Which section(s) of 4566 give registration rules for registration of session-level and media-level attribute parameters?  (I had assumed that attribute parameter registration rules could vary per attribute, but could be mistaken.)  Also, doesn’t “ session-level and media-level” attributes include all attributes?

Do we need to perpetuate the questionable practice of requiring a phone number?

Editorial/Nits:

§2:
- Please mention the update to 4855 in the introduction (in addition to the mention in the abstract and IANA considerations.)

- I think it would be helpful to a reader new to the subject to add a sentence or two around what we mean by “restrictions” in context.

- Paragraph 1: Please consider quotes around names of existing attributes (e.g. “rtpmap” and “fmtp”)

- paragraph 2: Is “Streams” in “RTP Streams” capitalized on purpose?

- paragraph 3: Please don’t make the reader draw the conclusion that 7-bits means 128 distinct values.

§4:
- 3rd paragraph: “To be clear,” are null words. The antecedent for “it” is unclear in “ Such implementations MUST send it for all streams…"

- 4th paragraph: First sentence is convoluted; can it be broken into simpler sentences?

- 5th paragraph: “MAY (but need not)”: Isn’t that always true for a MAY?

- paragraph starting with 'The optional “pt=<fmt-list> “ … ‘: This paragraph starts a pattern of using a fields names as nouns. For example, ‘ The optional “pt=<fmt-list>” ‘ rather than ‘ The optional “pt-<fmt-list>” field’. I leave it to the editor to decide whether that’s okay, but I personally find it jarring.

§8.3: Extraneous comma before “ or other mechanisms.”

§12.1: Consider using the IESG as a contact, since WG lists come and go.  (I realize MMUSIC may be an exception and lots of registrations use it as the contact, but we should probably get away from that.). Also, MMUSIC has a phone number?  (I realize the template requires a phone number, sigh.)