Subject: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

From: "Ed Juskevicius" <[email-masked]>
Date: Thu, 8 Jan 2009 16:43:50 -0500

The purpose of this message is twofold:

1) To summarize the issues that some members of our community 
   have experienced since the publication of RFC 5378 in November 2008, 
   and
2) To invite community review and discussion on a potential work-around 
   being considered by the IETF Trustees.

Some I-D authors are having difficulty implementing RFC 5378.  An  
example of the difficulty is as follows:

  - an author wants to include pre-5378 content in a new submission
    or contribution to the IETF, but
  - s/he is not certain that all of the author(s) of the earlier  
    material have agreed to license it to the IETF Trust according
    to RFC 5378.

If an I-D author includes pre-5378 material in a new document, then s/he
must represent or warrant that all of the authors who created the  
pre-5378 material have granted rights for that material to the IETF Trust.
If s/he cannot make this assertion, then s/he has a problem.

This situation has halted the progression of some Internet-Drafts and  
interrupted the publication of some RFCs.  The Trustees of the IETF Trust
are investigating ways to implement a temporary work-around so that IETF
work can continue to progress.  A permanent solution to this "pre-5378
problem" may require an update to RFC 5378, for example new work by the
community to create a 5378-bis document.

The remainder of this message provides an outline of the temporary work- 
around being considered by the Trustees.

RFC 5378 sections 1.j and 5.3.c provide the IETF Trust with the  
authority to develop legend text for authors to use in situations where
they wish to limit the granting of rights to modify and prepare
derivatives of the documents they submit.  The Trustees used this
authority in 2008 to develop and adopt the current "Legal Provisions
Relating to IETF Documents" which are posted at:
http://trustee.ietf.org/license-info/.

The Trustees are now considering the creation of optional new legend text  
which could be used by authors experiencing the "pre-5378 problem".

The new legend text, if implemented, would do the following:

  a. Provide Authors and Contributors with a way to identify (to the
     IETF Trust) that their contributions contain material from pre-5378  
     documents for which RFC 5378 rights to modify the material outside
     the IETF standards process may not have been granted, and

  b. Provide the IETF Trust and the community with a clear indication 
     of every document containing pre-5378 content and having the
     "pre-5378 problem".

So, how could the creation and use of some new legend text help people
work-around the pre-5378 problem?

The proposed answer is as follows:

  1. Anyone having a contribution with the "pre-5378" problem should add
     new legend text to the contribution, to clearly flag that it includes
     pre-5378 material for which all of the rights needed under RFC 5378
     may not have been granted, and

  2. The IETF Trust will consider authors and contributors (with the  
     pre-5378 problem) to have met their RFC 5378 obligations if the
     new legend text appears on their documents, and

  3. Authors and contributors should only resort to adding the new  
     legend text to their documents (per #1) if they cannot develop  
     certainty that all of the author(s) of pre-5378 material in
     their documents have agreed to license the pre-5378 content to
     the IETF Trust according to RFC 5378.

The proposed wording for the new legend text is now available for your
review and comments in section 6.c.iii of a draft revision to the
IETF Trust's "Legal Provisions Relating to IETF Documents" located at
http://trustee.ietf.org/policyandprocedures.html.

Please note that the above document also contains new text in section 5.c
dealing with "License Limitations".

If your review and feedback on this proposed work-around is positive,
then the new text may be adopted by the Trustees in early February 2009,
and then be published as an official revision to the Legal Provisions
document.  If so adopted, Internet-Drafts with pre-5378 material may 
advance within the Internet standards process and get published as RFCs
where otherwise qualified to do so.  Unless covered by sections 6.c.i or
6.c.ii, authors of documents in which there is no pre-5378
material must provide a RFC 5378 license with no limitation on
modifications outside the IETF standards process.

The IETF Trust will not grant the right to modify or prepare derivative
works of any specific RFC or other IETF Contribution outside the IETF
standards process until RFC 5378 rights pertaining to that document have
been obtained from all authors and after compliance by the IETF Trust
with RFC 5377.  The Trustees will establish one or more mechanisms by
which authors of pre-5378 documents may grant RFC 5378 rights.

The Trustees hereby invite your review, comments and suggestions on this
proposed work-around to the "pre-5378 problem".  The period for this review
is 30 days.  Microsoft WORD and PDF versions of the proposed revisions are
attached to this message.  Copies are also available on the IETF Trust
website under the heading "DRAFT Policy and Procedures Being Developed" at:
http://trustee.ietf.org/policyandprocedures.html 

All feedback submitted before the end of February 7th will be considered by
the Trustees.  A decision on whether to move forward with this proposal will
be made and communicated to you before the end of February 15th.

Please give this your attention.

Regards and Happy New Year !

Ed Juskevicius, on behalf of the IETF Trustees
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jan 2009 11:27:59 +1300

Ed,

Thanks for this.

As I understand it, the proposal boils down to adding a disclaimer to
affected documents that reads:

"This document contains material from IETF Documents or IETF Contributions
published before November 10, 2008 and, to the Contributor’s knowledge,
the person(s) controlling the copyright in such material have not granted
the IETF Trust the right to allow modifications of such material outside
the IETF Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright, this document may not be modified outside
the IETF Standards Process, and derivative works of it may not be created
outside the IETF Standards Process, except to format it for publication as
an RFC and to translate it into languages other than English."

That's a little bit long-winded but I agree that this is a correct fix.
However, I didn't see in your note an explanation of the procedure
for approving the use of this boilerplate (and preventing it being
used simply as an easy way out). Rather than ranting about that, I
will shortly submit an I-D that makes a concrete and, I hope, simple
proposal for that as a fix to RFC5378. I see no reason that we need
to revisit RFC5378 in a fundamental way.

Regards

      Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Jan 2009 14:49:16 -0800

You asked me to make this comment publicly, so here it is.

In my opinion, we need a 5378-bis that keeps the good bits but  
corrects the issue that has been problematic. The question before the  
house is how best to achieve that. The proposal here is to provide a  
work-around that enables an internet draft author to state that s/he  
has not verified the transferability of his/her text, which will work  
until an appropriate 5378-bis can be produced. This means that the  
tools people have to produce and accept the work-around and later on  
change the tools to accept 5378-bis, and it places a burden on authors  
to make that statement.

 From my perspective, the best approach involves keeping the general  
case simple. The documents that have been transferred outside the IETF  
in the past five years is a single digit number, a tenth of a percent  
of all RFCs if not a smaller fraction. From my perspective, the  
simplest solution to the transfer issue is to ask the people relevant  
to a document for which transfer has been suggested whether they have  
an issue with transferring it, rather than asking every document  
author his or her opinion on the vast majority of documents, which  
will never be transferred. Remember that this boilerplate affects  
internet drafts, but most internet drafts are discussion documents - a  
fraction of internet drafts even become RFCs, and a small fraction of  
RFCs are transferred elsewhere.

As to the other issues that 5378 addresses, I suspect that a better  
approach will be to fall back to 3978/4748/2026 temporarily and move  
to 5378-bis when it comes rather than to use this very general  
workaround to 5378's issues until 5378-bis is resolved. 3978 etc  
worked just fine for most purposes...

On Jan 8, 2009, at 1:43 PM, Ed Juskevicius wrote:

> <Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.DOC><Draft- 
> Update-to-IETF-Trust-Legal- 
> Provisions-1-06-09.pdf>_______________________________________________
> Trustees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trustees

---

From: TSG <[email-masked]>
Date: Thu, 08 Jan 2009 15:20:51 -0800

Ed Juskevicius wrote:

Ed - you nor the rest of this list is going to like this retort but I 
would ask that you read all of it prior to flushing the response.
>     material have agreed to license it to the IETF Trust according
Then the submission of such an assertion would be a criminal act of 
fraud by wire... and that is not a joke.
> pre-5378 material have granted rights for that material to the IETF Trust.
Something which by the way is physically impossible because of how the 
RFC2026 licensing model was setup. Hell even BCP78 and 79 exist under 
RFC2026 rules since they had to be published as such to get them into 
the channel to review and advance them to the BCP's. As such these all 
are moot... funny that eh?
> community to create a 5378-bis document.
You mean a POST-5378 IP Disclosure Document. The issue is what happens 
to any derivative licensing which stems from RFC2026 based controls. And 
since 5378 is a derivative of the BCP78 document it is tied itself to 
the RFC2026 rules still too one could easily argue.
> http://trustee.ietf.org/license-info/.
RFC2026 will not allow this. In fact once published under RFC2026 those 
document's are cast in concrete as far as the license model is concerned.
>      the IETF standards process may not have been granted, and
Meaning that those documents would be published under yet another set of 
IP licensing constraints - So lets see that makes

    1)   Pre BCP78
             o-   Pure RFC2026 based licensing

    2)   Post BCP-78 publishing with Pre-BCP 78 licensing included
             o- Includes non-trust managed IP
             o- Includes trust managed IP

    3)   Post BCP-78 with pure BCP-78 licensing through the Trust
>      of every document containing pre-5378 content and having the

Ahahahah - Oh damn that's funny. Try all of the RFC's published prior to 
(IMHO) the IESG's #$%^&*()_ act of putting BCP78 and BCP79 into production.
> work-around the pre-5378 problem?
It cannot. The RFC2026 Licensing model clearly must survive the original 
filing of the original BCP78 and its ludicrously funny and pretty stupid 
brother BCP79.
>      may not have been granted, and
They, according to the IETF submission process, cannot do this because 
the amended document supposedly has to be submitted under the BCP78/79 
Terms which is what we are saying doesn't work here. So this is clearly 
impossible.
>      new legend text appears on their documents, and
The TRUST isn't the issue - its the US Courts that are the issue.
>      the IETF Trust according to RFC 5378.
I would suggest that this also is not enough...
> Please give this your attention.
Ed this is garbage... If the earlier releases IP Owners will not 
formally change their licensing terms then the ONLY solution is that the 
original license terms for any initiative apply to any and all 
derivative works unless those works have more restrictive licenses. 

There is also an issue as to any physical works which were derived from 
those earlier licenses since they also would be constrained by those 
original terms too one would think. Further this is NOT rocket-science, 
its common sense. If work-product "A" contained specific IP then the 
uses of that IP cannot exceed the original licenses including being 
given to the Trust which RFC2026 doesn't provide for in any form. That 
means that the IETF may not in fact convey those document's to the Trust 
at all. They remain inside the IETF until those other licensees agree to 
relicense their work, and still anyone who was a relying party is still 
bound by the original RFC2026 release rules.

So as an example of how simple this is, take for instance work-product 
"A" which was filed under RFC20206 alone, and that means that the 
follow-on derivatives MUST also be totally contained/constrained by that 
same set of terms and conditions otherwise the original conveyance 
contract is flawed, and may be unenforceable.

Which brings us back to the issue of that the Trust MAY not rewrite 
licenses for any IP that the IETF processed under RFC2026 unless ALL of 
the parties - the people who wrote those drafts, the IP owners of that 
work and anyone who has relied on a SW or systems product fabricated 
under those licenses.

Wake up and smell the coffee... BCP 78 and BCP79 are a waste of time and 
were fabricated by individuals of questionable expertise since they 
pretty clearly have screwed the pooch on this one. Nice move Harald...

Todd Glassey
On behalf of the victims of the IETF Trust.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 8 Jan 2009 15:30:35 -0800

> will never be transferred.

Certainly in the IETF as we have known it, situations such as those
described in RFC 4663 have been rare.  If handling those scenarios is
the major focus, then I'd agree with your argument for "optimizing for the
common case".  In particular, corner conditions have a way of being 
somewhat unique (that's why they are corner conditions) so that 
trying to handle all of them in a unified way can prove elusive. 

So overall, the question seems to come down to whether transfers

are likely to become much more commonplace in the future than
they have in the past.  It strikes me that the situations in which
this would occur would tend to be rather dark -- and indeed the
discussion on this topic has wandered into some of those less rosy
scenarios. While an organization (or person) is healthy, it is often 
difficult to muster much enthusiasm for "estate planning" discussions. 

However, even if one considers those situations, it still is not entirely
clear to me that these provisions are required.  For example, over the 
last few years we seem to have made it through a number of wrenching
transitions without requiring this.   

For example, do we believe that the situation described in RFC 4663
is likely to become increasingly common in the years ahead? 
To be blunt, the only scenarios in which that would seem possible
would be "worst case" 

 Remember that this boilerplate affects

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 8 Jan 2009 16:48:00 -0800

Hi -

> From: "Ed Juskevicius" <[email-masked]>
> To: "'IETF Discussion'" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
> Cc: "'Trustees'" <[email-masked]>
> Sent: Thursday, January 08, 2009 1:43 PM
> Subject: ANNOUNCEMENT: The IETF Trustees invite your review and comments on aproposed Work-Around to the Pre-5378 Problem
...
> be made and communicated to you before the end of February 15th.
...

I admit to being completely baffled by the document.
My only concern at this time is finishing off two WG documents.
My questions:

  (1) Do we need to wait for the availability of the updated license form
        before we can submit new internet drafts?

  (2) How do we (the WG, since the editors are merely working under our
        direction) determine whose signatures are needed before we OK
        submission of an updated I-D?

We've always operated under the "Note Well" provisions, and consequently
have not tracked the origin of every snippet of text thrown into the editing
blender.

Randy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Jan 2009 00:59:06 +0000

+1 to fred's proposal, let the exceptions be just that and don't  
bother most I-D authors,
Stephen.

On 8 Jan 2009, at 22:49, Fred Baker <[email-masked]> wrote:

> corrects the issue that has been problematic. The question before  
> the house is how best to achieve that. The proposal here is to  
> provide a work-around that enables an internet draft author to state  
> that s/he has not verified the transferability of his/her text,  
> which will work until an appropriate 5378-bis can be produced. This  
> means that the tools people have to produce and accept the work- 
> around and later on change the tools to accept 5378-bis, and it  
> places a burden on authors to make that statement.
>
> case simple. The documents that have been transferred outside the  
> IETF in the past five years is a single digit number, a tenth of a  
> percent of all RFCs if not a smaller fraction. From my perspective,  
> the simplest solution to the transfer issue is to ask the people  
> relevant to a document for which transfer has been suggested whether  
> they have an issue with transferring it, rather than asking every  
> document author his or her opinion on the vast majority of  
> documents, which will never be transferred. Remember that this  
> boilerplate affects internet drafts, but most internet drafts are  
> discussion documents - a fraction of internet drafts even become  
> RFCs, and a small fraction of RFCs are transferred elsewhere.
>
>> Provisions- 
>> 1-06-09.pdf>_______________________________________________
>> Trustees mailing list
>> [email-masked]

---

From: Martin Duerst <[email-masked]>
Date: Fri, 09 Jan 2009 19:42:20 +0900

At 13:13 09/01/09, Brian E Carpenter wrote:
>
>On 2009-01-09 13:59, Stephen Farrell wrote:
>> +1 to fred's proposal, let the exceptions be just that and don't bother
>> most I-D authors,
>> Stephen.
>> 

>>> of all RFCs if not a smaller fraction. 
>
>If that was the main problem, I would agree. But it isn't; it's the ability
>to allow appropriate use of extracts, including code extracts, in 3rd
>party documents.

First, my gut feeling would be that use of ABNF and similar stuff
in actual implementations might simply be considered fair use, or
it may just be possible to consider implementations as part of the
IETF standards process (which they very much are).

The situation may be somewhat different for longer/longish pieces
of code, a typical example of which might be Appendix A of
http://www.ietf.org/rfc/rfc2192.txt. But the code is essentially
there to serve as an example, as an additional guarantee that
there is a common, shared understanding of the specification,
not as a drop-in implementation. Also, such code in many
instances is already covered under a more appropriate licence
anyway.

>That potentially concerns every RFC,

Given the above (some of which might be a bit out on a limb, or not),
I'm still not convinced the potential issue is that big.

>and automatically
>concerns every RFC that is a new version of an older one.
>
>It isn't hard to fix in my opinion (well, I just posted a draft with
>the proposed fix) and I don't see that it *requires* any tool fixes.
>Optionally, the tools could provide a macro that expands to the
>disclaimer text, but cut-and-paste would work equally well.

I have read your draft. I have one suggestion for modification.
The text says:

                           "the person(s) controlling the copyright in
   such material have not granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process."

I think it might be more appropriate to change "the person(s)" to
"some person(s)".

Overall, I think currently the aspect most overlooked in the general
discussion, but most relevant for somebody who would actually like
to move on with publications (I'm both a WG chair with some drafts
that have completed WG Last Call, but which are now in "RFC 5378 limbo",
and an author of some individual IDs that I'd like to update
and move forward) is:

WHO exactly are we supposed to get permissions from.

The situation of a deceased author is a tought one, but it's an
obvious one. But I haven't seen any clear answer to whether
permission from all the authors/editors (the people listed in
the front of the document) is sufficient, whether we have to
ask everybody above a certain percentage of email contributions
in the WG, everybody who's mentioned in the Acks section, or
what. It's a significant nuissance for everybody to go around
and beg people (maybe including for their former employer)
to confirm something they probably couldn't care less, even if
they otherwise think the IETF does great stuff and everything.
So it would really be good to know who exactly has to be
bothered, and who not.

Regards,    Martin.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jan 2009 07:08:20 -0500

On Jan 9, 2009, at 5:42 AM, Martin Duerst wrote:

>>> bother
>>>> IETF

That is really the Trust's text, from

http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf

And, it is from the DRAFT legal provisions, not the current legal  
provisions.

At any rate, I think it needs to be "persons or entities" as some  
copyrights are controlled by corporations, universities
or maybe even governments.

Regards
Marshall

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Jan 2009 09:32:25 -0500

>      the IETF standards process may not have been granted, and

One thing that I don't recall being mentioned explicitely is that any
such clause (IMO) needs to make clear which contributers are granting
full 5378 rights, and which are not. What I mean is that all *current*
contributers (i.e., those involved in the editing the *current*
version of the document) need to make clear that their *new*
contribution *is* covered by 5378. That is, we do not want existance
of pre-5378 text to allow a current contributer to continue to operate
under the pre-5378 rules. It is only the pre-existing text that is
covered by the older rules. Presumably, if at some future time we can
get proper rights from all previous contributers, the document should
then be covered in full by 5378.

Looking at the updated draft legal provisions, this aspect needs a
little bit more clarification, IMO. (I'd be happy to comment further
offline if that is not clear.)

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 09 Jan 2009 10:16:19 -0500

> So it would really be good to know who exactly has to be

IANAL, but if you are expecting anyone (like the IETF) to give a clear
final, legally defensible answer to "who do you need permission from",
you won't get it. That is the nature of legal questions and is what
makes this entire discussion so difficult. And why what is an
accptable risk for you may not be an acceptable risk for me or someone
else.

To answer the question, you have to look at who bears the risk if they
make an assertion (i.e, by claiming that all contributers have signed
off) that someone later challenges. And what the potential
consequences would be.

How likely is such a challenge? (the answer is almost always "it
depends").

What is the likelyhood of a challenge having merit? (answer is "it
depends").

What is the cost (time/money/aggrevation) of having to deal with such
a situation? ("it depends" -- see the pattern?)

While you (personally) may think the risk is negligble and silly, does
your employer (who also probably bears some risk) share your opinion
("it depends").

Etc.

And, it is all made that much worse by having to go through the same
excercise for each document. Having done the analysis on 10 documents,
doesn't help you much when it comes to the next document.

Thomas

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 9 Jan 2009 11:19:34 -0500

> accptable risk for you may not be an acceptable risk for me or someone

My personal feeling is that is it is reasonable to ask authors to give  
their
permission, and to obtain their company's permission, if need be, but  
that
it is not reasonable to ask _authors_ to obtain permissions from third  
parties.

Regards
Marshall

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

---

From: "Ed Juskevicius" <[email-masked]>
Date: Thu, 8 Jan 2009 20:46:54 -0500

Todd, Thank You for your comments. I've read them. Carefully. Three times.

I'm not sure if we are on the same page.

For example, you wrote:

> licenses for any IP that the IETF processed under RFC2026 unless ALL
> of the parties - the people who wrote those drafts, the IP owners of
> that work and anyone who has relied on a SW or systems product
> fabricated under those licenses.

The IETF Trust is not looking for a way to rewrite licenses for IP processed
under RFC2026.  That is not the objective or the driver of the proposed
revision to the Trust's "Legal Provisions" document. 

You also wrote:

> ... If work-product "A" contained specific IP then the used of that
> IP cannot exceed the original licenses including being given to the
> Trust which RFC2026 doesn't provide for in any form. That means that
> the IETF may not in fact convey those document's to the Trust at all.

Could you please point me to text in RFC2026 that pertains to the above?
When I read 2026, I see the following:

10.  INTELLECTUAL PROPERTY RIGHTS
10.3.  Rights and Permissions 
10.3.1.  All Contributions

   l. Some works (e.g. works of the U.S. Government) are not subject to
      copyright.  However, to the extent that the submission is or may
      be subject to copyright, the contributor, the organization he
      represents (if any) and the owners of any proprietary rights in
      the contribution, grant an unlimited perpetual, non-exclusive,
      royalty-free, world-wide right and license to the ISOC and the
      IETF under any copyrights in the contribution.  This license
      includes the right to copy, publish and distribute the
      contribution in any way, and to prepare derivative works that are
      based on or incorporate all or part of the contribution, the
      license to such derivative works to be of the same scope as the
      license of the original contribution.

I believe the text (above) is quite broad and does permit an author (today)
to prepare a derivative work from a pure 2026 licensed work, and then submit
that derived work into the IETF process.  RFC 5378 is the current BCP with
respect to rights in IETF Contributions; it replaces all of the text in
Section 10 from RFC 2026.  5378 requires new author(s) to make some clear
statements about rights to and for the IETF Trust.  

The issue for some authors today is that they may not be able to assert that
the original licenses (covering some earlier work that they may be using)
would allow for use of the new work outside of the IETF process.  Sam
Hartman identified this concern during the IETF Plenary in November 2008,
and that was a trigger for the "work-around" proposal which the Trustees
sent out for review to everyone a few hours ago.

BCP78 is not, in my personal opinion, "garbage".  Rather, I think it is
incomplete with respect to providing guidance on how pre-5378 content in new
contributions should be handled.  That issue is the driver for the proposed
(and temporary) work-around (per below), and it is also the reason I said
that a permanent solution may require new work by the IETF community to
update RFC 5378.

Regards,

Ed J.

-----Original Message-----
From: TSG [mailto:[email-masked]] 
Sent: January 8, 2009 6:21 PM
To: Ed Juskevicius
Cc: 'IETF Discussion'; [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; 'Trustees'
Subject: Re: ANNOUNCEMENT: The IETF Trustees invite your review and comments
on a proposed Work-Around to the Pre-5378 Problem

Ed Juskevicius wrote:

    1)   Pre BCP78

Todd Glassey

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Jan 2009 23:05:01 -0500

Stephen and Fred,

One of the interesting issues with 5378 is that there has never
been consensus about what problem(s) it was trying to solve.
The WG reached consensus on the two documents without, IMO,
reaching consensus on the problem statement.  Nothing in our
procedures prohibits that, whether it is wise or not in a
particular case.

However, to the extent to which "the problem" has been handing
off documents to other bodies, I believe it has always been a
distraction because there is a far easier solution... even
easier than the "go ask that set of authors" suggestion that
Fred proposes.  

One thing that has always been vague, perhaps deliberately, is
just where the boundary of "use in the IETF for IETF purposes"
(a crude paraphrase of the intent that has dominated our
thinking since 2026 and before) lies.    With the understanding
that their situations are a bit different because of different
basic IPR rules, other standards bodies have regularly
interpreted their equivalent principles as giving them the
ability to transfer change control to someone else _as a natural
part of their own work_.  I say "regularly", rather than "often"
because, AFAIK, inter-SDO transfers have never been frequent
(except for specifications developed as national standards by
ISO Member Bodies and then transferred to ISO (or ISO/IEC) for
development and maintenance as International Standards).
Sometimes it might require a bit of a dance --for example, we
could define an IEEE WG as being joint with a shadow IETF one,
but then permit it to work under IEEE rules and approval and
publications process-- but the big issue is the handing over of
change control, not the handing over of the document and the
right to maintain it.

>From that perspective, the "transfer" situation is entirely a
problem of definitions.  It is up to the Trustees to get an
opinion from Counsel, but, as a common-sense matter and with the
understanding that I'm one of the more reluctant members of the
community to hand "do whatever you want" rights off to the Trust
without a formal copyright transfer, I just can't imagine an
author/ contributor who would be ok with the IETF using a
Contribution in IETF Standards work for the benefit of the
Internet community taking serious exception to the IETF's
delegating responsibility for that Standard and its maintenance
to some other body.

If I'm correct and transfer of a Standard to another SDO is
really a non-issue, then perhaps the question of what problem(s)
5378 was intended to solve becomes more relevant... or perhaps
it does not.  But, given the problems the 5378/5377 model has
turned out to create, eliminating one of the major claimed
reasons for creating that model makes it much easier to consider
just repealing the things and doing a small update to 3978/4748
to de-glitch them.

     john

--On Friday, January 09, 2009 0:59 +0000 Stephen Farrell
<[email-masked]> wrote:

> +1 to fred's proposal, let the exceptions be just that and
> don't bother most I-D authors,
> Stephen.
> 
>> In my opinion, we need a 5378-bis that keeps the good bits
>> but   corrects the issue that has been problematic. The
>> question before   the house is how best to achieve that. The
>> proposal here is to   provide a work-around that enables an
>> internet draft author to state   that s/he has not verified
>...
>> From my perspective, the best approach involves keeping the
>> general   case simple. The documents that have been
>> transferred outside the   IETF in the past five years is a
>> single digit number, a tenth of a   percent of all RFCs if
>> not a smaller fraction. From my perspective,   the simplest
>> solution to the transfer issue is to ask the people  
>> relevant to a document for which transfer has been suggested
>> whether   they have an issue with transferring it, rather
>> than asking every   document author his or her opinion on the
>...
>> As to the other issues that 5378 addresses, I suspect that a
>> better   approach will be to fall back to 3978/4748/2026
>> temporarily and move   to 5378-bis when it comes rather than
>> to use this very general   workaround to 5378's issues until
>> 5378-bis is resolved. 3978 etc   worked just fine for most
>> purposes...

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Jan 2009 17:13:39 +1300

If that was the main problem, I would agree. But it isn't; it's the ability
to allow appropriate use of extracts, including code extracts, in 3rd
party documents. That potentially concerns every RFC, and automatically
concerns every RFC that is a new version of an older one.

     Brian

>> From my perspective, the
>>> <Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.DOC><Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf>_______________________________________________
>>>
>>> Trustees mailing list
>>> [email-masked]

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 11:01:09 -0500

--On Friday, January 09, 2009 10:16 -0500 Thomas Narten
<[email-masked]> wrote:

>> The situation of a deceased author is a tought one, but it's
>> an obvious one. But I haven't seen any clear answer to whether

> IANAL, but if you are expecting anyone (like the IETF) to give
> a clear final, legally defensible answer to "who do you need
> permission from", you won't get it. That is the nature of
> legal questions and is what makes this entire discussion so
> difficult. And why what is an accptable risk for you may not
> be an acceptable risk for me or someone else.
> 
> To answer the question, you have to look at who bears the risk
> if they make an assertion (i.e, by claiming that all
> contributers have signed off) that someone later challenges.
> And what the potential consequences would be.

I think this is the crux of the issue.  Let's consider three
possible assertions (deliberately trying to avoid expressing
them in lawyer-speak):

	(1) I give the Trust any rights that I or my company
	have and can give, but make absolutely no assertions
	about anyone else's rights.
	
	(2) I give the Trust any rights that I or my company
	have and can give, and have verified that everyone
	listed on the front page (or in some other list), with
	the following exceptions, have signed off on this.  But
	I make absolutely no assertions about either the rights
	of anyone not listed, nor about anyone whom I had to
	identify as an exception.
	
	(3) I transfer all rights in the document to the Trust
	and guarantee the Trust that I've gotten the ok to do so
	from everyone who might be able to assert a claim of
	rights to the content, whether they are explicitly
	listed or not and whether the claim is bogus or not.
	Implicitly, if the Trust acts on the assumption that
	they have all the rights and someone complains or
	litigates, that is my problem to defend against and not
	the Trust's.

Unless I am hugely confident, either

	*  That I wrote every word of the text myself,
	paraphrasing contributions or suggestions from others,
	or 
	
	* that no one will pop out of the woodwork,

I believe that making assertion (3) is basically insane unless
one is convinced that no one will _ever_ litigate any of this.
If the Trust and IPR WG believed the latter, we wouldn't need
any of this stuff, so forget that.  The 2026/ 3739/ 4879
requirement is not insane because it only requires me to make
assertions based on what I can be reasonably expected to know
(and the transfer is less general, lowering the odds of protests
somewhat).  That doesn't eliminate the risk, but, IMO, brings it
into manageable proportions.

(1) is easy.  (2) is a lot harder, but still plausible.   But
either of those do the one thing that (3) does not and that the
current state of things seem intended to avoid: With (1) or (2),
the Trust cannot write licenses that assert that they actually
control all of the relevant rights (at least without a lot of
expensive insurance).  Consequently, with either of those
options, the risk that someone unidentified might show up and
assert a claim falls on either the Trust or the user of the
material, not the author/editor of the document.

That is the common characteristic of my I-D, Brian's recent I-D,
and at least part of some of the "repeal 5378" suggestions: the
Trust doesn't get to assume that they have clear and unambiguous
title to documents and permission to license them further on
whatever terms they determine (and that, if the assumption is
wrong, it is the author's problem).

It is also, IMO, the fundamental problem with 5378/5377 and with
almost any attempt to patch them.  They are designed to protect
the Trust against granting rights it doesn't have by making the
submitter assume all of the obligations and risks of
guaranteeing the Trust that it does have certain rights.  That
is just not how we ought to be designing things if we want
people to make contributions to the IETF that build on the work
of others.

YMMD
   john

---

From: Dave CROCKER <[email-masked]>
Date: Fri, 09 Jan 2009 09:36:42 -0800

Fred Baker wrote:
> in the past five years is a single digit number, a tenth of a percent of 
> all RFCs if not a smaller fraction. From my perspective, the simplest 
> solution to the transfer issue is to ask the people relevant to a 
> document for which transfer has been suggested whether they have an 
> issue with transferring it, rather than asking every document author his 
> or her opinion on the vast majority of documents, which will never be 
> transferred. 

+1 for simplicity, pragmatics, stability, narrowness of impact, and probably 
"legality".

A number of the comments, so far, appear to hinge on a rather basic cost/benefit 
model that is clearly quite different from what the proposal is based.  I 
suspect that difference comes from a different sense of the problem, per John 
Klensin's posting.

My reference to "legality" is based on a view of the proposal which sees it as 
having individual submitters essentially say "I am required to get permission 
and I have not gotten it".  That's an admission of guilt, which seems like a 
very bad thing to admit and formally document, particularly for an issue 
involving the law.  And if you don't think that's what the proposal calls for, 
please explain, because I don't think my interpretation is all that creative.

I am also struck by the proposal's noting:

> interrupted the publication of some RFCs.  

This means that we have a crisis which is stopping productive work, yet the 
crisis appears to be caused by a faulty new requirement, rather than by the 
situation that the document seeks to correct.  In other words, remove the new 
requirement and we no longer have a crisis.  We have an issue to pursue -- the 
same one that prompted the new requirement -- but no crisis.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 09 Jan 2009 14:54:34 -0500

--On Thursday, January 08, 2009 02:49:16 PM -0800 Fred Baker 
<[email-masked]> wrote:

>  From my perspective, the best approach involves keeping the general case
> simple. The documents that have been transferred outside the IETF in the
> past five years is a single digit number, a tenth of a percent of all
> RFCs if not a smaller fraction. From my perspective, the simplest
> document for which transfer has been suggested whether they have an issue
> with transferring it, rather than asking every document author his or her
> opinion on the vast majority of documents, which will never be
> transferred. Remember that this boilerplate affects internet drafts, but
> most internet drafts are discussion documents - a fraction of internet
> drafts even become RFCs, and a small fraction of RFCs are transferred
> elsewhere.

The difficulty with this approach is that it allows authors to decide 
whether to grant us the rights we require until the point at which we wish 
to exercise them, rather than requiring that they grant those rights before 
we take their contribution and turn it into a widely-deployed Internet 
standard.

I don't believe we need to go back and ask every author of every published 
RFC and I-D to grant the additional rights, and I don't believe we need to 
have a system that blocks the submission and/or progress of current 
documents solely because they are built on earlier documents which were 
published before the new rules came into effect.  However, I do think if we 
want the additional rights required by RFC5378, we need to require they be 
granted at the time that a document is submitted.

It sounds to me like the trustees' proposal does a reasonable job of 
balancing the conflicting goals and achieving something useful.

-- Jeff

> approach will be to fall back to 3978/4748/2026 temporarily and move to
> 5378-bis when it comes rather than to use this very general workaround to
> 5378's issues until 5378-bis is resolved. 3978 etc worked just fine for
> most purposes...

If we reach consensus that the solution to the problem is to change 5378, 
rather than to semi-permanently adopt a workaround such as the trustees 
have proposed, then I would not object to falling back to the older rules 
until the issue is resolved.

---

From: Russ Housley <[email-masked]>
Date: Sun, 11 Jan 2009 12:25:59 -0500

[Smaller Distribution]

John:

You may recall the XMLDSIG WG, which operated under both the IETF and 
W3C to create a joint standards.  Getting the same words approved 
under both processes at the same time was a real pain.  One that was 
not repeated when XML Encryption standards were developed.

The recent discussions with ITU-T on requirements for MPLS-TP further 
demonstrate the difficulties of two SDOs working together.  If the 
IETF and ITU-T had to agree on the words for a protocol 
specification, the process would be much more lengthy.

My lesson from this activity is that joint development is much harder 
than the sum of its components.  The rewards would have to be 
significant in order to repeat it.  This is not a statement about W3C 
or the ITU-T.  It is a statement about trying to merge the approval 
processes of any two organizations.

Russ

---

From: [email-masked]
Date: Sun, 11 Jan 2009 17:02:40 -0500

John,

> just repealing the things and doing a small update to 3978/4748

My recollection of one of the major problems that 5378 was
intended to solve is allowing use of text from IETF standards
outside of the IETF.  Two specific examples are:
1) Use of code from an RFC in an implementation.  This often
	requires the ability to modify the code in some minor
	ways.
2) Use of text from an RFC in another standard.  This is *not*
	transfer of the standard, but rather allowing use of
	the actual text in a different standard that does
	something similar.
The pre-5378 copyright rules block both of these.

The ipr WG spent a great deal of time discussing code use, and
whether to apply the same provisions to text (ultimately, the
same provisions were not applied).  I have personally been in a
situation where an editor in another standards organization had
to do a complete rewrite of a large quantity of text obtained
from an RFC because the IETF could not grant copyright
permission independent of whether the IETF wanted to grant
that permission or not.

Regardless of the mess that's been made for revisions of
documents that used the old rules, I doubt that a "de-glitch"
effort on 3978/4748 can address the two examples noted above, 
as both require additional permissions from authors that the
IETF has not obtained in the past (and hence that the IETF
does not have for documents created under past rules).

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: John C Klensin <[email-masked]>
Date: Sun, 11 Jan 2009 13:47:09 -0500

--On Sunday, January 11, 2009 12:25 -0500 Russ Housley
<[email-masked]> wrote:

> [Smaller Distribution]
> 
> John:
> 
> You may recall the XMLDSIG WG, which operated under both the
> IETF and W3C to create a joint standards.  Getting the same
> words approved under both processes at the same time was a
> real pain.  One that was not repeated when XML Encryption
> standards were developed.
> 
> The recent discussions with ITU-T on requirements for MPLS-TP
> further demonstrate the difficulties of two SDOs working
> together.  If the IETF and ITU-T had to agree on the words for
> a protocol specification, the process would be much more
> lengthy.
> 
> My lesson from this activity is that joint development is much
> harder than the sum of its components.  The rewards would have
> to be significant in order to repeat it.  This is not a
> statement about W3C or the ITU-T.  It is a statement about
> trying to merge the approval processes of any two
> organizations.

Nor was I suggesting anything of the sort, especially since I
was somewhat in the policy middle of the ISO-ITU Joint
Development Agreement that brought us, among other things, OSI.

But joint development, or even joint approval, are very
different from one SDO saying "by mutual consent, we are
delegating further development and maintenance of this
particular document to some other SDO".

     john

---

From: "David Harrington" <[email-masked]>
Date: Mon, 12 Jan 2009 14:07:35 -0500

> case simple. 

I concur.
I think we should continue to use the RFC3978 rules as the default,
and to allow WGs to choose to assign, or not, the new rights on new
documents.

I was author of 4663, and I coordinated the whole effort to transfer
the rights to the Bridge MIB documents from IETF to IEEE. I can state
that getting permission from the authors and their companies was not
onerous, but I would not want to do that for documents that were not
being transferred.

I will observe that the requirement we met for RFC4663 was to get
permission from the authors of the current drafts, and the authors of
the previous revisions, and their companies. We did not try to
determine the complete list of people who contributed to the works as
WG members. I think THAT task would have been so onerous that I would
have argued against doing the transfer, and told IEEE persons to just
come work in the IETF instead.

In actuality, for RFC4663, the IEEE lawyers got the permissions. I
just helped by identifying the authors and their companies. I suggest
the right way to handle this in the future is to let the copying
organization go get the permissions and assume any related risk. To
make that easier, I would not have a problem with a WG deciding to
include the right to copy. But then the question becomes "is rough
consensus adequate?" or must it be unamimous? If it has to be
unanimous, then we apparently would need a membership and voting
system, so we know who has a say, and whether they have voted or not.

I have been an editor of IETF documents for years, and have never
tried to document where every contribution came from, or tried to
track the legal permissions granted by each contributor for their
text. If I am expected to assume legal risk for asserting that all
rights have been granted for text in documents being transferred or
being copied into other documents, for all contributors to a WG
document, then I would gladly give up editing.

I really do not like the changes this new boilerplate forces onto the
IETF process.
I would rather continue to use RFC2026/3978 rules.

David Harrington
[email-masked]
[email-masked]
[email-masked]