Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and co

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.
>
> On 8 Jan 2009, at 22:49, Fred Baker <fred(_at_)cisco(_dot_)com> wrote:
>
> > 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. 
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.

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.

     Brian

> > 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:
> >
> > > 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
> > > edj(_dot_)etc(_at_)gmail(_dot_)com
> > > <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
> > > Trustees(_at_)ietf(_dot_)org
> > > https://www.ietf.org/mailman/listinfo/trustees
> _______________________________________________
> Ietf mailing list
> Ietf(_at_)ietf(_dot_)org
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf