RTP Payload Format for Scalable Video Coding
draft-ietf-avt-rtp-svc-27

[Ballot discuss]
Updated (#2 removed)

#1) Section 3.1: It's probably worth pointing out where the normative definitions are.  That is, add "Where there is a discrepancy, the definitions in [H.264] are normative."

[Ballot comment]
In the MIME registration section:

"Encoding Considerations" says that the media type is framed and binary. I think you need to pick one (just "framed").

[Ballot discuss]
[Updated as per -25]

Issue for the AD to address:

The shepherding write-up doesn't list anything in response to the following question:
  In the case of a Media Type review, on what date was the request posted?

The registration template was posted to ietf-types@iana.org for 2 weeks review:


Please add this to the ballot write-up, as this is going to be sent out on document approval. This is required as per RFC 4288.

[Ballot discuss]
[Updated. One issue added at the beginning.]

Issue for the AD to address:

The shepherding write-up doesn't list anything in response to the following question:
  In the case of a Media Type review, on what date was the request posted?

The registration template was posted to ietf-types@iana.org for 2 weeks review:


Please add this to the ballot write-up, as this is going to be sent out on approval.

[Ballot discuss]
This is initially a Discuss Discuss

I have two issues that I would like to understand before taking a position:

1) The document discusses a MANE as a type of middlebox. I would like to understand whether the content server and user explicitly request the services of a MANE to modify the content, or whether it's services are imposed on the stream by a third party?

If the server or the user request the services of the MANE, and the traffic is explicitly addressed there this fine. If one the other hand the MANE just sits in the path and does this, issues of compliance with the Internet Architecture and  issues of net-neutrality apply.

2) I would like to understand whether this draft proposes modification to the output of an ITU-T codec. If it does, has the draft been liaised to ITU-T to ensure that the stream is conferment to their specification.

[Ballot discuss]
[Updated. One issue added at the beginning.]

Issue for the AD to address:

The shepherding write-up doesn't list anything in response to the following question:
  In the case of a Media Type review, on what date was the request posted?

The registration template was posted to ietf-types@iana.org for 2 weeks review:


Please add this to the ballot write-up, as this is going to be sent out on approval.

--------------------

In Section 7.1:

Encoding considerations:
        This type is only defined for transfer via RTP (RFC 3550).

This text is not valid for this field in the registration template. It must be moved to the "Restrictions on usage:" field of the template (which is missing from this section).

Please check the Section 4.8 of RFC 4288 for the list of valid values for this field.


The registration template is also missing the following fields:

  Interoperability considerations:

  Applications that use this media type:

Please read RFC 4288 for possible values of these fields.

[Ballot comment]
I concur with Alexey's DISCUSS regarding compliance with RFC 4288.

Section 4.5.1 states:

  When SST is in use, Section 5.4 of [I-D.ietf-avt-rtp-rfc3984bis]
  applies with the following modifications.

And Section 4.6 states:

  Section 5.6 of [I-D.ietf-avt-rtp-rfc3984bis] applies with the
  following modifications.

Does this specification modify 3984[bis], or does it only extend 3984[bis]?

[Ballot discuss]
[Updated. One issue added at the beginning.]

Issue for the AD to address:

The shepherding write-up doesn't list anything in response to the following question:
  In the case of a Media Type review, on what date was the request posted?

Note that 2 weeks review period on ietf-types@iana.org mailing list is mandatory.

--------------------

In Section 7.1:

Encoding considerations:
        This type is only defined for transfer via RTP (RFC 3550).

This text is not valid for this field in the registration template. It must be moved to the "Restrictions on usage:" field of the template (which is missing from this section).

Please check the Section 4.8 of RFC 4288 for the list of valid values for this field.


The registration template is also missing the following fields:

  Interoperability considerations:

  Applications that use this media type:

Please read RFC 4288 for possible values of these fields.

[Ballot comment]
#1) The RFC editor will make you remove the reference in the abstract.

#2) Abstract: r/in_Annex/in Annex

#3) Expand HDTV and Mbps.

#4) Section 4.4, last para: Wouldn't it be easier to say SST is the default?

[Ballot discuss]
#1) Section 3.1: It's probably worth pointing out where the normative definitions are.  That is, add "Where there is a discrepancy, the definitions in [H.264] are normative."

#2) Section 3.1 the bit about section 3.1.2: If you're copying the definitions and then changing them, then it would greatly aid the reader if you said which ones you're changing and how.

[Ballot comment]
It would help to more clearly call out the consequences rewriting RTCP has on the way SRTP can be used. Currently the document only mentions this (and not as directly as it could) in an "Informative Note". Pointing to the last paragraph in the Security Considerations section of 3894bis would help.

[Ballot discuss]
In Section 7.1:

Encoding considerations:
        This type is only defined for transfer via RTP (RFC 3550).

This text is not valid for this field in the registration template. It must be moved to the "Restrictions on usage:" field of the template (which is missing from this section).

Please check the Section 4.8 of RFC 4288 for the list of valid values for this field.


The registration template is also missing the following fields:

  Interoperability considerations:

  Applications that use this media type:

Please read RFC 4288 for possible values of these fields.

IANA understands that, upon approval of this document, there is one IANA
Action that needs to be completed.

In the Video Media Types registry located at:

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

a new video media type will be registered:

H264-SVC

with a reference of [ RFC-to-be ].

IANA understands that this is the only IANA Action required upon
approval of this document.

Document Shepherd Write-Up

    (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 three WGLC. The third one was to allow people to
verify the consistency with draft-ietf-avt-rfc384bis. The comments were
addressed. Before the first WGLC, the document merged two proposals and a
lot of editorial work from all authors. 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. There are 6 IPR statements
(https://datatracker.ietf.org/ipr/search/?option=document_search
&document_search=draft-ietf-avt-rtp-svc ).
There were discussions on the list and in previous IETF meetings but they
were all addressed and there was a consensus to accept this work with all
these IPR statements. The merging of the two initial individual drafts was
done in correlation with the finalizing of some of the IPR statements.

    (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 has good consensus from the WG there was a good mailing list
discussion on the individual drafts that resulted in a WG document.  There
was a design team that put a lot of effort to draft the final document. It
was presented in AVT sessions and was heavily discussed considering that
this is a payload specification which are usual simple.

    (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 comments and warnings which are 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 are two normative references to 
internet-drafts which are in publication stages.

    (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 memo describes an RTP payload format for Scalable Video Coding
  (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is
technically identical to Amendment 3 of ISO/IEC International Standard
14496-10.  The RTP payload format allows for packetization of one or more
Network Abstraction Layer (NAL) units in each RTP  packet payload, as well
as fragmentation of a NAL unit in multiple  RTP packets.  Furthermore, it
supports transmission of an SVC stream
  over a single as well as multiple RTP sessions.  The payload format
  defines a new media subtype name "H264-SVC", but is still backwards
  compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer,
  when encapsulated in its own RTP stream, must use the H.264 media
  subtype name ("H264") and the packetization method specified in [I-
  D.ietf-avt-rtp-rfc3984bis].  The payload format has wide
  applicability in videoconferencing, Internet video streaming, and
  high bit-rate entertainment-quality video, among others."

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 was a very heated discussion before the two proposals were merged.
Once agreement was achieved the work progress smoothly using a design team.



          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 is a payload specification for H.264 scalable video coding. It is being
used in some streaming and video conferencing applications. It is referenced
by other standard bodies.

          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.