Re: Status of RFC 20

joel jaeggli <joelja@bogus.com> Sun, 07 December 2014 22:50 UTC

Return-Path: <joelja@bogus.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 AE44A1A1A6C for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 14:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jFTlDMepoI7X for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 14:50:35 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAEE61A1A6A for <ietf@ietf.org>; Sun, 7 Dec 2014 14:50:35 -0800 (PST)
Received: from mbp.local ([IPv6:2601:9:7680:ec8:c99c:4552:7ee6:89ec]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sB7MoSDx018766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Dec 2014 22:50:28 GMT (envelope-from joelja@bogus.com)
Message-ID: <5484D9B3.2050803@bogus.com>
Date: Sun, 07 Dec 2014 14:50:27 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Barry Leiba <barryleiba@computer.org>, "Black, David" <david.black@emc.com>
Subject: Re: Status of RFC 20
References: <CE03DB3D7B45C245BCA0D24327794936289DC7@MX104CL02.corp.emc.com> <CAC4RtVA10gUzmug4+H5SW2JL4Q7-Yh_ntiqPTswYSUUgXMoczA@mail.gmail.c om> <BB4CB3D8CA03EB4A03FEA99B@JcK-HP8200.jck.com> <5484CAFC.7090909@bogus.com> <0F31F56DA06E076BFA0E2EA9@JcK-HP8200.jck.com>
In-Reply-To: <0F31F56DA06E076BFA0E2EA9@JcK-HP8200.jck.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="E7PJmCPaNbW8O3IpJVTlJwbnSkJSm2HLM"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/oiugp6AtrnBJykiF2titV0AwrNE
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:50:40 -0000

On 12/7/14 2:13 PM, John C Klensin wrote:
>
> --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. 
There are normative citations of RFC 20

Q.E.D.

Whether to include one on the future is a judgment call on the part of
the person writing the last call writeup, e.g. the sponsoring AD.
>  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.
...
> 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.
That's not the point, nobody cited it because they couldn't read it.
>