Re: [codec] AD review: draft-ietf-codec-opus-11

[Ron <[e-mail]>]

On Thu, Apr 26, 2012 at 02:58:07PM -0500, Robert Sparks wrote:
> Note that I've requested IETF LC for version -12 (which includes
> this section).
> 
> I'd like to continue this conversation.
> 
> All the examples below are from before the current TLP (4) was in place.

Ah, that detail had slipped past me, though I did refer to the text of the
current TLP to see if the reasons for adding this were still applicable.


> As you note the TLP does not restrict the authors from making the
> grants you describe.
> Why is it important to include this statement as part of _this_ document?

We could indeed include this as a separate, external, grant statement.
It wasn't clear to me that this would be less confusing than having a
single document with a grant similar to the previous examples, but that
solution would also work for me, yes.

The curious twist with this particular document is that the normative
sections of it are the code, which are BSD licenced and allow the extra
modification rights granted by section 10 - while the informative parts
of the text may not be modified, and so could not be updated to document
any changes made to a particular implementation of the code without this
extra grant.  Since the encoder specification is also not normative, and
there is known scope to make improvements to it, the value of being able
to do this, both to the people making such changes, and to the WG which
may later find reason to fold them into an updated RFC, does seem more
than just whimsical in this case.


> If you are able to do what you need without the section (which is
> what I think you're saying
> below), removing it removes any _chance_ of confusion.
> 
> If you are not able to do what you want without the section, we need
> to talk about the TLP.
> (If that's the case, could you call out the constraint that is in your way?)

The restrictions on modification in 3.c and 3.d are I think the only part
of the TLP that we'd need to waive to match the intent of section 10.

The crux here (for me) is that Debian (among others) considers the right
to modification an essential element to not spending our entire lives as
developers reinventing the wheels of our fathers from scratch.  Not having
to ask permission (or to charter a WG) before performing some experiment
(of which most will never go anywhere before being abandoned) is a powerful
enabler of progress.  The ones that are successful will naturally seek for
broader acceptance and formalisation (and may then reasonably seek to
engage with or charter a WG to do so).  But being able to do (and publish)
those initial experiments is an important part of the process.

This WG has been a living testament to how the initial informal legwork
to produce two good codecs could then come together in an open and formal
collaboration and produce a result so far outstanding beyond prior art and
expectations, that both doubters and advocates had to compete over whose
jaws have since dropped the most.  Signing off on that, and sealing it as
an interoperable standard now seems correct.  Erecting artificial barriers
to further experimentation down these lines though, I'm less sure about ...
The right to future experimentation does not conflict with the desire for
a fixed standard guaranteeing interoperability today.  Both are essential
if progress is to continue its steady march.

So if there is a possibility of future versions of the TLP finding some
suitable language to accommodate this case, without the need for these
additional grants, and while still meeting the concerns of the IETF about
maintaining the integrity and reliability of its publications, then that
would be a very interesting conversation to continue.  Though it's surely
out of the scope of this WG (and I'm not sure offhand exactly where the
appropriate place for that would be).

A grant which allowed modification, but which prohibited misrepresenting
modified versions as an RFC, or which required attribution to the original
document and source, would remove the blocking constraint.  The former is
the condition we placed on the extra grant in section 10, the latter is
indicated by the current TLP, and would be an acceptable restriction if it
also allowed for producing clearly marked, modified works outside of a
formal working group.

If nothing else, this would permit Debian to include the relevant RFCs in
the documentation of packages which implement them.  But my broader wish
is for something a little more than that, for more than just Debian too.

 Cheers,
 Ron