Subject: IESG Statement on Removal of an Internet-Draft from the IETF Web Site

From: IESG Secretary <[email-masked]>
Date: Thu, 25 Oct 2012 11:47:20 -0700

Internet-Drafts (I-Ds) are working documents of the IETF.  RFC 2026,
BCP 9, describes the purpose of I-Ds, and it also provides some policies
that govern the I-D Repository.  RFC 2026 says:

   During the development of a specification, draft versions of the
   document are made available for informal review and comment by
   placing them in the IETF's "Internet-Drafts" directory, which is
   replicated on a number of Internet hosts.  This makes an evolving
   working document readily available to a wide audience, facilitating
   the process of review and revision.

   An Internet-Draft that is published as an RFC, or that has remained
   unchanged in the Internet-Drafts directory for more than six months
   without being recommended by the IESG for publication as an RFC, is
   simply removed from the Internet-Drafts directory.  At any time, an
   Internet-Draft may be replaced by a more recent version of the same
   specification, restarting the six-month timeout period.

   An Internet-Draft is NOT a means of "publishing" a specification;
   specifications are published through the RFC mechanism described in
   the previous section.  Internet-Drafts have no formal status, and are
   subject to change or removal at any time.

I-Ds provide important historical records for the open and transparent
operation of the IETF.  It should be noted that individuals and groups,
including the IAB and IRTF Research Groups, have chosen to distribute
working documents as I-Ds.

I-Ds are stored in two places on the IETF web site.  First, current I-Ds
are stored in the I-D Repository.  Second, current and past I-Ds are
stored in a Public I-D Archive.

The policies associated with I-D Repository are discussed in RFC 2026,
and this IESG statement offers no additional policies regarding the
I-D Repository.

As RFC 2026 says, the entries in the I-D Repository are subject to
change or removal at any time; however, I-Ds generally remain in the
Public I-D Archive to support easy comparison with previous versions.
This availability facilitates review, comment, and revision.

An I-D will only be removed from the Public I-D Archive under unusual
circumstances with consensus of the IESG.  If you are aware of abuse or
misuse that warrants removal of an I-D from the Public I-D Archive,
please write to [email-masked] and explain the situation.  At its
discretion, the IESG may consult counsel or the IETF community before
taking any action on such requests.  If circumstances permit, a removed
I-D will be replaced with a tombstone file that describes the reason that
the I-D was removed from the Public I-D Archive.

When an I-D is removed from the Public I-D Archive, a copy will be kept
in a location accessible by the IETF Secretariat.  This private location
is described in RFC 2026 as follows:

  ... Internet-Drafts that
  have been removed (for any reason) from the Internet-Drafts
  directories shall be archived by the IETF Secretariat for the sole
  purpose of preserving an historical record of Internet standards
  activity and thus are not retrievable except in special
  circumstances.
  
The IESG, IAB, IAOC, or the Internet Society Board of Trustees can
request the IETF Secretariat to search this private location in
support of responses to appeals, responses to subpoenas, or other
handling of legal matters.  The IETF Secretariat is expected to make
the results of searches of the private location available as needed to
appropriately respond to such matters.

---

From: tglassey <[email-masked]>
Date: Thu, 25 Oct 2012 13:07:17 -0700

On 10/25/2012 11:47 AM, IESG Secretary wrote:
>     replicated on a number of Internet hosts.
OK - we acknowledge that we replicate this for wide distribution... why? 
what specifically is the goal in that? If the goal is to say "This is 
deployed across a large number of sites to enable wide-community 
exposure to in-process works" then perhaps we should revise the BCP's to 
include that idea as well.
>   This makes an evolving
I.e. its supposed to be a snapshot, a signpost along the path so to 
speak...
>     simply removed from the Internet-Drafts directory.

An interesting question is how this affects the people hosting images of 
the IETF media and what their legal obligations under CFAA and 
associated legal precedents is. Hosting the IETF file-store could be 
very financially dangerous for publication partners in that they dont 
get the IETF research exemption and are at risk for litigation no matter 
what the "hey the world is flat because we said so" idea which has 
existed so long here.

-------------------------

    At any time, an

Which then raises the issue of whether an I-D provides any 'right to implement the proposed IP it defines' because if it does in any form then it or the trust must address 'rights collisions' or 'rights expiry' and what that means to Relying Parties (as part of the Relying Party License blob) attached to everything IETF.

Yeah right - an I-D is exactly a means of publishing a specification, just not one which is a IETF Standard... The problem is the improper use of the Term SPECIFICATION to imply "approved IETF Standard" instead of just a technical discourse on how some protocol works.

Again - All IETF IP seems to be published with an eternal-use license so all documents must be maintained forever under that mindset it would seem...

    operation of the IETF.

Yes very important point and one which ties the issues of the mandatory term of availability to the archival period...

    It should be noted that individuals and groups,
    including the IAB and IRTF Research Groups, have chosen to distribute
    working documents as I-Ds.

-------------------------

Yes but what happens to the legal assignment for the licensing of the IP 
in the I-D for its uses as described therein? Does it persist? Is it 
superseded and if so what are the responsibilities in the relying 
parties to deal with that?
> and this IESG statement offers no additional policies regarding the
That is the problem RFC2026 and BCP78/79 fail (and intentionally too) to 
address this issue to try and make an argument that the IETF is not 
accountable for these processes because it has no membership - one of 
those famous fictions the IETF was based on... wink nod...

So the real issue is now - in today's world where the sponsor is 
accountable - what does all this mean?

>    activity and thus are not retrievable except in special
Again - more smoke and mirrors - please simply answer the question as to 
what happens to the legal contract for the use and reprinting of that IP 
per RFC2026 and all of the subsequent RFC's on the matter?
> handling of legal matters.

Minimum Storage Period is Seven Years by US Law... sorry... =
=====================================================
OK, in all other areas for every other tax exempt entity there is a 
minimum archive requirement for storage of documents. Since much of the 
IETF's operations are supported by effort which is tied to either tax 
exempt entities or those using the IETF participation as part of 
employee development, it would seem that this same minimum legal 
mandatory retention period of seven years  would apply to any 
workproduct done as part of that process.

Since both ISOC and the parties making those contributions do so under 
this banner its just simple logic that QED the IETF Standards Process 
was impinged by any legal organization requirements for retention of 
documents tied to the charter of that org.

Jorge - since many people use the IETF as part of their tax status 
clearly this is true right? Since the IETF itself is claiming Tax Exempt 
Status all of its operations under the ISOC would also seem to be tied 
for seven years as well... and so many not be an issue which is subject 
to negotiation here.
> The IETF Secretariat is expected to make

-- 
Regards TSG
"Ex-Cruce-Leo"

//Confidential Mailing - Please destroy this if you are not the intended recipient.