RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) ST 336 Encoded Data
draft-ietf-payload-rtp-klv-04

Pete actually cleared his DISCUSS - the extra copy of it appearing in the log below is a bug in the tracker. The status of that bug can be tracked here:

[Ballot discuss]
The text in the bullets in 4.3.1.1 is ambiguous. In the first bullet, I took the "KLVunit presently being received" to mean the KLVunit associated with the RTP packet that was just received. That's not what was intended. What was really intended was the KLVunit that was was being processed, i.e. the one that was partially received before the lost packet. In the second bullet, "all subsequent packets" was intended to mean all packets after the *lost* one. However, I took it to mean anything subsequent to (i.e., not including) the currently received packet. That would end up throwing away a perfectly good KLVunit.

May I suggest some replacement text:


  o  MUST consider the KLVunit partially received before a lost packet
      as damaged. This damaged KLVunit includes all packets prior to the
      lost one (in sequence number order) back to, but not including,
      the most recent packet in which the M-bit in the RTP header was
      set to '1'.

  o  MUST consider the first KLVunit received after a lost packet as
      damaged. This damaged KLVunit includes the first packet after the
      lost one (in sequence number order) and, if the first packet has
      its M-bit in the RTP header is set to '0', all subsequent packets
      up to and including the next one with the M-bit in the RTP header
      set to '1'.

[Ballot comment]
Although I agree that the $100 charge to obtain a copy of SMPTE 336M is unpleasant, RFC 3497 provides a precedent of normatively referencing a specification (SMPTE 292M) for which payment is required. Therefore I am balloting "No Objection".

[Ballot comment]
Although I agree that the $100 charge to obtain SMPTE 336M is unpleasant, RFC 3497 provides a precedent of normatively referencing specification (SMPTE 292M) for which payment is required. Therefore I am balloting "No Objection".

[Ballot comment]
From the table in 4.1:

"The timestamp clock frequency SHALL be defined as a parameter to the payload format (Section 6)."

I don't believe this is an implementation requirement, and therefore the SHALL is not necessary. I suggest instead, "The timestamp clock frequency is defined as a parameter to the payload format (see section 6.1)."

"The RTP header marker bit (M) SHALL be set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit SHALL be set to '0'."

The passive voice confused me. I suggest instead, "The RTP header marker bit (M) is used to demarcate KLVunits. Senders MUST set the marker bit to '1' for any RTP packet which contains the final  byte of a KLVunit. For all other packets, senders must set the RTP header marker bit to '0'."

The instruction in 4.2.2, "A receiver MUST consider a KLVunit to be completed when it receives either a packet with M=1 or a packet with a new timestamp", is not necessary: You are telling receivers that they must look at the timestamp. Instead, they should stick to only looking at RTP sequence numbers and the M-bit to determine KLVunit completion. Unless you want receivers to handle the edge case of losing a single lost packet this you know has a marker bit, they never need to look at the timestamp.

If you do want them to handle that edge case (and I don't think they need to), you can insert the following bullet into 4.3.1.1:


  o  MAY consider the first KLVunit received after a lost packet as
      undamaged if and only if there was only a single packet was lost
      and the M-bit in the RTP header of the packet prior to the lost
      one was set to '0' and the timestamp of the packet prior to the
      lost one is different than the time stamp of the packet received
      after the last one. If any of those conditions are not met (or if
      the receiver does not implement this option), then the receiver:

[Ballot comment]
From the table in 4.1:

"The timestamp clock frequency SHALL be defined as a parameter to the payload format (Section 6)."

I don't understand what the above means.

"The RTP header marker bit (M) SHALL be set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit SHALL be set to '0'."

I don't understand what the interoperability implications of the above "SHALL"s are. Why the 2119 language? I think it makes more sense to say:

"The RTP header marker bit (M) is set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit is set to '0'."

The instruction in 4.2.2, "A receiver MUST consider a KLVunit to be completed when it receives either a packet with M=1 or a packet with a new timestamp", is not necessary: You are telling receivers that they must look at the timestamp. Instead, they should stick to only looking at RTP sequence numbers and the M-bit to determine KLVunit completion. Unless you want receivers to handle the edge case of losing a single lost packet this you know has a marker bit, they never need to look at the timestamp.

If you do want them to handle that edge case (and I don't think they need to), you can insert the following bullet into 4.3.1.1:


  o  MAY consider the first KLVunit received after a lost packet as
      undamaged if and only if there was only a single packet was lost
      and the M-bit in the RTP header of the packet prior to the lost
      one was set to '0' and the timestamp of the packet prior to the
      lost one is different than the time stamp of the packet received
      after the last one. If any of those conditions are not met (or if
      the receiver does not implement this option), then the receiver:

[Ballot discuss]
The text in the bullets in 4.3.1.1 is ambiguous. In the first bullet, I took the "KLVunit presently being received" to mean the KLVunit associated with the RTP packet that was just received. That's not what was intended. What was really intended was the KLVunit that was was being processed, i.e. the one that was partially received before the lost packet. In the second bullet, "all subsequent packets" was intended to mean all packets after the *lost* one. However, I took it to mean anything subsequent to (i.e., not including) the currently received packet. That would end up throwing away a perfectly good KLVunit.

May I suggest some replacement text:


  o  MUST consider the KLVunit partially received before a lost packet
      as damaged. This damaged KLVunit includes all packets prior to the
      lost one (in sequence number order) back to, but not including,
      the most recent packet in which the M-bit in the RTP header was
      set to '1'.

  o  MUST consider the first KLVunit received after a lost packet as
      damaged. This damaged KLVunit includes the first packet after the
      lost one (in sequence number order) and, if the first packet has
      its M-bit in the RTP header is set to '0', all subsequent packets
      up to and including the next one with the M-bit in the RTP header
      set to '1'.

[Ballot discuss]
It bothers me somewhat that a normative reference is only available for
review by paying $100 [SMPTE336M].

It may be worth considering placing sufficient text in this document to
make review and implementation possible (maybe that is already the case)
and moving the reference to Informative.

[Ballot comment]
-  What happens if the RTP packet with M=1 gets lost? It may
be in there but I either missed it or didn't get it.

- The normative [SMPTE336M] document costs $100 so I cannot
check it. Maybe that's considered ok in this space but its quite odd
for a standards-track RFC in general. Is there no way that that
specification could be made available for free so that people can
implement IETF standards without having to pay? That's highly
desirable at least.  (I assume the WG did specifically consider this
and decided they were ok with it. Consider this an exhortation
from outside the WG.)

[Ballot comment]
From the table in 4.1:

"The timestamp clock frequency SHALL be defined as a parameter to the payload format (Section 6)."

I don't understand what the above means.

"The RTP header marker bit (M) SHALL be set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit SHALL be set to '0'."

I don't understand what the interoperability implications of the above "SHALL"s are. Why the 2119 language? I think it makes more sense to say:

"The RTP header marker bit (M) is set to '1' for any RTP packet which contains the final byte of a KLVunit. For all other packets, the RTP header marker bit is set to '0'."

[Ballot discuss]
The table in 4.1 says: "When one KLVunit is placed in multiple RTP packets, the RTP timestamp of all packets comprising that KLVunit MUST be the same." And 4.2.2 says: "Additionally, when a KLVunit is fragmented across multiple RTP packets, all RTP packets transporting the fragments a KLVunit MUST have the same timestamp." I don't understand the requirement that the timestamp be the same for fragmented KLVunits. The timestamp from the KLVunit can simply be taken from the first RTP packet. Subsequent packets are all determined by sequence number and their timestamps can be ignored. There is no issue with implementations being confused about middle packets because those are all determined by RTP sequence number. And the end of the KLVunit is determined by the M-bit, so looking at the timestamps after the first one is unnecessary. I don't know how most implementations form the KLVunits into RTP packets, but I can imagine an implementation that does it on the fly, meaning that preserving the timestamp in subsequent packets might be more likely to get screwed up. Finally, the instruction in 4.2.2, "A receiver MUST consider a KLVunit to be completed when it receives either a packet with M=1 or a packet with a new timestamp", seems to be inviting trouble: You are telling implementations that they must look at the timestamp. Instead, the should stick to only looking at RTP sequence numbers and the M-bit to determine KLVunit completion. I suggest the requirement be dropped, but if you'd like to keep it, I'd like an interoperability justification explicit in the document. As far as I can tell, there is no interoperability reason for the MUST in this protocol.

In 4.3.1.1, it says, "When a lost packet is detected[...], the receiver [...] MUST consider all subsequent packets (in sequence number order) up to and including the next one with the M-bit in the RTP header set to '1' as part of a damaged KLVunit." I don't think that's correct. If the presently received packet has an M-bit of 1, and the next packet has a correct subsequent sequence number, then the subsequent packet is not part of the damaged KLVunit. There's no reason to discard it.

IANA has questions about one of the actions required by
draft-ietf-payload-rtp-klv-02.txt:

ACTION 1:

IANA will register the following application media type at
http://www.iana.org/assignments/media-types/application/index.html

smpte336m [RFC-to-be]


ACTION 2:

IANA will register the following in the RTP Payload Format media types
(note: no longer "MIME") registry at
http://www.iana.org/assignments/rtp-parameters

Media Type Subtype Clock Rate (Hz) Channels (audio) Reference
---------- ------- --------------- ---------------- ---------
application smpte336m ?? ?? [RFC-to-be]


QUESTION: how should we fill in the "Clock Rate (Hz)" and "Channels
(audio)" columns for this registration? Should they be left blank?

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RTP Payload Format for SMPTE 336M Encoded Data) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'RTP Payload Format for SMPTE 336M Encoded Data'
  as a Proposed Standard

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 2012-01-27. 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 specifies the payload format for packetization of KLV
  (Key-Length-Value) Encoded Data, as defined by the Society of Motion
  Picture and Television Engineers (SMPTE) in SMPTE 336M, into the
  Real-time Transport Protocol (RTP).




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

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


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

UPDATED Writeup:

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Ali Begen. He has reviewed the document and believes it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed adequately by the WG members. The shepherd does not have concerns about the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

There are no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no concerns from the document shepherd from this perspective. No IPR disclosures have been made against this document.

(1.e) 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?

No objections have been raised and the reviewers were confident in their reviews.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Version idnits 2.12.12 of ID Nits identifies no issues except one comment (which is OK).

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document does split normative and informative references.

There is a normative reference to SMPTE336M, which is a spec produced by the SMPTE organization. This is not an RFC but it is already a produced spec.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations have been reviewed, the registry is correctly identified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No issues.

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP).

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

No, it was relatively a smooth process.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

The document achieved consensus in the PAYLOAD working group. According to the authors, there have been prototypical implementations, including implementation inside existing open toolkits and applications. One such prototype involved a (modified to implement) VideoLAN VLC to a proprietary RTP-capable desktop application.

The review request for media type registration has been sent to ietf-types on Jan 11th. Here is the link:
http://www.ietf.org/mail-archive/web/ietf-types/current/msg01608.html

Shepherd writeup for draft-ietf-payload-rtp-klv-02.txt:

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

The document shepherd is Ali Begen. He has reviewed the document and believes it is ready for forwarding to the IESG for publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed adequately by the WG members. The shepherd does not have concerns about the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

There are no such concerns.

(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

There are no concerns from the document shepherd from this perspective. No IPR disclosures have been made against this document.

(1.e) 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?

No objections have been raised and the reviewers were confident in their reviews.

(1.f) 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
entered into the ID Tracker.)

No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Version idnits 2.12.12 of ID Nits identifies no issues except one comment (which is OK).

(1.h) Has the document split its references into normative and
informative? 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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document does split normative and informative references.

There is a normative reference to SMPTE336M, which is a spec produced by the SMPTE organization. This is not an RFC but it is already a produced spec.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The IANA considerations have been reviewed, the registry is correctly identified.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

No issues.

(1.k) 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
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?

This document specifies the payload format for packetization of KLV (Key-Length-Value) Encoded Data, as defined by the Society of Motion Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Real-time Transport Protocol (RTP).

The document achieved consensus in the PAYLOAD working group.