Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
draft-ietf-avtext-multicast-acq-rtcp-xr-06

It would have helped me as a reader to have had some idea of the range
of potential sizes of the random acquisition delay. I suspect that it
can be expressed in packets and extrapolated to a time interval based
on line speeds, etc. Obviously (?) if the range is 0 to < 1ms we might
conclude that this work is not very necessary.

Can you add a short note to help scope the work?

---

Section 3 says:

   This document uses the following acronyms and definitions from
   [I-D.ietf-avt-rapid-acquisition-for-rtp]:

But the definitions presented are somewhat different from those in 
the referenced document. Although the intent may be the same, I don't
think it is helpful to have different definitions and I recommend that
you remove all but a list of terms and a pointer to the other I-D.

---

Nit
Abstract                   
s/ore/or/

1) in 4.1, "Rsvd. (16 bits): The RTP receiver MUST set this bit to zero. The recipient MUST ignore this bit when received." - MUST ignore these bits or MUST ignore this field.
2) in 7.1, do you want to replcae or supplement the existing RFC#?
3) in 7.4, should 0, 255, and 128-254 be included in the registry with approrpiate notations?

In 4:

   It is better to send the MA report block after all the necessary
   information is collected and computed.  Partial reporting is
   generally not useful as it cannot give the full picture of the
   multicast acquisition, and causes additional complexity in terms of
   report block matching and correlation.  The MA report block is only
   sent as a part of an RTCP compound packet, and it is sent in the
   primary multicast session.

Is there a reason 2119 language was not used here? (i.e., SHOULD send
only after all information is collected, MUST send as part of an RTCP
compound packet in the primary multicast session)

In 4.2.1:

   o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
      of zero or the time difference (in ms) between the instant SFGMP
      Join message has been sent and the instant the first packet was
      received in the multicast session.  If the multicast join was
      successful, this element MUST be included.  If no multicast packet
      has been received, this element MUST NOT exist in the report
      block.

and

   o  Size of Burst-to-Multicast Gap (32 bits):  Optional TLV element
      that denotes the greater of zero or the difference between the
      sequence number of the first multicast packet (received from the
      primary multicast stream) and the sequence number of the last
      burst packet minus 1 (considering the wrapping of the sequence
      numbers).  If no burst packet has been received in the unicast
      session or no RTP packet has been received from the primary
      multicast stream, this element MUST NOT exist in the report block.

When could the "greater of zero or" part kick in? That is, when can the
difference possibly be negative?

Additional text describing the assumptions around when you would use a status code of zero would help greatly. The expected use is that the sender of a report would only use that code when it knew from out-of-band methods that the receiver would understand the private TLVs in the report - one of those private TLVs, ostensibly, would replace semantics of the status code. Saying that explicitly would help avoid the situation where a client unintentionally throws away information like "multicast join was successful" by adding a private TLV that the server doesn't understand to a report that it would otherwise have used a status code of 1 on.

Sec 4: r/The optional extensions that are/The OPTIONAL extensions that are 

Sec 4.2.1: r/Optional/OPTIONAL  x 9. For Types 1 and 2 - are they optional too?

(1) s/one ore more/one or more/

(C2 The constant 11 - I assume that's decimal - probably worth
saying just in case someone interprets it as '11'H or 3 or
whatever.

(C3 I think you want to to s/this bit/this field/g below.  

      o  Rsvd. (16 bits):  The RTP receiver MUST set this bit to zero.  The
      recipient MUST ignore this bit when received.

(4) Suggest rephrasing this in 4.2.1 (how can a time measured
locally be negative?)

OLD

  o  SFGMP Join Time (32 bits):  TLV element that denotes the greater
      of zero or the time difference (in ms) between the instant SFGMP
      Join message has been sent and the instant the first packet was
      received in the multicast session. 

NEW
  o  SFGMP Join Time (32 bits):  TLV element 
      with the time difference (in ms) between the instant the SFGMP
      Join message was sent and the instant the first packet was
      received in the multicast session.