Re: Backdoor standards?

"Scott O. Bradner" <sob@sobco.com> Wed, 12 January 2022 21:20 UTC

Return-Path: <sob@sobco.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 7D1903A1DEA for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 13:20:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.916
X-Spam-Level:
X-Spam-Status: No, score=-0.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_RDNS_DYNAMIC_FP=0.002, RDNS_DYNAMIC=0.982, 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 5nnN3P5V9pkm for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 13:20:44 -0800 (PST)
Received: from sobco.sobco.com (173-166-5-71-newengland.hfc.comcastbusiness.net [173.166.5.71]) by ietfa.amsl.com (Postfix) with ESMTP id EA3933A1DDF for <ietf@ietf.org>; Wed, 12 Jan 2022 13:20:43 -0800 (PST)
Received: from [192.168.50.224] (173-166-5-67-newengland.hfc.comcastbusiness.net [173.166.5.67]) by sobco.sobco.com (Postfix) with ESMTPSA id 77E5C10DAEC8; Wed, 12 Jan 2022 16:20:42 -0500 (EST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\))
Subject: Re: Backdoor standards?
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <85191ed3-5fc1-67da-888a-8af7bf9064f8@comcast.net>
Date: Wed, 12 Jan 2022 16:20:38 -0500
Cc: ietf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <39E40B7D-0E51-41A9-A8A3-026A0013F032@sobco.com>
References: <85191ed3-5fc1-67da-888a-8af7bf9064f8@comcast.net>
To: Mike StJohns <mstjohns@comcast.net>
X-Mailer: Apple Mail (2.3445.9.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/YSUcvBoI186hUeQ35zuvjQhWQN8>
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: Wed, 12 Jan 2022 21:20:46 -0000

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