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

[Ron <[e-mail]>]

Hi Stephan,

On Tue, Feb 02, 2016 at 10:46:10PM +0000, Stephan Wenger wrote:
> On 2/2/16, 14:26, "codec on behalf of Timothy B. Terriberry" <[e-mail] on behalf of [e-mail]> wrote:
> 
> >[…]
> >
> >We are able and willing. If adding an additional boilerplate text block 
> >is not the way to go about it (and I have no particular ties to that 
> >solution, we were simply doing what had been done before with RFC 6716), 
> >what should we do?
> 
> Take the text, minus RFC boilerplate and formatting, and publish it
> wherever and however you want, but not in a form that could be
> confused with an RFC.

That's *exactly* what this grant allows, yes :)

The only difference is it defers that actually happening until someone
actually has a compelling reason to do so, rather than preemptively
creating that situation even if ultimately nobody ever does.


> That’s a least my recollection of the spirit of the discussions we had
> when deliberating RFC 5377.

RFC 5377 is Informational and offers a number of options for rights
grants.  Including the option we are asking to exercise here.

That does not conflict with RFC 5378 though (aka BCP 78) which says:

  Ownership of the copyright in an RFC does not diminish the
  Contributors' rights in their underlying contributions, but it does
  prevent anyone other than the IETF Trust (and its licensees) from
  republishing or modifying an RFC in RFC format.  In this respect,
  Contributors are treated the same as anybody else: though they may
  extract and republish their own Contributions without limitation, they
  may not do so in the RFC format used by the IETF.  And while this
  principle (which is included in Section 5.9 below) may appear to be
  new to the IETF, it actually reflects historical practice and has been
  observed for many years through the inclusion of an ISOC or IETF Trust
  copyright notice on all RFC documents since the publication of RFC
  2026.


> At the time, my recollection of the consensus was that we specifically
> DID NOT want to give open source folks the option to take an RFC and
> “run with it”.

And we are specifically not proposing to give *anyone*, open source or
otherwise, "the option to take an RFC and “run with it”" ...

We're trying to find consensus on the best way to apply BCP 78 and the
options outlined in RFC 5377 to the needs of this document, in a way
that best matches the needs of its intended users to the best interests
of the IETF.


> Debian and its requirements were specifically mentioned then.

The problem we are trying to find a solution for here is not in any way
specific to Debian, or even specific to "open source folks".

I may wear a hat from both groups, but here I speak "for Debian" in the
same way that I speak "for the IETF".  As an individual participant.
And since this is an IETF list, and not a Debian one, I speak with only
the best interests of the IETF as the focus of my contributions to this
question.


I'm not yet convinced that forking this document immediately is the
best solution here, or that we have consensus on that being the best
approach, but that does seem to be the question we are now looking
to answer in the best way that the collective wisdom here can.

  Cheers,
  Ron