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@xxxxxxxxx> 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.etc@xxxxxxxxx
>>> <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@xxxxxxxx
>>> https://www.ietf.org/mailman/listinfo/trustees
>>
> _______________________________________________
> Ietf mailing list
> Ietf@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
>
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf