IETF Logo Mail Archive

Re: Backdoor standards?

"Andrew G. Malis" <agmalis@gmail.com> Wed, 12 January 2022 22:29 UTC

Return-Path: <agmalis@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 90A073A2045 for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 14:29:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 lgXoItRWSR0j for <ietf@ietfa.amsl.com>; Wed, 12 Jan 2022 14:29:21 -0800 (PST)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 EADFB3A2043 for <ietf@ietf.org>; Wed, 12 Jan 2022 14:29:20 -0800 (PST)
Received: by mail-io1-xd2a.google.com with SMTP id i14so5777291ioj.12 for <ietf@ietf.org>; Wed, 12 Jan 2022 14:29:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BuHWbBiuwYRARCPKdrcMJ0KQ24AHFomu+z2R4PLn5tM=; b=T6CfbbOD8updvi6YV0CHm6SSO7BQMGotmxQvdskrYVaabr2fFMCQRn2XomcXyHrDvq zueVVyfzXwzdBKQXL+Tog6m+R6YVceRiYK830vYLBae0uR4HoeOUL3XeXjEV7PsfQKjE S20X7slNNoY7Wg2mrUOS8Piyfcqtb/o6QwNC2SBpqb8fCotlbtDVbULNL2ZzZFjgbNvd 62zVO4LISE5YSnJiHjRSU4S9dq84yak2tU7Hxu1sf868I7CStiTMvoqZZgdlzVDdiE1Y FhIo8W6yyRaAqC69mDpFGjNrib6DomRfg3HsoaWHetI3rVW6nZxom8KkFwdqzAfvg6NC jDQQ==
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=BuHWbBiuwYRARCPKdrcMJ0KQ24AHFomu+z2R4PLn5tM=; b=wKKaMpJEIi+QhRtaRzoD3IRaqU9LpXN/2GfxdMcH8dNH0k7SnxtHlMrpzqClnvci6r GBowQHOyM96NPr2XNVQFK3aVHbHEdVmtOpVMfVpE/vdN8M+oLssSbkqN10dG3Ojy+aHi eScNGr8WQG+Nlghvt26o0Xsm94G2YSG3swnA0t/a34nvHs+KepFEtQKb7b3ebmRGBIQ+ uRZFw/H8Yj1hVdCU4K/nAExzAjISXZCjkVGoOkRgvYhfbJ3BBBG1DVDDDWVnNvshbhrr kV0arx1p3Z6M3VbGbp19YvMxSX1Yrkpn7+Gm1+OcN6fnrTAsSfpilDc1D+AVA/TSZskz agOw==
X-Gm-Message-State: AOAM533EV4T44L2Q09CrGTf2/gssquWxNpgiRCmw5RTWQOhYBND3Bn3r c77XTzRVRb9k1ofgvP/S3A8MoWczBJPTjwhWq7k=
X-Google-Smtp-Source: ABdhPJwR+ROxwxzO/eSsl4zuPBflPizO4jkUdWrMuZgS8wlYi4yMyzPdh5vDrP/ckYsYaPuRCSvVqOWRQOJxobzB6FE=
X-Received: by 2002:a02:cd1b:: with SMTP id g27mr850865jaq.0.1642026558632; Wed, 12 Jan 2022 14:29:18 -0800 (PST)
MIME-Version: 1.0
References: <85191ed3-5fc1-67da-888a-8af7bf9064f8@comcast.net> <CAA=duU27S172yCm_6s7gxuN7Cs7k7tRirA0W4YdT8VWepcDARg@mail.gmail.com>
In-Reply-To: <CAA=duU27S172yCm_6s7gxuN7Cs7k7tRirA0W4YdT8VWepcDARg@mail.gmail.com>
From: "Andrew G. Malis" <agmalis@gmail.com>
Date: Wed, 12 Jan 2022 17:29:02 -0500
Message-ID: <CAA=duU19xQEo0gfEk43zruaONF_QX9p02a2AAzHy-WS_UA8J+g@mail.gmail.com>
Subject: Re: Backdoor standards?
To: Michael StJohns <mstjohns@comcast.net>
Cc: IETF Discussion <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000bd340605d56a1985"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/TeG-zjlwspUvuyw-Z4QjhZ0OT1w>
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 22:29:26 -0000

I meant "archived", not "achieved". :-)

Cheers,
Andy


On Wed, Jan 12, 2022 at 5:26 PM Andrew G. Malis <agmalis@gmail.com> wrote:

> Mike,
>
> I would suggest that the relevant AD speak to the authors about publishing
> -18 as an informative RFC, which can then be superseded once the ARK spec
> completes.
>
> There was a time, in the distant sands of the past, when I-Ds actually did
> disappear from the IETF systems after they expired, but there were third
> party sites (I seem to recall Waterstones) that conveniently achieved all
> of them. Having expired drafts available directly from the IETF systems is
> a necessary convenience.
>
> Cheers,
> Andy
>
>
> On Wed, Jan 12, 2022 at 4:13 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
>>
>>
>>
>>
>>

v2.23.0 | Report a Bug | By Email