Re: [codec] AD Evaluation of draft-ietf-codec-oggopus-09

["Ben Campbell" <[e-mail]>]

Hi, more comments inline. I deleted sections that do not seem to need 
further discussion.

Thanks!

Ben.

On 28 Dec 2015, at 7:00, Timothy B. Terriberry wrote:

[...]

>>>> What does it mean, in context, to "reject" headers?
>>>
>>> The same thing as rejecting a stream (i.e., don't try to play/decode
>>> it). Changed to say that instead.
>>
>> Which "that"?
>
> To quote the attached diff:
>
> -Implementations SHOULD reject ID headers which do not contain enough 
> data for
> - these fields, even if they contain a valid Magic Signature.
> +Implementations SHOULD reject streams with ID headers that do not 
> contain
> + enough data for these fields, even if they contain a valid Magic 
> Signature.

I don't find that in the attached diff.

>
>> Maybe this is a conventional way to say things in the codec 
>> community,
>> but when I see "reject" I usually think that means you generate some
>> sort of error back to the source of the thing you reject. (As opposed 
>> to
>> "ignore")
>
> Well, the most likely behavior here is to tell the user that the file 
> is not a valid Ogg Opus file, so your sense of "generating some sort 
> of error back" is in fact correct. But that makes some 
> application-level assumptions I'm not sure I'm comfortable writing 
> normative text around. Any ideas for a better way to phrase this?

"treat as invalid"?

>
>> If this spec reserves those values, then people still need to update 
>> it
>> to assign them. If you want to make it extensible, then perhaps it 
>> needs
>> an IANA registry, which, depending on the assignment policy, may not
>> require an RFC at all (seems like "expert review" or "specification
>> required" might make sense).
>
> An IANA registry actually does not seem like a terrible idea. Reading 
> RFC 5226 it doesn't seem too hard to set one up. I attempted to draft 
> some text.
>
>> it's what our "UPDATES" process is for. The idea that you might want 
>> to
>> informally experiment with different approaches is more convincing. 
>> But
>> if that is the case, it would be helpful to have a sentence to that
>> effect in the text.
>
> Okay, I will add one.


That text looks good, except that I would avoid normative language:

s/ "IANA SHALL..."/"IANA is requested to..."
s/"All maintenance within and additions to the contents of this name 
space MUST be according"/"Modifications to this registry follow..."

[...]

>
>
>>> For the second, this is the same as the previous comment about
>>> excessive allocations. I have no objection to changing this one, 
>>> either.
>>
>> I realize now there were 3 SHOULDs in that paragraph. I mean the one
>> about avoiding excessive allocations. It sounds like
>
> You may have forgotten to complete your thought here.

Apparently. I think I meant to delete "It sounds like". I think my 
original thought was about whether the SHOULD in "Demuxers SHOULD avoid 
attempting to allocate excessive amounts of memory when presented with a 
very large packet." should be a MUST or otherwise be explained. But on 
reflection, I think I am okay with that one.


>
>> Please consider saying something like "For more information on linear
>> prediction, see [XXX]." As it's currently stated, it looks like it 
>> says
>> MAY do X, where the reference specified X, which would require a
>> normative reference.
>
> That's a good suggestion. Done.
>
>> That language is a bit of a problem for a standards track RFC. If 
>> people
>
> You mean the current text, or the actual text that wound up in RFC 
> 6716?

Either, really. But obviously the 6716 was accepted, so it would be 
easier to accept due to precedent. The question I have is whether that 
precedent applies here. And you will recall that there was some 
tooth-gnashing over it for 6716 :-)

>
>> are really attached to it, we can pursue allowing it. But I expect
>> objections down the line. Keep in mind "NOTE WELL" says that any
>> contributions are subject to the rules of BCP 78 and 79.
>
> Yes, I think this has more to do with letting people use such 
> contributions _outside_ the context of the IETF (i.e., it grants 
> additional rights to those already granted in BCP 78 and 79, which I 
> understand is allowed).
>
> You are probably right about people objecting down the line (again), 
> but I am happy to address those objections when they come, as we did 
> for RFC 6716.
>
>> In any case, 6716 is a bit more code centric , so the discussion made
>> more sense there.
>
> Well, from our point of view, the XML source for both RFCs is included 
> in the repository with libopus, which is distributed in Debian. If we 
> didn't have some kind of grant like this, they would have to somehow 
> strip those documents out. So it is not so much the code being in the 
> RFC as the draft being distributed with the code.

I'm curious--are there no other RFCs distributed in Debian?

>
> In any case, I have attempted to draft an RFC Editor's note requesting 
> the same text that RFC 6716 used. Since that text grants a license 
> from the IETF Trust, instead of the authors, I assume that someone 
> from the Trust will have to approve of it, however (and reading 
> <http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-15.ppt> 
> it seems that the current opinion of the Trust is that this approach 
> is legally required).

I'll let that (as updated) go to IETF LC. But don't be surprised if 
there's further discussion to be had here.

>
> I have also gone through and finished removing the 2119 language for 
> general Ogg requirements.
>
> The diff of all changes is attached. If these look good (or if it's 
> simply helps in reviewing them) I can publish a new version.