RE: Backdoor standards?

[Vasilenko Eduard <[e-mail]>]

Hi Scott,
Big thanks for your efforts!
Eduard
-----Original Message-----
From: ietf [mailto:[e-mail]] On Behalf Of Scott Bradner
Sent: Thursday, January 13, 2022 6:13 PM
To: IETF <[e-mail]>
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 <[e-mail]> wrote:
> 
> Mike,
> 
> --On Wednesday, January 12, 2022 21:21 -0500 Michael StJohns 
> <[e-mail]> 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
> 
>