Subject: Backdoor standards?

From: Michael StJohns <[email-masked]>
Date: Wed, 12 Jan 2022 16:12:11 -0500

Hi -

I got curious when I saw a draft being published with a version number 
of -33 - https://datatracker.ietf.org/doc/html/draft-kunze-ark-33.  I 
got even more curious when I noticed that -00 of that ID had been 
uploaded back in 2001.  So I read the intro in the -33 version and found 
this:

> This is a transitional draft.  The ARK Alliance Technical Working
>     Group (https://wiki.lyrasis.org/display/ARKs/Technical+Working+Group)
>     is in the process of revising the ARK spec via a series of Internet-
>     Drafts.  While the spec is in transition, new implementors should
>     followhttps://datatracker.ietf.org/doc/html/draft-kunze-ark-18.

  -18 having been uploaded in 2013.

I'm not sure there's anything that can or should be done, but IDs are 
supposed to be transient documents that either go away or lead to an 
RFC.  Looking at the update history for this document, I'm pretty sure 
the draft system has been co-opted to be a standards repository for this 
specification.  AFAICT, this draft has never been submitted - in 20 
years! - to any RFC stream for publication and that's at least a 
violation of the spirit of the ID system. I.e. a violation of:

> It is inappropriate to use Internet-Drafts as reference
>     material or to cite them other than as "work in progress.

Perhaps we may want to think about making URL references to previous (or 
long expired) versions quite a bit less stable to avoid gaming of the 
system like this?  Or prohibit updates of draft chains once a draft has 
been expired for a year?

Or leave it be?

Mike

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 12 Jan 2022 16:20:38 -0500

leave it be 

having the old versions accessible is very useful for IPR disputes 

and I’m not sure we could write a ruleset that said no 3rd party standards repository that would not impact our own work

Scott

> On Jan 12, 2022, at 4:12 PM, Michael StJohns <[email-masked]> wrote:
> 
> Hi - 
> I got curious when I saw a draft being published with a version number of -33 -  https://datatracker.ietf.org/doc/html/draft-kunze-ark-33.  I got even more curious when I noticed that -00 of that ID had been uploaded back in 2001.  So I read the intro in the -33 version and found this:
> 
> 
> 
>>    Group (
>> https://wiki.lyrasis
>> .org/display/ARKs/Technical+Working+Group)
>>    follow 
>> https://datatracker.ietf.org/doc/html/draft-kunze-ark-18. 
> 
> I'm not sure there's anything that can or should be done, but IDs are supposed to be transient documents that either go away or lead to an RFC.  Looking at the update history for this document, I'm pretty sure the draft system has been co-opted to be a standards repository for this specification.  AFAICT, this draft has never been submitted - in 20 years! - to any RFC stream for publication and that's at least a violation of the spirit of the ID system.  I.e. a violation of:
> 
> 
> Perhaps we may want to think about making URL references to previous (or long expired) versions quite a bit less stable to avoid gaming of the system like this?  Or prohibit updates of draft chains once a draft has been expired for a year?
> 
> Or leave it be?
> 
> Mike
> 
> 
> 
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 12 Jan 2022 13:24:31 -0800

The primary reason that drafts remain available after six months is, I’m told, that lawyers want to be able to look up IPR. I suspect that your suggestion, which I otherwise support, would run afoul of that. What might be good would be to describe a mechanism that would allow the draft to vanish in six months but somehow remain available to an IPR search.

Sent using a machine that autocorrects in interesting ways...

> On Jan 12, 2022, at 1:13 PM, Michael StJohns <[email-masked]> wrote:
> 
> 
> Hi - 
> 
>>    follow https://datatracker.ietf.org/doc/html/draft-kunze-ark-18.

---

From: Brian Carpenter <[email-masked]>
Date: Thu, 13 Jan 2022 11:18:43 +1300

Agree with Scott. Give these people a small prize for creative use of the
I-D system, in fact. The Internet should be the home of subversive
technology - that's how we  got here. We use github for similar purposes,
don't we?

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Thu, 13 Jan 2022, 10:21 Scott O. Bradner, <[email-masked]> wrote:

> and I’m not sure we could write a ruleset that said no 3rd party standards
> repository that would not impact our own work
>
> Scott
>
> got even more curious when I noticed that -00 of that ID had been uploaded
> back in 2001.  So I read the intro in the -33 version and found this:
> >
> >
> >
> supposed to be transient documents that either go away or lead to an RFC.
> Looking at the update history for this document, I'm pretty sure the draft
> system has been co-opted to be a standards repository for this
> specification.  AFAICT, this draft has never been submitted - in 20 years!
> - to any RFC stream for publication and that's at least a violation of the
> spirit of the ID system.  I.e. a violation of:
> >
> >

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 12 Jan 2022 17:26:11 -0500

Mike,

I would suggest that the relevant AD speak to the authors about publishing
-18 as an informative RFC, which can then be superseded once the ARK spec
completes.

There was a time, in the distant sands of the past, when I-Ds actually did
disappear from the IETF systems after they expired, but there were third
party sites (I seem to recall Waterstones) that conveniently achieved all
of them. Having expired drafts available directly from the IETF systems is
a necessary convenience.

Cheers,
Andy

On Wed, Jan 12, 2022 at 4:13 PM Michael StJohns <[email-masked]>
wrote:

> Hi -
>
> I got curious when I saw a draft being published with a version number of
> -33 -  https://datatracker.ietf.org/doc/html/draft-kunze-ark-33.  I got
> even more curious when I noticed that -00 of that ID had been uploaded back
> in 2001.  So I read the intro in the -33 version and found this:
>
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 12 Jan 2022 17:29:02 -0500

I meant "archived", not "achieved". :-)

Cheers,
Andy

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Jan 2022 18:10:50 -0500

Mike,

First, to what Scott and Fred said, yes.

Prior to when we made them readily available after the nominal
six months, they were still available to anyone who showed up
with a subpoena or, IIR, a small wad of cash to cover presumed
Secretariat expenses to dig them out, but my recollection (which
Scott can probably confirm and recalibrate) is that just became
too much trouble... for us and the Secretariat, not (just) the
lawyers.

Partially for the reasons you identify (which may not apply to
this draft -- see below) I've wondered whether we could make
drafts moderately easy for the lawyers to identify and find but
destabilize URLs pointing to them.  For example, instead of
having expired drafts with stable URLs, we could move them to
this-year.datatracker.ietf.org, then move then again to
last-year.datatracker.ietf.org, and so on, maybe making them
still possible to find via the Data Tracker, but making stable
references to the URLs impossible and getting to them a bit
difficult or annoying, but not terribly so.  Or, as a different
example, we could get rid of the equivalent to a stable
https://datatracker.ietf.org/doc/draft-whatever-whateverElse/
and, after six months, change the file names to
draft-screech-whatever and set the tracker up so that, instead
of supplying a clickable-URL, we simply supplied the equivalent
of "screech-whatever" as text and made people copy that string
and paste it in somewhere.  The obvious question is whether the
tooling to support such a scheme would be worth the trouble.
My impression is that, in the past, the answer has been "no"
but, as we review and rewrite various tools, that decision may
be worth reviewing.

That said, this document, however evolved, may be a poor example
of your concern.  We do so say (see the first paragraph of
https://www.ietf.org/standards/ids/ ) "Other groups may also
distribute working documents as Internet-Drafts." so we are
explicitly authorizing the behavior with which you are
concerned.  And John Kunze (copied) is a long-time and very
constructive IETF participant -- see RFCs including 1625, 1736,
2056, 2413, 2731, 5013, 5791, 8493, and 8574 -- who perfectly
well knows what the rules are.    If I had to make a somewhat
educated guess (I hope he will confirm or correct as needed),
what is going on is exactly what the Abstract says is going on,
i.e., that this is a gradually developing and evolving spec in a
different group (remember, we said such groups could use I-Ds
for that purpose), that it is valuable to both them and us to
have the IETF community be aware of the work, and, I hope that,
when it is stable, they will either bring it to us for
standardization or bring a stable and approved version to the
IETF or ISE for informational publication as a standard from
another SDO.

The ARK Identifier scheme is another variation on the idea,
mentioned in RFC 3986, of document identifiers/ names rather
than locators.  I think or at least hope, that we gave up on the
"one name system to rule them all" theme.  More familiar
variations on that theme (with different design assumptions and
success criteria) are URNs (RFC 8141) and DOIs.

John (Kunze), anything to add?

best,
   john (klensin)

--On Wednesday, January 12, 2022 13:24 -0800 Fred Baker
<[email-masked]> wrote:

> The primary reason that drafts remain available after six
> months is, I'm told, that lawyers want to be able to look up
> IPR. I suspect that your suggestion, which I otherwise
> support, would run afoul of that. What might be good would be
> to describe a mechanism that would allow the draft to vanish
> in six months but somehow remain available to an IPR search.

--On Wednesday, January 12, 2022 16:20 -0500 "Scott O. Bradner"
<[email-masked]> wrote:

> and I'm not sure we could write a ruleset that said no 3rd
> party standards repository that would not impact our own work
> 
> Scott
> 
>> I got curious when I saw a draft being published with a
>> version number of -33 -
>> https://datatracker.ietf.org/doc/html/draft-kunze-ark-33.  I
>> got even more curious when I noticed that -00 of that ID had
>> been uploaded back in 2001.  So I read the intro in the -33
>> version and found this:
>> 
>> 
>> 
>>> This is a transitional draft.  The ARK Alliance Technical
>>> Working Group (
>>> https://wiki.lyrasis
>>>    is in the process of revising the ARK spec via a series
>>>    of Internet- Drafts.  While the spec is in transition,
>>>    new implementors should follow 
>> I'm not sure there's anything that can or should be done, but
>> IDs are supposed to be transient documents that either go
>> away or lead to an RFC.  Looking at the update history for
>> this document, I'm pretty sure the draft system has been
>> co-opted to be a standards repository for this specification.
>> AFAICT, this draft has never been submitted - in 20 years! -
>> to any RFC stream for publication and that's at least a
>> Perhaps we may want to think about making URL references to
>> previous (or long expired) versions quite a bit less stable
>> to avoid gaming of the system like this?  Or prohibit updates
>> of draft chains once a draft has been expired for a year?
>> 
>> Or leave it be?
>> 
>> Mike
>> 
>> 
>> 
>> 
>

---

From: John Kunze <[email-masked]>
Date: Wed, 12 Jan 2022 16:22:49 -0800

Thanks for CCing me, John. I can see how this ARK spec evolution looks a
bit unusual, especially given its 20-year run. It's taken a while to get
real experience with persistent identifiers.

In fact this run of drafts is heading towards a projected submission as an
Informational RFC of April 2022. Things got somewhat reactivated in 2019
when the "ARK Alliance" (arks.org) established a technical working group
that's been shepherding along a set of changes and updates based on
deployment (of an estimated 4.2 billions ARKs by some 880 institutions).

The very latest flurry of revisions is me thrashing around trying to figure
out how to use the martinthomson/i-d-template github repo and setting
things up as a github organization. Please pardon my noise (I started this
spec using nroff ;).

I can't comment on how others may have been (ab)using the internet draft
system since I only know it through my keyhole view. Personally, I love it
and frequently cite it as a very fine example of the open internet and its
values. There were two "long-term stable" drafts in 2008 and 2018, which I
did manage to separately archive because I didn't know how long the expired
drafts would be available.

In the "Transitional Note", would it be better for us to refer to the 2018
(v18) draft via the archived copy's URL rather than via the datatracker
copy? Perhaps that would be more appropriate.

I'm quite pleased that everyone's old drafts do remain available since as a
researcher/scholar (not as an IPR lawyer) I'm often trying to find out the
details of an idea that I vaguely recall even if the ideas didn't get
developed further (at least not in I-D form). I think there's lots of
valuable history in the IETF repository and the tools make the whole corpus
easy to use.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jan 2022 19:36:56 -0500

There are multiple overlapping issues here.

First, +1 to what John said. But also pointing out that the IPR issue isn't
just answering subpoenas, it is expert witnesses and expert consultants
like myself searching for prior art. I don't think publishing the IDs
forever necessarily removes the need to serve a subpoena to get a certified
copy but it certainly makes it easier.

Going back to the point raised by the original poster, the underlying
problem is that for better or worse, the IETF brand is tied to a document
series whose title essentially says 'what about we try this!'. Instead of
WAWT2, we have RFCs.

One consequence of this branding is that it is not immediately obvious that
Internet Draft is a lesser document unless the reader is in the know. When
we had DRAFT Standard things were even more confused. And then there is the
fact that not all RFCs are even published by the IETF...

Given where we start from, expecting to avoid confusion is an unreachable
goal. That ship sailed long ago.

But the more interesting question to me is whether the original situation
is even a problem. Publishing and approving documents is only a means to an
end.The real point is enabling people to use the Internet. Persuading
everyone to do the same thing in the same way is one way of doing that but
not the only way.

---

From: Larry Masinter <[email-masked]>
Date: Wed, 12 Jan 2022 16:44:00 -0800

draft-masinter-dated-uri-00.txt

only has 8 versions but was produced as a response.

It's useful to have a stable reference to the concepts -- so I and others
can cite it.
But more of a thought experiment than a technical proposal that I care that
people implement one way or another.

* Anything you can describe, you can have a URL for! 
* No, it isn't hard to give everyone permanent unique IDs by adding a short
date to temporarily unique IDs.
* No other distinguishing metadata is as good as a date.

Why bother the RFC editor?  

If there is some kind of abuse you are aiming to quell, some examples might
be helpful.
--
https://LarryMasinter.net https://interlisp.org

> -----Original Message-----
> From: ietf <[email-masked]> On Behalf Of John C Klensin
> Sent: Wednesday, January 12, 2022 3:11 PM
> To: Scott O. Bradner <[email-masked]>; Mike StJohns
> <[email-masked]>; Fred Baker <[email-masked]>
> Cc: John Kunze <[email-masked]>; [email-masked]
> Subject: Re: Backdoor standards?
> 
> Mike,
> 
> Prior to when we made them readily available after the nominal six months,
> they were still available to anyone who showed up with a subpoena or, IIR,
a
> small wad of cash to cover presumed Secretariat expenses to dig them out,
> but my recollection (which Scott can probably confirm and recalibrate) is
that
> just became too much trouble... for us and the Secretariat, not (just) the
> lawyers.
> 
> Partially for the reasons you identify (which may not apply to this draft
-- see
> below) I've wondered whether we could make drafts moderately easy for
> the lawyers to identify and find but destabilize URLs pointing to them.
For
> example, instead of having expired drafts with stable URLs, we could move
> them to this-year.datatracker.ietf.org, then move then again to last-
> year.datatracker.ietf.org, and so on, maybe making them still possible to
find
> via the Data Tracker, but making stable references to the URLs impossible
> and getting to them a bit difficult or annoying, but not terribly so.  Or,
as a
> different example, we could get rid of the equivalent to a stable
> and, after six months, change the file names to draft-screech-whatever and
> set the tracker up so that, instead of supplying a clickable-URL, we
simply
> supplied the equivalent of "screech-whatever" as text and made people
> copy that string and paste it in somewhere.  The obvious question is
whether
> the tooling to support such a scheme would be worth the trouble.
> but, as we review and rewrite various tools, that decision may be worth
> reviewing.
> 
> That said, this document, however evolved, may be a poor example of your
> concern.  We do so say (see the first paragraph of
> https://www.ietf.org/standards/ids/ ) "Other groups may also distribute
> working documents as Internet-Drafts." so we are explicitly authorizing
the
> behavior with which you are concerned.  And John Kunze (copied) is a long-
> time and very constructive IETF participant -- see RFCs including 1625,
1736,
> educated guess (I hope he will confirm or correct as needed), what is
going
> on is exactly what the Abstract says is going on, i.e., that this is a
gradually
> developing and evolving spec in a different group (remember, we said such
> groups could use I-Ds for that purpose), that it is valuable to both them
and
> us to have the IETF community be aware of the work, and, I hope that, when
> it is stable, they will either bring it to us for standardization or bring
a stable
> and approved version to the IETF or ISE for informational publication as a
> standard from another SDO.
> 
> The ARK Identifier scheme is another variation on the idea, mentioned in
RFC
> 3986, of document identifiers/ names rather than locators.  I think or at
least
> hope, that we gave up on the "one name system to rule them all" theme.
> More familiar variations on that theme (with different design assumptions
> and success criteria) are URNs (RFC 8141) and DOIs.
> 
> > The primary reason that drafts remain available after six months is,
> > I'm told, that lawyers want to be able to look up IPR. I suspect that
> > your suggestion, which I otherwise support, would run afoul of that.
> > What might be good would be to describe a mechanism that would allow
> > the draft to vanish in six months but somehow remain available to an
> > IPR search.
> 
> 
> > and I'm not sure we could write a ruleset that said no 3rd party
> > standards repository that would not impact our own work
> >
> > Scott
> >
> >> I got curious when I saw a draft being published with a version
> >> number of -33 -
> >> https://datatracker.ietf.org/doc/html/draft-kunze-ark-33.  I got even
> >> more curious when I noticed that -00 of that ID had been uploaded
> >>> Group ( https://wiki.lyrasis
> >> RFC.  Looking at the update history for this document, I'm pretty
> >> sure the draft system has been co-opted to be a standards repository
> >> for this specification.
> >> AFAICT, this draft has never been submitted - in 20 years! - to any
> >> RFC stream for publication and that's at least a violation of the
> >> Perhaps we may want to think about making URL references to previous
> >> (or long expired) versions quite a bit less stable to avoid gaming of
> >> the system like this?  Or prohibit updates of draft chains once a
> >> draft has been expired for a year?
> >>
> >> Or leave it be?
> >>
> >> Mike
> >>
> >>
> >>
> >>
> >
>

---

From: Michael StJohns <[email-masked]>
Date: Wed, 12 Jan 2022 21:21:07 -0500

> If there is some kind of abuse you are aiming to quell, some examples might

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

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

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.

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.

Perhaps 2026 no longer correctly expresses the status of IDs?

Mike

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Jan 2022 21:59:13 -0500

And almost a decade earlier, John Mallery at MIT came up with something
remarkably similar. I eventually persuaded him to write an ID:

https://datatracker.ietf.org/doc/html/draft-mallery-urn-pdi-00.txt
draft-mallery-urn-pdi-00 (ietf.org)
<https://datatracker.ietf.org/doc/html/draft-mallery-urn-pdi-00.txt>

Isn't it better that these ideas are preserved in some form at least?

Why do people think it is a problem if someone has an idea and someone else
copy it? Isn't that the point?

Ah yes, some people worry that people might mistakenly believe that
publication means it is the ONLY way to do a thing and that other ways are
wrong. And such folk tend to also make the mistake of thinking that if you
can get something through the process playing dirty pool, other folk are
then obliged to comply.

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Jan 2022 01:04:28 -0500

Mike,

--On Wednesday, January 12, 2022 21:21 -0500 Michael StJohns
<[email-masked]> 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):
> 
> 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

---

From: Lloyd W <[email-masked]>
Date: Thu, 13 Jan 2022 17:56:26 +1100

Waterstones is a UK bookstore.

You meant watersprings.

http://www.watersprings.org/

Lloyd Wood
[email-masked]

> On 13 Jan 2022, at 09:30, Andrew G. Malis <[email-masked]> wrote:
> 
> 
>> I would suggest that the relevant AD speak to the authors about publishing -18 as an informative RFC, which can then be superseded once the ARK spec completes.
>> 
>> There was a time, in the distant sands of the past, when I-Ds actually did disappear from the IETF systems after they expired, but there were third party sites (I seem to recall Waterstones) that conveniently achieved all of them. Having expired drafts available directly from the IETF systems is a necessary convenience.
>> 
>> Cheers,
>> Andy
>> 
>> 
>>> On Wed, Jan 12, 2022 at 4:13 PM Michael StJohns <[email-masked]> wrote:
>>> Hi - 
>>>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 13 Jan 2022 08:00:52 +0000

It is not good to clean all other opinions out of the public availability, irrespective of IPR.
It is the way to "there is my way and there is the wrong way".
Of course, would be the people that would like to ban the opinions of opponents.
Ed/
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of John C Klensin
Sent: Thursday, January 13, 2022 9:04 AM
To: Michael StJohns <[email-masked]>; [email-masked]
Cc: John Kunze <[email-masked]>
Subject: Re: Backdoor standards?

Mike,

--On Wednesday, January 12, 2022 21:21 -0500 Michael StJohns <[email-masked]> wrote:

>> If there is some kind of abuse you are aiming to quell, some examples 
>> might be helpful.
> 
> Hi Larry -
> 
> 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.)

> 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

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Jan 2022 10:21:25 +0100

On 2022-01-13, at 00:10, John C Klensin <[email-masked]> wrote:
> 
> we could get rid of the equivalent to a stable

Baby/bathwater.

https://www.w3.org/Provider/Style/URI
“Hypertext Style: Cool URIs don't change.”

Yes, Mike identified an issue here.
Any sweeping solutions discussed in this thread have several orders of magnitude more downside to them than the problems.
Better to do a point solution, such as publishing -18 as informational.

Can we stop discussing the dead horse and instead look at the best point solution for the actual issue?

Grüße, Carsten

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Jan 2022 09:03:19 -0500

Lloyd,

Thanks! It's been a while since I've been there, since the IETF stopped
deleting expired drafts.

Cheers,
Andy

On Thu, Jan 13, 2022 at 1:56 AM Lloyd W <[email-masked]> wrote:

>> I would suggest that the relevant AD speak to the authors about
>> publishing -18 as an informative RFC, which can then be superseded once the
>> ARK spec completes.
>>
>> There was a time, in the distant sands of the past, when I-Ds actually
>> did disappear from the IETF systems after they expired, but there were
>> third party sites (I seem to recall Waterstones) that conveniently
>> achieved all of them. Having expired drafts available directly from the
>> IETF systems is a necessary convenience.
>>
>> Cheers,
>> Andy
>>
>>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 13 Jan 2022 09:08:36 -0500

John,

Is there any reason to not publish the v18 draft as an informational RFC,
since it's in use in the field, and then supersede it when the final RFC is
published?

Cheers,
Andy

On Wed, Jan 12, 2022 at 7:23 PM John Kunze <[email-masked]> wrote:

> The very latest flurry of revisions is me thrashing around trying to
> figure out how to use the martinthomson/i-d-template github repo and
> setting things up as a github organization. Please pardon my noise (I
> started this spec using nroff ;).
>
> I'm quite pleased that everyone's old drafts do remain available since as
> a researcher/scholar (not as an IPR lawyer) I'm often trying to find out
> the details of an idea that I vaguely recall even if the ideas didn't get

---

From: Scott Bradner <[email-masked]>
Date: Thu, 13 Jan 2022 10:12:54 -0500

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 <[email-masked]> wrote:
> 
> Mike,
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Jan 2022 11:58:40 -0500

--On Thursday, January 13, 2022 08:00 +0000 Vasilenko Eduard
<[email-masked]> wrote:

> It is not good to clean all other opinions out of the public
> availability, irrespective of IPR. It is the way to "there is
> my way and there is the wrong way". Of course, would be the
> people that would like to ban the opinions of opponents. Ed/

Ed,

Either I misunderstand your comment or you misunderstood mine.
I'm in favor of Mike's suggestion that we review some of these
things and see if we still believe them.  For me, that is more
about how much has changed in the Internet generally and IETF
specifically in, for example, the quarter-century since RFC 2026
was published and the even longer period since phrasing about
other groups publishing such drafts first appeared.  In that
time, we have eliminated the provisions about deleting expired
or "obsoleted" drafts (ones replaced by others) and made other
small adjustments, but there has never been a comprehensive
review of the (other) basic principles nor whether the current
policy toward those expired and/or obsoleted drafts (they are
probably two separate issues) is just right.

While I think that review would be healthy --having principles
and requirements that are not being followed and that few of us
believe is clearly a bad idea-- my personal view is that, if
changes are needed, they would be more about fine-tuning of what
to do about replaced specifications than significant changes of
direction and, in particular, handling of nominally expired
I-Ds. I think Carsten's "Baby/bathwater" comment is a little
exaggerated, but I share the concern.

More to your particular point, no one has suggested prohibiting
John Kunze and his colleagues (or anyone else) from putting
forth their ideas.  The discussion has been about documents that
preserve versions of those ideas that they might have discarded,
not about suppressing their current ideas.   For this long set
of drafts, I don't even see discarded ideas, only more details
and better explanations.  There is even an additional safeguard
for getting dissenting views into public sight: the RFC series
has been used to publish alternative to, and dissenting views
about, protocols and design choices since before there was an
IETF.  The principles behind that are close to what you
describe.  Even today, there is a process, called "independent
submission" for (among other things) publishing documents that
say, explicitly or not, "I think the IETF is wrong about this
because... and I have a better idea, which is...".  Current
procedures require drafts for such documents to first be posted
as I-Ds but, were the IETF to prevent doing that (something many
of us would fight very strongly), I assume the Independent
Submission Editor would quickly adopt a different procedure.

So, if we are actually disagreeing about anything --other than,
perhaps, the desirability of periodically reviewing old
decisions-- I'd like to understand how and about what.

thanks,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Jan 2022 12:20:46 -0500

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
<[email-masked]> wrote:

> 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
> 
>>> 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.
>> 
>> 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...
>> 
>> 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.
>> 
>> 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.
>> 
>>> 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.
>> 
>> 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.
>> 
>> 
>> 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
>> consider the Appeal and Recall procedures sufficient
>> safeguards against such actions.  
>> 
>> best,
>>   john
>> 
>> 
>

---

From: "Gorman, Pierce" <[email-masked]>
Date: Thu, 13 Jan 2022 17:38:04 +0000

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 <[email-masked]> On Behalf Of John C Klensin
Sent: Thursday, January 13, 2022 11:21 AM
To: Scott Bradner <[email-masked]>; IETF <[email-masked]>
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 <[email-masked]> wrote:

> 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)
>
> 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 
> 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
>
> - it just happened because Henrik thought it was the right thing to do 
> (strongly supported by a bunch of us)
>
> Scott
>
>>> This has been the expectation basically from the first moment that 
>>> the ID system was created (right after the meeting at Boulder NCAR):
>>>
>>> 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.
>>
>> 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
>> 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 
>> 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 
>> discussion, but of "John K"s.  Don't know how to work around that 
>> that except by spelling out surnames.)
>>
>> 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...
>>
>> (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
>> 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.
>>
>>> 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
>> 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.
>>
>> To me, that is another example, perhaps the earliest important one, 
>> of the IESG making a decision that ignores rather clear
>> this particular case, the decision was not to ignore that text but, 
>> essentially, to treat warnings that have evolved into the current 
>> 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 
>> 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 
>> 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
>>
>>
>

---

From: David Borman <[email-masked]>
Date: Thu, 13 Jan 2022 11:55:21 -0600

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 <[email-masked]> wrote:
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 13 Jan 2022 18:16:00 +0000

Hi Scott,
Big thanks for your efforts!
Eduard
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Scott Bradner
Sent: Thursday, January 13, 2022 6:13 PM
To: IETF <[email-masked]>
Subject: Re: Backdoor standards?

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

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

> 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
> 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.
> 
> discussion, but of "John K"s.  Don't know how to work around that that 
> except by spelling out surnames.)
> 
> 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...
> 
> (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.
> 
> documents, from other SDOs or even individual
> 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.
> 
> 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.
> 
> To me, that is another example, perhaps the earliest important one, of 
> the IESG making a decision that ignores rather clear
> essentially, to treat warnings that have evolved into the current "The 
> information below is for an old version of the
> 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.
> 
> 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
> 
>

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 13 Jan 2022 18:35:09 +0000

Hi John,
Last year I've researched one topic. I have found many expired drafts 5-10 years ago on the topic.
I am scared that behind this polite and politically correct discussion
Would be the decision to shut up opinions that have lost political battles in respective WGs.
I hope you understand, that IETF drafts are driven more by politics than technology.
Hence, abandoned drafts are sometimes very valuable.

I am happy that there are people like Scott Bradner that would not permit this information to disappear anyway.
I am more confident now (after Scott's message), that it is not possible to clean other opinions anyway.
Eduard
-----Original Message-----
From: John C Klensin [mailto:[email-masked]] 
Sent: Thursday, January 13, 2022 7:59 PM
To: Vasilenko Eduard <[email-masked]>; Michael StJohns <[email-masked]>; [email-masked]
Cc: John Kunze <[email-masked]>
Subject: RE: Backdoor standards?

--On Thursday, January 13, 2022 08:00 +0000 Vasilenko Eduard <[email-masked]> wrote:

> availability, irrespective of IPR. It is the way to "there is my way 
> and there is the wrong way". Of course, would be the people that would 
> like to ban the opinions of opponents. Ed/

Ed,

Either I misunderstand your comment or you misunderstood mine.
I'm in favor of Mike's suggestion that we review some of these things and see if we still believe them.  For me, that is more about how much has changed in the Internet generally and IETF specifically in, for example, the quarter-century since RFC 2026 was published and the even longer period since phrasing about other groups publishing such drafts first appeared.  In that time, we have eliminated the provisions about deleting expired or "obsoleted" drafts (ones replaced by others) and made other small adjustments, but there has never been a comprehensive review of the (other) basic principles nor whether the current policy toward those expired and/or obsoleted drafts (they are probably two separate issues) is just right.

While I think that review would be healthy --having principles and requirements that are not being followed and that few of us believe is clearly a bad idea-- my personal view is that, if changes are needed, they would be more about fine-tuning of what to do about replaced specifications than significant changes of direction and, in particular, handling of nominally expired I-Ds. I think Carsten's "Baby/bathwater" comment is a little exaggerated, but I share the concern.

More to your particular point, no one has suggested prohibiting John Kunze and his colleagues (or anyone else) from putting forth their ideas.  The discussion has been about documents that preserve versions of those ideas that they might have discarded,
not about suppressing their current ideas.   For this long set
of drafts, I don't even see discarded ideas, only more details and better explanations.  There is even an additional safeguard for getting dissenting views into public sight: the RFC series has been used to publish alternative to, and dissenting views about, protocols and design choices since before there was an IETF.  The principles behind that are close to what you describe.  Even today, there is a process, called "independent submission" for (among other things) publishing documents that say, explicitly or not, "I think the IETF is wrong about this because... and I have a better idea, which is...".  Current procedures require drafts for such documents to first be posted as I-Ds but, were the IETF to prevent doing that (something many of us would fight very strongly), I assume the Independent Submission Editor would quickly adopt a different procedure.

So, if we are actually disagreeing about anything --other than, perhaps, the desirability of periodically reviewing old
decisions-- I'd like to understand how and about what.

thanks,
   john

---

From: John C Klensin <[email-masked]>
Date: Thu, 13 Jan 2022 13:35:08 -0500

--On Thursday, January 13, 2022 17:38 +0000 "Gorman, Pierce"
<[email-masked]> 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).

Yes.  However...

(1) See my note to Ed.

(2) And sometimes, when they do that, the IETF decides to change
important details.  That results in a new I-D and ultimately an
RFC for which implementations of an earlier version cannot
conform.   Either the adopters accept that change, makes changes
to their implementations, and convince their users to accept
those changes or they don't.  In the first case, the early
drafts become irrelevant.  In the second, we end up with,
politely, a mess.  At their worst, such messes involve arguments
that the IETF specs should reflect implementation realities even
if the IETF has determined that those implementation cause
serious risks to users or the Internet infrastructure (often
invoking the "running code" principle) and/or that particular
kinds of implementation are inherently more virtuous than others
and that the standard should follow them.

There are some other issues as well, but the primary reason for
all of the language about limited validity, references,
citations as work in progress [1] is precisely to avoid those
messes.

    john

{1} See the "Status of This Memo" in any current Internet-Draft
as well as Statements and documents cited earlier.

---

From: "Gorman, Pierce" <[email-masked]>
Date: Thu, 13 Jan 2022 18:46:00 +0000

Sometimes I-Ds get early adoption because, for instance, a problem needs solved, and implementors don't or can't wait for IETF political processes to complete.  Sometimes those I-Ds result in RFCs and sometimes in multiple RFCs and sometimes it is indeed an ugly mess.  E.g., SIP DIVERSION and HISTORY-INFO.

Nevertheless, I value access to historical information over pedantic tidiness.

-----Original Message-----
From: John C Klensin <[email-masked]> 
Sent: Thursday, January 13, 2022 12:35 PM
To: Gorman, Pierce <[email-masked]>; Scott Bradner <[email-masked]>; IETF <[email-masked]>
Subject: RE: Backdoor standards?

[External]

--On Thursday, January 13, 2022 17:38 +0000 "Gorman, Pierce"
<[email-masked]> 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).

Yes.  However...

(1) See my note to Ed.

(2) And sometimes, when they do that, the IETF decides to change important details.  That results in a new I-D and ultimately an RFC for which implementations of an earlier version cannot
conform.   Either the adopters accept that change, makes changes
to their implementations, and convince their users to accept those changes or they don't.  In the first case, the early drafts become irrelevant.  In the second, we end up with, politely, a mess.  At their worst, such messes involve arguments that the IETF specs should reflect implementation realities even if the IETF has determined that those implementation cause serious risks to users or the Internet infrastructure (often invoking the "running code" principle) and/or that particular kinds of implementation are inherently more virtuous than others and that the standard should follow them.

There are some other issues as well, but the primary reason for all of the language about limited validity, references, citations as work in progress [1] is precisely to avoid those messes.

    john

{1} See the "Status of This Memo" in any current Internet-Draft as well as Statements and documents cited earlier.

---

From: Vasilenko Eduard <[email-masked]>
Date: Thu, 13 Jan 2022 18:51:09 +0000

The current status of the IETF documents:
- personal draft
- WG draft
- standard
Looks perfectly fine and reasonable.

But I should accept that some engineers in Telco and especially Enterprises
Do not understand these 3 levels because they do not participate in the IETF process.
Hence, some vendors are capable of "selling" them WG or even personal draft as something equal to standard.
I do not know what to do about it.

By the way, cleaning old personal drafts would not help against this problem.
Because vendors never sell something stale, for sure it would be the active and updated draft.

Are you sure that you are discussing the right problem in this thread?
Because a market understanding of the document status is important,
Not the old documents availability. The more available - the better.

Ed/
-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of John C Klensin
Sent: Thursday, January 13, 2022 9:35 PM
To: Gorman, Pierce <[email-masked]>; Scott Bradner <[email-masked]>; IETF <[email-masked]>
Subject: RE: Backdoor standards?

Yes.  However...

(1) See my note to Ed.

    john

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Jan 2022 14:14:27 -0500

Mike,

> stable references as a side effect of how the tooling was

Everyone looks at diffs when reviewing documents.  When I was IETF Chair, I made the decision, after discussion with the IESG, to keep I-Ds online so that the rfcdiff tool made diffs easy for all.

<snip>

Russ

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jan 2022 08:54:47 +1300

On 14-Jan-22 06:55, David Borman wrote:
...> 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.

Well yes. And every I-D for an effectively infinite length of time has said exactly that in its boilerplate [1]. It's beside the point that many people don't read the boilerplate. The fact that it's there is necessary and sufficient.

As for the public archive of expired I-Ds, it's a useful tool. I've used it, for
example, to track back when a particular item appeared in a draft, so as to locate the WG discussion of that item. Ain't broken, don't fix. [2]

Pseudo-hiding old I-Ds by breaking URLs such as https://datatracker.ietf.org/doc/html/draft-ietf-anima-grasp-06 or https://tools.ietf.org/search/draft-ietf-anima-grasp-06 would be pointless vandalism.

    Brian (grumpily)

[1] Here's what a draft I wrote in 1994, two years before RFC2026, says:

"Expires 26 September 1994
...
    This document is an Internet Draft.  Internet Drafts are working
    documents of the Internet Engineering Task Force (IETF), its Areas,
    and its Working Groups.  Note that other groups may also distribute
    working documents as Internet Drafts.

    Internet Drafts are draft documents valid for a maximum of six
    months.  Internet Drafts may be updated, replaced, or obsoleted by
    other documents at any time.  It is not appropriate to use Internet
    Drafts as reference material or to cite them other than as a
    ``working draft'' or ``work in progress.''"

That was of course generated by an nroff template.

[2] If you want to fix something, fix RFC2026 to match reality.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 13 Jan 2022 20:05:01 -0500

On Thu, Jan 13, 2022 at 2:15 PM Russ Housley <[email-masked]> wrote:

>
> Everyone looks at diffs when reviewing documents.  When I was IETF Chair,
> I made the decision, after discussion with the IESG, to keep I-Ds online so
> that the rfcdiff tool made diffs easy for all.
>
> <snip>
>
> Russ
>

More information is almost always better than less. I think we need to
think very hard before taking any information away. Someone writing a
driver to allow people to mount the IDs as a file system for instance.

I submit my documents as IDs so they come under NOTE WELL. Whether I bring
them to IETF, W3C or OASIS or spin up a new organization, my number one
concern is to keep the IP issues straight.

Internet Drafts have an explicit statement saying what they are as far as
IETF is concerned. We are a couple of thousand people, most part time
serving a community of 5 billion. Some folk are going to get the wrong end
of the stick no matter what.

As people have noticed, I believe in permissionless innovation. Or at
least, I don't ask.

isn't that supposed to be the IETF mantra as well? So why get worried about
the possibility someone is going to get confused?

I thought that one of the things we were trying to do was build information
systems that allowed documents to be made persistent with a really low
threshold for inclusion. Like someone being likely to want to read it.

People ask: what might happen if we lose control?

How about we instead ask, What might we achieve if we give control back to
the people it really belongs to?

---

From: David Borman <[email-masked]>
Date: Thu, 13 Jan 2022 20:52:38 -0600

FYI the creation of the Internet-Drafts directory and the rules governing it are in the proceedings of the 12th IETF, see https://www.ietf.org/proceedings/12.pdf <https://www.ietf.org/proceedings/12.pdf>, pages 5 and 8.

			-David Borman

> On Jan 13, 2022, at 1:54 PM, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Larry Masinter <[email-masked]>
Date: Thu, 13 Jan 2022 19:02:47 -0800

Stable URLs for old Internet drafts are useful without obfuscation. I’m happy that tools.ietf.org/html/ seems to redirect to their current location.

But https://www.researchgate.net/publication/2923961_An_IETF_URN_Sub-namespace_for_Registered_Protocol_Parameters

points to http://tools.ietf.org/pdf/rfc2648   which used to work but now gives a 404 not found.

I’d like retiring old URLs for documents be given the amount of consideration as was given the retiring of the various ftp services. Avoid breaking old references unless you must.

Note that RFC 2648 “A URN Namespace for IETF Documents” supports bcp, fyi, id, rfc, std as the kinds of documents the IETF might want more “permanent” names for. It seems to assume no renaming of expired (i)nternet (d)rafts.

--

 <https://LarryMasinter.net> https://LarryMasinter.net  <https://interlisp.org> https://interlisp.org

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 14 Jan 2022 15:31:16 +0100 (CET)

> Il 13/01/2022 20:54 Brian E Carpenter <[email-masked]> ha scritto:
> 

However, if we really felt the need to emphasize the point and the different status of the various documents (and I personally think we do, given how often this issue pops up), we could consider emphasizing that specific paragraph in all non-TXT renderings of the documents. It could appear in bold, with a thick border, etc, and possibly have a link to a specific FAQ page written for non-engineers. 

HTML renderings, including the datatracker, could even make use of new and experimental technologies like frames or CSS to keep a shortened version of the message (and other metadata) always visible no matter where you are in the document, and it could go into headers/footers in PDFs, if we had PDFs which were not meant to appear just like a screenshot of the TXT version.

That shortened version could be even more understandable than the boilerplate - things like "OFFICIAL IETF STANDARD", "CURRENT IETF WORKING DRAFT", "EXPIRED IETF WORKING DRAFT", "UNOFFICIAL PERSONAL DOCUMENT" would convey the message more effectively. You could even say "DO NOT USE" if you wanted.

This would not remove the problem completely, but IMHO it could reduce it substantially, as in most cases it is due to people a) reading the boilerplate but not understanding it, b) not reading the boilerplate because they scroll down and think "this is clearly some boring legal boilerplate so I'll skip it entirely", or c) starting directly at page X of the document, where lies the juicy technical part that they need.

-- 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Larry Masinter <[email-masked]>
Date: Fri, 14 Jan 2022 14:08:08 -0800

Currently, when I ask for 
https://tools.ietf.org/html/draft-ietf-iri-3987bis
I get to 
https://datatracker.ietf.org/doc/html/draft-ietf-iri-3987bis 
which gives me a TXT+hyperlink styled HTML document with a header

[Search] [txt|xml|pdf|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-duerst-iri-bis)  00 01 02 03 04         Standards Track
          05 06 07 08 09 10 11 12 13                                    

And only later the Expires: date.  It seems some thought went into
segregating and minimizing the discernable differences between
the text as it appears in this representation of the document and the
other representations. Only the  header changes
over time (when a document is superseded or expires).

People make references to documents and use those references
for all kinds of reasons, and for many use cases the document status
Is irrelevant.

Some modest improvements might be:
*  Don't hyperlink to version NN from version NN.  That would make it
   slightly clearer at a glance if you're not looking at the latest version.
* Move [Tracker] to the first (is [Search] useful? How did they get here?)
* If you ARE looking at the latest version,  AND it is Expired,
  replace  the word "Tracker"  with "Expired" (keeping the link to the tracker).
  This would make the first word [Expired].

[Expired] [txt|xml|pdf|pdfized] [bibtex] [WG] [Email] [Diff1] [Diff2] [Nits]

In this use case for stable URLs for a 10 year old Internet Draft, the draft is
awaiting reconciliation with https://url.spec.whatwg.org/ (perhaps using
 https://github.com/alwinb/url-specification)
--
https://LarryMasinter.net https://interlisp.org