Re: [MMUSIC] Spencer Dawkins' No Objection on draft-ietf-mmusic-rid-14: (with COMMENT)

[Adam Roach <[e-mail]>]

On 4/16/18 7:11 PM, Spencer Dawkins wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> If "rid" actually means something, it might be nice to expand it in the
> Abstract and Introduction. After the first couple of pages, I was guessing that
> it means something like "RTP Stream Identifier", based on a quick scan of
> https://tools.ietf.org/html/draft-ietf-avtext-rid-09, but that draft doesn't
> ever expand "rid" or use "rid" in the text, so then I think I'm wrong, because
> this draft also uses "rid-id", and I'm guessing that's probably not "RTP Stream
> Identifier Identifier". By the time I get down to Section 5, I decide it means
> "Restriction Identifier", but then I'm not any happier that I'm guessing
> "rid-id" means "Restriction Identifier Identifier" :-)

https://en.wikipedia.org/wiki/RAS_syndrome

The history here is storied, and the notion of calling this a 
"Restriction Identifier" is a backronym, at best. There were discussions 
-- some longer than you might expect -- about exactly what to call this 
thing, and precisely what acronym to use (with "RSID" being a leading 
contender for a while).

All of that said, your suggestion is a good one, so I've moved the 
"restriction identifier" expansion up into the introduction (on first 
mention), and also expanded it in the abstract.

> I'm confused by the SHOULD NOT in
>
>    o  max-fps, for frame rate in frames per second.  For encoders that
>        do not use a fixed framerate for encoding, this value should
>        restrict the minimum amount of time between frames: the time
>        between any two consecutive frames SHOULD NOT be less than 1/max-
>        fps seconds.
>
> The related description of max-pps, also uses a SHOULD, but explains why
> excursions outside this value are permissible.

Due to the fact that many codecs are shipped as black box software (or 
even firmware) components, it's possible that they lack the knobs to 
adjust certain characteristics of the output stream to the precision 
that their using software might like. For most of the restrictions 
described in this document, it's better to have a best-effort attempt to 
satisfy the requirement than it is to just ignore it as "something I 
can't do."

There might be other architectural trade-offs, unrelated to that issue, 
that also make this infeasible. Enumerating the ways in which this 
restriction cannot be satisfied would be an enormous undertaking.

So, basically, the "SHOULD" here is intended to mean that there may 
exist valid reasons in particular circumstances to ignore this 
particular requirement (even if those reasons aren't easily identifiable 
or enumerable right now), but the full implications must be understood 
and carefully weighed before choosing a different course.

In other words: this is a true "SHOULD" rather than a "MUST ... unless".


> (I'm also confused by "this value should restrict the minimum amount of time
> between frames" - I saw that you're using RFC 8174 for keywords, but is this
> just saying "this value restricts the minimum amount of time between frames",
> or something else?)

The latter -- I'll replace it with "...this value is used to restrict..."

> I note that 8.1 and 8.2 both include something like
>
>     Both
>     correspond to restrictions on receiver capabilities, and never
>     indicate sending restrictions.
>
> Is that true for all format parameters, for all codecs? If so, perhaps that
> should be explicit, in one of the normative sections (in which case, it
> wouldn't be useful here). If not, are implementations supposed to know what to
> do?

The above-quoted passage is an observation about RFC 7741, unrelated to 
"a=rid" behavior. The congruent statement in 8.2 is similarly making an 
observation about RFC 6184.


You can view the diffs between -14 and -15 at 
<https://www.ietf.org/rfcdiff?url1=draft-ietf-mmusic-rid-14&url2=draft-ietf-mmusic-rid-15>

/a