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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 02 Feb 2016 14:01:33 -0600

On 28 Jan 2016, at 16:09, Timothy B. Terriberry wrote:

> Joel M. Halpern wrote:
>> The second, changing the text, is not something I or the IETF 
>> community
>> support.
>
> 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.

The IETF made an exception to the TLP policies for RFC 6716 not because 
it was a codec definition per se, but because the normative definition 
was in the code components. The BSD licensing for code components 
already allowed derivative works for the code components themselves, but 
there was a perceived need to also be able to modify text to document 
any modification of "normative" code components.

That reasoning does not apply to this draft, since it does not have 
normative code components. Can you elaborate on whether it is different 
from other IETF standards track documents in some other way that might 
justify such an exception?

Thanks!

Ben.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 2 Feb 2016 14:51:38 -0600

Ben's recent response to Tim captures the main point, but to reinforce 
what's said there:

We learned a lot as a community from going through the development of 
RFC6716, and there's been  strong sentiment expressed that we wouldn't 
do things like produce normative code again. I think if we were able to 
repeat the exercise fresh, knowing what we learned, that we also 
wouldn't have made this copyright change in just this way. However, the 
most relevant point is that with RFC6716 we at least had an exceptional 
condition to point to. This draft does not have that.

It is not clear to me how the things you are hoping to achieve with this 
extra language are not already available to you (under fair use for 
example). In the copy below, you elided my suggestion that the draft 
argue why the existing boilerplate is insufficient.

It _is_ fairly clear to me that the kind of change you're asking for is 
not really specific to this draft, though.
The community developed a set of acceptable boilerplate text blocks. The 
draft should use what we have, or convince the community that we need to 
change what we allow for RFCs.

RjS

On 1/28/16 9:10 PM, Ron wrote:
> 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.
>>
>> 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.
> 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: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 02 Feb 2016 14:26:50 -0800

> argue why the existing boilerplate is insufficient.

We weren't ignoring it. But first we need to get consensus on an argument.

I don't think fair use is sufficient. That might be acceptable for some 
examples given (e.g., quoting one or two sentences in API 
documentation), but would not be acceptable for the examples I gave of 
using the text as a basis for a mapping for a new codec into Ogg, or a 
new mapping of Opus into some other container. I mean, IANAL, but my 
understanding is that both of those would go against the spirit of 
Folsom v. Marsh and not qualify for fair use.

> not really specific to this draft, though.

Well, the specific thing about this draft is that we wish to include the 
XML source as documentation alongside an open-source software library, 
with all of the usual open-source rights associated with that. That is 
not a property of every draft, at least (for example, it was not a 
property of RFC 7007).

> change what we allow for RFCs.

Reading what the community said in Section 4.4 of RFC 5377, it says, 
"There is no consensus at this time to permit the use of text from RFCs 
in contexts where the right to modify the text is required. The authors 
of IETF Contributions may be able and willing to grant such rights 
independently of the rights they have granted to the IETF by making the 
Contribution."

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?

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 2 Feb 2016 22:46:10 +0000

See below:

On 2/2/16, 14:26, "codec on behalf of Timothy B. Terriberry" <[email-masked] on behalf of [email-masked]> wrote:

>[…]

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 a least my recollection of the spirit of the discussions we had when deliberating RFC 5377.  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”.  Debian and its requirements were specifically mentioned then.

Stephan

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

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 02 Feb 2016 14:51:21 -0800

> 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 a least my recollection of the spiri…

Is it your opinion that the XML source for the latest draft (which 
includes instructions to produce the boilerplate and formatting, but not 
the actual boilerplate and formatting) would qualify as "not in a form 
that could be confused with an RFC"?

---

From: Stephan Wenger <[email-masked]>
Date: Tue, 2 Feb 2016 22:54:33 +0000

Yes, unfortunately.
Stephan

---

From: Ron <[email-masked]>
Date: Wed, 3 Feb 2016 13:37:00 +1030

On Tue, Feb 02, 2016 at 02:51:38PM -0600, Robert Sparks wrote:
> RFC6716, and there's been  strong sentiment expressed that we wouldn't do
> things like produce normative code again. I think if we were able to repeat
> the exercise fresh, knowing what we learned, that we also wouldn't have made
> this copyright change in just this way. However, the most relevant point is
> that with RFC6716 we at least had an exceptional condition to point to. This
> draft does not have that.

This draft does however include things which are directly applicable to
any code which might implement it, even if they don't appear in it in
the form of "normative code".

At the very least things like the header definitions and downmixing
matrices would seem to fall quite squarely under what is described in
RFC 5377 4.3, which says:

 Rights Granted for Implementing Based on IETF Contributions

 ...

 As such, the rough consensus is that the IETF Trust is to grant
 rights such that code components of IETF Contributions can be
 extracted, modified, and used by anyone in any way desired.

And above that gives examples of things considered "code components" and
a rationale which I think is congruent with many of the reasons we've
given for thinking this is needed in this case.

The nature of a codec mapping means this document is full of such things
in various places, and we're keen to avoid the mistakes which severely
limited the use of RFC 3951, which people could only use by distributing
a parser to extract them from the RFC and compile them on the end user's
machine.

> example).

There is no international consensus on what constitutes "fair use", and
the IETF has no change control over the exceptions that regional
jurisdictions might grant to the terms of the explicit licence granted.

If the intention is to allow things, we should say explicitly what we
intend to allow.  I think we have reasonably broad agreement on what
"common sense" says people should be allowed to do with this text, we
just need to agree on the language which actually allows them to do
that - without needing to resort to external 'loopholes'.

> In the copy below, you elided my suggestion that the draft argue
> why the existing boilerplate is insufficient.

Sorry, that didn't mean I was ignoring it.  To me that question was
implicit, and I thought the previous discussion that you referred to
in that had already answered it - which is why I was trying to
understand the basis upon which you thought it didn't in this case.

> It _is_ fairly clear to me that the kind of change you're asking for is not
> really specific to this draft, though.

I'm not actually sure that the things which we do need to make this a
practically useful document are actually applicable to *all* RFCs.

I do think they may be applicable to many more of them, and in more
parts of them, than have currently addressed this question head on.
But this discussion seems to make it clear that we are still at the
"understanding the problem" stage of fixing that, which makes it a
bit premature to be heading straight for "propose a general solution
for all documents" on the basis of what this one needs.

The IETF clearly recognises there is nuance in what rights it needs
to grant individual documents to maximise their usefulness.

RFC 5377 defines some broad categories for the type of rights which
may be required in different cases.

RFC 5744 extends that and requires independent submissions published
as RFCs to always have the sort of liberal grant that we've requested
here, except in exceptional circumstances.

I think the intended uses for *this* document falls across a range
of the categories recommended for use in RFC 5377 section 4.
And that unless we want to get into a horrible game of trying to
individually salami slice which clauses in it most fit into which
categories for which users, the only sensible and pragmatic choice
from that set which could be applied singly is 4.3.

Which is essentially what asking for this extra header text has done.

I think that's a somewhat blunt instrument, and I agree there are
other ways that we can achieve the same outcome, and I agree that
there are questions here which the community will at some point
need to address as it continues to refine the boilerplate options
which it recommends.

Personally, I think that separately publishing the content of this
document, under a licence equivalent to what 4.3 would allow, is not
the option which minimises the risk of having people diverge from
this document in ways I think we all agree would be undesirable.

But I think it does need to be available under such a licence to
cover all the use cases we can already reasonably envisage.

Which is why I think the best option is to have a single publication
as an RFC, which people can only exercise the rights of 4.3 to if
they no longer claim the result is still an RFC.  And I think the
method used for 6716 fits this well, and falls within the existing
recommendations.

Reasonable people could disagree with that though, so I think the
question as it relates to this document is whether the consensus
is that the IETF is best served by doing this, and remaining the
single authoritative source until someone does exercise that right.

Or whether the authors should publish a separate grant, which would
effectively create two sources of this document immediately, in its
unmodified form.  One of which has a less restrictive licence than
the other, and (as Gresham's Law tells us) may then be the most
likely to become the common currency with the widest circulation.

I think that's a question the community does need to form a good
understanding of and address, but the immediate question is what
is the best answer for us to employ with this document?  The
broader question will need to consider many more cases based on
the needs of many more documents, but I think this is a good
example of one of those cases for us to explore solutions to.

  Cheers,
  Ron

---

From: Ron <[email-masked]>
Date: Wed, 3 Feb 2016 14:08:55 +1030

Hi Stephan,

On Tue, Feb 02, 2016 at 10:46:10PM +0000, Stephan Wenger wrote:
> 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

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 02 Feb 2016 20:19:16 -0800

> that best matches the needs of its intended users to the best interests

It seems to me like putting a BSD copyright header in an XML comment at 
the top of the XML source file and dropping Section 13 from the draft 
would resolve all of the issues, if everyone agrees that is an 
acceptable thing to do. Ron?

---

From: Ron <[email-masked]>
Date: Wed, 3 Feb 2016 16:05:46 +1030

On Tue, Feb 02, 2016 at 08:19:16PM -0800, Timothy B. Terriberry wrote:
> It seems to me like putting a BSD copyright header in an XML comment at the
> top of the XML source file and dropping Section 13 from the draft would
> resolve all of the issues, if everyone agrees that is an acceptable thing to
> do. Ron?

It leaves us with the issue of creating a perverse incentive for some
parties to prefer distributing the "non-rfc" version over the official
RFC - even when they themselves have not modified it and don't have
any direct plans to.  And in some cases, will force their hand, making
that the only version they can redistribute ...

But aside from that, I think it would cover the practical problems
which we currently see for implementors needing to use this in their
own work.  Which is the most immediate issue here.

It's not my first preference, and not what I think serves the IETF's
interest best, for all of the reasons I've outlined earlier in this
thread -- but if we can't get consensus for adding a RFC 5377 4.3
exception to add the "Rights Granted for Implementing" to it, and
nobody has a better suggestion, then I can accept this option as the
pragmatic way we should proceed here.

I think both options are in the scope of current recommendations to
allow, but I'll defer to peer review on that.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Tue, 02 Feb 2016 22:26:44 -0800

> own work.  Which is the most immediate issue here.

I've gone ahead and published a new version implementing this 
suggestion. Please holler if I've missed anything.

Thank you everyone for your patience on this.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Feb 2016 09:52:32 -0600

On 2 Feb 2016, at 22:19, Timothy B. Terriberry wrote:

> It seems to me like putting a BSD copyright header in an XML comment 
> at the top of the XML source file and dropping Section 13 from the 
> draft would resolve all of the issues, if everyone agrees that is an 

I think that's acceptable in theory. In practice, keep in mind that if 
someone uses xml2rfc to render the text, it's going to create IETF 
headers and boilerplate, at least if the "external" version of the XML 
uses the same settings.

That's probably not what you want, regardless of whether the section 13 
language stays or goes.

How did this end up working for 6716?

Ben.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 3 Feb 2016 16:10:58 +0000

Tim,

>acceptable thing to do. Ron?

I believe that, even if I were so inclined (which I’m not), I could not prevent anyone from downloading the so-labelled XML source from the IETF datatracker and modify it in any way I wish.  So, yes, it appears to me that this is an option that solves your problem.

However, it is still a procedural end-run around the currently in-force IETF position that the IETF reserves the right for itself to create derivative works from the RFCs it created (my paraphrasing).  While perhaps not relevant for oggopus, it’s also against the main mission of standardization: ensure interoperability.  From a standardizer’s viewpoint, derivative work is evil (unless conducted in a backward compatible way), because it leads to non-interoperable implementations solving the same problem.  So if I were on the IESG, I would probably insist on an IESG note to the RFC editor requiring that this weird comment in the XML source be removed as of the time of publication of the RFC.

Trying to be creative here: I think your main motivation for asking the IETF to allow derivative work outside the IETF context is that the text could be used outside the IETF to create new containers for codecs other than opus.  That’s perhaps somewhat justifiable, as the ogg base spec is not an IETF spec, and many codecs are not IETF codecs.  (It would not be right, for example, for opus’ RTP payload format.)  Is that about right?  If yes, then why not express it in a field of use limitation in the license granted?  That seems like a reasonable and sufficiently narrowly defined exception that could be justified.  

Now, such a narrow exception does not solve the open source related problems, but for that you should really start a debate about the copyright policy as a whole, because it would be a major change affecting key tradeoffs of that policy that were deliberated literally for years.

Stephan

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 03 Feb 2016 10:28:02 -0600

> On 2 Feb 2016, at 22:19, Timothy B. Terriberry wrote:

[...]

> That's probably not what you want, regardless of whether the section 
> 13 language stays or goes.

To clarify: I think that would only matter for versions with modified 
content.

[...]

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 3 Feb 2016 12:34:00 -0500

> How did this end up working for 6716?

For 6716, we made sure that the XML version in the git repository
produces a draft, not an RFC when run with xml2rfc. That's the best way
to avoid accidents and ensure it's never "presented, displayed or
published in a manner that states or implies that it is part of this RFC
or any other IETF Document".

	Jean-Marc

---

From: Ron <[email-masked]>
Date: Thu, 4 Feb 2016 04:11:52 +1030

On Wed, Feb 03, 2016 at 04:10:58PM +0000, Stephan Wenger wrote:
> However, it is still a procedural end-run around the currently
> in-force IETF position that the IETF reserves the right for itself to
> create derivative works from the RFCs it created (my paraphrasing).

I can quote more directly without paraphrasing if that helps.

The current TLP says:

  The IETF Trust does not limit the ability of IETF Contributors to
  license their Contributions, so long as those licenses do not affect
  the rights granted to the IETF Trust under RFC 5378.

And RFC 5377 4.5 says:

  Authors of Contributions retain all rights in their Contributions.
  As such, an author may directly grant any rights they wish separately
  from what the IETF grants.

And this is one of the options canvassed with Robert for 6716 before it
was decided the header text was the option of choice there.

The mechanics of the best way to do it, I'm open to suggestions about,
but characterising it as an 'end-run' would seem to be misrepresenting
both the documented position of the IETF and the intent of the authors.

  Ron

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 3 Feb 2016 12:57:54 -0500

On 02/03/2016 11:10 AM, Stephan Wenger wrote:
> While perhaps not relevant for oggopus, it’s also against the main
> mission of standardization: ensure interoperability.  From a
> standardizer’s viewpoint, derivative work is evil (unless conducted
> in a backward compatible way), because it leads to non-interoperable
> implementations solving the same problem.  So if I were on the IESG,
> I would probably insist on an IESG note to the RFC editor requiring
> that this weird comment in the XML source be removed as of the time
> of publication of the RFC.

You cannot ensure interoperability through legal means here. I've seen
several cases where the text of the standard is not free so people
implement it from second-hand descriptions that are freely available on
the web and end up making mistakes. In the case of the IETF, the fact
that the unmodified text is freely (as in beer) distributable helps a
lot, but in any cases where someone needs to distribute a modified copy,
you're always better off given them permission than have them paraphrase
the whole thing the way they understand it.

> Trying to be creative here: I think your main motivation for asking
> the IETF to allow derivative work outside the IETF context is that
> the text could be used outside the IETF to create new containers for
> codecs other than opus.

That's one of them, but there's also mapping Opus to non-Ogg containers,
experimenting with new channel mapping families, and probably others I
can't think of at the moment.

> That’s perhaps somewhat justifiable, as the
> ogg base spec is not an IETF spec, and many codecs are not IETF
> codecs.  (It would not be right, for example, for opus’ RTP payload
> format.) 

Even text of the RTP spec is something that can reasonably be borrowed
for a different container. Not to mention there's still the
documentation-related issue.

> Is that about right?  If yes, then why not express it in a
> field of use limitation in the license granted?  That seems like a
> reasonable and sufficiently narrowly defined exception that could be
> justified.
> 
> Now, such a narrow exception does not solve the open source related
> problems, but for that you should really start a debate about the
> copyright policy as a whole, because it would be a major change
> affecting key tradeoffs of that policy that were deliberated
> literally for years.

Well, for the open-source issue, I think the best solution is still the
license given by authors on the XML.

	Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 3 Feb 2016 18:07:32 +0000

Hi Jean-Marc,

>the whole thing the way they understand it.

I tend to agree (except perhaps for the word “always” in the last sentence), but what I described is my understanding of the IETF’s position when creating the currently in force copyright policy, and not an absolute truth.

>can't think of at the moment.

So the issue with that proposal would be that it is difficult to create a sufficiently wide carve-out (short of “go and do with it whatever you want”)?  I somewhat doubt that.  Unfortunately, I don’t have the time right now to be more creative :-)

>documentation-related issue.

I assume you are referring to the RTP payload format spec for opus, and not RFC 3550.  With that spec there is absolutely nothing different from other RTP payload formats and nothing, in my view, that would justify any detour from our established policies and procedures.

>license given by authors on the XML.

Within the narrowly interpreted language of the copyright policy RFCs, perhaps yes.  But I continue to maintain it would still go against the spirit of the copyright policy.

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Wed, 03 Feb 2016 11:19:50 -0800

Hi Stephan,

 > create derivative works from the RFCs it created (my paraphrasing).

I am trying to follow the procedure. RFC 5377 says that authors should 
be able to grant these rights. The first example I know of people doing 
this was by putting a copyright statement in the XML source (RFC 2629). 
But my understanding was that it was later preferred that an additional 
grant be added in a section of the draft (see RFC 5215 Section 11). Then 
with RFC 6716 the IETF decided it was better to add this grant to the 
boilerplate text. Now there are objections to that approach, and we've 
come full circle to a copyright statement in the XML source again. As 
long as there is some way to do it, then I am happy.

> affecting key tradeoffs of that policy that were deliberated literally
> for years.

I am actually personally fine if most authors do not want to grant these 
rights. To my mind, they are the ones who wrote the documents, and if 
they see these restrictions as beneficial, it's not my place to tell 
them they are not allowed to have them.

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 3 Feb 2016 20:22:53 +0000

>long as there is some way to do it, then I am happy.

Look, there are countless ways for RFC authors to publish a collection of characters outside the IETF that also happen to be part of the RFC.  For this particular case, it’s IMO absolutely OK and supported by language and spirit of the IETF’s copyright policy, not to mention adequate, if you authors take the RFC once done, strip it of IETF specific boilerplate, (optionally add your own with whatever term you choose), and put it on the xiph.org webpage.  

That works for as long as you are reasonably certain that you authors are the only ones who made substantial contributions to the text.  If, for example, the IESG put in a 10 page IESG note into the doc, or if the RFC editor rewrites your whole text, then you probably should get their OK as well.  But these are corner-cases you can control well enough so that I don’t worry about them.  And, it’s your risk and it’s easy enough to mitigate.

You folks can certainly ensure that the text you publish is identical to the RFC minus boilerplate.  You can also make a statement in this regard on the web page.  This is, in my understanding, what was meant in those sections of RFC 5377 that Ron cited.

Note that I do not consider this a “Good Thing” to implement for all, or even a substantial number, of RFCs.  It has the potential to create an unreliable (in the sense that not all IETF RFCs are present) quasi-mirror of the IETF RFC documents.  But for this particular RFC-to-be, it may be the right thing to do.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Feb 2016 20:43:23 -0500

I think people need to remember that 'forks happen'.

IETF has forked other standards bodies on quite a few occasions.
Notably the WebPKI is built on PKIX, not X.509. If we are OK with
that, we should be OK with other people forking our work.

That doesn't seem to be the intention here but it is a possible
outcome. The issue seems to be that they are sure other people will
want to build on the CODEC but not precisely how it would modularize.
At least not now.

My concern is not so much version N versus version N', it is the
question of what happens for version N+1. Do the forks continue or is
one orphaned (like X.509v3).

Another possibility to consider is that the group goes off and does
its 'thing' and when it is ready, comes back with an update,
supplement or whatever. That way we can merge the streams back into
one at a later date (should that seem desirable).

---

From: Adam Roach <[email-masked]>
Date: Wed, 3 Feb 2016 16:59:35 -0600

From what I can see, the text in RFC 5378 is pretty unambiguous that 
the rights granted to the IETF trust are non-exclusive. I don't imagine 
we're arguing about whether authors have the legal ability to grant 
rights in their work to others under different terms, as long as those 
terms don't somehow interfere with the rights granted to the IETF.

For this document, it's clear that the authors intend to grant 
additional rights to their text.

I think there are two questions here: the first is whether the authors 
are allowed to be transparent and include the extra rights grant as part 
of the IETF document, or if they simply indicate that rights grant in 
some other venue and leave the RFC silent on the topic. I suspect that 
more information is better than less, and that is not in the IETF's 
interest to bury the intention to grant additional rights. To that end, 
I see the RFC 5215 and RFC 6716 approaches as vastly superior to hiding 
the grant in the XML source [1] or precluding mention altogether.

The second question is whether the authors should have the IETF Trust 
grant these additional rights (in the style of RFC 6716), or whether the 
authors grant these rights directly (as in RFC 5215). I don't think it 
matters, but we should certainly allow at least one of the two 
formulations. It would also be nice if we settled on a recommended 
practice, and documented it somewhere so that it didn't cause a 
hullabaloo whenever authors tried to grant additional rights.

/a

_____
[1] Obligatory Douglas Adams reference:

Prosser: But Mr. Dent, the plans have been available in the local planning
          office for the last nine months.

Arthur: Oh yes, well as soon as I heard I went straight round to see them,
         yesterday afternoon. You hadn't exactly gone out of your way to 
call
         attention to them had you? I mean like actually telling anybody or
         anything.

Prosser: But the plans were on display...

Arthur: On display? I eventually had to go down to the cellar to find them.

Prosser: That's the display department.

Arthur: With a torch.

Prosser: The lights had probably gone out.

Arthur: So had the stairs.

Prosser: But look, you found the notice, didn't you?

Arthur: Yes. Yes I did. It was on display at the bottom of a locked filing
         cabinet stuck in a disused lavatory with a sign on the door saying
         "beware of the leopard."

On 2/3/16 13:19, Timothy B. Terriberry wrote:
> be able to grant these rights. The first example I know of people 
> doing this was by putting a copyright statement in the XML source (RFC 
> 2629). But my understanding was that it was later preferred that an 
> additional grant be added in a section of the draft (see RFC 5215 
> Section 11). Then with RFC 6716 the IETF decided it was better to add 
> this grant to the boilerplate text. Now there are objections to that 
> approach, and we've come full circle to a copyright statement in the 
> XML source again. As long as there is some way to do it, then I am happy.
>
> I am actually personally fine if most authors do not want to grant 
> these rights. To my mind, they are the ones who wrote the documents, 
> and if they see these restrictions as beneficial, it's not my place to 
> tell them they are not allowed to have them.
>