Re: Backdoor standards?

[David Borman <[e-mail]>]

Going way back to the start of the IETF, there was originally an IDEA series of documents that were intended to be draft documents before they became RFCs.  Unfortunately, these found their way into marketing literature from some companies, claiming conformance to IDEA documents, which was not what we wanted.  That is when we came up with the current naming scheme, so that if vendors wanted to reference in-work documents, it would be obvious that these were just draft documents, and that they would expire after 6 months.

I personally don’t have any issues with old drafts remaining accessible somewhere.  The key thing was to make it clear that these are draft documents, and that if vendors choose to include them in their marketing literature, it is still clear that these are draft documents.

			-David

> On Jan 13, 2022, at 11:38 AM, Gorman, Pierce <[e-mail]> wrote:
> 
> 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
>>> 
>>> 
>> 
> 
> 
>