ietf
[Top] [All Lists]

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

2012-09-24 14:36:43
On 9/24/2012 7:02 AM, Russ Housley wrote:
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.

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.
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.)

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,
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."

               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.
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.
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.

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 has been consulted.  After exchanging several messages, this is the 
resulting text.  This text was never a part that was edited in the exchange.

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.
Interesting.  An archive archive.

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



-----
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.