Hi Scott, Big thanks for your efforts! Eduard -----Original Message----- From: ietf [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Scott Bradner Sent: Thursday, January 13, 2022 6:13 PM To: IETF <ietf@xxxxxxxx> Subject: Re: Backdoor standards? 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 > >
