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

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

On 22 Dec 2015, at 14:31, Ron wrote:

> 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).

My question here is, why is this different for this draft than for any 
other RFC? Are there no other RFCs that get distributed by Debian or 
others with similar requirements? As you mention, RFC 6716 was unique in 
the fact that the code _was_ the spec. This draft does not share that 
property--so how is it different from any other standards-track RFC?

(As I just responded to Tim, I will not block IETF last call over this 
particular issue, but I expect that there is more discussion to be had 
before all is said and done.)

Thanks!

Ben.