RTP Payload Format for H.264 Reduced-Complexity Decoding Operation (RCDO) Video
draft-ietf-avt-rtp-h264-rcdo-08

[Ballot discuss]
This is a discuss-discuss; I will clear on the call regardless of the result of the discussion.

The authors cut-and-paste the boilerplate security considerations introduced in 3984bis.  The secdir reviewer
suggested something rather different (and much shorter) which the authors agreed to after some modifications,
but quite rightly pointed out that the boilerplate in 3984bis should be revised if the guidelines aren't correct.

Looking back, I find I was distracted by an IANA-related discussion and apparently missed the fact that new
boilerplate had been established.  It doesn't appear that the secdir reviewer noticed either.

I am not too concerned about the security considerations text in this document - either version is okay by me.
I am concerned about the boilerplate in 3984bis, though

[Ballot comment]
Because the number 1 (U+0031) and lowercase l (U+006C) look very similar in fixed-width fonts such as those used to render Internet-Drafts, I suggest changing things like [value 1] to [value "1"] or even [value "1" (one)] to avoid any possible ambiguity. You might also consider [value "0" (zero)] for the same reason.

[Ballot comment]
In the Section registering the new media type:

  Applications that use this media type:  None

According to the document write-up this is not correct. Please state the type of application using this media type (e.g. "video streaming applications").

Upon approval of this document, IANA understands that there are two IANA
Actions it must complete.

First, in the Video Media Types registry located at:

http://www.iana.org/assignments/media-types/video/

the following media type will be registered: H264-RCDO
with the reference: [ RFC-to-be ]

Second, in the RTP Payload Format media types registry located at:

http://www.iana.org/assignments/rtp-parameters

a new registration will be added as follows:

Media type: Video
Subtype: H264-RCDO
Clock rate: 90000
Channels:
Reference: [ RFC-to-be ]

IANA understands that these two actions are the only ones needed to be
completed upon approval of this document.

(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 Roni Even. I have reviewed the document,
and believe it is ready 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 went through a WGLC. The comments were minor and were
addressed. The delay in publication was to in order to wait to
draft-ietf-avt-rtp-rfc3984bis to go to publication. The document shepherd
has no concerns about the review process.

(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?

No 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.

No concerns.

(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?

The document had consensus from the WG. It was presented in AVT sessions.
This is a payload specification for an ITU-T H.241 specification of an
optimization of H.264.

(1.f) Has anyone threatened an appeal or otherwise indicated
extreme discontent? If so, please summarize 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
http://www.ietf.org/ID-Checklist.html 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?

The idnits tool reports some reference to ITU-T documents which look OK.
The media subtype was sent to review to ietf-types and there were no
comments.

(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].

References have been split. There is a normative reference to
draft-ietf-avt-rtp-rfc3984bis which is now in publication state.

(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 [RFC2434]. 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 section exists; the registries are identified there are no new registries.

(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 such sections

(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 describes an RTP Payload format for the Reduced-
Complexity Decoding Operation (RCDO) for H.264 Baseline profile
bitstreams, as specified in ITU-T Recommendation H.241. RCDO reduces
the decoding cost and resource consumption of the video processing.
The RCDO RTP Payload format is based on the H.264 RTP Payload format."

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?

There is nothing specific to note.

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 a payload specification for an optional H.264 mode
that is being used in video conferencing systems by companies like Tandberg,
Polycom and others. There is interoperability in the implementations.

Personnel

Who is the Document Shepherd for this document? Who is
the Responsible Area Director?

Roni Even is the document shepherd.
The responsible area director is Robert Sparks.