Hello Russ, sorry for this late reply... thanks for reviewing the document! As to the points you raised in your review, I've added a couple of comments inline.
On Mon, 3 Oct 2016 15:26:30 -0400 Russ Housley <hous...@vigilsec.com> wrote: > 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 wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Document: draft-ietf-straw-b2bua-rtcp-13 > Reviewer: Russ Housley > Review Date: 2016-10-03 > IETF LC End Date: 2016-10-10 > IESG Telechat date: unknown > > Summary: Almost Ready > > > Major Concerns: I wonder if this ought to be a standards-track > document. I recognize that the STRAW WG charter calls for a > standards-track document, but it only contains a handfull of MUST > statements that are not repeats from another RFC. Maybe this > document should become a Best Current Practice (BCP) instead of a > standards-track document. > The standards-track scope of the document was also addressed and discussed on the STRAW ML before LC, you can find the related discussion here: https://www.ietf.org/mail-archive/web/straw/current/msg00579.html which lead to no objection to keep the document's scope as it is. Do you believe the scope should change nevertheless? > > Minor Concerns: In Section 3.1, it says: > > ... It SHOULD NOT, though, forward SDP > attributes that may lead to call failures (e.g., candidates, > fingerprints, crypto, etc.) for different reasons out of scope to > this document. ... > > This SHOULD NOT statement if a bit vague. The previous sentence lists > specific attributes, and I see why that might be difficult to match > here, but it does not tell an implementer what attributes to not > forward. > The SHOULD NOT statement is indeed a bit vague, but that's due to the dynamic nature of SDP attributes, and the fact that new ones could be added at any time. We tried to clarify what we meant by listing some of the categories that, messed with improperly, could cause issues (the candidates, fingerprints, crypto we mention in brackets), but an exhaustive list is unfortunately impossible. Do you believe that making the enumeration in brackets clearer, e.g.: (e.g., attributes listing candidates, fingerprints, crypto, etc.) would make the sentence clearer, or do you still think that would need work? Do you have any suggestion on how to improve the text here? Thanks! Lorenzo _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
