RE: Backdoor standards?

[Larry Masinter <[e-mail]>]

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 <[e-mail]> On Behalf Of John C Klensin
> Sent: Wednesday, January 12, 2022 3:11 PM
> To: Scott O. Bradner <[e-mail]>; Mike StJohns
> <[e-mail]>; Fred Baker <[e-mail]>
> Cc: John Kunze <[e-mail]>; [e-mail]
> Subject: Re: Backdoor standards?
> 
> 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
> <[e-mail]> 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"
> <[e-mail]> wrote:
> 
> > 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 <[e-mail]>
> >> 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:
> >>
> >>
> >>
> >>> 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 follow
> >>> https://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
> >>
> >>
> >>
> >>
> >
>