Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-13

[Lorenzo Miniero <[e-mail]>]

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 <[e-mail]> 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