Re: Backdoor standards?

John C Klensin <john-ietf@jck.com> Thu, 13 January 2022 06:04 UTC

Return-Path: <john-ietf@jck.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 215AE3A102A for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 22:04:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham 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 IhiMLrbdYpc5 for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 22:04:39 -0800 (PST)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6373A1025 for <ietf@ietf.org>; Wed, 12 Jan 2022 22:04:37 -0800 (PST)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1n7tDu-0003bR-Hr; Thu, 13 Jan 2022 01:04:34 -0500
Date: Thu, 13 Jan 2022 01:04:28 -0500
From: John C Klensin <john-ietf@jck.com>
To: Michael StJohns <mstjohns@comcast.net>, ietf@ietf.org
cc: John Kunze <jak@ucop.edu>
Subject: Re: Backdoor standards?
Message-ID: <A7AC7B3B5BCD87E65B4F253C@PSB>
In-Reply-To: <ee8acffd-e808-67fd-cf92-52b3f9f3e195@comcast.net>
References: <85191ed3-5fc1-67da-888a-8af7bf9064f8@comcast.net> <39E40B7D-0E51-41A9-A8A3-026A0013F032@sobco.com> <9C232BA5452C4F0F9DD26674@PSB> <003701d80816$a85ab810$f9102830$@acm.org> <ee8acffd-e808-67fd-cf92-52b3f9f3e195@comcast.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/laTE9vd1azvqODoim6y1pkkS_iE>
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 06:04:42 -0000

Mike,

--On Wednesday, January 12, 2022 21:21 -0500 Michael StJohns
<mstjohns@comcast.net> wrote:

> On 1/12/2022 7:44 PM, Larry Masinter wrote:
>> If there is some kind of abuse you are aiming to quell, some
>> examples might be helpful.
> 
> Hi Larry -
> 
> It's not so much about quelling abuse as it might be in
> reinforcing expectations.
> 
> This has been the expectation basically from the first moment
> that the ID system was created (right after the meeting at
> Boulder NCAR):
> 
>> It is inappropriate to use Internet-Drafts as reference
>>     material or to cite them other than as "work in progress"
> 
> And that was reinforced in some ways by the original manual
> submission model for IDs.  Over time, the tools have changed
> some of that calculus and most drafts get posted without human
> intervention, and the old versions of a draft now have fairly
> stable references as a side effect of how the tooling was
> built.

Actually not for the old (and expired) versions part.  Scott can
comment but I remember the decision to keep them generally
available without interaction with the Secretariat (the caution
on the datatracker page notwithstanding -- see below) as being
very explicit, a recollection that is reinforced by a 2012 IESG
Statement [1].  That was partially because of the IPR issue and
partially, as the Statement indicates, to facilitate comparisons
among versions.   Assuming we are not going to reverse that,
that part of the question is whether the current tooling
implements the intent properly and/or whether we might want to
review and adapt the intent.  In particular, if the intent is to
keep almost all I-Ds publicly available, we might think about
how to do something to make them less useful as stable
references.  Some variation of Larry's time-based idea or of the
ideas I mentioned in my note might work or, if he is willing to
be engaged on this a bit longer, John Kunze might have good
ideas about that in spite of its being the very opposite of his
research interests in stable references.

(Sorry, we have a small surplus, not only of "John"s in this
discussion, but of "John K"s.  Don't know how to work around
that that except by spelling out surnames.)

> All I'm really saying here is that it may be time to review
> that expectation and retain it, expand on it or revise it.

Agreed.  But the first part of that process is probably figuring
out which problem we are trying to solve.  Based on reading John
Kunze's note a few times, I'm guessing that making the old ARK
versions vanish entirely (per the original rule that "expires"
means "disappears from effortless public view) probably would
(or perhaps would) have caused only one change in behavior:
publication of Informational RFC snapshots of the current state
of the research based on the drafts of 2008 and 2018.  That, I
hope, would have forced (we don't have firm rules and that might
be something else we need to review) clear "what is different
from the last time and why" sections.  I just suggested in
another context that we may want to make an explicit rule about
that.  But, otherwise...

My guess is that there are three separate issues and
expectations we should review:

(1) Whether the introductory text that I cited earlier about
what I-Ds are about should be revised to eliminate the phrase
claiming other bodies can use them.  For the reasons John Kunze
mentioned in his explanation, I think that would hurt us and the
Internet, but YMMD and it is worth a discussion.

(2) Even in the RFC Series, whether we should reexamine the very
long tradition (going back to documents with two-digit numbers
long before there were I-Ds) of  publishing documents, or long
excerpts of documents, from other SDOs or even individual
companies for the information of the community.   I think
stopping that would harm the Internet but, again, you and others
might see the tradeoffs differently.  PHB's first note in this
thread may be helpful in looking at that.

(3) Whether our present method and tooling for making I-Ds
available long-term, motivated by the comparison and IPR issues
(including, as has been pointed out, making things easy for
people in other parts of that process, not just lawyers armed
with subpoenas), is encouraging bad behavior.  If so, whether
(i) we can and should either erect defenses against that
behavior and how or (ii) whether the risk of bad behavior
justifies going back to the "expires means disappears" rule even
if makes it hard for the folks trying to do comparisons or with
IPR concerns.

> In the instant case, removing the old ID versions of
> draft-kunze-ark  or changing the locator for the old versions
> might cause problems for the ARK community.  But not being
> able to remove (or "move" URL wise) those documents seems to
> be counter to the plain text intentions of RFC2026 section 2.2
> as well as other IETF statements of procedures.

If I correctly understand John Kunze's note, not really for the
ARK case.  As I guessed when writing my earlier note, ARK is not
a good example of the abuse case I think you are concerned about
(see (3) above), but that does not make that concern any less
real and important.

> Perhaps 2026 no longer correctly expresses the status of IDs?

To me, that is another example, perhaps the earliest important
one, of the IESG making a decision that ignores rather clear
text of a BCP procedural RFC and then just moving on [1].   In
this particular case, the decision was not to ignore that text
but, essentially, to treat warnings that have evolved into the
current
 "The information below is for an old version of the
	document" or just "Expired Internet-Draft (individual)"
	and
 "This Internet-Draft is no longer active. A copy of the
	expired Internet-Draft can be found at..."
as equivalent to the 2026 text
  "is simply removed from the Internet-Drafts directory"

And, of course, whether it is significant or not, the statement
in 2026 does not contain "MUST be removed" language but,
instead, makes what appears to be a statement of fact.  Scott
probably remembers my whining about the change when it was
announced, but the IESG consensus was clearly to make it.  

I think things have improved in more recent years in the sense
that the IESG, faced with a situation like this, would almost
certainly propose such a statement and explicitly ask for
community comment on it.  I don't recall that being done for the
case of retaining I-Ds.  However, if we don't like the idea of
the IESG being able to make decisions that contradict -- or
reinterpret well beyond the obvious original intent-- BCP
procedural language that reasonable people can interpret as
requirements, then there are other things that should be
considered again and reevaluated, especially if we do not
consider the Appeal and Recall procedures sufficient safeguards
against such actions.  

best,
   john