FWIW, Scott's summary is consistent with what I remember, even though I had forgotten the mirrored, no deletion, collections. I was somewhat in the loop when Jon Postel initially resisted the idea of I-Ds, especially ones that might become an archival alternative to RFCs. Scott's account is essentially correct and, FWIW, some of the discussion in this thread revisits that one. I do consider that 2012 IESG Statement [1] to be strong evidence of a formal IESG decision on the matter although, if Scott's recollection is that the actual decisions and actions were made long before that statement was issued, I would trust those recollections. It may also be worth noting that the Statement is one of many reaffirmations about groups other than the IETF posting I-Ds containing their working documents. That policy definitely began many years earlier. We would probably benefit from someone putting together and publishing a history of Internet-Drafts, paralleling RFC 8700, before more of our memories deteriorate or otherwise become inaccessible. best, john [1] https://www.ietf.org/about/groups/iesg/statements/internet-draft-removal/ --On Thursday, January 13, 2022 10:12 -0500 Scott Bradner <sob@xxxxxxxxx> wrote: > there is a history to the decision to not actually expire I-Ds > > at the start Jon Postel accepted the idea of I-Ds only if they > expired (so I'm told - I was not in the loop at that time) > > so I-Ds were removed from the ietf.org ftp site after some > time - officially 6 months but often longer > > so a bunch of places started mirroring the I-D directory & > specifically not removing the expired I-Ds (Robert Elz was > one, I was another, and there were quite a few others) > > when I got on the IESG I argued that I-Ds should not be > removed but just moved to some specific "old" directory - (to > support IPR searches and so the technology would not be lost) > the IESG agreed & Steve Coya went about the business of > retrieving the old I-Ds from backup tapes (a big task but > lowish priority) and stopped removing the "expired" I-Ds > > just about when Steve was ready to post all the old I-Ds he > had found, a some new IESG members were installed and some of > them disagreed with the previous decision & the concept of not > expiring I-Ds was debated in the IESG & on the IETF list - > strong feelings both ways and the idea died > > that did not stop the mirrors even though a few authors sent > cease & desist emails to Robert and others > > at some point Henrik brought up tools.ietf.org including old > I-Ds (the ones he could find) - I gave him a copy of my > repository to fill in some of the blanks and I think Henrik > reached out to Robert as well > > so there was not a formal IESG decision to not expire the I-Ds > - it just happened because Henrik thought it was the right > thing to do (strongly supported by a bunch of us) > > Scott > >> On Jan 13, 2022, at 1:04 AM, John C Klensin >> <john-ietf@xxxxxxx> wrote: >> >> Mike, >> >> --On Wednesday, January 12, 2022 21:21 -0500 Michael StJohns >> <mstjohns@xxxxxxxxxxx> wrote: >> >>> On 1/12/2022 7:44 PM, Larry Masinter wrote: >>>> If there is some kind of abuse you are aiming to quell, some >>>> examples might be helpful. >>> >>> Hi Larry - >>> >>> It's not so much about quelling abuse as it might be in >>> reinforcing expectations. >>> >>> This has been the expectation basically from the first moment >>> that the ID system was created (right after the meeting at >>> Boulder NCAR): >>> >>>> It is inappropriate to use Internet-Drafts as reference >>>> material or to cite them other than as "work in progress" >>> >>> And that was reinforced in some ways by the original manual >>> submission model for IDs. Over time, the tools have changed >>> some of that calculus and most drafts get posted without >>> human intervention, and the old versions of a draft now have >>> fairly stable references as a side effect of how the tooling >>> was built. >> >> Actually not for the old (and expired) versions part. Scott >> can comment but I remember the decision to keep them generally >> available without interaction with the Secretariat (the >> caution on the datatracker page notwithstanding -- see below) >> as being very explicit, a recollection that is reinforced by >> a 2012 IESG Statement [1]. That was partially because of the >> IPR issue and partially, as the Statement indicates, to >> facilitate comparisons among versions. Assuming we are not >> going to reverse that, that part of the question is whether >> the current tooling implements the intent properly and/or >> whether we might want to review and adapt the intent. In >> particular, if the intent is to keep almost all I-Ds publicly >> available, we might think about how to do something to make >> them less useful as stable references. Some variation of >> Larry's time-based idea or of the ideas I mentioned in my >> note might work or, if he is willing to be engaged on this a >> bit longer, John Kunze might have good ideas about that in >> spite of its being the very opposite of his research >> interests in stable references. >> >> (Sorry, we have a small surplus, not only of "John"s in this >> discussion, but of "John K"s. Don't know how to work around >> that that except by spelling out surnames.) >> >>> All I'm really saying here is that it may be time to review >>> that expectation and retain it, expand on it or revise it. >> >> Agreed. But the first part of that process is probably >> figuring out which problem we are trying to solve. Based on >> reading John Kunze's note a few times, I'm guessing that >> making the old ARK versions vanish entirely (per the original >> rule that "expires" means "disappears from effortless public >> view) probably would (or perhaps would) have caused only one >> change in behavior: publication of Informational RFC >> snapshots of the current state of the research based on the >> drafts of 2008 and 2018. That, I hope, would have forced (we >> don't have firm rules and that might be something else we >> need to review) clear "what is different from the last time >> and why" sections. I just suggested in another context that >> we may want to make an explicit rule about that. But, >> otherwise... >> >> My guess is that there are three separate issues and >> expectations we should review: >> >> (1) Whether the introductory text that I cited earlier about >> what I-Ds are about should be revised to eliminate the phrase >> claiming other bodies can use them. For the reasons John >> Kunze mentioned in his explanation, I think that would hurt >> us and the Internet, but YMMD and it is worth a discussion. >> >> (2) Even in the RFC Series, whether we should reexamine the >> very long tradition (going back to documents with two-digit >> numbers long before there were I-Ds) of publishing >> documents, or long excerpts of documents, from other SDOs or >> even individual companies for the information of the >> community. I think stopping that would harm the Internet >> but, again, you and others might see the tradeoffs >> differently. PHB's first note in this thread may be helpful >> in looking at that. >> >> (3) Whether our present method and tooling for making I-Ds >> available long-term, motivated by the comparison and IPR >> issues (including, as has been pointed out, making things >> easy for people in other parts of that process, not just >> lawyers armed with subpoenas), is encouraging bad behavior. >> If so, whether (i) we can and should either erect defenses >> against that behavior and how or (ii) whether the risk of bad >> behavior justifies going back to the "expires means >> disappears" rule even if makes it hard for the folks trying >> to do comparisons or with IPR concerns. >> >>> In the instant case, removing the old ID versions of >>> draft-kunze-ark or changing the locator for the old versions >>> might cause problems for the ARK community. But not being >>> able to remove (or "move" URL wise) those documents seems to >>> be counter to the plain text intentions of RFC2026 section >>> 2.2 as well as other IETF statements of procedures. >> >> If I correctly understand John Kunze's note, not really for >> the ARK case. As I guessed when writing my earlier note, ARK >> is not a good example of the abuse case I think you are >> concerned about (see (3) above), but that does not make that >> concern any less real and important. >> >>> Perhaps 2026 no longer correctly expresses the status of IDs? >> >> To me, that is another example, perhaps the earliest important >> one, of the IESG making a decision that ignores rather clear >> text of a BCP procedural RFC and then just moving on [1]. In >> this particular case, the decision was not to ignore that text >> but, essentially, to treat warnings that have evolved into the >> current >> "The information below is for an old version of the >> document" or just "Expired Internet-Draft (individual)" >> and >> "This Internet-Draft is no longer active. A copy of the >> expired Internet-Draft can be found at..." >> as equivalent to the 2026 text >> "is simply removed from the Internet-Drafts directory" >> >> And, of course, whether it is significant or not, the >> statement in 2026 does not contain "MUST be removed" language >> but, instead, makes what appears to be a statement of fact. >> Scott probably remembers my whining about the change when it >> was announced, but the IESG consensus was clearly to make it. >> >> >> I think things have improved in more recent years in the sense >> that the IESG, faced with a situation like this, would almost >> certainly propose such a statement and explicitly ask for >> community comment on it. I don't recall that being done for >> the case of retaining I-Ds. However, if we don't like the >> idea of the IESG being able to make decisions that contradict >> -- or reinterpret well beyond the obvious original intent-- >> BCP procedural language that reasonable people can interpret >> as requirements, then there are other things that should be >> considered again and reevaluated, especially if we do not >> consider the Appeal and Recall procedures sufficient >> safeguards against such actions. >> >> best, >> john >> >> >
