Subject: [avtext] Warren Kumari's No Objection on draft-ietf-avtext-lrr-06: (with COMMENT)

From: Warren Kumari <[email-masked]>
Date: Mon, 19 Jun 2017 09:42:31 -0700

Warren Kumari 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:
----------------------------------------------------------------------

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

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 29 Jun 2017 23:13:16 +0000

Hi, sorry for the delay in responding.  Responses inline.

> On Jun 19, 2017, at 12:42 PM, Warren Kumari <[email-masked]> wrote:
> 

My inclination had been to leave it up to implementor discretion, as with most malformed messages, but on reflection that possibly wouldn't be great for future extensibility.    I’ll say it MUST be discarded.  This is then the same as the requirement if you get a message with an invalid layer ID.

> this changes the meaning at all; tis just a nit, feel free to ignore.

That’s fine, you’re right, it reads better.

> for frame numbering - if so, feel free to ignore.

‘1’ is indeed intended to be the first frame in all the cases; and frame 2 is indeed dependent on frame 1.  So clearly my diagram is confusing.

But I can’t see how you’re interpreting it that way.  What about the diagram made you think frame 2 is dependent on frame 3?

> -- swap S6 and 7? (Hey, I did say these are nits!)

No problem.