On 28 Jan 2016, at 16:09, Timothy B. Terriberry wrote:
Joel M. Halpern wrote:
The second, changing the text, is not something I or the IETF
community
support.
Well, I don't claim to speak for the whole IETF community, but this is
certainly something I support.
No one is claiming that someone is going to edit the RFC and claim to
have a new, better RFC (without going through the RFC update/errata
process), and the grant in question specifically disclaims anyone's
right to do that.
But, particularly for a document like this, which is defining a codec
mapping, I would hope that people would be free to borrow this text
for future mappings: either of Opus into another container or another
codec into Ogg, or even something totally unrelated to either if it
applies.
The IETF made an exception to the TLP policies for RFC 6716 not because
it was a codec definition per se, but because the normative definition
was in the code components. The BSD licensing for code components
already allowed derivative works for the code components themselves, but
there was a perceived need to also be able to modify text to document
any modification of "normative" code components.
That reasoning does not apply to this draft, since it does not have
normative code components. Can you elaborate on whether it is different
from other IETF standards track documents in some other way that might
justify such an exception?
Thanks!
Ben.