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

Note: This RFC has been updated by RFC 5506, RFC 8108

Errata ID: 768
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17

Errors (1)-(10) of 19

(1)

Section 1.1 of RFC 4585, on mid-page 4, says:

   Feedback (FB) message:
      An RTCP message as defined in this document is used to convey
      information about events observed at a receiver -- in addition to
      long-term receiver status information that is carried in RTCP
      receiver reports (RRs) -- back to the sender of the media stream.
|     For the sake of clarity, feedback message is referred to as FB
|     message throughout this document.

I do not see how and why using the abbreviation might have improved
*clarity* of the text; apparently, it has been used for *brevity* .
Therefore, the two tagged lines should better say:

|     For the sake of brevity, feedback message is referred to as FB
|     message throughout this document.

Similarly, at the bottom of page 4, where the RFC says:

   Feedback (FB) threshold:
      The FB threshold indicates the transition between Immediate
      Feedback and Early RTCP mode.  [...]
      [...]
      to application designers and is not used in any calculations.  For
|     the sake of clarity, the term feedback threshold is referred to as
      FB threshold throughout this document.

The last 3 lines should better say:

      to application designers and is not used in any calculations.  For
|     the sake of brevity, the term feedback threshold is referred to as
      FB threshold throughout this document.


(2)

The first bulleted item in Section 3.1, on page 7, says:
                                                    vvvvvvvvvvvvv
|  o  Status reports are contained in sender report (SR)/received report
      (RR) packets and are transmitted at regular intervals as part of
      compound RTCP packets (which also include source description
      (SDES) and possibly other messages); these status reports provide
      an overall indication for the recent reception quality of a media
      stream.

For *clarity*, it perhaps should better say -- not binding together the
words intended to being separated by the slash marking the alternative:
                                                        vvv
|  o  Status reports are contained in sender report (SR) / received
      report (RR) packets and are transmitted at regular intervals as
      part of compound RTCP packets (which also include source
      description (SDES) and possibly other messages); these status
      reports provide an overall indication for the recent reception
      quality of a media stream.


(3)  [missing article]

In Section 3.4, on mid-page 11, RFC 4585 says:

   j) Let T_fd be the actual (randomized) delay for the transmission of
      FB message in response to an event at time t0.

It should say:

   j) Let T_fd be the actual (randomized) delay for the transmission of
|     a FB message in response to an event at time t0.
      ^^

(4)  [inappropriate wording]

The algorithm in Section 3.5.2, at the bottom of page 16, contains
the sub-step:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random function evenly distributed between 0 and 1.
                        ^^^^^^^^

This wording is inappropriate.  RND is not a *function* (that's code!),
but a *number*, the function *value*.  Therefore, the RFC should say:

      4b) If allow_early == TRUE, then R MUST schedule an Early RTCP
          packet for te = t0 + RND * T_dither_max with RND being a
|         pseudo random number evenly distributed between 0 and 1.
                        ^^^^^^


(5)  [inappropriate wording]

The algorithm in Section 3.5.3, at the top of page 19, says:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random function evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:

Similar to item (4) above, the RFC should say instead:

   2. Otherwise, a temporary value T_rr_current_interval is calculated
      as follows:

         T_rr_current_interval = RND*T_rr_interval

|     with RND being a pseudo random number evenly distributed between
      0.5 and 1.5.  This dithered value is used to determine one of the
      following alternatives:


(6)  [typo / dup. wording]

Section 3.6.2 of RFC 4585, on mid-page 21, says:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit in into one packet leading to a packet rate of
   30 packets per second.  [...]

It should say:

   Example: If a 256-kbit/s video with 30 fps is transmitted through a
   network with an MTU size of some 1,500 bytes, then, in most cases,
|  each frame would fit into one packet leading to a packet rate of
   30 packets per second.  [...]


(7)  [wrong ref. tag]

On mid-page 23, Section 4.1 of RFC 4585 says:

                             vvv
|  The AV profile defined in [4] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".

There apparently is a confusion of the ref. tags used.
The RFC should say:
                             vvv
|  The AV profile defined in [2] is referred to as "AVP" in the context
   of, e.g., the Session Description Protocol (SDP) [3].  The profile
   specified in this document is referred to as "AVPF".


(8)  [missing article]

In Section 4.2, near the top of page 25, the ABNF production:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in SDP spec

should better say, improving the ABNF comment text:

      rtcp-fb-pt         = "*"   ; wildcard: applies to all formats
|                        / fmt   ; as defined in the SDP spec
                                                ^^^^^


(9)  [inconsistent specification]

In Section 4.2, the ABNF on page 25 contains the following productions:

      rtcp-fb-val        = "ack" rtcp-fb-ack-param
                         / [...]
and
      rtcp-fb-ack-param  = SP "rpsi"
                         / SP "app" [SP byte-string]
                         / SP token [SP byte-string]
|                        / ; empty

This means that the feedback type "ack" *MAY* have parameters.

Contrary to that, below the ABNF, the RFC explains:

   Feedback type "ack":

      This feedback type indicates that positive acknowledgements for
      feedback are supported.

      The feedback type "ack" MUST only be used if the media session is
      allowed to operate in ACK mode as defined in Section 3.6.1.

|     Parameters MUST be provided to further distinguish different types
|     of positive acknowledgement feedback.

      [...]

The *MUST* in the tagged lines contradicts the ABNF.

Authors, please resolve the issue:

Either have the ABNF changed by omission of the tagged line above,

|                        / ; empty

or change the tagged explanation lines to say:

|     Parameters MAY be provided to further distinguish different types
|     of positive acknowledgement feedback.


(10)  [incomplete specification, and an extraneous word]

At the bottom of page 26, Section 4.2 of RFC 4585 says:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST to
      be unique (and thus MUST be registered with IANA).  Along with a
|     new name, its semantics, packet formats (if necessary), and rules
      for its operation MUST be specified.

It should say:

   Other feedback types <rtcp-fb-id>:

      Other documents MAY define additional types of feedback; to keep
      the grammar extensible for those cases, the rtcp-fb-id is
|     introduced as a placeholder.  A new feedback scheme name MUST be
      unique (and thus MUST be registered with IANA).  Along with a new
|     new name, its semantics, possible parameters, packet formats (if
      necessary), and rules for its operation MUST be specified.

Rationale:

a) "MUST to be unique" should be "MUST be unique".

b) Syntax and semantics of parameters (if any) obviously MUST be
   specified as well.  The RFC text in the IANA Considerations
   (Section 9) already reflects this requirement.
   For completeness and clarity, it should be stated here as well.
   I have proposed minimal additional wording -- you might choose
   alternative words.

Notes:

from pending

--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.

We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).

Report New Errata