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

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!)

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

 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.