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: 51
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 (11)-(19) of 19

(11)  [formatting issue]

In Section 6, the text around the page break from page 31 to page 32
is not formatted properly.
The RFC says:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all
 << page break >>
      payload-specific as well as application layer FB messages.  It is
      up to the specification of an FB message to define how payload
      type information is transmitted.

It should say:

      [...]
      audio and DTMF) or when codec changes occur, the payload type
      information may need to be conveyed explicitly as part of the FB
      message.  This applies to all payload-specific as well as
 << page break >>
      application layer FB messages.  It is up to the specification of
      an FB message to define how payload type information is
      transmitted.


(12)  [inconsistent text]

Still in Section 6, the second paragraph on page 32 (immediately
following the text quotation in item (11) above) says:

                         vvv
|  This document defines two transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

It should say:
                         vvv
|  This document defines one transport layer and three (video) payload-
   specific FB messages as well as a single container for application
   layer FB messages.  Additional transport layer and payload-specific
   FB messages MAY be defined in other documents and MUST be registered
   through IANA (see Section 9, "IANA Considerations").

Rationale:
Cf. the third paragraph of Section 6, on page 31, and
the subsequent pages, in particular page 34, where the
second paragraph of Section 6.2 says:

|  A single general purpose transport layer FB message is defined in
   this document: Generic NACK.  It is identified by means of the FMT
   parameter as follows:

   [...]

(And so it does, per Section 6.2.1.)


(13)  [incomplete specification?]

Within Section 6.1, the last paragraph on page 33 says:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same FMT.
|  If multiple types of feedback messages, i.e., several FMTs, need to
   be conveyed, then several RTCP FB messages MUST be generated and
   SHOULD be concatenated in the same compound RTCP packet.

I strongly suspect -- and this is supported by the examples in the
RFC -- that feedback packets to be combined MUST also have the same
payload type (PT), not only agree in their FMT values.
Otherwise, there would be no way to carry the different PT values
in the FB message according to the format specified in Figure 3.

Therefore, the RFC should say:

   Each RTCP feedback packet MUST contain at least one FB message in the
   FCI field.  Sections 6.2 and 6.3 define for each FCI type, whether or
   not multiple FB messages MAY be compressed into a single FCI field.
|  If this is the case, they MUST be of the same type, i.e., same PT and
|  the same FMT.  If multiple types of feedback messages, i.e., several
|  PTs and/or several FMTs, need to be conveyed, then several RTCP FB
   messages MUST be generated and SHOULD be concatenated in the same
   compound RTCP packet.

(Authors, please supply alternative wording, if you desire.)

Note:
Perhaps, this issue arised because of the slightly differing
semantics implied for the various usages of the term "FB message"
in Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic
entity carried in the FCI field of that RTCP message.
Future updates to the RFC might try further clarifications of the
text to avoid this subtle sematic overloading.


(14)  [missing article]

The last paragraph of Section 6.3, at the bottom of page 35, says:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines FCI format for the
   application layer FB message.

It should say:

   The following subsections define the FCI formats for the payload-
|  specific FB messages, Section 6.4 defines the FCI format for the
   application layer FB message.


(15)  [extraneous words]

The second paragraph of Section 6.3.1.1, on page 36, says:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for some for certain codecs.  An application
   supporting both schemes MUST use the feedback mechanism defined in
   this specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.

It should say:

   Other RTP payload specifications such as RFC 2032 [6] already define
|  a feedback mechanism for certain codecs.  An application supporting
   both schemes MUST use the feedback mechanism defined in this
   specification when sending feedback.  For backward compatibility
   reasons, such an application SHOULD also be capable to receive and
   react to the feedback scheme defined in the respective RTP payload
   format, if this is required by that payload format.


(16)  [misleading wording]

The first paragraph of Section 6.3.2.2, on page 37, says:

                                                     vvvvv
|  The Slice Loss Indication uses one additional FCI field, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.

To avoid the semantic overloading of the word "field", it should
perhaps better say:
                                                     vvvv
|  The Slice Loss Indication uses one additional FCI word, the content
   of which is depicted in Figure 6.  The length of the FB message MUST
   be set to 2+n, with n being the number of SLIs contained in the FCI
   field.


(17)  [typo]

The first paragraph of Section 6.3.3.1, on page 39, says:

                             v
                                   [...].  As this reference picture is
|  temporally further away then usual, the resulting predictively coded
   picture will use more bits.

It should say:
                             v
                                   [...].  As this reference picture is
|  temporally further away than usual, the resulting predictively coded
   picture will use more bits.


(18)  [inappropriate wording]

The first paragraph of Section 8, on page 42, says:

   RTP packets transporting information with the proposed payload format
   are subject to the security considerations discussed in the RTP
   specification [1] and in the RTP/AVP profile specification [2].  This
   profile does not specify any additional security services.

The wording of the first sentence is inappropriate for this RFC.
(It perhaps has been copied unchanged from an RFC with an RTP Payload
specification.)

RFC 4585 should say instead:

|  RTP packets transporting information as defined in various payload
|  formats supporting this profile are subject to the security
   considerations discussed in the RTP specification [1] and in the
   RTP/AVP profile specification [2].  This profile does not specify any
   additional security services.


(19)  [redundant Ref.]

The Normative Reference [7] (in Section 11.1, on page 48) and
the Informative Reference [20] (in Section 11.2, on page 49)
both point to RFC 3448.
([7] and [20] are referred to once each in the RFC text.)

This is unusual and unexpected.  Only one pointer to RFC 3448
should have been specified.  Authors, please check.

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