RE: Backdoor standards?

["Gorman, Pierce" <[e-mail]>]

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 <[e-mail]> On Behalf Of John C Klensin
Sent: Thursday, January 13, 2022 11:21 AM
To: Scott Bradner <[e-mail]>; IETF <[e-mail]>
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&amp;data=04%7C01%7Cpierce.gorman%40t-mobile.com%7C7db703f6fe4b43fc50a608d9d6b92801%7Cbe0f980bdd994b19bd7bbc71a09b026c%7C0%7C0%7C637776913909215857%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=CVKdw3FKNX%2FqzlfhNd9XV4KboxchQi1yvEM26xTvYo0%3D&amp;reserved=0

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