Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)
draft-ietf-avt-avpf-ccm-10

[Ballot discuss]
[Resending discuss to correct spelling of the reviewer's name.  My apologies.]

[This discuss is based on Juergen Schoenwaelder's security directorate review.]

The security considerations section is very well done, and provides a concise
description of the threats and security services required to mitigate the threat.
However, the second paragraph does not provide any specific options to the
reader.  Please identify a protocol or protocols that would provide the necessary
authentication and integry protection for the setup signaling.

[Ballot discuss]
[This discuss is based on Juergen Schoenwalder's security directorate review.]

The security considerations section is very well done, and provides a concise
description of the threats and security services required to mitigate the threat.
However, the second paragraph does not provide any specific options to the
reader.  Please identify a protocol or protocols that would provide the necessary
authentication and integry protection for the setup signaling.

[Ballot comment]
From Gen-ART Review by Vijay Gurbani.

  S3.5.4.2: You may want to consider breaking into two lines the
  equations labeled (1) and (2) at the top of page 25.  The reason
  is that as the labels appear now, they are hidden.  Thus, when you
  refer to equations (1) and (2) later, it is hard to visually see
  where these equations are.  I had to go back and use the browser's
  find command to help me locate them.

  OLD:
  Max_net media_BR_A = TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ...
  (1)
  Max_net media_BR_B = TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ...
  (2)

  NEW:
  Max_net media_BR_A =
      TMMBR_max total BR_A - PR * TMMBR_OH_A * 8 ... (1)
  Max_net media_BR_B =
      TMMBR_max total BR_B - PR * TMMBR_OH_B * 8 ... (2)

[Ballot discuss]
Much of the issues surrounding multicast are "punted" and left to be covered w/ implementation specific solutions. To have interoperable implementations some guidance and a default behavior is required. Only H.271 was given a slight specification of what to do if in a p2mp or mcast scenario. Sections 3.5.1, 3.5.2.2, 3.5.4.6 are examples of underspecified text.

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following assignments
in the "Session Description Protocol (SDP) Parameters - per [RFC4566]"
registry located at
http://www.iana.org/assignments/sdp-parameters
sub-registry ""rtcp-fb" Attribute Values - per [RFC4585]"

Value Name Long Name Reference
---------- --------------------------------- ---------
ccm Codec Control Commands and Indications [RFC-avt-avpf-ccm-09]


Action 2:

Upon approval of this document, the IANA will in the following
registry "Session Description Protocol (SDP) Parameters - per [RFC4566]"
located at http://www.iana.org/assignments/sdp-parameters
create a new sub-registry "Codec Control Messages"

Allocation Policy: "Specificatoin Required" as defined by ]RFC2434]

Initial contents of this sub-registry will be:

Value Name Long Name Usable With Reference
---------- --------------------------------- ----------- ---------
fir Full Intra Request Command ccm
[RFC-avt-avpf-ccm-09]
tmmbr Temporary Maximum Media Stream Bit Rate ccm
[RFC-avt-avpf-ccm-09]
tstr temporal Spatial Trade Off ccm
[RFC-avt-avpf-ccm-09]
vbcm H.271 video back channel messages ccm
[RFC-avt-avpf-ccm-09]


Action 3:

Upon approval of this document, the IANA will make the following assignments
in the "RTP PARAMETERS" registry located at
http://www.iana.org/assignments/rtp-parameters
sub-registry "FMT Values for both RTPFB and PSFB Payload Types - per [RFC4585]"

RTPFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- ---------
Reserved [tbd(2)] [RFC-avt-avpf-ccm-09]
TMMBR Temporary Maximum Media Stream Bit [tbd(3)] [RFC-avt-avpf-ccm-09]
Rate Request
TMMBN Temporary Maximum Media Stream Bit [tbd(4)] [RFC-avt-avpf-ccm-09]
Rate Notification

Action 4:

Upon approval of this document, the IANA will make the following assignments
in the "RTP PARAMETERS" registry located at
http://www.iana.org/assignments/rtp-parameters
sub-registry "FMT Values for both RTPFB and PSFB Payload Types - per [RFC4585]"

PSFB range
Name Long Name Value Reference
-------------- --------------------------------- ----- -------
FIR Full Intra Request Command [tbd(4)]
[RFC-avt-avpf-ccm-09]
TSTR Temporal-Spatial Trade-off Request [tbd(5)]
[RFC-avt-avpf-ccm-09]
TSTN Temporal-Spatial Trade-off Notification [tbd(6)]
[RFC-avt-avpf-ccm-09]
VBCM Video Back Channel Message [tbd(7)]
[RFC-avt-avpf-ccm-09]

We understand the above to be the only IANA Actions for this document.

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

This document defines extensions to AVPF. The document went through two long WGLC (on 03 and 07 versions). It was reviewed by assigned reviewers and the latest revision was given sufficient time for review. 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 is no disclosed IPR on 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?

The document has good consensus from the WG.

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

Idnits identify some warnings on weird spaces but those are OK. The informative reference to RFC 2032 is on purpose. SAVPF is now in publication. There are no other issues.

(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 AreaDirector in the Last Call procedure for them [RFC3967].

References have been split. There are no normative references to
internet-drafts, and no normative down-references.

(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 exist, and are consistent with the document.

(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 specifies a few extensions to the messages defined in the Audio-Visual Profile with Feedback (AVPF). They are helpful primarily in conversational multimedia scenarios where centralized multipoint functionalities are in use. However, some are also usable in smaller multicast environments and point-to-point calls.
The extensions discussed are messages related to the ITU-T H.271 Video Back Channel, Full Intra Request, Temporary Maximum Media Stream Bit Rate and Temporal Spatial Trade-off.

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?

The document has been reviewed by the AVT working group to ensure consistency the AVPF profile and there was consensus on using RTCP feedback for scenarios described in the draft.

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?

There are no current implementations but many vendors expressed their desire to implement these mechanisms.

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

Roni Even is the document shepherd.