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