Re: Status of RFC 20

John C Klensin <john-ietf@jck.com> Sun, 07 December 2014 22:14 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E761A01D8 for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 14:14:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 DDKjA2INK94U for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 14:14:36 -0800 (PST)
Received: from bsa2.jck.com (ns.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 B9A3D1A0242 for <ietf@ietf.org>; Sun, 7 Dec 2014 14:14:36 -0800 (PST)
Received: from h8.int.jck.com ([198.252.137.35] helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Xxk5a-000CE2-Td; Sun, 07 Dec 2014 17:14:02 -0500
Date: Sun, 07 Dec 2014 17:13:57 -0500
From: John C Klensin <john-ietf@jck.com>
To: joel jaeggli <joelja@bogus.com>, Barry Leiba <barryleiba@computer.org>, "Black, David" <david.black@emc.com>
Subject: Re: Status of RFC 20
Message-ID: <0F31F56DA06E076BFA0E2EA9@JcK-HP8200.jck.com>
In-Reply-To: <5484CAFC.7090909@bogus.com>
References: <CE03DB3D7B45C245BCA0D24327794936289DC7@MX104CL02.corp.emc.com> <CAC4RtVA10gUzmug4+H5SW2JL4Q7-Yh_ntiqPTswYSUUgXMoczA@mail.gmail.c om> <BB4CB3D8CA03EB4A03FEA99B@JcK-HP8200.jck.com> <5484CAFC.7090909@bogus.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.35
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/FTMDmhjhl7bpp8Jto9s6INlilic
Cc: rse@rfc-editor.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Sun, 07 Dec 2014 22:14:38 -0000


--On Sunday, December 07, 2014 13:47 -0800 joel jaeggli
<joelja@bogus.com> wrote:

>> So, rather than go through a discussion about downrefs and the
>> like every time RFC 20 is referenced from a Standards-Track
>> specification, I suggest that the IESG reclassify it to
>> Internet Standard and waste as little more time doing so as
>> possible. 
 
> 3967 applies quite effectively
> 
>    Once a specific down reference to a particular document has
> been    accepted by the community (e.g., has been mentioned in
> several Last    Calls), an Area Director may waive subsequent
> notices in the Last    Call of down references to it.  This
> should only occur when the same    document (and version) are
> being referenced and when the AD believes    that the
> document's use is an accepted part of the community's
> understanding of the relevant technical area.  For example,
> the use    of MD5 [RFC1321] and HMAC [RFC2104] is well known
> among    cryptographers.

Except that 3967 requires that the downref be _explicitly_
identified in Last Call announcements and that waiver doesn't
apply unless that has been done.  Approving documents that
contain the downref without an explicit mention in the Last Call
announcement may be fine and sensible but, as 3967 is written,
doesn't count.

One can quibble about the lower case "should not" (and, given
how this conversation has gone, I'm certain someone will), but
the paragraph of 3967 after the one you quoted expressly forbids
the use of the 3967 procedure as a substitute for reclassifying
a document "into the appropriate category".  As John Levine
pointed out, RFC 20 is a standard by any criteria one can use
other than the failure of the RFC Editor and then the IESG to
appropriately identify it.

> Anyone raising downref issues with rfc 20 is out of their mind.

There we agree, but this issue didn't come up because someone
was looking for a way to start trouble.  It came up in a real
review because tools that reviewers are expected to look at and
use called it out.  We could figure out lots and lots of
complicated ways to work around that problem, of which a Last
Call that uses the 3967 mechanism (despite the prohibition)
would be an example, but I need to once again ask why we don't
just fix the problem and reclassify the document to reflect its
obvious status.

> that said you'll note a rather large gap in citations, given
> that for something like 29 of the last 45 years there wasn't
> an online copy in the rfc repository.

(I added Heather to the distribute because of the above)

To the best of my knowledge, there has _never_ been a
requirement that cited documents be available online, and
especially that authoritative copies be available online.
Certainly it is preferred for many reasons, but never has it
been a rule, nor is there a rule that makes RFCs special in that
regard.  If the IESG asked the community for permission to
impose such a rule, it certainly was not within my memory.  As
to the "last 45 years", there simply has not been an online
repository for that long, so that criticism would apply to any
older RFC.

If we want to start inventing new rules about citations to block
progress, I think there are any number of members of the
community who would be happy to contribute to the effort.  More
constructively, April 1 will be here soon.  :-(
  

  john, probably becoming unbearable