Subject: I-D ACTION:draft-ietf-ipr-rules-update-04.txt

From: [email-masked]
Date: Thu, 02 Mar 2006 15:50:01 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Intellectual Property Rights Working Group of the IETF.

	Title		: RFC 3978 Update
	Author(s)	: S. Bradner
	Filename	: draft-ietf-ipr-rules-update-04.txt
	Pages		: 11
	Date		: 2006-3-2
	
This document modifies RFC 3978 "IETF Rights in Contributions" as
   follows: (1) recognizing that the IETF Trust is now the proper
   custodian of all IETF-related intellectual property rights, (2)
   giving IETF Trust the right to permit extraction of material from
   RFCs, and (3) giving IETF Trust the right to permit others to create
   derivative works outside the IETF Standards Process.

   This document does not constrain how the IETF Trust exercises those
   rights.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipr-rules-update-04.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ipr-rules-update-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ipr-rules-update-04.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Ipr-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipr-wg

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Mar 2006 08:34:44 +0100

I think this is subtstantially fine. In fact I only have a few
comments.

> 1.3 Right to reprint RFCs
...
>    ...The IETF Trust should add a new Section 3.3(F) to RFC 3978 to
>    clarify that the Contributor permits the IETF Trust to grant this
>    right to third parties,...

It isn't the Trust that can add anything to RFC 3978. I think this should
be phrased in the passive tense:

    ...A new Section 3.3(F) should be added to RFC 3978 to
    clarify that the Contributor permits the IETF Trust to grant this
    right to third parties,...

> 6.2.1 Revised Section 5.4
> 
>    5.4.  Copyright Notices (required for all IETF Documents)
> 
>       (Normally placed near the beginning of the IETF Documents)
> 
>          "Copyright (C) The IETF Trust (year).

Needs clarification of *which* year is to be mentioned.

I still have my general preference for this to be finally published
as a clean RFC3978bis and not as a set of deltas.

    Brian

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 14 Mar 2006 14:03:04 +0100

> Abstract

Very clear.

> 1. Introduction
>
> 1.1  IETF Trust
>
>    Currently the IETF requires that authors of Contributions to the IETF
>    grant to the IETF (meaning the full set of participants in the IETF
>    Standards Process) a limited set of non-exclusive rights and
>    permissions as part of the process of submitting such Contribution.
>    These rights and permissions are detailed in "IETF Rights in
>    Contributions" (RFC 3978 - BCP 78) [RFC3978].

And as updated by this document?

>    The IETF Trust was recently formed to act as the administrative
>    custodian of all copyrights and other intellectual property rights
>    relating to the IETF Standards Process that had previously been held
>    by ISOC (See [reference to IETF Trust Agreement]).  This document
>    modifies RFC 3978 in order to implement this structure.

Ok.

>    Most importantly, it alters the license-grant path as follows:
>    whereas previously authors of Contributions to the IETF would
>    grant a license both to ISOC and to all IETF participants, it is
>    now proposed that such authors grant a license to the IETF Trust
>    (in Section 3.3),

Right.

>    and that the IETF Trust concurrently grant the necessary
>    corresponding licenses to all IETF participants (in a new Section
>    3.7).

This seem to be an outbound rights matter.  That is not discussed in
the abstract.  I believe we agreed in the charter to separate these
two matters into different documents.

>    In addition, under new Section 3.7 the IETF Trust will be able to
>    grant rights to third parties (such as the right to reproduce and/or
>    create derivative works outside of the IETF Standards Process).  This
>    right may be constrained in future RFCs, and this memo is not
>    intended to dictate how or when the IETF Trust may grant licenses to
>    third parties.  It merely obtains the necessary "inbound" rights from
>    the relevant Contributors.

The section 3.7 title is 'Rights granted by IETF Trust to IETF
Participants'.  That seems to be an outbound right.  Conflating these
two issues in the same text update seem flawed to me.

> 1.2. Extractions from RFCs
>
>    Many people have expressed a desire to extract material from IETF
>    RFCs for use in documentation, textbooks, on-line help systems, and
>    for similar uses. In addition, some IETF RFCs contain MIBs and other
>    types of program code that could be compiled. The IETF Trust should
>    update Section 3.3(a)(E) of RFC 3978 (now renumbered 3.3(E)) to at
>    least explicitly permit extracting material, without modification of
>    the text or figures, for such uses.  Non-substantive changes such as
>    changes to fonts, and translations into languages other than English
>    would be permitted.

This seems good.

>    Since the start of the RFC series, third parties have been free to
>    reproduce RFCs as-is or as translations.

To avoid getting into interpretation of old legal language, and
rewriting history, I suggest changing this to:

    Since the start of the RFC series, the intention has been that
    third parties have at least been free to reproduce RFCs as-is or
    as translations.

This enable the possibility that some past legal texts we used did not
actually permit this.  (Example: the legal license text in RFC 3978
does not grant third parties this right.)

This also enable the possibility that the intention has been that
third parties was free to do even more things.  (Example: Given how
IETF standards have been used in both closed source and free
implementation in the past 20 years, I believe the intention all along
has been to permit implementations to adapt text and to be able to
modify it.)

>    The permission to do so was not specifically noted in early RFCs
>    (other than a note to say that the distribution of the RFC was
>    unlimited).  The copyright notice introduced with RFC 1602
>    specifically granted these permissions.  But an unintended
>    byproduct of the attempt in BCP 78 to simplify the copyright

For completeness, it would be helpful to talk about RFC 2026 too.

>    statement in published RFCs was the lack of any specific
>    statement of these permissions in the RFC copyright notice or in
>    BCP 78.  The IETF Trust should add a new Section 3.3(F) to RFC
>    3978 to clarify that the Contributor permits the IETF Trust to
>    grant this right to third parties,

Right.

>    and also add the IETF Trust's grant of such license as to both
>    the rights granted by each Contributor and the rights in the
>    collection that are possessed by IETF Trust itself.

I don't understand this sentence.  Is it talking about a new outbound
rights grant?  I believe it shouldn't.

>    This latter grant was previously implied through the copyright
>    legend material included in RFC documents, but was not expressed
>    as a license grant as it now is.

Please change 'implied' to 'intended to be implied' and 'copyright
legend' to 'RFC legend'.

Discussion:

Implying something doesn't make it legal, especially when the actual
license says the opposite.

The legend was in the 'Status of this memo' section which does not
talk about copyrights.  Calling it the 'copyright legend' false imply
that the note about unlimited distribution was given in a copyright
context.

> 1.4  Derivative Works
>
>    Currently the IETF obtains from Contributors the right to prepare
>    derivative works of their Contributions within the IETF Standards
>    Process.  This is done in RFC 3978 Section 3.3 (a) (C).   The IETF
>    Trust should modify that paragraph in Section 3.7 to grant the IETF
>    Trust the ability to authorize the preparation of derivative works
>    without limiting such development to the IETF Standards Process.

Good.

>    Such a paragraph would not, by itself, grant any additional
>    permissions outside of the IETF, but would empower the IETF Trust to
>    authorize the development of derivative works outside of the IETF
>    Standards Process.

Very clear, nice.

>    One example of where the IETF Trust might grant such a right is
>    the case where another standards development organization (SDO)
>    wants to update or extend an IETF technology (which would
>    normally be done by the SDO sending their requirements to the
>    IETF) but the IETF no longer has a working group focused on the
>    particular technology and the IETF does not have the interest to
>    create a new working group.

I suggest splitting the text in section 1.4 into three paragraphs, as
I have done here.  The reason is that the first sentence contain the
interesting stuff, and the second two only discuss consequences and
examples.

> 1.5  No Retroactive Effect
>
>    The addition of these rights to those granted by Contributors under
>    RFC 3978 starts with the publication of this memo as a RFC.

Technically, isn't this actually when the IETF and RFC Editor start to
use the new RFC as their guiding document?  It may take for the IETF
to update the NOTE WELL notices etc.

>    This memo does not retroactively obtain these rights from
>    Contributions that predate the publication of this memo as a RFC.
>    Accordingly, the legends and other text accompanying this memo
>    still reflect the provisions of RFC 3978, even though those
>    provisions will be amended once this memo is published as an
>    RFC. However, nothing prevents the Contributors of such
>    Contributions voluntarily granting these rights retroactively.

Very clear!

> 2.   General Statements
>
> 2.1  In order to clarify that Contributors are bound by all provisions
>    of RFC 3978 upon submission of a Contribution to the IETF, the
>    following paragraph is moved from Section 3.3 to the end of Section
>    3.1, with clarifying adjustments:
>
>       "By submission of a Contribution, each person actually submitting
>       the Contribution, and each named co-Contributor, is deemed to
>       agree to the terms and conditions set forth in this document, on
>       his or her own behalf and on behalf of the organization the
>       Contributor represents or is sponsored by (if any), when
>       submitting the Contribution."

Changing 'the following terms and conditions' (RFC 3978 3.3) to 'the
terms and conditions set forth in this document' (text above)
complicate several things:

Which document does 'this document' refer to?  RFC 3978?  BCP 78?
draft-ietf-ipr-rules-update-04.txt?

Further, it may cause the contributor to agree to many terms that
doesn't affect him as contributor.  That seem to be a legal risk.  It
would be better if the list of terms and conditions he needs to agree
to was limited to the terms and conditions needed by the IETF to use
the contribution.

I think there may be some other minor problems too.

This problem suggest we should supersede RFC 3978 completely with one
document.

I ask that this text should be moved back to 3.3 (and to each section
demanding similar text) and the wording changed back to the RFC 3978
wording.

> 2.2  Because it is necessary in this document to refer to individual
>    IETF participants, the following sentence is added at the end of the
>    definition of "IETF" in Section 1(a) of RFC 3978:
>
>       "An "IETF Participant" shall mean any such individual
>       participant."

Good.

> 3.   Rights Granted By Contributors to IETF Trust - New Section 3.3
>
>    The following text describes the rights that are granted by each
>    Contributor to the IETF Trust and replaces Section 3.3 of RFC 3978 in
>    full:
>
>       "3.3.  Rights Granted by Contributors to IETF Trust
>
>       To the extent that a Contribution or any portion thereof is
>       protected by copyright or other rights of authorship, the
>       Contributor, and each named co-Contributor, and the organization
>       he or she represents or is sponsored by (if any) grant a
>       perpetual, irrevocable, non-exclusive, royalty-free, world-wide
>       right and license to the IETF Trust under all such copyrights and
>       other rights in the Contribution, with the understanding that the

Why was 'and other rights' added?  This seem unclear to me.  Can it be
read to cover patents?  I think this should be clarified so it is
clear what other rights are intended.

>       IETF Trust shall have the right to sublicense these rights to the
>       extent described in Section 3.7 below:
>
>       (A) to copy, print, publish, display, and distribute the
>          Contribution as part of the IETF Standards Process or in an
>          Internet-Draft,
>
>       (B) to prepare or allow the preparation of translations of the
>          Contribution into languages other than English,
>
>       (C) unless explicitly disallowed in the notices contained in a
>          Contribution [as per Section 5.2 below],
>
>          (1) to modify or prepare derivative works (in addition to
>             translations) that are based on or incorporate all or part
>             of the Contribution or comment upon it, within the IETF
>             Standards Process, and

Ok.

>          (2) as determined by the IETF Trust, to grant third parties the
>             right to modify or prepare derivative works of the
>             Contribution outside of the IETF Standards Process, and to
>             copy, publish, display and distribute such modifications or
>             derivative works outside the IETF Standards Process, subject
>             to a requirement to properly acknowledge the IETF (it being
>             understood that neither consent of, nor notice to, the
>             Contributor shall be required for any such grant),

The requirement in the INBOUND rights to have the OUTBOUND rights
properly acknowledge the IETF seem very unfortunate.  Let's leave
those decisions to the IETF Trust.

>          provided that in each case the license to such modification or
>          derivative works does not grant any more rights than the
>          license to the original Contribution, and
>
>       (D) to reproduce any trademarks, service marks or trade names
>          which are included in the Contribution solely in connection
>          with the reproduction, distribution or publication of the
>          Contribution and derivative works thereof as permitted by this
>          Section 3.3, provided that when reproducing Contributions,
>          trademark and service mark identifiers used in the
>          Contribution, including (TM) and (R) will be preserved, and

This is also unfortunate, and may restrict the rights to derivative
works.  In many jurisdictions, there are no requirement to include
(TM) and (R) notices.  Again, having the INBOUND rights place
restrictions on what the OUTBOUND rights can be seem unfortunate.

>       (E) to extract, copy, print, publish, display, distribute and
>          incorporate into other works, for any purpose (and not limited
>          to use within the IETF Standards Process), any portion of the
>          Contribution without modification (other than non-substantive
>          modifications such as reformatting, translation into languages
>          other than English or compilation of source code statements
>          into executable code), and further provided that the notices
>          required by Sections 5.4 or 5.6 below, as applicable, are
>          included, and

This change is moving in the right direction, but there are still
several problems here.

1: It is unclear what non-substantive modifications are permitted by
   'compilation of source code statements into executable code'.  I
   wonder whether it is understood what compilation of source code to
   an executable code means here.  To me, any compilation of source
   code statements into executable code is a substantive
   modifications.

   It would be better if it is changed to 'any changes required to
   make use of source code statements, including compilation to
   executable code'.

2: The notice in 5.4 is:

         This document is subject to the rights, licenses and
         restrictions contained in BCP 78, and except as set forth
         therein, the authors retain all their rights."

   If I extract a small portion of the core part of the document (such
   as an ASN.1 schema or StringPrep tables), which the IETF Trust
   doesn't have any copyright claim to, this copyright statement is
   confusing.  I'm told that in some jurisdictions, it is even illegal
   to incorrectly claim copyright on something.

   This may be mitigated by the 'as applicable' statement in the text
   above.  However, it is not clear what this applies to.  If it is OK
   to avoid the 5.4 notice in, e.g., an ASN.1 schema extract, that
   should be clarified somehow.

3: This talks about OUTBOUND rights.  My discussion about moving all
   those discussions to a separate document apply.

>       (F) to permit third parties to copy, publish, display and
>          distribute the Contribution without modification, as part of a
>          full, unmodified RFC and to permit third parties to translate
>          the Contribution as part of a full, unmodified RFC into
>          languages other than English, for any purpose, whether or not
>          within the IETF Standards Process.

>          The licenses granted in this Section 3.3 shall not be deemed to
>          grant any right under any patent, patent application or other
>          similar intellectual property right disclosed by the
>          Contributor under BCP 79.

The last paragraph seem to be poorly indented.  It claim to refer to
all of 3.3, but is indented to be under (F) only.  What is the
intention?

> 4.   Rights Granted By IETF Trust to IETF Participants - Possible new
>    Section 3.7

This seem to be an OUTBOUND right.

>    Now that Contributors are granting rights to the IETF Trust, the IETF
>    Trust will have to state what rights are being granted to IETF
>    Participants.  Accordingly, the IETF should add text no more
>    restrictive than the following Section 3.7.  Such a section woukd
>    simply repeat the license grants from Section 3.3 that are intended
>    to be granted to all IETF Participants.  Additional rights described
>    in Section 3.3 could also be granted by the IETF Trust pursuant to
>    separate documents.

I have to admit that requiring the IETF Trust to use text 'no more
restrictive' than some clearly explained terms seem like a good idea.

Such text may ease concerns that we don't want to give the IETF Trust
too much powers in this area; that opinion was voiced during the
Vancouver meeting, but was (I believe) inappropriately dismissed
immediately.  The IETF Trust doesn't seem to be formally controlled by
the IETF (having the same membership as some IETF accountable body is
not the same thing), so putting in some restrictions on what it can do
seem prudent.

>    "3.7 Rights granted by IETF Trust to IETF Participants
>
>       The IETF Trust hereby grants to each IETF Participant, to the
>       greatest extent it is permitted to do so, the following perpetual,
>       irrevocable, non-exclusive, royalty-free, world-wide rights and
>       licenses under all copyrights and other rights of authors:
>
>       (A) to copy, publish, display, and distribute each IETF Document
>          (including all Contributions and other portion thereof) as part
>          of the IETF Standards Process, in an Internet-Draft or
>          otherwise,
>
>       (B) to prepare translations of IETF Documents (including all
>          Contributions and other portion thereof) into languages other
>          than English,
>
>       (C) unless explicitly disallowed in the notices contained in a
>          Contribution [as per Section 5.2 below], to modify or prepare
>          derivative works (in addition to translations) that are based
>          on or incorporate all or part of the Contribution or comment
>          upon it, within the IETF Standards Process, provided that in
>          each case the license to such modification or derivative works
>          does not grant any more rights than the license granted to the
>          IETF Trust in the original Contribution, and
>
>       (D) to reproduce any trademarks, service marks or trade names
>          which are included in a Contribution solely in connection with
>          the reproduction, distribution or publication of the
>          Contribution and derivative works thereof as permitted by this
>          Section 3.7, provided that when reproducing Contributions,
>          trademark and service mark identifiers used in the
>          Contribution, including (TM) and (R) will be preserved.
>
>             The licenses granted in this Section 3.7 shall not be deemed
>       to grant any right under any patent, patent application or other
>       similar intellectual property right disclosed by the Contributor
>       under BCP 79.

I will postpone my review of these grants until I see more discussion
on this general direction.  We have not discussed this approach
before.  Jumping into the legal texts may be premature.

> 5.   Rights Granted By IETF Trust to Third Parties - Possible New
>    Section 3.8
>
>    Under the licenses granted by Contributors in Section 3.3, the IETF
>    Trust has the ability to grant rights in Contributions and other
>    portions of IETF Documents to third parties for use outside the IETF
>    Standards Process.   One such right is the right to copy and
>    republish IETF Documents without modification.  This right is
>    automatically granted to all persons pursuant to new Section
>    3.8(A)(1) below.  Other rights may be granted by the IETF Trust in
>    its discretion.  Rules about the exercise of this discretion may be
>    implemented at a later date, and do not form part of this document.

Here it may also be useful to define the least restrictive license
that we are willing to accept, just like in the new 3.7.

>    "3.8 Rights Granted by the IETF Trust to Third Parties
>
>       (A)  The IETF Trust hereby grants to any person wishing to obtain
>          such rights, to the greatest extent it is permitted to do so,
>          the following perpetual, irrevocable, non-exclusive, royalty-
>          free, world-wide rights and licenses under all copyrights and
>          other rights of authors:
>
>          (1)  to extract, copy, publish, display, distribute and
>             incorporate into other works, for any purpose (and not
>             limited to use within the IETF Standards Process), all or
>             any portion of any IETF Document (including all
>             Contributions and other portions thereof) without
>             modification (other than non-substantive modifications such
>             as reformatting, translation into languages other than
>             English or compilation of source code statements into
>             executable code), and further provided that the notices
>             required by Sections 5.4 or 5.6 below, as applicable, are
>             included.
>
>       (B)  The IETF Trust may, in its discretion, grant additional right
>          to third parties to the extent that its licenses under Section
>          3.3 permit it to do so.  Until specific procedures for the
>          exercise of such discretion are published in an RFC, the IETF
>          Trust shall consult with the IESG prior to granting any such
>          rights.

I will postpone my review of these grants too.  They seem to be an
OUTBOUND rights, so inappropriate in this document.  I see directly
that I will have strong opinions on this section.

> 6.   Legends and Notifications
>
>    The legends and notifications required by RFC 3978 are hereby updated
>    as set forth below to reflect the other provisions of this document.
>
> 6.1  The first paragraph of Section 5 of RFC 3978 explains the
>    requirement for applying certain notices and legends to IETF
>    documents.  There has been considerable confusion in the past
>    regarding the meaning of the copyright notice on these documents.
>    Accordingly, the first paragraph of Section 5 is hereby amended as
>    follows to explain the purpose and meaning of this copyright notice
>    requirement, as well as to substitute "IETF Trust" for "ISOC":
>
>       "The IETF requires that certain notices and disclaimers described
>       in this Section 5 be reproduced verbatim in all IETF Documents
>       (including copies, derivative works and translations of IETF
>       Documents, but subject to the limited exceptions noted in Section
>       5.2).  This requirement protects the IETF Trust, IETF and IETF
>       Participants from liabilities connected with these documents.
>
>       The copyright notice also alerts readers that the document is an
>       IETF Document, and that the IETF Trust owns the copyright in the
>       "collective work", as well as certain aspects of the document,
>       such as its layout, the RFC numbering convention and the prefatory
>       language of the document.  This legend is not, however, intended
>       to imply that IETF or the IETF Trust owns the text of any
>       Contribution included in an IETF Document.  Rather, ownership of
>       such Contributions is retained by the author(s) or remains in the
>       public domain, as applicable, subject only to the licenses granted
>       to IETF and the IETF Trust under Section 3.3 above."

That is a good section.

> 6.2 Update copyright statement and clarify text about additional
>    copyright statements
>
>    The creation of the IETF Trust to hold IETF-related IPR requires that
>    the copyright statement in Section 5.4 be changed.  Since it has been
>    established practice to include a one-line copyright statement near
>    the beginning of IETF Documents this should be mentioned.
>
>    The text in Section 5.4 about multiple copyright statements has
>    occasionally been misinterpreted so should be clarified.

Fine.

>       (Normally placed at the end of the IETF Document.)
>
>          This document is subject to the rights, licenses and
>          restrictions contained in BCP 78, and except as set forth
>          therein, the authors retain all their rights."

These notices are required in other situations too, compare the text
in 3.3 (E), but this section is very focused only on IETF documents.
Perhaps there could be a notice that is more appropriate for other
uses.

>       Only copyright notices for the IETF Trust are permitted in IETF
>       Documents except in the case where such a document is the product
>       of a joint development effort between the IETF and another
>       standards development organization or the document is a
>       republication of the work of another standards organization.  Such
>       exceptions must be approved on an individual basis by the IAB.

I wonder whether we may want to change this requirement.  In some
situations (like source code snippet with a permissive license) it
does seem useful to permit inclusion of a copyright statement.

> 6.3  In Section 5.6 of RFC 3978, all occurrences of "Internet Society"
>    or "ISOC" are replaced by "IETF Trust".
>
>    to reduce confusion the note about multiple copyright notices
>
> 6.4  In Section 5.5 of RFC 3978, ", THE IETF TRUST" is inserted after
>    "INTERNET SOCIETY".
>
> 7.   Errata
>
> 7.1  The two sentences of Section 4.2(a)(C) are combined into a single
>    sentence separated by a comma.
>
> 7.2  In Section 7.1, all occurrences of "Internet Society" or "ISOC" are
>    replaced by "IETF Trust".
>
> 7.3  The section reference at the end of the first paragraph of Section
>    7.3 is changed from 3.3(E) to 3.3(C).
>
> 7.4. In Section 8, ", the IETF Trust" is inserted after "ISOC".

Fine.

Thanks,
Simon

---

From: [email-masked] (Scott Bradner)
Date: Tue, 14 Mar 2006 08:51:46 -0500 (EST)

> has been to permit implementations to adapt text and to be able to

believe what you want, but you are wrong when it comes to post RFC 1602
IETF RFCs - it was never the intent to permit the modification of RFC
text (other than translations) outside of the standards process

Scott
(editor of 2026 and quite sure what I and the poised WG intended
when I edited the dociment)

---

From: "todd glassey" <[email-masked]>
Date: Tue, 14 Mar 2006 09:28:22 -0800

HARALD - new issue #6

HA - in addition to the five (5) Issues I sent you yesterday, there is
another one... that of how Industry BCP's are expired within the IETF and
how long a unreviewed for current-accuracy BCP documents remain 'current'
per BCP79 and other IETF framework documents.

The problem is that unlike RFC's where the publication is a Request for
Input - a BCP is a formal attestation as to what a current Best Current
Practice actually is. At least how the documents are perceived by the
Industry based on how they are represented by the IETF's membership - making
any disclaimers of "Fit for Use" or Disclaimers of Liability likely
unenforceable in a court - and as such both worthless and a smokescreen to
allow the IETF to not address this matter IMHO...

Managing BCP's
-----------------
As noted above, BCP documents published under the banner of the IETF
represent a liability - unless they are constrained to being in the IPR WG
about the IETF's processes. They are the IETF's assurance to the World that
they as "Best Current Practice" documents represent the best current (and
the timeliness of this statement is the key here) practices in the Industry
or a proposed-BCP for an Industry.

Expiring BCP's
---------------
The problem is that Industry Adoption of BCP's change and age, and when the
Industry evolves past them there is this document which the IETF is stuck
with as 'still being the current document' which means that from an
audit-perspective the controls on BCP are essentially non-existent. Once
published as a BCP today - then always referenceable as a BCP permanently
which creates a liability to the IETF when that BCP becomes dated or stayed.

What the Industry BCP's need is a regular review process formally. The
review should be done by the WG or someone who doesn't have a vested
interest in the work itself, like possibly the WG Chair although from an
Arms-length model, that may be too close as well.

This cannot be left to the WG
------------------------------
Many of you will disagree with this statement, and claim that WG's can
expire their own documents per their own desires, and this is the perfect
demonstration why this IETF is broken fundamentally from the Top-Down. How
many documents has this IETF actually expired formally - and what happened
to them in that expiry - did their copyrights change, was there anything
done to prevent their continued use? - no - they were mechanically - by the
IETF's operating processes, abandoned on the instant of their publication
and that is something IMH lay opinion that this IETF cannot refute, legally
speaking.

Standard of Care Requirement in managing BCP's
---------------------------------------------------
The problem is that the IETF is about open and fair processes that can be
used to create relevant and important standards work, but this process must
also in a timely manner expire and remove from circulation,
critically-outdated documents released as BCP's because of the potential
liabilities of being a Public Standards Org and not being able to keep the
'public recommendations up to date' which would make participation in the
IETF less important and weaken its Brand-value in my opinion.

Means a new Copyright Statement
-----------------------------------
The issue with meeting this document and publication management requirement
is of course how to expire documents and pull them from circulation which
clearly also means rethinking the Copyright Statements since the IETF can
***never*** lose control of its BCP's as it does with its RFC's

Just an observation as an Entrepreneur and IP owner...

Todd Glassey