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

From: The IESG <[email-masked]>
Date: Wed, 13 Jan 2016 06:15:06 -0800

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
[email-masked] mailing lists by 2016-01-27. Exceptionally, comments may be
sent to [email-masked] 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.

---

From: Robert Sparks <[email-masked]>
Date: Wed, 27 Jan 2016 14:44:41 -0600

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

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

RjS

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 Jan 2016 15:09:47 -0600

> OPUS, where the additional grants were to deal with the code being 

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.

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Jan 2016 15:23:37 -0500

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

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 28 Jan 2016 15:59:11 -0500

On 01/28/2016 03:23 PM, Joel M. Halpern wrote:
> 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.

The main issue here is not that people would like to change what the
RFC says. It's quite the opposite in fact. People would like to be
able to reuse parts the RFC text in other contexts (e.g. documentation
for a piece of software that relies on several RFCs). Without
additional rights, they would have to paraphrase the content of RFCs,
which would actually lead to more compatibility problems. Also, the
proposed text already includes the condition "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". Given that, I'm not sure what the problem is.

Cheers,

	Jean-Marc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 28 Jan 2016 16:07:28 -0500

We (the IETF) had this discussion regarding our copyright rules.  We 
discussed the tension with reuse by open source documentation where the 
community could not commit to copying things without changing them  (If 
they could make that promise, there would be no problem as such copying 
is already permitted.)

So either the open source communities needs to be able to change the 
text, or it does not need to be able to change the text, or it has 
created rules for itself where it needs to be permitted to change the 
text even though it does not actually want to change.

The first, not changing the text, is already covered.
The second, changing the text, is not something I or the IETF community 
support.
The third would seem to be a different problem, and asking the IEtF to 
change its rules for that seems a VERY strange answer.

Yours,
Joel

On 1/28/16 3:59 PM, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWqoEbAAoJEJ6/8sItn9q9a1wH+wY6k2UP7iYQjLng6XQ79hgD
> W7pklezNzSXUlohTcUMK6s9n03fa1rK2jJcslDGgpO/qqzqdUDbEAlqqZhH2H+hc
> KXac5S6XVp56k0/QGPuyap9Ijshurs5ehvnYvBAuqcWAb9u9HaYlylZtH9/e482c
> Cretot8m5d2quZ1i3j23HccrfLiyve097OufY2sdgbzL1Xzu5qwcn/xJh27ccFtN
> 0Cbhigr7r6b8rNM/9VHSIF50shM2EuqULHBj+ABJbGfGIcWq4zRVJOsY0OqMaFcS
> 42y/974N/Admp6en1kITfdD6ZOn3jJpON6QOpaFRiGCiW3OsGs9AMCjZ+do4KM4=
> =WfO7
> -----END PGP SIGNATURE-----
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 28 Jan 2016 16:29:12 -0500

> The second, changing the text, is not something I or the IETF community

It depends on your definition of "changing the text". There's a lot of
pretty reasonable changes you can make to get the RFC text to better fit
within a new document without changing the meaning. Any of these sure
beats "paraphrasing a section of the RFC" from a compatibility point of
view.

> change its rules for that seems a VERY strange answer.

There's certainly a bit of that as well. But keep in mind there's no
"chair of the open source community" who can change all the rules.

Cheers,

	Jean-Marc

> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 28 Jan 2016 14:09:46 -0800

> The second, changing the text, is not something I or the IETF community

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.

---

From: Ron <[email-masked]>
Date: Fri, 29 Jan 2016 13:40:44 +1030

Hi Robert,

On Wed, Jan 27, 2016 at 02:44:41PM -0600, Robert Sparks wrote:
> This document has an unusual feature that I think needs to be highlighted in
> this last call.
> 
> 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).
> 

Could you spell out in a bit more detail what you see as being different
for this document, and what your concerns are with either (or both!) the
letter and the intent in this case.

I really would like to understand your concerns, and if necessary have
this evolve into language that does cover everyone's needs and fears as
comprehensively as we can.

We've got nearly 4 years behind us now with no terrible abuse of this
grant having occurred for 6716, but if you think it's less than ideal,
I'd like us to consider ways we can still improve on that.

  Cheers,
  Ron

---

From: Ron <[email-masked]>
Date: Fri, 29 Jan 2016 15:54:42 +1030

Hi Joel,

On Thu, Jan 28, 2016 at 03:23:37PM -0500, Joel M. Halpern wrote:
> The point of doing the work to create an RFC is to reach agreements on
> what the words should be.

Yes, and we spent a lot of time and put a lot of work into making sure
we picked the best words to clearly describe what it was that we wanted
to define.

Which is exactly why we want as many people as possible to reuse those
words *precisely*, rather than having to rewrite them or paraphrase them
willy-nilly, when they need them to appear in some other context where
reproducing the full document in its entirety would not be appropriate
or helpful for perfect understanding.

If I want to provide a function in a library which allows the caller to
construct or manipulate an OggOpus header structure, it would be much
better if I can quote the relevant parts of this document directly, with
some surrounding text that talks about the other constraints and return
codes of my function, than it would be for me to invent new ways of
describing that (for no other reason than I'm not permitted to cut and
paste that and manipulate it to fit my documentation coherently without
this extra grant).

I think you and I are in violent agreement here that we want these words
to be preserved as perfectly as possible everywhere they are used in
reference to this standard.

> they want" just does not work for me.

Fortunately, that's not what we are saying.  We expressly state that
you can not call anything you extracted from this an RFC.

We don't want people to misrepresent this, because we already spend
enough time correcting people who accidentally made some error in
their implementation.

We don't think that situation would be improved by *forcing* people
to change these words to use them in their own descriptions and
library/application documentation.

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

Again, I think we are in violent agreement with what I *think* is your
real concern here.  You just appear to be misunderstanding what the
"apparent effort" is aimed at doing here - and how by not allowing
people to use selected and context appropriate parts of these words
verbatim, you are actually forcing them to create precisely the terrible
outcome that you fear.

Because the only other alternative to that, is they completely ignore
the licence grant on this document, and we turn a blind eye to that
and pretend they didn't do that and don't prosecute them for it.

Which isn't a good outcome either, for lots of reasons.  I know a lot
of corporate licence grants work that way, but I don't think we win
at this by forcing people who do respect licences to act in a way that
we seem to agree we all would rather they didn't (and so rewrite this
document in their own words which they can then redistribute).

On Thu, Jan 28, 2016 at 04:07:28PM -0500, Joel M. Halpern wrote:
> community could not commit to copying things without changing them  (If they
> could make that promise, there would be no problem as such copying is
> already permitted.)

I can't extract portions of this document, to copy verbatim just the
salient parts of it into a context where that is what needs to be
highlighted or explained.

At least not without this extra grant, which is why we want it, or
something like it, to be part of how these words are licenced for
reuse.

Doing that is indistinguishable from "modification".

We're running on the assumption that people with good intent should
be able to misrepresent this document as little as possible in their
genuine use of it, with the guarantee that people with bad intent
can't misrepresent their corruption of it as an RFC.

If you're coming at this with the mindset of it being some sort of
ideological war that those evil open source commies are waging on
our purity of essence, then I can see how you might be missing or
blinded to the real concern that we have about people using and
implementing this standard as accurately and correctly as possible.

What we'd like to see happen is that we *strengthen* the IETF's
authority as the source of the words that everyone uses in their
own dissemination of understanding this standard.  And you don't
do that by saying "you must paste in the entire War And Peace epic,
everywhere you want to do that, or you're allowed to use none of it".

> So either the open source communities needs to be able to change the text,
> or it does not need to be able to change the text, or it has created rules
> for itself where it needs to be permitted to change the text even though it
> does not actually want to change.

... or they have decided that the only protection they have against
abuse of their own licence conditions is to strictly respect the
licences that others have given them.

Which means they are in a position of not being able to do things
which the IETF would probably agree is in its best interests and was
its intent, and which it can only otherwise turn a blind eye to when
people and companies who don't show that respect do things which the
letter of the licence grant did not allow them to do.

RFC 3951 was a poster child for the (I believe unintended) consequences
of that.  I'm sure there are certainly many others.

The IETF has shown that it has learnt from that, and improved things
somewhat.  And what we discussed and did for 6716 shows that there is
understanding about how we're still not quite where we really want to
be yet ...

Unless "where you want us to be" speaking as an individual is for these
standards to only be maximally useful to people who ignore the licence
granted to use them.  Which doesn't seem like a defensible position.

Let me quote the explanation I gave before this went to IETF LC, and
offer another example of why this is important, and why it is being
recognised more broadly by other standards organisations too ...

In https://www.ietf.org/mail-archive/web/codec/current/msg03163.html
I wrote:
> In the context of this draft, we *want* people to be able to use it.
> And personally, I'd much rather have them quote parts of it verbatim,
> modified to fit coherently into their own documentation, than have them
> paraphrase those parts of it to avoid the legal restriction - possibly
> introducing new ambiguities or misunderstandings, which may then become
> quoted even more widely than the original RFC, simply because people are
> allowed to reproduce that error in their own work, but aren't allowed to
> quote or redistribute the RFC directly ...
>
> That outcome seems fairly directly counterproductive to what we want to
> achieve by having a formal standard that we'd like everyone to follow.
>
> We'd have a kind of SDO version of Gresham's Law undermining the value
> and currency of the words we worked so hard to choose carefully here.
> The aim here is not to dilute the IETF's authority over this document,
> but to give that authority the greatest possible value we can.

The standing proof of that (though certainly not the only example) is
the POSIX manual pages.

A lot of programmers love manual pages as a primary source of
documentation, but for many years, we faced the same sort of
restrictions as we do here without this grant for creating and
distributing them.

And what was the result of that?

An entire shadow standard emerged, of manual pages rewritten from scratch
to describe the behaviour of POSIX functions in someone's own words.
Which people then used as their primary source of information about them,
and all of the errors, and omissions, and small differences became deeply
engrained in the body of extant code that people came to depend on.

Sometimes those errors would get noticed and fixed, and sometimes it was
far too late to put the djinn back in the bottle and the chaos that
caused would become the new reality everyone had to deal with.

I'm sure there's an awesome April 1 RFC waiting to be written where the
history of that happening to standards produced here is dissected as a
hilarious yet sad warning to future participants.

We can't (always) fix the past, but it is our responsibility to learn
from it and try not to stuff up the future.

In 2004, the IEEE and The Open Group granted permission to include
extracts of their documents in derived works which included manual pages
that detailed the known deviations which programmers may really have to
deal with in the wild when writing portable code.

In 2014, they renewed that grant for their latest publication of them,
so it would appear their experience after 10 years, was that the upside
benefits had clearly exceeded any downside risk.

https://lwn.net/Articles/581858/

If the wording of the extra grant that IETF-legal came up with for 6716
is somehow not optimal, I'd love for us to have that discussion and try
to address any substantive concerns people have.  But in order to do
that, I think those need to be expressed a bit more concretely than
"this is not how we do things", or "I'm afraid", or by picturing it as
some sort of "them against us" agenda which is only "apparent" to some
individual participants.

I personally have a strong interest in open source software, not as an
ideology, but because as a methodology It Works.  I likewise have a
strong interest in the success and the strength of the IETF as an SDO,
again, because the methodology used here Really Works to produce widely
accepted standards that people can really use.

I don't think either group can yet claim to be a "solved problem".
I think we both have a lot we can learn from each other still, and I
think we have enough overlap for that to occur naturally by osmosis.
I'd rather we didn't squander that by claiming there is a barrier
between us which is impermeable as a matter of dogma.

So if there is a real problem here, let's discuss what that is, not
handwave it away as some sort of outside conspiracy to destroy our
way of life.

The IETF is one of the best friends and resources that the developers
of openly interoperable systems have.  There's no way I'd want it on
my permanent record that I'd done anything to harm that in any way.
And I don't see how this would.  But if we've missed something that
we need to pay more attention to, that's where this process excels,
so let's use it and fix any actual devil we can see in the details.

  As an individual participant who helped author this draft,
  Ron

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Jan 2016 01:10:09 -0500

If what is needed is the right to excerpt, with unmodified content 
(format modification clearly would be allowed) portions of the RFC, I 
would support that.  I understand your reasons, as set forth below, for 
seeing that as useful.

But that is not what the text in the draft asks for.  It asks for the 
right to create derivative works.  In copyright terms, that means the 
right to modify the text.  That is where I have trouble.

Yours,
Joel

---

From: Ron <[email-masked]>
Date: Fri, 29 Jan 2016 18:33:30 +1030

On Fri, Jan 29, 2016 at 01:10:09AM -0500, Joel M. Halpern wrote:
> If what is needed is the right to excerpt, with unmodified content (format
> modification clearly would be allowed) portions of the RFC, I would support
> that.  I understand your reasons, as set forth below, for seeing that as
> useful.
> 
> But that is not what the text in the draft asks for.  It asks for the right
> to create derivative works.  In copyright terms, that means the right to
> modify the text.  That is where I have trouble.

I think I understand the sort of abuse you'd like to ensure doesn't
happen as a result of this, but I think we have that covered by firmly
saying that if you do excerpt this in any way, you must remove the IETF
header and must not claim your document is an RFC.

Otherwise, excerpting it is essentially indistinguishable from modifying
it anyway ...

To show that as a pathological case, I could excerpt 3 words from it
somewhere, insert of a few of my own, skip a few from the RFC and then
excerpt some more of it.

Which could be a completely reasonable thing to do if I'm explaining how
the requirements of calling my function fit together with the requirements
of the standard.

Or which could be used to excerpt individual sequences of letters from
it to create a quote from Shakespeare.

And I don't really see how we can sensibly separate those two cases in
a way that someone sufficiently crazy couldn't make a joke of.

We can however clearly point at someone who is claiming that something
is an RFC when it is not a published and unmodified RFC and come down
on them like a ton of bricks.  And I fully support that we should be
able to do that.

It's just not clear to me what other case of using some other part of
the text would create a problem for us.  But if people can describe one
we can (and should) consider the best way to mitigate it.