Re: Backdoor standards?

[Scott Bradner <[e-mail]>]

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