The Layer Refresh Request (LRR) RTCP Feedback Message
draft-ietf-avtext-lrr-07

[Ballot comment]
Section 2.1: "...requires that a spatial layer be encoded in a way that references only lower-layer subpictures..." had me puzzled for quite some time, as I didn't think this was an inherent charateristic of *any* codec. It took quite a bit of re-reading before I figured out that this is referring only to the refresh packets themselves, not an intrinsic constraint on the stream across all time. Rephrase.

The description of temporal scaling introduces the same confusion.

I had the same heartburn as EKR regarding "(opt)" in Figure 5 -- given that it appears at the end of the data, there is a real risk that some implementors will attempt to literally omit the field rather than setting it to 0. Please remove the "(opt)". [n.b., I'm on the fence as to whether this should be a Comment or a Discuss, as it has the risk of introducing actual interop issues in the field].

The description for "Seq nr." indicates that the number is increased by "1 modulo 256." While it's certainly possible to figure out what is intended here, what this says on its face is to increase by one, as "1 modulo 256" is always one. Please rephrase to indicate that "modulo" applies to "Seq nr." instead of applying to "1".

Section 3.2 indicates that the technique should not be used for picture losses (packet losses, presumably?), but instead for situations where not sending it would "render the video unusable."  This all seems very subjective and ill-defined for normative statements. Please be precise with what you mean by "picture losses," and please give an example of when LRR SHOULD be used -- perhaps my imagination is a bit dull today, but I cannot come up with situations in which LRR would be appropriate, given this "MUST."

[Ballot comment]
S 2.1.
  In a layer refresh, however, other layers than the ones requested for
  refresh may still maintain dependency on earlier content of the
  stream.  This is the difference between a layer refresh and a Full

This "however" is hard to read because the entire previous graf
talks about layer refreshes.

All the diagrams in this section would be a lot easier to read
if they said that <- means "refers to"

S 3.1
  The Feedback Control Information (FCI) for the Layer Refresh Request
  consists of one or more FCI entries, the content of which is depicted
  in Figure 5.  The length of the LRR feedback message MUST be set to
  2+3*N, where N is the number of FCI entries.

You should state that the length is in 32-bit words.


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | RES    | TTID| TLID          | RES    | CTID| CLID (opt)    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

How is CLID optional? It seems like it still has to be there,
unless I am misreading the text.


  Reserved (RES) (16 bits / 5 bits / 5 bits)  All bits SHALL be set to
      0 by the sender and SHALL be ignored on reception.

I would mention that this is three fields.

[Ballot comment]
Firstly, thank you for addressing Fred Baker's OpsDir comments - https://datatracker.ietf.org/doc/review-ietf-avtext-lrr-05-opsdir-lc-baker-2017-06-07/ -- this change "fixes" the document for me.

I found this document easy to read, and a useful introduction to the topic; this is in spite of my knowing basically nothing about codecs and RTCP.

I did have some nits and a larger question:
Question:
1: 3.1.  Message Format (and others)
The document says things like: " When C is 1, TTID MUST NOT be less than CTID, and TLID MUST NOT be less than CLID;" -- cool, no worries... But, what do I do if I receive an LRR feedback message where e.g: the TTID *is* less than CTID? Do I just ignore the message? Do I self destruct? (Basically, what does error-handling look like?)

Nits:
1: 2.1.  Terminology
"In a layer refresh, however, other layers than the ones requested for refresh may still..."
To me the "other layers" bit sounds clumsy - "In a layer refresh, however, layers other than the ones requested for refresh may still..." reads much better - this construct is in a few other places too. I don't think that this changes the meaning at all; tis just a nit, feel free to ignore.

2: The "numbers" in the figures feel like they are going backwards (or I've completely misunderstood the document :-)) -- I would expect the frame numbered '1' to be the first frame, and the second to be numbered 2. So, the number in the diagrams would go " 4  3  2  1 "; otherwise, you are counting "down" towards frame 0. It feels weird (and is somewhat confusing) for e.g frame 2 to be based on frame 3 (and not frame 1).
I have no idea if this is the convention for frame numbering - if so, feel free to ignore.

3: The convention is Security Considerations go just before IANA Considerations -- swap S6 and 7? (Hey, I did say these are nits!)

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

The IANA Services Operator has completed its review of draft-ietf-avtext-lrr-05.txt. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, a new entry will be registered in the Codec Control Messages registry on the Session Description Protocol (SDP) registry page located at:

https://www.iana.org/assignments/sdp-parameters/

as follows:

Value Name: lrr
Long Name: Layer Refresh Request Command
Usable with:ccm
Mux:
Reference: [ RFC-to-be ]

IANA Question -> what should be the entry for "Mux" for this new registration?

Second, in the FMT Values for PSFB Payload Types registry on the Real-Time Transport Protocol (RTP) Parameters registry page located at:

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

a single, new value is to be registered as follows:

Value: [ TBD-at-registration ]
Name: LRR
Long name: Layer Refresh Request Command
Reference: [ RFC-to-be ]

Because this registry requires Expert Review [RFC5226] for registration, we've contacted the IESG-designated expert in a separate ticket to request approval. Expert review should be completed before your document can be approved for publication as an RFC.

The IANA Services Operator understands that these two actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, draft-ietf-avtext-lrr@ietf.org, avtext@ietf.org, rachel.huang@huawei.com, avtext-chairs@ietf.org, Rachel Huang
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Layer Refresh Request (LRR) RTCP Feedback Message) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Extensions
WG (avtext) to consider the following document:
- 'The Layer Refresh Request (LRR) RTCP Feedback Message'
  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 2017-06-08. 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 memo describes the RTCP Payload-Specific Feedback Message "Layer
  Refresh Request" (LRR), which can be used to request a state refresh
  of one or more substreams of a layered media stream.  It also defines
  its use with several RTP payloads for scalable media formats.




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

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


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

This is my AD Evaluation of draft-ietf-avtext-lrr-05. I only have a couple of editorial comments, which can be handled along with any IETF Last Call comments. I will request IETF Last Call shortly.
————————

-3.2, last paragraph: the “MAY” seems like a statement of fact, rather than normative permission. Please consider lower case.

-4.3, 2nd paragraph: "
Figure 8 shows the format of the layer index field for H.265 streams. The "RES" fields MUST be set to 0 on transmission and ignored on reception.”

Is that MUST a new normative requirement, or a reference to one in RFC 7798? If the later, please use descriptive (i.e. non-2119) language.

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 document defines a new feedback message to allow requesting one or more layered streams to be refreshed. It complements RFC5104 which only defines a Full Intra Request (FIR).

(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 specifies a new RTCP payload-specific feedback mssage to allow a receiver of a layered media stream to request one or more of its substreams to be refereshed without requiring the entire stream to be refreshed. This new message can be used for both temporally and spatially scaled streams. This document also defines its use with several RTP payloads for scalable media formats.

Working Group Summary:

The WG is happy with current version. No technical comments are received.

Document Quality:

The document got some reviews from AVT experts, and enough discussions during the meetings. There exist widely deployed implementations of the FIR message specified in RFC5104. This draft introduces a new request for layered codecs either spatially or temporally to avoid unnecessary information obtained by FIR. This is expected to be a very useful implementation when used with scaled streams, for example, streams with H.264 SVC.

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 05 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. Mainly the security concerns are covered by RFC5104. But still particular reviews regarding security may be 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 understands and agrees 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.

Checked with the idnits tool. 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 such a 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).

The document defines two IANA registrations. One is a new value for “FMT Values for PSFB Payload Types”; another is a new value to the “Codec Control Messages” subregistry of SDP parameters. They are all described correctly.

(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 new registries are defined.

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