Re: Backdoor standards?

[John C Klensin <[e-mail]>]

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://www.ietf.org/about/groups/iesg/statements/internet-draft-removal/

--On Thursday, January 13, 2022 10:12 -0500 Scott Bradner
<[e-mail]> 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
>> <[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
>> 
>> 
>