On Wed, Sep 5, 2012 at 8:50 AM, Adrian Farrel <adrian@xxxxxxxxxxxx> wrote: > Hi Ted, > > I think an I-D can be removed from the I-D directory by replacing it with > another I-D (possibly with null content, or possibly with tombstone text) using > existing process. > > Cheers, > Adrian Hi Adrian, That's true, and if the existing author wants to do that, this policy is not needed at all. The question is who needs to approve a request to remove it if it does not come from the author. Sorry that this was not clear. regards, Ted Hardie > >> -----Original Message----- >> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Ted >> Hardie >> Sent: 05 September 2012 16:05 >> To: IETF Chair >> Cc: IETF >> Subject: Re: Draft IESG Statement on Removal of an Internet-Draft from the > IETF >> Web Site >> >> On Mon, Sep 3, 2012 at 5:00 PM, IETF Chair <chair@xxxxxxxx> wrote >> > The IESG is considering this IESG Statement. Comments from the community >> are solicited. >> > >> > 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, its Areas, >> > and its Working Groups. In addition, other groups, including the IAB >> > and the IRTF Research Groups, distribute working documents as I-Ds. >> > I-Ds are stored in two places on the IETF web site. First, current >> > ones are stored in the I-D directory. Second, current and past ones >> > are stored in a public I-D archive. >> > >> > I-Ds are readily available to a wide audience from the IETF I-D >> > directory. This availability facilitates informal review, comment, >> > and revision. >> > >> > While entries in the I-D directory are subject to change or removal >> > at any time, I-Ds generally remain publicly archived to support easy >> > comparison with previous versions. >> > >> > Entries in the I-D directory are 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 in compliance >> > with a duly authorized court order. 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. >> > >> >> This statement doesn't actually seem to cover the case for removal >> from the I-D directory, only the public archive. If you would like it >> to cover the case where a court order or other action causes a >> document to be removed from the public I-D directory, it probably >> needs an update. If that's covered in another document, pulling them >> into a single document makes sense to me. >> >> I support the idea that there be mechanisms for removal of IDs from >> both that don't require a court order, but I don't think it should be >> too simple. I'd suggest: >> >> a) Stream owner approval for streams outside the IETF stream >> (documents identified as irtf or IAB). >> b) Relevant AD for WG documents >> c) IESG for individual submissions, with any AD able to put the matter >> to the IESG. >> >> There is an existing method for b as it relates to the current >> directory--a working group chair replacing an editor and then having >> the new editor issue a new draft. The AD should be consulted and >> approve, though, if it either needs to be done more quickly than that >> or it needs to relate to the archive. >> >> c) is the most onerous because of the risk that simpler mechanisms >> might be used to shut out ideas. It might also be useful to clarify >> that the appeal chain for this action follows the usual process. >> >> Just my two cents, >> >> Ted >