Re: Backdoor standards?

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 13 January 2022 00:37 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5C13A03ED for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 16:37:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.398
X-Spam-Level:
X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZx1Q-jHv7-G for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 16:37:10 -0800 (PST)
Received: from mail-yb1-f170.google.com (mail-yb1-f170.google.com [209.85.219.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 226A03A03C9 for <ietf@ietf.org>; Wed, 12 Jan 2022 16:37:10 -0800 (PST)
Received: by mail-yb1-f170.google.com with SMTP id h14so10378531ybe.12 for <ietf@ietf.org>; Wed, 12 Jan 2022 16:37:10 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=m5Yj/82QPihg8htdTWDDC7req7518P6vqB/MrJ/nfrg=; b=U5EPSToClqX/Pxl1E48lvXDRUn/ifXw1wFY5Sr4FSix9ZcRtVDKQx6Y4LtQFvOa+DA AWxPKbIfydxB8pCJI1EqD6miGKTXZbAkKbih+GepdM3G/wO649AYXL0PyKbBtZw0jyVB fGVoJGhAsNZZoLPeEciZqLq7mENzF/78kr/EngsDc5S+lsHnO3Jhdh35kATteU87JaVq S54wjYN5I6rxnsEI8wZYRolH7XKjPRhtFCj1qUxuh5sYBdRSMWpEYUjto1Y87udzol6U oaA11w/Gnd0CmV5HWCsSy4ctJRJF7YDXB/b8k8ss0bACrA2wIsg8LEGygYOtyK0asj6v kpNg==
X-Gm-Message-State: AOAM530HJmnSXYbS8WIE1Rh7FrCR3l6I4u+GZnDIjsDPYwKPeyDxQtB4 ItuAnW60usgYhvUEthUU+9y0XPtD2qfBiUbOUIc=
X-Google-Smtp-Source: ABdhPJwyZZUYBsR8RpOtTO8F54rDSN7u5uNUeesRHT5WBAyRQgyMahAoJ7DdHq7gMquwVdXgneWysbJHXMtn0NP2ALg=
X-Received: by 2002:a25:ce4b:: with SMTP id x72mr2834074ybe.532.1642034229247; Wed, 12 Jan 2022 16:37:09 -0800 (PST)
MIME-Version: 1.0
References: <85191ed3-5fc1-67da-888a-8af7bf9064f8@comcast.net> <39E40B7D-0E51-41A9-A8A3-026A0013F032@sobco.com> <9C232BA5452C4F0F9DD26674@PSB>
In-Reply-To: <9C232BA5452C4F0F9DD26674@PSB>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 12 Jan 2022 19:36:56 -0500
Message-ID: <CAMm+LwjU65bm9pski5cPhJiZr-q_xtfujrrq8Q1io__c9hD2Zw@mail.gmail.com>
Subject: Re: Backdoor standards?
To: John C Klensin <john-ietf@jck.com>
Cc: "Scott O. Bradner" <sob@sobco.com>, Mike StJohns <mstjohns@comcast.net>, Fred Baker <fredbaker.ietf@gmail.com>, John Kunze <jakkbl@gmail.com>, IETF Discussion Mailing List <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f1817e05d56be244"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/96Qxt1m1NcdvgwSSlCvONjo_V50>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Jan 2022 00:37:14 -0000

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.


On Wed, Jan 12, 2022 at 6:11 PM John C Klensin <john-ietf@jck.com> wrote:

> 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
> <fredbaker.ietf@gmail.com> 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"
> <sob@sobco.com> 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
> >> <mstjohns@comcast.net> 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
> >>
> >>
> >>
> >>
> >
>
>
>