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

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

On 11 Dec 2015, at 17:52, Ron wrote:


[I have no opinion on the "not valid audio samples" discussion.]

>
>>> - 5.1.1.4: Why not MUST?
>>
>> I think the idea was to allow assigning reserved values without 
>> explicitly
>> updating this specification. Even though I expect we _would_ want to 
>> update
>> this specification, given how long it's taken to get this draft 
>> published,
>> I'm wary of adding more pressure to people not to deploy new mappings
>> (because this RFC says they MUST not), even when it looks like 
>> they'll be
>> relatively stable and interoperable. At least not for the sole reason 
>> that
>> they haven't gotten an RFC number yet.
>
> Mark Harris and I had some discussion about this in the light of 
> whether
> it should be MUST or SHOULD - and perhaps the most interesting thing 
> to
> come out of that was wondering if we should in fact offer some advice 
> on
> ways that people can safely use experimental new mappings before a new
> channel mapping number has been allocated for them.
>
> One option would be to suggest they use mapping 255 (which existing
> decoders SHOULD/MUST ignore) along with a special comment field of
> their own choosing which allows experimental decoders to know how to
> treat that stream.

It's a common practice to mark certain code points or ranges as 
"experimental" in IETF specs.

>
> If the experiment fails, we lose an arbitrary unique name in the 
> comment
> space, if it succeeds and gets consensus, we can add a mapping for it,
> and decoders can continue to recognise both the magic comment and the
> new mapping as appropriate.  But we don't end up with incompatible 
> uses
> for the same mapping number.
>
> It may be a bit late in the game to be adding something like that to
> this document - but we probably also don't strictly need to, since it
> doesn't change anything that is already normatively specified, it 
> would
> just offer advice about how to proceed if you are developing a new
> mapping.  Which means maybe it's also uncontroversial to add it too?

I think adding that at this point would require mention on the working 
group list, to give people a chance to object. But that's not difficult.

>
>
>>> - 13:
>>> Is this needed? Are the IETF BCP 78 and 79 provisions incorrect for 
>>> this?
>>
>> This text was specifically requested by the Debian project (and I 
>> support it
>> personally). The same issue came up for RFC 6716 (for the same 
>> reasons). See
>> the discussion at
>> <https://www.ietf.org/mail-archive/web/codec/current/msg02845.html> 
>> and
>> <https://www.ietf.org/mail-archive/web/ietf/current/msg73116.html>.
>>
>> Reviewing those conversations, I do notice that the language of that 
>> section
>> was changed after last call for RFC 6716, but the corresponding 
>> language in
>> our source repository was not updated (because it was added to the 
>> document
>> boilerplate manually by the RFC Editor, and not included in a 
>> separate
>> section).
>
> Yes, I think this probably needs to be changed to something more like
> what IETF legal suggested for RFC 6716, granting "the right to extract
> sections 1 - 14 ...".  This allows people to make liberal use of the
> details in this document, but ensures they can't misrepresent any such
> use as somehow being an RFC.
>

Using the modified boilerplate from RFC 6716 would make more sense, if 
this document really needs it. But why does this document need it? It 
doesn't include code (normative or otherwise) like 6716. Or more to the 
point, why does this document need the extra grants more than any other 
standards-track RFC?

Thanks!

Ben.