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

From: IETF Chair <[email-masked]>
Date: Fri, 21 Sep 2012 16:45:34 -0400

The IESG has updated the draft IESG Statement based on the many comments that have been received.  It is clear that the community wants the IESG to be able to remove an Internet-Draft from the Public I-D Archive without a court order to do so.  That said, the IESG firmly believes that the collection of I-Ds provide important historical records for the open and transparent operation of the IETF.  Therefore, removal of a I-D from the  Public I-D Archive should teated as a significant event.

Comments from the community are solicited on the revised draft IESG statement.

On behalf of the IESG,
Russ

--- DRAFT IESG STATEMENT ---

SUBJECT: Removal of an Internet-Draft from the IETF Web Site

Internet-Drafts (I-Ds) are working documents of the IETF.  I-Ds provide
important historical records for the open and transparent operation of
the IETF.  Other 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.

While entries in the I-D Repository are subject to change or removal
at any time, 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 entry in the I-D Repository is removed as part of normal process
when it expires after six months, when it is replaced by a subsequent
I-D, or when it is replaced by the publication of an RFC.  In all
of these situations, the I-D remains in the Public I-D Archive.

An I-D will only be removed from the Public I-D Archive with consensus
of the IESG.  There are two situations when the IESG will take this
action.  First, to comply with a duly authorized court order.  Second,
to resolve some form of abuse.  If possible, 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 only by the IETF Leadership and the IETF
Secretariat.  This private location may be searched by the IETF
Leadership or the IETF Secretariat when responding to appeals,
responding to subpoenas, or otherwise handling to legal matters.

If you are aware of abuse that warrants removal of an I-D from the
Public I-D Archive, please write to the [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.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 21 Sep 2012 21:16:09 +0000

Overall I like this--enough wiggle-room to deal with situations we cannot
foresee now, but still sufficient guidance for the IESGs to come.  One
small issue, inline.
Stephan

On 9.21.2012 13:45 , "IETF Chair" <[email-masked]> wrote:

>[...]
>Secretariat.  

It's quite likely, if there really were a court order to remove an I-D
from public access, that there is also a demand to destroy any copies.
The sentence above could be read that the IETF would keep a copy
nevertheless.  

To cure this, you could insert a sentence "This copy will be removed only
based on a court order or a legal request of comparable strength.".

In other words, IESG common sense is enough to remove an I-D from the
publicly accessible archive, but it takes a court order to remove it for
good.

>[...]

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Sep 2012 17:48:40 -0700

> Research Groups, have chosen to distribute working documents as I-Ds.

The IAB and IRTF are not part of the IETF?  The Independent stream also 
uses I-Ds.  Isn't it part of the IETF?

> at any time,

They are?  Is this new?  I thought the only established removal policy 
was the regular 6-month timeout.

>                I-Ds generally remain in the Public I-D Archive to support

The text up to this point mostly looks like a general set of policy 
assertions about I-Ds.  Those need to exist separately as a formal 
policy statement about the series and its archive(s).

That would leave the current statement to focus on its specific topic.

> to resolve some form of abuse.

This second basis looks sufficiently broad and vague to invite its own 
abuse and certainly inconsistent application.  Did IETF counsel express 
comfort with this language?

>  If possible, a removed I-D will be

Interesting.  An archive archive.

IETF "leadership" isn't a formal term.  Who does it include/exclude?  WG 
Chairs?  Why?  Why not?

Over time, given the number of people who hold various IETF leadership 
positions, this effectively gives access to a very large fraction of the 
IETF community.

> community before taking any action on such requests.

d/

-- 
  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: David Morris <[email-masked]>
Date: Fri, 21 Sep 2012 18:41:25 -0700 (PDT)

On Fri, 21 Sep 2012, Dave Crocker wrote:

> They are?  Is this new?  I thought the only established removal policy was the
> regular 6-month timeout.

Can't the author replace the repository version at any time AND can't that 
replacement effectively delete it by sending minimal boilerplate to
pass any format testing.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 21 Sep 2012 18:59:56 -0700

> replacement effectively delete it by sending minimal boilerplate to

Fair point.

Except that 'replacing' seems a bit different than 'deleting'.

While yes it deletes the old version, the effect of a replacement seems 
significantly different than is intended by the text (and the topic of 
the Subject line.)

d/

---

From: Pete Resnick <[email-masked]>
Date: Sat, 22 Sep 2012 09:33:23 -0500

Answering two bits I happen know the answers to:

> was the regular 6-month timeout.

2026, section 2.2:

    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.

That language dates back to RFC 1310 (March 1992). Not new.

> abuse and certainly inconsistent application.  Did IETF counsel 
> express comfort with this language?

Counsel actually wanted us to broaden the language, thinking "abuse" was 
too limiting.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: John C Klensin <[email-masked]>
Date: Sat, 22 Sep 2012 10:53:30 -0400

--On Saturday, September 22, 2012 09:33 -0500 Pete Resnick
<[email-masked]> wrote:

>...
>>> An I-D will only be removed from the Public I-D Archive with
>>> consensus of the IESG.  There are two situations when the
>>> IESG will take this action.  First, to comply with a duly
>>> authorized court order.  Second, to resolve some form of
>>> abuse.
>> 
>> This second basis looks sufficiently broad and vague to
>> invite its own  abuse and certainly inconsistent application.
>> Did IETF counsel  express comfort with this language?
> 
> Counsel actually wanted us to broaden the language, thinking
> "abuse" was too limiting.

Yeah.  I think the new language is a considerable improvement
and I can live with it, but only because I think "abuse" can be
interpreted very broadly should someone be able to convince the
IESG there is a problem or unfairness associated with leaving
things up.  My preference would be to go back to what I believe
was the spirit of the 2026 "...no formal status, and are subject
to change or removal at any time", leaving the IESG with
discretion to consider individual cases and decide what to do
without having to assign them to a category (whether "court
order" or "abuse").

Three observations in that context:

	-- Whatever the language of BCP 78/79, or even the IPR
	language of 2026, _permits_, doesn't imply that we
	should do it, only that we (perhaps) can
	
	-- I think the IESG should be more sympathetic to
	removal requests for earlier documents that were posted
	with the understanding that there would be no
	IETF-maintained authoritative public archive than to
	ones posted after the public archive became the
	practice.  That is not to suggest that all requests
	about early document should be approved or that all
	requests about later ones should be denied, but, as a
	general guideline, I think it would be helpful.  
	
	-- I also believe that the IESG should be more reluctant
	to remove a document whose successors are still under
	active development (especially the immediately-previous
	or otherwise very recent drafts for which diffs are
	important) than documents that are only of historical
	interest.   If nothing else, it is easy to make a case
	that having those recent documents with active
	successors in the archive is serving the needs of the
	IETF, while it is somewhat harder to defend keeping a
	document that is of historical interest only on that
	basis.

None of the above has to be written into a policy, but I believe
that the interests of the overall community and suitable respect
for the desires of authors, would be better served by such
guidelines than by, e.g., trying to figure out a specific and
yet sufficiently flexible definition of "abuse".

    john

---

From: Dave Crocker <[email-masked]>
Date: Sat, 22 Sep 2012 08:49:36 -0700

> Counsel actually wanted us to broaden the language, thinking "abuse" was

Wow.  Well, that certainly satisfies the question I asked.

Thanks, I think.

d/

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Sep 2012 10:02:26 -0400

Dave:

> The IAB and IRTF are not part of the IETF?  The Independent stream also uses I-Ds.  Isn't it part of the IETF?

No.  The Independent Stream is not part of the IETF.  Like the IAB and the IRTF, the independent Stream has chosen to use I-Ds.

RFC 4844 says:

5.1.4.  Independent Submission Stream

   The RFC Series has always served a broader Internet technical
   community than the IETF.  The "Independent Submission" stream is
   defined to provide review and (possible) approval of documents that
   are outside the scope of the streams identified above.

   Generally speaking, approval of documents in this stream falls under
   the purview of the RFC Editor, and the RFC Editor seeks input to its
   review from the IESG.

   The process for reviewing and approving documents in the Independent
   Submission stream is defined by

   o  Independent Submissions to the RFC Editor (RFC 4846 [RFC4846]).

   o  The IESG and RFC Editor Documents: Procedures (RFC 3932
      [RFC3932]).

(Since RFC 4844 was written, RFC3932 was obsoleted by RFC 5742.)

> They are?  Is this new?  I thought the only established removal policy was the regular 6-month timeout.

No, this is not new.  It goes back to RFC 1310 in March 1992.  If you publish draft-crocker-blah-blah-00.txt, is is very ofter replaced by -01.  The -00 is taken down before the six month expiration.

RFC 1310 said:

   An Internet Draft that is published as an RFC is removed from the
   Internet Draft directory.  A document 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 Draft directory.  At any time, an
   Internet Draft may be replace by a more recent version of the same
   specification, restarting the six-month timeout period.

This remains today; the I-D boilerplate says:

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

> The text up to this point mostly looks like a general set of policy assertions about I-Ds.  Those need to exist separately as a formal policy statement about the series and its archive(s).
> 

These were included to provide context for the policy statement.  As we have seen on this thread, there has been at least as much discussion about these background paragraphs as the policy.

> This second basis looks sufficiently broad and vague to invite its own abuse and certainly inconsistent application.  Did IETF counsel express comfort with this language?

Counsel has been consulted.  After exchanging several messages, this is the resulting text.  This text was never a part that was edited in the exchange.

> IETF "leadership" isn't a formal term.  Who does it include/exclude?  WG Chairs?  Why?  Why not?

I think it is fairly clear that the "leadership" is a party that would need access to this material when "responding to appeals, responding to subpoenas, or otherwise handling to legal matters."  I proposed this term because the parties that need access may well depend on the nature of the legal matter.
 
> Over time, given the number of people who hold various IETF leadership positions, this effectively gives access to a very large fraction of the IETF community.

I envision a mechanism where the access is only granted to the specific files needed to address the appeal, subpoena, or other legal matter.

Russ

---

From: Dave Crocker <[email-masked]>
Date: Mon, 24 Sep 2012 09:27:30 -0700

Russ,

On 9/24/2012 7:02 AM, Russ Housley wrote:
> Dave:
>
>>> The IESG has updated the draft IESG Statement based on the many
>>> comments that have been received.  It is clear that the community
>>> wants the IESG to be able to remove an Internet-Draft from the
>>> Public I-D Archive without a court order to do so.

I hadn't remembered that we have existing text that already covers this, 
in RFC 2026.   (It's also worth noting that, apparently, IETF counsel 
considers the existing RFC 2026 text sufficient.)

What isn't clear is why you are promoting additional language which 
seems to conflict with 2026, introduces some vague terminology (abuse, 
leadership), and covers only a subset of I-Ds.

>> The IAB and IRTF are not part of the IETF?  The Independent stream
>> also uses I-Ds.  Isn't it part of the IETF?
>
> No.  The Independent Stream is not part of the IETF.  Like the IAB
> and the IRTF, the independent Stream has chosen to use I-Ds.
>
> RFC 4844 says:
>

First, I note that you didn't respond about the IRTF or the IAB.  And my 
original query should have included the RFC Editor (which happens to 
fall under the IAB.)

Apparently you consider the IRTF, IAB and RFC Editor all to be outside 
the IETF.

Second, it appears that you are taking the "served a broader Internet 
technical community than the IETF" language as the basis for declaring 
the Independent Stream also to be outside of the IETF.

I think you are confusing the source with the agency and result that 
produces the output.

By implication, your assessment seems to mean that the only target for 
the output of working groups are people who participate in the IETF.  Or 
that anyone who consumes the output of an IETF working group is 
automatically part of the IETF.

That is, you seem to be confusing the source of authors with the 
publication vehicle itself and the target audience(s) of the work.

Independent Stream authors well might not be "part of" the IETF -- 
always a strange line of thinking, given that the IETF doesn't have 
members -- but that doesn't mean that the Stream itself is outside the IETF.

>> This second basis looks sufficiently broad and vague to invite its
>> own abuse and certainly inconsistent application.  Did IETF counsel
> Counsel has been consulted.  After exchanging several messages, this
> is the resulting text.  This text was never a part that was edited in
> the exchange.

You are saying that IETF Counsel did not offer comment on this bit of text?

Actually, I note that you didn't actually answer my question:  Does the 
IETF Counsel like the text?

d/

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Sep 2012 13:16:04 -0400

Dave:

> Actually, I note that you didn't actually answer my question:  Does the IETF Counsel like the text?

While counsel offered comment on other parts of the text, none were offered on the part you cite.  I am sure that comments would have been offered on the part you cite if it caused concern.

Russ

---

From: tglassey <[email-masked]>
Date: Mon, 24 Sep 2012 12:36:23 -0700

> Dave:
Russ - can the Independent Submission Stream (ISS) be used to create a 
fully franchised IETF Standard Process???

i.e. could I for instance through the ISS process submit a I-D and a 
RFC-Framework Proposal with that? In this case the framework proposal 
would define the 'canonization process' for this specific piece of IP 
and set the milestones for this independent stream standard???

This would be a very very good thing I think if it were to become possible.

>>> The IESG has updated the draft IESG Statement based on the many comments that have been received.  It is clear that the community wants the IESG to be able to remove an Internet-Draft from the Public I-D Archive without a court order to do so.
Which will apply to its publication and continued use rights how?

I still think we need to answer the specific question as to what this 
actually means to the previous licensing...
>>> That said, the IESG firmly believes that the collection of I-Ds provide important historical records for the open and transparent operation of the IETF.  Therefore, removal of a I-D from the  Public I-D Archive should teated as a significant event.
>>>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2221 / Virus Database: 2441/5288 - Release Date: 09/23/12
>
>
>

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

---

From: Russ Housley <[email-masked]>
Date: Mon, 24 Sep 2012 16:01:59 -0400

Todd:

The Independent Submission Stream cannot be used to produce standards track RFCs.

Russ

On Sep 24, 2012, at 3:36 PM, tglassey wrote:

> Russ - can the Independent Submission Stream (ISS) be used to create a fully franchised IETF Standard Process???
> 
> i.e. could I for instance through the ISS process submit a I-D and a RFC-Framework Proposal with that? In this case the framework proposal would define the 'canonization process' for this specific piece of IP and set the milestones for this independent stream standard???
> 
> I still think we need to answer the specific question as to what this actually means to the previous licensing...