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

[Ron <[e-mail]>]

On Mon, Dec 21, 2015 at 04:14:27PM -0600, Ben Campbell wrote:
> On 11 Dec 2015, at 17:52, Ron wrote:
> >
> >>>- 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.

I don't feel a strong need to see this added, but I mentioned it precisely
because it did seem like a discussion that should be aired on the list, if
only as a reminder for later about why we didn't do this and a note that
we did think about it.

I think Tim was already looking into what we need to do to set up an
IANA registry for this.  Which is seeming like it's probably the right
thing here.


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

The crux here is twofold.  We have organisations including, but not
limited to, Debian, who cannot distribute this included with an
implementation of it, unless it also grants people the right to
redistribute potentially modified versions of it.  A restriction
which prevents people from claiming that a modified version is an
RFC is fine, but people need to be able to cut selected parts out
of it (possibly to include just selected parts in the documentation
of their own library or applications), and/or adapt them for other
purposes too.

But beyond that, this document itself cribbed as much as we could
from the work of other previous Ogg mappings, and includes things
which are more generally useful, like the channel mapping definitions
and the downmixing matrices, just to pick two.

So it's not unreasonable to think this may in turn be a base which
future work is built on, and in fact we'd encourage that, because
it's definitely good not to change things that aren't broken and
don't need changing for other future mappings.

We'd also encourage that work to ultimately end up in an IETF working
group too - but any initial work at least is quite likely to start
outside of one until things are proven enough to take that next step.


Ultimately, the rationale for this is actually almost identical to
6716, the only difference is 6716 created the weird situation where
the normative part *was* the code, and it was already covered by a
grant even more liberal than what we'd like for the descriptive text.

The alternative (which we discussed with Robert Sparks for 6716) is
the authors could publish a separate "this is not an RFC" version
outside of the IETF with the extra grants - but that didn't seem like
it would create less confusion than the solution IETF legal arrived
at - which seems pretty close to ideal for any document that might
be the basis for future or continuing work.


We don't want people to be claiming that modified versions are an RFC,
but we would like them to be able to reuse anything out of this that
it makes sense to, as freely as we can allow them to.  Otherwise we
just artificially stifle further progress (or force everyone to turn
a blind eye when people do things we didn't explicitly grant them
the right to do - and that is the part I think we all share the desire
to avoid).

  Cheers,
  Ron