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

[Ballot comment]
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?

[Ballot comment]


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.

[Ballot comment]
-- 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....

[Ballot discuss]


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.

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot 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.

[Ballot comment]
These are all nit-level comments. 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?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-payload-rtp-howto-10, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (How to Write an RTP Payload Format) to Informational RFC


The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'How to Write an RTP Payload Format'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document contains information on how to best write an RTP
  payload format specification.  It provides reading tips, design
  practices, and practical tips on how to produce an RTP payload format
  specification quickly and with good results.  A template is also
  included with instructions.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-payload-rtp-howto/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Informational as indicated in the title page.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

This document describes guidelines for people who would like to write an RTP payload format specification. There have been changes in this process and this document describes the latest. A document template is also provided.

Working Group Summary

The document received several reviews on various parts and as a whole. There have been quite a big number of improvements over time, both editorially and technically.

Document Quality

This document is informational, so does not require an implementation. Several people who have written payload format specs before reviewed the material carefully.

Personnel

Ali Begen is the document shepherd and Richard Barnes is the responsible AD.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

There were a number of review stages. The document is ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed? 

No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

No IPR disclosures are needed and none were submitted.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

N/A

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Full WG support.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

ID nits tool lists a few things. There is no 2119 keyword usage in this document as explained in the header. The

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

There are no such reviews needed.

(13) Have all references within this document been identified as
either normative or informative?

They are all informative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No normative reference exists.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

N/A

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No replacement of an existing document.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

There are no IANA considerations here.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

None was performed as it was not needed.