Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)
RFC 4585

[Ballot comment]
in draft-ietf-avt-rtcp-feedback-08.txt on page 42, I see:
  Payload Type: 8 bits
      Indicates the RTP payload type in the context of which the
      native RPSI bit string MUST be interpreted.
The diagram shows that it is a 7-bit field though!

$ /bin/checkpage.awk

[Ballot comment]
Section 6.4 of draft-ietf-avt-rtcp-feedback-08.txt has
references to ITU-T and ISO standards for examples of where
application layer feedback messages can be drawn.  Are
there any IETF examples which can be given?  Both of the others require
a subscription or payment for the standard (though the
ITU allows a small number free, it is still essentially a paid
service).  If not, no big deal, but if there is one of our own standards
which can be cited in addition, it seems like a good idea.

[Ballot discuss]
In draft-ietf-avt-rtcp-feedback-08, I expected the Security Considerations
  discussion to include SRTP.

  In draft-burmeister-avt-rtcp-feedback-sim-05, delete section 2.  RFC 2119
  language is not used (or needed) in this document.  Also, a Security
  Considerations section needs to be added.

[Note]: 'The AD Review and the IETF Last Call started in parallel, with the authors/chairs taking the token for response to my comments at that time.  The AD Review comments call for some revisions.  They are available in the tracker log.' has been cleared by Allison Mankin

[Note]: 'The AD Review and the IETF Last Call started in parallel, with the authors/chairs taking the token for response to my comments at that time.  The AD Review comments call for some revisions.  They are available in the tracker log.' added by Allison Mankin

[Note]: 'The AD Review and the IETF Last Call started in parallel, with the authors/chairs taking the token for response to my comments at that time.  The AD Review comments call for some revisions.  They are available in the tracker log.' added by Allison Mankin

[Note]: 'The AD Review and the IETF Last Call are running in parallel.  The AD Review comments call for some revisions - they are available in the tracker log.' added by Allison Mankin

These comments are AD review - the IETF Last Call is started in parallel with my sending them.

The protocol is very careful to get the early feedback right so that it does not result in too much overhead.  The significance of  payload-specific feedback types are clear, but the significance of generic transport feedback types are much less clear.  Section 3.7.1 gives some reasonable guidance to future application designers, but beyond this, one has to ask questions:  What is the relationship of adding NACKs and ACKs to RTCP to the feedback when DCCP is used under  RTP - perhaps they could ultimately be complementary (anyway, there ought to be a little comparison with DCCP for perspective somewhere).  To what extent could any existing video or audio codecs  do something useful with NACK feedback  (e.g. the example in Section 4.4)?  To what extent would is the ACK for DTMF example in 4.4  realistic?  In Section 4, there's the statement that "if no "rtcp-fb" attribute is specified, the RTCP receivers SHOULD assume that the RTCP senders only support NACK".  Why?  Where does this come from?  What is fundamental about NACK in AVPF? 

Congestion discussion (Section 7):  this invokes a kind of SHOULD for TFRC from the recipient of the transport layer feedback, but with a too open description:    "[feedback of loss]...MUST NOT lead to a (mid-term) increase in the data transmission rate and SHOULD lead to a (short-term) decrease in the data transmission rate" - this approach to a TFRC-like behavior is a lot more lenient than TFRC.  Since the transport feedback material is really so much about congestion avoidance, and TFRC is the only congestion algorithm we know at this point or media streams, the spec must come closer to it.

Extensibility - for each of the feedback types, considerable effort in this spec goes into holding the bandwidth low while providing early, useful feedback.  Assuring this for future types will require some review.  Having the fb types be first-come-first-serve registrations at IANA without documentation is not going to maintain the design goal.  They should be RFC 2434 Specification Required.

Cite the SAVPF work-in-progress at the end of the Security Considerations to show it is not just an idea.

Nits:

"receivers SHOULD behave conservative"
                                                                          ^ly

Please run the ABNF through a checker - it is not  compliant with RFC 2234 - a pointer to a checker is given on the i-d  nits page.

For the Burmeister draft, the References should be renamed the Informative References.