[avtext] Adam Roach's No Objection on draft-ietf-avtext-lrr-06: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-avtext-lrr-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtext-lrr/



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