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
ietf(_at_)ietf(_dot_)org mailing lists by 2016-01-27. Exceptionally, comments
may be
sent to iesg(_at_)ietf(_dot_)org 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.