Guidelines for End-to-End Support of the RTP Control Protocol (RTCP) in Back-to-Back User Agents (B2BUAs)
draft-ietf-straw-b2bua-rtcp-17

I agree with Alissa that the set of attributes that fall into each category is just not clear or fully specified.
I'm not sure about better wording - but at least indicating how to categorize the different attributes (if listing them
all isn't reasonable) would help.  Describing the category as "those that cause issues"' is not helpful.

Thanks for addressing my comments.

[1] As I understand it, a Media-Aware Relay is an instance of a RTP/RTCP translator.  I'm wondering whether the behavior in 3.2 can/should be more broadly applied to other types of translators, and not just to a media-aware B2BUA.   ??   [Disclaimer:  I am out of my depth here...]

[2] The guidelines in 3.2 have a normative "MUST" attached to them: "...a media-aware B2BUA MUST handle incoming RTCP messages to forward following this guideline".  However, some of the references are not Normative.  I assume that (as with the guidelines related to RFC3550) the text in 3.2 represents a behavior beyond what is described in the references, which implies to me that those references should be Normative.  The solution seems simple: move rfc3611, rfc5104, etc. to be Normative references...but I-D.alvestrand-rmcat-remb is also referenced, which not only expired 3 years ago, but it is marked as Experimental.  Can the expected behavior from I-D.alvestrand-rmcat-remb be somehow defined in this document so that the reference is not needed?

Two points were raised by Russ Housley's Gen-ART review. On the first one, I plan to watch the resolution of the Discusses related to the unclear SHOULD NOT. (It certainly would have been a Discuss from me if a Discuss wasn’t already raised.) On the second point regarding the document class, I have noted the issue but don't plan on block document based on it. Looking forward to further discussion if people want to argue it.

High level comment:
This document mainly talks about cases where the SSRC or the RTP seq# is changed. Are they no other fields that could be changed as well? Would there need to be additional guidance (in 3.2) then, or are SSRC and seq# more special then other fields? And why would a relay change those fields? Wouldn't it be appropriate to give the guidance somewhere that those fields SHOULD NOT be changed!?!

Smaller comments:

section 3.1:
"Apart from the
   mentioned attributes, B2BUAs SHOULD forward all other SDP attributes
   they don't have a reason not to forward, in order to avoid breaking
   additional functionality endpoints may be relying on."
Shouldn't that be a MUST (with all the exceptions given already)...?

"...a B2BUA MAY rewrite CNAME items if any potential collision
   is detected..."
And why is that a MAY? Shouldn't this be a SHOULD at least?

Thanks for responding to Magnus's thorough TSV-ART review (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00111.html). 

I'm inclined to agree with the resolutions you've proposed (for reference, https://www.ietf.org/mail-archive/web/tsv-art/current/msg00112.html), but I do have one question - given that you want to include REMB, because it's deployed in Chrome and Firefox, and given that https://datatracker.ietf.org/doc/draft-alvestrand-rmcat-remb/ hasn't moved in three years and RMCAT is doing something else, what's your plan for publishing this draft as an RFC that's not stuck in MISSREF forever?

Thanks for handling my discuss point. Sorry for being a 
bit slow in clearing that.

- The security considerations section is (still!) pretty good,
thanks!