Re: Backdoor standards?

[Phillip Hallam-Baker <[e-mail]>]

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.



On Wed, Jan 12, 2022 at 7:44 PM Larry Masinter <[e-mail]> wrote:

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