Also FWIW. Early adopters and independent adopters occasionally implement what is described in I-Ds and it can be helpful to have the I-Ds persist as a usable public reference (IMHO). Pierce -----Original Message----- From: ietf <ietf-bounces@xxxxxxxx> On Behalf Of John C Klensin Sent: Thursday, January 13, 2022 11:21 AM To: Scott Bradner <sob@xxxxxxxxx>; IETF <ietf@xxxxxxxx> Subject: Re: Backdoor standards? [External] 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://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Finternet-draft-removal%2F&data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C7db703f6fe4b43fc50a608d9d6b92801%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637776913909215857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=CVKdw3FKNX%2FqzlfhNd9XV4KboxchQi1yvEM26xTvYo0%3D&reserved=0 --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 >> >> >
