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

"Ed Juskevicius" <> Thu, 08 January 2009 21:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 8C9113A69D1; Thu, 8 Jan 2009 13:43:37 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C995F3A6990; Thu, 8 Jan 2009 13:43:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.666
X-Spam-Status: No, score=-2.666 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N6K3UOCVgVcC; Thu, 8 Jan 2009 13:43:34 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 59B303A67CC; Thu, 8 Jan 2009 13:43:33 -0800 (PST)
Received: by with SMTP id c5so3245154anc.4 for <multiple recipients>; Thu, 08 Jan 2009 13:43:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject:date :message-id:mime-version:content-type:x-priority:x-msmail-priority :x-mailer:thread-index:x-mimeole:importance; bh=fJTJS3cAryI6uj/JYy+1cY/PI/FBceiKTp4Xf2y0MCM=; b=aWPSO5YWQhergfJ+i1at6ieucxPMm9mRWql5OKVYaEfXMqWcCK7AFSfBnHtd2+qvnT kXX2Y2KoN1Bhjnt91CKx1JgoOvDXg3BQwpH/M6QysGk8+wxqrPHM0rOPrLDp/4/gNTR6 2BD2n/3LluDLZGJW2ak0UejBZ1cXkVomXut0g=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-priority:x-msmail-priority:x-mailer:thread-index:x-mimeole :importance; b=H+/k2YGtz/kV9nq4ssIFxqFPFf9YSDVorhuX55F2vbU1tsD+7dOnLolGy6h5qws8kz Wn85Ar1fOGY4TwmMvCw0uyjj0r2ZvoAari5M/FzLGB76C9Wwa4Ej+MtG4sK0GmpPISQL Qqvh5PI6QTEKn0tEqavG/7/7nZ7/KoZ2cdFl8=
Received: by with SMTP id z18mr17831549qbl.11.1231450997994; Thu, 08 Jan 2009 13:43:17 -0800 (PST)
Received: from noisy ( []) by with ESMTPS id k27sm56383273qba.22.2009. (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jan 2009 13:43:15 -0800 (PST)
From: Ed Juskevicius <>
To: 'IETF Discussion' <>,,,,,
Subject: ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Date: Thu, 08 Jan 2009 16:43:50 -0500
Message-ID: <70873A2B7F744826B0507D4B84903E60@noisy>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0020_01C971B0.4A1BABC0"
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AclxuETcvNCPupucRASslmyMepJprwAFxkPA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Importance: High
Cc: 'Trustees' <>
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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, 
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:

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

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: 

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
Ietf mailing list