Robert, thanks for your review. I have entered a No Objection ballot and flagged your comments to the authors.
Alissa > On Feb 27, 2018, at 3:54 PM, Robert Sparks <rjspa...@nostrum.com> wrote: > > Reviewer: Robert Sparks > Review result: Ready with Nits > > 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. > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
