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

[Bernard Aboba <[e-mail]>]

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

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  
> 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:
> 
> > 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
> > [e-mail]
> > <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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/trustees
> 

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf