Skip to main content

How to Write an RTP Payload Format
draft-ietf-payload-rtp-howto-14

Yes

(Richard Barnes)

No Objection

(Benoît Claise)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Stewart Bryant)

Note: This ballot was opened for revision 10 and is now closed.

Richard Barnes Former IESG member
Yes
Yes (for -10) Unknown

                            
Spencer Dawkins Former IESG member
(was Discuss) Yes
Yes (2014-01-09 for -12) Unknown
Thank you for addressing my DISCUSS (and my comments). 

- Previous DISCUSS:

This is a trivial Discuss to fix, but it seems important because a reader who believes the references would miss parts of key BCPs. I'll be a Yes when it's resolved.

In section 3.2.1.  IETF Process and Publication,

   It is very important to note and understand the IETF Intellectual
   Property Rights (IPR) policy that requires early disclosures based on
   personal knowledge from anyone contributing in IETF.  The IETF
   policies associated with IPR are documented in BCP 78 [RFC5378]
   (related to copyright, including software copyright for example code)
   and BCP 79 [RFC3979] (related to patent rights).

BCP 78 is a single-RFC BCP, so that's correct now, but the base RFC could be reissued or updated in other RFCs included in the BCP, and BCP 79 is a multi-RFC BCP, so citing it as [RFC3979] isn't quite right. A bit further in the same section, in

   The main part of the IETF process is formally defined in RFC 2026
   [RFC2026].  RFC 2418 [RFC2418] describes the WG process, the relation
   between the IESG and the WG, and the responsibilities of WG chairs
   and participants.

both RFC 2026 and RFC 2418 are part of multi-RFC BCPs (BCP 9 and BCP 25, respectively).

My suggestion would be cite all of these by BCP numbers.

- Previous comments:

These are all nit-level comments. Please do the right thing.

In section 3.2.1.  IETF Process and Publication,

   The standard tracks
   previously allowed for documents of three different maturity
   classifications, proposed, draft and Internet Standard.  Since
   October 2011 this has been reduced to only two levels: Proposed
   Standard and Internet Standard [RFC6410].

you might consider describing only the current maturity classifications, unless you expect awareness of draft standards to be of particular use to your target audience.

In section 3.3.2.  RTP Header

   The RTP header contains a number of fields.  Two fields always
   require additional specification by the RTP payload format, namely
   the RTP Timestamp and the marker bit.  Certain RTP payload formats
   also use the RTP sequence number to realize certain functionalities.

if you could give an example ("for example, the frobnitz payload format uses the RTP sequence number as a covert channel to subvert network security systems", or something), that would be helpful to me.

In section 3.3.3.  RTP Multiplexing

   The first one is separation of media streams of different types or
   usages, which is accomplished using different RTP sessions.  So for
   example in the common multimedia session with audio and video, RTP
   commonly multiplexes audio and video in different RTP sessions.  To
   achieve this separation, transport-level functionalities are used,
   normally UDP port numbers.  

[deleted down to]

   For more discussion and consideration of how and when to use the
   different RTP multiplexing points see
   [I-D.ietf-avtcore-multiplex-guidelines].

[I-D.ietf-avtcore-multiplex-guidelines] describes the issues with NAT binding keepalives and port exhaustion when using transport-level RTP multiplexing, but there's no hint of those issues here. Maybe i's worth a sentence here that points to the issues that [I-D.ietf-avtcore-multiplex-guidelines] explains?

In section 3.4.2.2.  Declarative Usage in RTSP and SAP

   SAP (Session Announcement Protocol) [RFC2974] is used for announcing
   multicast sessions.  Independently of the usage of Source-specific
   Multicast (SSM) [RFC3569] or Any-source Multicast (ASM), the SDP
   provided by SAP applies to all participants.  All media that is sent
   to the session must follow the media stream definition as specified
   by the SDP.  This enables everyone to receive the session if they
   support the configuration.  Here SDP provides a one way channel with
   no possibility to affect the configuration that the session creator
   has decided upon.  Any RTP Payload format that requires parameters
   for the send direction and which needs individual values per
   implementation or instance will fail in a SAP session for a multicast
   session allowing anyone to send.

does SAP appear often enough, in practice, to be described here, as if it was in common use and payload designers should keep SAP in mind for new payload specifications? If the answer is "yes", that's fine, but if not, maybe it's worth pointing out that SAP is obsolete/obsolescent? 

I know you're using it to explain declarative usage, but with no qualifiers, a new payload designer could be forgiven for saying "SAP looks really simple, let's use that!"

In section 3.5.2.  Different Queuing Algorithms

   Routers and switches on the network path between an IP sender and a
   particular receiver can exhibit different behaviors affecting the
   end-to-end characteristics.  One of the more important aspects of
   this is queuing behavior.  Routers and switches have some amount of
   queuing to handle temporary bursts of data that designated to leave
   the switch or router on the same egress link.  A queue when not empty
   results in an increased path delay.

I wonder if a pointer to a recent description of Bufferbloat would be helpful? I'm still running into lots of people who don't know/believe how much queuing can increase path delay ...

In 3.5.3.  Quality of Service

   Using best effort Internet has no guarantees for the paths
   properties.  Quality of Service (QoS) mechanism are intended to
   provide the possibility to bound the path properties.  Where Diffserv
   [RFC2475] markings effects the queuing and forwarding behaviors of
   routers, the mechanism provides only statistical guarantees and care
   in how much marked packets of different types that are entering the
   network.  Flow-based QoS like IntServ [RFC1663] has the potential for
   stricter guarantees as the properties are agreed on by each hop on
   the path.

it's possible to read this as saying that IntServ is better than DiffServ. Perhaps the last sentence could end with something like "... by trading per-flow state in the network for better performance"?

In section 4.1.1.  Steps from Idea to Publication

   Submission of the first version:   When one has performed the above
      one submits the draft as an individual draft.  This can be done at
      any time except the 3 weeks (current deadline at the time of
      writing, consult current announcements) prior to an IETF meeting.

The statement about deadlines is going to be really fragile (we've changed this since I joined the IESG in May). Is it necessary to include the "current" deadline in this document?
Barry Leiba Former IESG member
No Objection
No Objection (2013-12-19 for -10) Unknown
-- Section 1 --

   This document extends and updates the information that is available
   in "Guidelines for Writers of RTP Payload Format Specifications"
   [RFC2736].  Since that RFC was written, further experience has been
   gained on the design and specification of RTP payload formats.
   Several new RTP profiles have been defined, and robustness tools have
   also been defined, and these need to be considered.

So, then, should this document "Update" 2736 ?

-- Section 4 --
This document contains a lot of information that seems *way* beyond its scope, talking about how working group meetings work, and that sort of thing.  I'm concerned, as are Stephen and Spencer, about that, and I'm not sure the solutions they're suggesting are sufficient.  That said, I'm not making this a DISCUSS, and am not blocking publication on this point.

I don't think it's a good idea for a technical working group in an IETF technical area to cover all this sort of information in this way.  It's written as being specific to the PAYLOAD working group, and yet....
Benoît Claise Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -10) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-12-19 for -10) Unknown
I might have missed it but it's worth stating that if there's conflict between what the RFC editor wants in terms of format, etc. that the RFC wins out over this draft.  For example, we later require a privacy/management/deployment considerations section in all drafts - those will need to be added.
Stephen Farrell Former IESG member
(was Discuss) No Objection
No Objection (2014-01-08 for -11) Unknown

This used to be a discuss. But looking at -11 with its
new text, and given the low probability that we
reach a new consensus on anything related to IPR
in anything that could be called the short-term, I've
made this a comment.

3.2.1 says: "Note: These IPR rules applies on what is
specified in the RTP Payload format Internet Draft
(and later RFC), IPRs that relates to a codec
specification from an external body does not require
IETF IPR disclosure." That is the subject of a
current thread on rtcweb and ipr@ietf.org so I want
to check that the IESG agree that the above is
correct before we put this out in a new RFC. (I'm not
sure myself, but don't want us to contradict what
could be an emerging consensus that's different from
this, in the unlikely event that such a consensus
emerges in the short-term.)

Note that this discuss is also slightly different
from the apt-x thing, in which case I believe that
the codec is not openly published.
Stewart Bryant Former IESG member
No Objection
No Objection (for -10) Unknown