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.