Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs
draft-ietf-avtext-avpf-ccm-layered-04

[Ballot comment]

- MRST, MRMT, SRST - expand on 1st use please, not sure
if there are more of those too

- Just checking: I assume when "repairing" something,
that requires the same security properties be
maintained or re-established and that there's no
bidding down attack here that e.g. a middlebox
could mount here?

[Ballot comment]
- Section 5: s/dependent from each other/dependent on each other/

- Section 6: The formulation "the authors' current understanding" seems a bit out of place for a document that is a product of a WG/the IETF; perhaps "based on current information" or some such would be better.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has reviewed draft-ietf-avtext-avpf-ccm-layered-03, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

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

Thank you,

Amanda Baber
Lead IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: ben@nostrum.com, avtext@ietf.org, rachel.huang@huawei.com, "Rachel Huang" , avtext-chairs@ietf.org, draft-ietf-avtext-avpf-ccm-layered@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'Using Codec Control Messages in the RTP Audio-Visual Profile with
  Feedback with Layered Codecs'
  as 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 2016-12-14. 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 updates RFC5104 by fixing a shortcoming in the
  specification language of the Codec Control Message Full Intra
  Request (FIR) as defined in RFC5104 when using it with layered
  codecs.  In particular, a Decoder Refresh Point needs to be sent by a
  media sender when a FIR is received on any layer of the layered
  bitstream, regardless on whether those layers are being sent in a
  single or in multiple RTP flows.  The other payload-specific feedback
  messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have
  also been analyzed, and no corresponding shortcomings have been
  found.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-avtext-avpf-ccm-layered/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-avtext-avpf-ccm-layered/ballot/


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

This is my AD Evaluation of draft-ietf-avtext-avpf-ccm-layered-02. I have one substantive question that I would like to discuss prior to IETF LC, and several editorial comments that can be resolved along with any last call feedback.

Substantive Comment:

- Section 5:

I'm confused by this section. It purports to offer guidance on how to tell if a layered codec is in use, but it seems to talk about certain use cases where layered codecs are in fact used, but in a way where the rules in this draft would lead to suboptimal behavior.

So is the point of this section to detect the use of layered codecs per se, or is it to detect layered-codec scenarios where these rules should not apply?


Editorial Comments:

- 1, first sentence: missing article (e.g. "_The_ RTP profile..."

-1, 2nd paragraph: Heavy use of parenthetical phrases make the middle of this paragraph hard to read. (This occurs elsewhere; I suggest an editing pass with the goal of cutting down on the parentheses.)

-1, list item "b": The sentence doesn’t parse. What is required to send the DRP? The media sender? Does “Require a media sender to send a Decoder Refresh Point when it receives an FIR…”? get the same point across?

-3, first paragraph: Please be specific on how the text updates the original. Does the rest of the text in this section replace the entire definition of DRP?

-3, paragraph 5: I suggest dropping the all-caps on "COMPLETELY". Mixing non-2119 words in all-caps along with 2119 keywords can be confusing.

-5, first paragraph: "However, there are use
  cases of the use of layered codecs that may be viewed as somewhat
  exotic today but clearly are supported by the video coding syntax..."

Hard to parse. What is viewed as exotic, the use case or the codec?

-5, 2nd paragraph, first sentence: consider s/"for the use of layering"/"that layering is in use" . The former makes it sound like an indication that you need to use layering.

-6.4, first parapgraph: "allows to communicate": Missing word? ("allows" needs a direct object)

-6.4, last paragraph: This is hard to parse. Can you break it into multiple simpler sentences?

-9, "The clarified response to FIR does not require any
  updates."

It did create updates, just not security consideration updates. Consider something to the effect of "The clarified response ... does not introduce additional security considerations"

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

RFC Type: Proposed Standard. This is a document updating RFC5104, which is a protocol specification document. RFC type is indicated in the title page header.

(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 fixes a shortcoming in the specification language of the Codec Control Message Full Intro Request (FIR) as defined in RFC5104 when using with layered codecs. In particular, a Decoder Refresh Point needs to be send by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found.

Working Group Summary:
The WG is happy with current version. No technical comments are received. The WG process was fast and efficient.

Document Quality:
There are existing deployed implementations of the RFC5104 based mechanisms. This draft is trying to solve the issues of using RFC5104 in the case of layered codec, which is expected to be a very common implementation.
It’s a simple document and all the technical parts have been agreed in the WG.

Personnel:
Document Shepherd: Rachel Huang
Responsible AD: Ben Campell

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

As the Document Shepherd, I have carefully reviewed the version 01 being forwarded to IESG. In my opinion, it accurately reflects the consensus of the working group and is ready for publication.

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

This document has a security consideration chapter. However, this draft doesn’t propose any new mechanisms. So it seems no specific security issues will be produced. But still particular reviews regarding security are required.

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

There are no such issues.

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

I have confirmed that the authors are not personally aware of any IPR related to this document.

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

No.

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

WG as a whole understand and agree with the document.

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

No ID nits found.

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

No further formal review required.

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

Yes.

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

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

No.

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

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

No IANA considerations.

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

No IANA considerations.

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

No such formal language is used in this document.