Last Call Review of draft-ietf-mmusic-rid-14
review-ietf-mmusic-rid-14-genart-lc-sparks-2018-02-27-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-mmusic-rid-14
Reviewer: Robert Sparks
Review Date: 2018-02-27
IETF LC End Date: 2018-03-30
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with nits

Nits:

I could see implementor disagreement around what's allowed when modifying a
session driven by the statement in the introduction that "They do not relax any
existing descriptions." (where "They" here are the restrictions communicated
with this attribute). Please look for a way to make it clear that an updating
offer-answer round _can_ result in fewer restrictions than the original round
did, just not fewer restrictions than the description places on the media if
the "rid" extension is not present.

(Micronit): I don't think the "To be clear" in the first paragraph on page 5
helps. I also worry that "it" may not have a clear meaning in "Such
implementations must send it" later in that paragraph.

At the description of max-bpp on page 7, the last sentence is awkward. Do you
perhaps mean "These values MUST NOT be encoded with more than four digits to
the right of the decimal point."?

In the second paragraph of section 6, "its own unique 5-tuple" is arcane if the
reader hasn't read the rest of the rtcweb work. Could you provide a description
or a pointer to a description here?

At section 6.3, where you say 'For each "a=rid" line:', should you say 'For
each "a=rid" line that has not been discarded by the requirements in section
6.2:'?

I found "a non-empty union" to be a confusing description of the condition you
are trying to convey in section 8. (A union of two sets, at least one of which
is not empty is going to be non-empty). I'm not sure intersection is the right
word here either. Perhaps you could find a different way to characterize the
condition?

The BNF for rid-id allows rid-ids like "This-is_my-favorite" or
"Gm-Cqzkj4VHVD". But all the examples use single digits for rid-ids. I see the
statement that "the actual identifiers used for RIDs are expected to be
opaque". I strongly encourage putting some opaque ones in the examples.

Consider reminding people that ABNF quoted strings are case-insensitive, and
that the grammar as written will allow things like "MaX-WiDtH" and "rECv". If
that's not what you want, consider bringing in RFC7405.