RE: Backdoor standards?

Vasilenko Eduard <vasilenko.eduard@huawei.com> Thu, 13 January 2022 08:01 UTC

Return-Path: <vasilenko.eduard@huawei.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 52C893A0736 for <ietf@ietfa.amsl.com>; Thu, 13 Jan 2022 00:01:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 myY2Q55lrhcw for <ietf@ietfa.amsl.com>; Thu, 13 Jan 2022 00:00:56 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77F713A0777 for <ietf@ietf.org>; Thu, 13 Jan 2022 00:00:56 -0800 (PST)
Received: from fraeml743-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4JZH1D4GYRz67NNV for <ietf@ietf.org>; Thu, 13 Jan 2022 16:00:48 +0800 (CST)
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml743-chm.china.huawei.com (10.206.15.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 13 Jan 2022 09:00:53 +0100
Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Thu, 13 Jan 2022 11:00:52 +0300
Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.020; Thu, 13 Jan 2022 11:00:52 +0300
From: Vasilenko Eduard <vasilenko.eduard@huawei.com>
To: John C Klensin <john-ietf@jck.com>, Michael StJohns <mstjohns@comcast.net>, "ietf@ietf.org" <ietf@ietf.org>
CC: John Kunze <jak@ucop.edu>
Subject: RE: Backdoor standards?
Thread-Topic: Backdoor standards?
Thread-Index: AQHYB/k6m+6RYE4L8EKHFHZToEv/qaxfskAAgAAeygCAABoHAIAAGyOAgAA+ZwCAAFIRoA==
Date: Thu, 13 Jan 2022 08:00:52 +0000
Message-ID: <d26e9f470ba546dfb0fd3421b217b9b0@huawei.com>
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> <A7AC7B3B5BCD87E65B4F253C@PSB>
In-Reply-To: <A7AC7B3B5BCD87E65B4F253C@PSB>
Accept-Language: zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.161.102]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/saMwT6bY9tCDr5fxMcxAitXyN4M>
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 08:01:01 -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:ietf-bounces@ietf.org] On Behalf Of John C Klensin
Sent: Thursday, January 13, 2022 9:04 AM
To: Michael StJohns <mstjohns@comcast.net>; ietf@ietf.org
Cc: John Kunze <jak@ucop.edu>
Subject: Re: Backdoor standards?

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