Re: [codec] Last Call: <draft-ietf-codec-oggopus-10.txt> (Ogg Encapsulation for the Opus Audio Codec) to Proposed Standard

["Joel M. Halpern" <[e-mail]>]

I think that this is a very bad idea.  The point of doing the work to 
create an RFC is to reach agreements on what the words should be. 
Saying after that "oh, but anyone else can change these words any way 
they want" just does not work for me.

More generally, I think we need to establish that this is not how we 
work, rather than letting folks do this more and more often.

In terms of documentation, I am actually very concerned with this 
apparent effort for us to support documenting of protocols and behaviors 
that do not comply with the RFC.  That is not our purpose.

Yours,
Joel

On 1/27/16 4:09 PM, Ben Campbell wrote:
> On 27 Jan 2016, at 14:44, Robert Sparks wrote:
>
>> This document has an unusual feature that I think needs to be
>> highlighted in this last call.
>>
>> Section 13 instructs the RFC editor to:
>>> In the Copyright Notice at the start of the document, the following
>>> paragraph is to be appended after the regular copyright notice text:
>>>
>>> "The licenses granted by the IETF Trust to this RFC under Section 3.c
>>> of the Trust Legal Provisions shall also include the right to extract
>>> text from Sections 1 through 14 of this RFC and create derivative
>>> works from these extracts, and to copy, publish, display, and
>>> distribute such derivative works in any medium and for any purpose,
>>> provided that no such derivative work shall be presented, displayed,
>>> or published in a manner that states or implies that it is part of
>>> this RFC or any other IETF Document."
>> I understand why we did what we did for RFC6716 (the specification for
>> OPUS, where the additional grants were to deal with the code being
>> normative).
>
> For the record, the rights grant in RFC 6716 covered the textual parts
> in addition to the code parts. Given that the code components are
> already covered by the BSD licensing option in the TLP, this seems
> mainly relevant to the textual parts.
>
> I don't mean to refer to that as precedent; only to suggest that if
> people think it's not appropriate now, it might not have been a good
> idea then either.
>
>>
>> I do not think it is the right thing to do for this document.
>>
>> It would have been better if the document, or the shepherd's writeup,
>> spelled this issue out. For now, Ron's message at
>> <https://mailarchive.ietf.org/arch/msg/codec/5pl4RhroYqB9vLRnOyeIKOC8lkA>
>> is a good place to start - scroll down to the section starting "The
>> crux here is twofold."
>
> Thanks for spelling it out now :-)
>
>>
>> RjS
>>
>>
>>
>>
>> On 1/13/16 8:15 AM, The IESG wrote:
>>> The IESG has received a request from the Internet Wideband Audio
>>> Codec WG
>>> (codec) to consider the following document:
>>> - 'Ogg Encapsulation for the Opus Audio Codec'
>>> <draft-ietf-codec-oggopus-10.txt> as Proposed Standard
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits
>>> final comments on this action. Please send substantive comments to the
>>> [e-mail] mailing lists by 2016-01-27. Exceptionally, comments
>>> may be
>>> sent to [e-mail] instead. In either case, please retain the
>>> beginning of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>> This document defines the Ogg encapsulation for the Opus interactive
>>> speech and audio codec.  This allows data encoded in the Opus format
>>> to be stored in an Ogg logical bitstream.
>>>
>>> Please note that the document makes normative references to RFCs 3533
>>> and 4732, which are informational.
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/
>>>
>>> IESG discussion can be tracked via
>>> https://datatracker.ietf.org/doc/draft-ietf-codec-oggopus/ballot/
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>
>