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