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

From: "Ben Campbell" <[email-masked]>
Date: Mon, 11 Jan 2016 22:15:41 -0600

Hi, more comments inline. I deleted sections that do not seem to need 
further discussion.

Thanks!

Ben.

On 28 Dec 2015, at 7:00, Timothy B. Terriberry wrote:

[...]

>>>> What does it mean, in context, to "reject" headers?
>>>
>>> The same thing as rejecting a stream (i.e., don't try to play/decode
>>> it). Changed to say that instead.
>>
>> Which "that"?
>
> To quote the attached diff:
>
> -Implementations SHOULD reject ID headers which do not contain enough 
> data for
> - these fields, even if they contain a valid Magic Signature.
> +Implementations SHOULD reject streams with ID headers that do not 
> contain
> + enough data for these fields, even if they contain a valid Magic 
> Signature.

I don't find that in the attached diff.

>
>> Maybe this is a conventional way to say things in the codec 
>> community,
>> but when I see "reject" I usually think that means you generate some
>> sort of error back to the source of the thing you reject. (As opposed 
>> to
>> "ignore")
>
> Well, the most likely behavior here is to tell the user that the file 
> is not a valid Ogg Opus file, so your sense of "generating some sort 
> of error back" is in fact correct. But that makes some 
> application-level assumptions I'm not sure I'm comfortable writing 
> normative text around. Any ideas for a better way to phrase this?

"treat as invalid"?

>
>> If this spec reserves those values, then people still need to update 
>> it
>> to assign them. If you want to make it extensible, then perhaps it 
>> needs
>> an IANA registry, which, depending on the assignment policy, may not
>> require an RFC at all (seems like "expert review" or "specification
>> required" might make sense).
>
> An IANA registry actually does not seem like a terrible idea. Reading 
> RFC 5226 it doesn't seem too hard to set one up. I attempted to draft 
> some text.
>
>> it's what our "UPDATES" process is for. The idea that you might want 
>> to
>> informally experiment with different approaches is more convincing. 
>> But
>> if that is the case, it would be helpful to have a sentence to that
>> effect in the text.
>
> Okay, I will add one.

That text looks good, except that I would avoid normative language:

s/ "IANA SHALL..."/"IANA is requested to..."
s/"All maintenance within and additions to the contents of this name 
space MUST be according"/"Modifications to this registry follow..."

[...]

>
>
>>> For the second, this is the same as the previous comment about
>>> excessive allocations. I have no objection to changing this one, 
>>> either.
>>
>> I realize now there were 3 SHOULDs in that paragraph. I mean the one
>> about avoiding excessive allocations. It sounds like
>
> You may have forgotten to complete your thought here.

Apparently. I think I meant to delete "It sounds like". I think my 
original thought was about whether the SHOULD in "Demuxers SHOULD avoid 
attempting to allocate excessive amounts of memory when presented with a 
very large packet." should be a MUST or otherwise be explained. But on 
reflection, I think I am okay with that one.

>
>> Please consider saying something like "For more information on linear
>> prediction, see [XXX]." As it's currently stated, it looks like it 
>> says
>> MAY do X, where the reference specified X, which would require a
>> normative reference.
>
> That's a good suggestion. Done.
>
>> That language is a bit of a problem for a standards track RFC. If 
>> people
>
> You mean the current text, or the actual text that wound up in RFC 
> 6716?

Either, really. But obviously the 6716 was accepted, so it would be 
easier to accept due to precedent. The question I have is whether that 
precedent applies here. And you will recall that there was some 
tooth-gnashing over it for 6716 :-)

>
>> are really attached to it, we can pursue allowing it. But I expect
>> objections down the line. Keep in mind "NOTE WELL" says that any
>> contributions are subject to the rules of BCP 78 and 79.
>
> Yes, I think this has more to do with letting people use such 
> contributions _outside_ the context of the IETF (i.e., it grants 
> additional rights to those already granted in BCP 78 and 79, which I 
> understand is allowed).
>
> You are probably right about people objecting down the line (again), 
> but I am happy to address those objections when they come, as we did 
> for RFC 6716.
>
>> In any case, 6716 is a bit more code centric , so the discussion made
>> more sense there.
>
> Well, from our point of view, the XML source for both RFCs is included 
> in the repository with libopus, which is distributed in Debian. If we 
> didn't have some kind of grant like this, they would have to somehow 
> strip those documents out. So it is not so much the code being in the 
> RFC as the draft being distributed with the code.

I'm curious--are there no other RFCs distributed in Debian?

>
> In any case, I have attempted to draft an RFC Editor's note requesting 
> the same text that RFC 6716 used. Since that text grants a license 
> from the IETF Trust, instead of the authors, I assume that someone 
> from the Trust will have to approve of it, however (and reading 
> <http://www.ietf.org/proceedings/85/slides/slides-85-iesg-opsandtech-15.ppt> 
> it seems that the current opinion of the Trust is that this approach 
> is legally required).

I'll let that (as updated) go to IETF LC. But don't be surprised if 
there's further discussion to be had here.

>
> I have also gone through and finished removing the 2119 language for 
> general Ogg requirements.
>
> The diff of all changes is attached. If these look good (or if it's 
> simply helps in reviewing them) I can publish a new version.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 11 Jan 2016 22:22:33 -0600

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.

---

From: Ron <[email-masked]>
Date: Wed, 13 Jan 2016 06:47:56 +1030

On Mon, Jan 11, 2016 at 10:22:33PM -0600, Ben Campbell wrote:
> >>>what IETF legal suggested for RFC 6716, granting "the right to extract
> >>>details in this document, but ensures they can't misrepresent any such
> >>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
> My question here is, why is this different for this draft than for any other
> RFC?

I think there's sort of two questions embedded in that, both of which
are relevant and important, but only one of which is sort of in the
scope for this WG to address (which doesn't mean I wouldn't like to
also see the other addressed in whatever is the right scope for it :)

*What* is different, is that the authors are very conscious of this
problem and would very much like to avoid having this RFC caught up
in it, in whatever the best way we might do that would be.  That seems
like a discussion we can reasonably have here (though of course it
won't end here, it still needs broader approval too).

*How* this is document is different from other RFCs, is a somewhat
bigger can of worms.  Because I do actually think that a lot of other
RFCs would stand to benefit from something like this too.

The only ones that maybe wouldn't, would be documents in the mold of
"here's some arbitrary proclamation, that's necessary for interop,
but that there really isn't any scope at all for further development
or research on, unless we find a reason to make an updated arbitrary
proclamation on this later".

But I'd tend to think they are probably in the minority, and most
non-trivial RFCs would be open to further research, possibly initially
outside of the IETF before that research is proven enough to then be
formalised for wider use on one of the RFC tracks.  For things like
that, I think the interesting question is why should the IETF prohibit
that work by default (or only permit it by everyone turning a blind
eye to breaches of the licencing provisions that were granted).

That is a discussion I'd like to have, but here doesn't seem to be
the right place to have it.  Nutting through the details for this
particular draft though might be helpful to that process.  If only
to establish where the right bounds may be, and give everyone some
experience that the world doesn't end and chaos doesn't reign if we
do this.

> Are there no other RFCs that get distributed by Debian or others with
> similar requirements?

There are some other RFCs which can be and are distributed by people
in this position.  But what those have in common is they *all* have
some extra grant permitted in their text to make that possible.

The big difference that occurred with 6716, was that rather than
adding an arbitrary clause somewhere in the text (which tends to
be a bit different if not substantively similar in each document),
IETF legal approved some alternative header boilerplate, which I
do think is a big improvement.  Having a standard grant for this
makes it a lot easier for everyone to know where they stand, and
for the IETF itself to issue a later clarification of its position
if some unforeseen corner case should ever make that necessary.

Debian definitely isn't the only user affected by this, but they
do make a reasonably good John Doe that we can discuss specific
details around.

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

I don't think that's actually the important property of 6716 which
gave adding this grant to it real value.  The important part was
that there was a reasonable expectation other users would want to
publish all or some of it in contexts which the standard grant
would otherwise prohibit.

As another example, it might be impossible for me to use parts of
that text, or even the whole document, in a GPL licenced work (in
any way more than just "mere aggregation"), since the added
restrictions could be in conflict with the GPL's licence conditions
(which mandate no additional restrictions), and the resulting work
would be undistributable by anyone who took respecting licences
seriously.  There's a big can of worms all its own in that example,
so again, it's better considered as a poster child for a class of
problems we'd be wise to avoid than a specific individual exception
that needs to be singled out for special treatment.

In 6716 we just had the added paradox of the normative part of the
spec already having a liberal licence grant, while the informative
parts of it did not without the extra grant.

> before all is said and done.)

Nod.  I quite expect there will be too :)  But I think it is a useful
thing for us to inch toward some sort of broader consensus on, that
takes everyone's concerns and use cases and fears into account.

I think in some ways, part of the crux of the problem is that historically
many of the participants have come from corporate backgrounds, where the
default legal presumption is to prohibit as much as you think you can get
away with prohibiting, to the point of actually outlawing things you do
expect and want your users to do, but then ignoring widespread breaches of
that unless someone crosses some line you don't like, in which case you
have the biggest possible bag of ammo for your lawyers to fire at them.

But that kind of falls down when you have organisations that do take such
licence grants seriously, and don't ignore "inconvenient" parts of them
to use them anyway in contravention of what was actually allowed.

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.

These are all good questions to ask though, and I would like to see
this bubble up into some good answers the IETF can build consensus on.

  Cheers,
  Ron

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jan 2016 13:17:15 -0800

> I don't find that in the attached diff.

I meant the one that was attached to the e-mail to which you were 
responding: 
https://www.ietf.org/mail-archive/web/codec/current/msg03150.html

Sorry for being unclear.

>> normative text around. Any ideas for a better way to phrase this?

I can work with that.

> space MUST be according"/"Modifications to this registry follow..."

Normative language removed.

> tooth-gnashing over it for 6716 :-)

I remember. I think the precedent does apply, since the issue is 
including the RFC with the code package, not whether or not the RFC 
itself contains code.

> I'm curious--are there no other RFCs distributed in Debian?

Ron may have a better idea of real numbers, but it is certainly an issue 
that has come up before. See 
<https://wiki.debian.org/NonFreeIETFDocuments>, which links to a list of 
bugreports. As Ron points out, there are a few RFCs that are distributed 
because they included additional grants (after which the original grants 
in draft-ietf-codec-opus and this draft were modeled). It does not 
appear as if that page has been updated since RFC 6716 was published, 
though.

> there's further discussion to be had here.

I fully expect it.

Additional changes for the above attached. If there are no more 
comments, I can publish a new version with all of these included.
>From 451cc67936db4220038221aff684be8c617c751a Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jan 2016 13:08:27 -0800
Subject: [PATCH 1/2] oggopus: Replace 'reject' with 'treat as invalid'.

>From AD review.
---
 doc/draft-ietf-codec-oggopus.xml | 48 ++++++++++++++++++++++------------------
 1 file changed, 26 insertions(+), 22 deletions(-)

diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index 7489c20..b343e42 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -507,27 +507,27 @@ This does not affect the behavior of pre-skip: exactly 'pre-skip' samples
  initial PCM sample position is greater than zero.
 </t>
 
 <t>
 On the other hand, a granule position that is smaller than the number of
  decoded samples prevents a demuxer from working backwards to assign each
  packet or each individual sample a valid granule position, since granule
  positions are non-negative.
-An implementation MUST reject as invalid any stream where the granule position
+An implementation MUST treat any stream as invalid if the granule position
  is smaller than the number of samples contained in packets that complete on
  the first audio data page with a completed packet, unless that page has the
  'end of stream' flag set.
 It MAY defer this action until it decodes the last packet completed on that
  page.
 </t>
 
 <t>
-If that page has the 'end of stream' flag set, a demuxer MUST reject as invalid
- any stream where its granule position is smaller than the 'pre-skip' amount.
+If that page has the 'end of stream' flag set, a demuxer MUST treat any stream
+ as invalid if its granule position is smaller than the 'pre-skip' amount.
 This would indicate that there are more samples to be skipped from the initial
  decoded output than exist in the stream.
 If the granule position is smaller than the number of decoded samples produced
  by the packets that complete on that page, then a demuxer MUST use an initial
  granule position of '0', and can work forwards from '0' to timestamp
  individual packets.
 If the granule position is larger than the number of decoded samples available,
  then the demuxer MUST still work backwards as described above, even if the
@@ -751,23 +751,24 @@ Its contents are specified in <xref target="channel_mapping"/>.
 </t>
 </list>
 </t>
 
 <t>
 All fields in the ID headers are REQUIRED, except for the channel mapping
  table, which MUST be omitted when the channel mapping family is 0, but
  is REQUIRED otherwise.
-Implementations SHOULD reject streams with ID headers that do not contain
- enough data for these fields, even if they contain a valid Magic Signature.
+Implementations SHOULD treat a stream as invalid if it contains an ID header
+ that does not have enough data for these fields, even if it contain a valid
+ Magic Signature.
 Future versions of this specification, even backwards-compatible versions,
  might include additional fields in the ID header.
 If an ID header has a compatible major version, but a larger minor version,
- an implementation MUST NOT reject it for containing additional data not
- specified here, provided it still completes on the first page.
+ an implementation MUST NOT treat it as invalid for containing additional data
+ not specified here, provided it still completes on the first page.
 </t>
 
 <section anchor="channel_mapping" title="Channel Mapping">
 <t>
 An Ogg Opus stream allows mapping one number of Opus streams (N) to a possibly
  larger number of decoded channels (M&nbsp;+&nbsp;N) to yet another number of
  output channels (C), which might be larger or smaller than the number of
  decoded channels.
@@ -1180,19 +1181,20 @@ This field contains a single user comment string.
 There is one for each user comment indicated by the 'user comment list length'
  field.
 </t>
 </list>
 </t>
 
 <t>
 The vendor string length and user comment list length are REQUIRED, and
- implementations SHOULD reject comment headers that do not contain enough data
- for these fields, or that do not contain enough data for the corresponding
- vendor string or user comments they describe.
+ implementations SHOULD treat a stream as invalid if it contains a comment
+ header that does not have enough data for these fields, or that does not
+ contain enough data for the corresponding vendor string or user comments they
+ describe.
 Making this check before allocating the associated memory to contain the data
  helps prevent a possible Denial-of-Service (DoS) attack from small comment
  headers that claim to contain strings longer than the entire packet or more
  user comments than than could possibly fit in the packet.
 </t>
 
 <t>
 Immediately following the user comment list, the comment header MAY
@@ -1205,19 +1207,20 @@ This allows informal experimentation with the format of this binary data until
  it can be specified later.
 </t>
 
 <t>
 The comment header can be arbitrarily large and might be spread over a large
  number of Ogg pages.
 Implementations MUST avoid attempting to allocate excessive amounts of memory
  when presented with a very large comment header.
-To accomplish this, implementations MAY reject a comment header larger than
- 125,829,120&nbsp;octets, and MAY ignore individual comments that are not fully
- contained within the first 61,440 octets of the comment header.
+To accomplish this, implementations MAY treat a stream as invalid if it has a
+ comment header larger than 125,829,120&nbsp;octets, and MAY ignore individual
+ comments that are not fully contained within the first 61,440&nbsp;octets of
+ the comment header.
 </t>
 
 <section anchor="comment_format" title="Tag Definitions">
 <t>
 The user comment strings follow the NAME=value format described by
  <xref target="vorbis-comment"/> with the same recommended tag names:
  ARTIST, TITLE, DATE, ALBUM, and so on.
 </t>
@@ -1294,28 +1297,29 @@ In the authors' investigations they were not applied consistently or broadly
 <t>
 Technically, valid Opus packets can be arbitrarily large due to the padding
  format, although the amount of non-padding data they can contain is bounded.
 These packets might be spread over a similarly enormous number of Ogg pages.
 When encoding, implementations SHOULD limit the use of padding in audio data
  packets to no more than is necessary to make a variable bitrate (VBR) stream
  constant bitrate (CBR), unless they have no reasonable way to determine what
  is necessary.
-Demuxers SHOULD reject audio data packets (treat them as if they were malformed
- Opus packets with an invalid TOC sequence) larger than 61,440 octets per
- Opus stream, unless they have a specific reason for allowing extra padding.
+Demuxers SHOULD treat audio data packets as invalid (treat them as if they were
+ malformed Opus packets with an invalid TOC sequence) if they are larger than
+ 61,440&nbsp;octets per Opus stream, unless they have a specific reason for
+ allowing extra padding.
 Such packets necessarily contain more padding than needed to make a stream CBR.
 Demuxers MUST avoid attempting to allocate excessive amounts of memory when
  presented with a very large packet.
-Demuxers MAY reject or partially process audio data packets larger than
- 61,440&nbsp;octets in an Ogg Opus stream with channel mapping families&nbsp;0
- or&nbsp;1.
-Demuxers MAY reject or partially process audio data packets in any Ogg Opus
- stream if the packet is larger than 61,440&nbsp;octets and also larger than
- 7,680&nbsp;octets per Opus stream.
+Demuxers MAY treat audio data packets as invalid or partially process them if
+ they are larger than 61,440&nbsp;octets in an Ogg Opus stream with channel
+ mapping families&nbsp;0 or&nbsp;1.
+Demuxers MAY treat audio data packets as invalid or partially process them in
+ any Ogg Opus stream if the packet is larger than 61,440&nbsp;octets and also
+ larger than 7,680&nbsp;octets per Opus stream.
 The presence of an extremely large packet in the stream could indicate a
  memory exhaustion attack or stream corruption.
 </t>
 <t>
 In an Ogg Opus stream, the largest possible valid packet that does not use
  padding has a size of (61,298*N&nbsp;-&nbsp;2) octets.
 With 255&nbsp;streams, this is 15,630,988&nbsp;octets and can
  span up to 61,298&nbsp;Ogg pages, all but one of which will have a granule
-- 
1.8.3.2

>From db33abdc906978dae74c7b2c54494b4a9c46707f Mon Sep 17 00:00:00 2001
From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jan 2016 13:12:22 -0800
Subject: [PATCH 2/2] oggopus: Remove normative language from IANA registry.

>From AD review.
---
 doc/draft-ietf-codec-oggopus.xml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/draft-ietf-codec-oggopus.xml b/doc/draft-ietf-codec-oggopus.xml
index b343e42..05bdae1 100644
--- a/doc/draft-ietf-codec-oggopus.xml
+++ b/doc/draft-ietf-codec-oggopus.xml
@@ -1546,20 +1546,20 @@ This document updates the IANA Media Types registry to add .opus
  as a file extension for "audio/ogg", and to add itself as a reference
  alongside <xref target="RFC5334"/> for "audio/ogg", "video/ogg", and
  "application/ogg" Media Types.
 </t>
 <t>
 This document defines a new registry "Opus Channel Mapping Families" to
  indicate how the semantic meanings of the channels in a multi-channel Opus
  stream are described.
-IANA SHALL create a new name space of "Opus Channel Mapping Families".
-All maintenance within and additions to the contents of this name space MUST be
- according to the "Specification Requried with Expert Review" registration
- policy as defined in <xref target="RFC5226"/>.
+IANA is requested to create a new name space of "Opus Channel Mapping
+ Families".
+Modifications to this registry follow the "Specification Requried with Expert
+ Review" registration policy as defined in <xref target="RFC5226"/>.
 Each registry entry consists of a Channel Mapping Family Number, which is
  specified in decimal in the range 0 to 255, inclusive, and a Reference (or
  list of references)
 Each Reference must point to sufficient documentation to describe what
  information is coded in the Opus identification header for this channel
  mapping family, how a demuxer determines the Stream Count ('N') and Coupled
  Stream Count ('M') from this information, and how it determines the proper
  interpretation of each of the decoded channels.
-- 
1.8.3.2

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 12 Jan 2016 15:29:10 -0600

There's a typo in "specification required". Otherwise, It think it's 
probably ready for IETF last call. Please submit when you are ready.

Thanks!

Ben.

On 12 Jan 2016, at 15:17, Timothy B. Terriberry wrote:

> Ron may have a better idea of real numbers, but it is certainly an 
> issue that has come up before. See 
> <https://wiki.debian.org/NonFreeIETFDocuments>, which links to a list 
> of bugreports. As Ron points out, there are a few RFCs that are 
> distributed because they included additional grants (after which the 
> original grants in draft-ietf-codec-opus and this draft were modeled). 
> It does not appear as if that page has been updated since RFC 6716 was 
> published, though.
>

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 12 Jan 2016 13:41:53 -0800

> probably ready for IETF last call. Please submit when you are ready.

Thanks. Fixed and posted.