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

[Jonathan Lennox <[e-mail]>]

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

> On Jun 19, 2017, at 12:42 PM, Warren Kumari <[e-mail]> wrote:
> 
> Warren Kumari has entered the following ballot position for
> draft-ietf-avtext-lrr-06: No Objection
> 
> ----------------------------------------------------------------------
> 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?)

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.

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

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

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

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

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

No problem.