Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 03 June 2016 19:09 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 94ABA12D7C2 for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 12:09:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.727
X-Spam-Level:
X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 JnjmycCWs7ib for <ietf@ietfa.amsl.com>; Fri, 3 Jun 2016 12:09:32 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D0D712D7AF for <ietf@ietf.org>; Fri, 3 Jun 2016 12:09:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4FF12BE29; Fri, 3 Jun 2016 20:09:30 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jy1uhcxZZctT; Fri, 3 Jun 2016 20:09:29 +0100 (IST)
Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 860F9BE25; Fri, 3 Jun 2016 20:09:28 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1464980968; bh=SKxQY+06vDU3RTVZ7FTaXuzXI4oxgLtyMLeGDOU/+2A=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=BSqZbQaEvu8/o0OMlaszqIded7wyXtaLDFHgbw74HdjeSXYMXlJS5nvLA/P/haiqz X+DTtzAkslOh1g1eVJUZZJGw7vdrNnfIGeVtoDRIWvNM/EZZ+OsFU9SxGbnl6g4Hix qhD8bx8WrSfGh0iXhC3HnYH7lQxez02lSl0nal5Q=
Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
To: Barry Leiba <barryleiba@computer.org>, Donald Eastlake <d3e3e3@gmail.com>
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com> <575185A2.70908@cs.tcd.ie> <EDA3CD0D-BDCA-4AC6-AA67-318670080338@sobco.com> <CAC4RtVBngkPc-yQ8P0qyvwsG9L4qjDMDPZ5xwa4gR84=ov4iUg@mail.gmail.com> <CAF4+nEHzvVOq_1L2ukX-OcPGkVFgR2OOD5puLMBJGif3a=Hzaw@mail.gmail.com> <CAC4RtVC6sKnYQS3mOay8-rSLQ0+U5mYGVhBbSSD=0xNX6dt2ng@mail.gmail.com>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url=
Message-ID: <5751D5E8.6030803@cs.tcd.ie>
Date: Fri, 3 Jun 2016 20:09:28 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.8.0
MIME-Version: 1.0
In-Reply-To: <CAC4RtVC6sKnYQS3mOay8-rSLQ0+U5mYGVhBbSSD=0xNX6dt2ng@mail.gmail.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040100000904050408040809"
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/ck3W19mcZPxNpKK3QM403UK8P7E>
Cc: IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 03 Jun 2016 19:09:34 -0000

Hiya,

On 03/06/16 19:45, Barry Leiba wrote:
> Hi, Donald.
> 
>> It is also possible that a code point is being obsoleted by an RFC bis
>> document but is retained in the registry, in which case you want the
>> reference for that value to be to the obsolete RFC where it is
>> specified.
> 
> Ooh, yes, that's certainly correct.  The current text handles that by
> saying "for any registries or registered items that are still in
> current use."
> 
> Would anyone object, and would this address your concern, Stephen, if
> I should change the text like this:
> 
> OLD
>    If information for registered items has been or is being moved to
>    other documents, then, of course, the registration information should
>    be changed to point to those other documents. In no case is it
>    reasonable to leave documentation pointers to the obsoleted document
>    for any registries or registered items that are still in current use.
> NEW
>    If information for registered items has been or is being moved to
>    other documents, then the registration information should be changed
>    to point to those other documents. In most cases, documentation
>    references should not be left pointing to the obsoleted document
>    for registries or registered items that are still in current use.
> END

That is better, but I'm still worried that it'd be used by well meaning
folk to force authors to do more work than is needed for no real gain.

My preferred OLD/NEW would be:

OLD
   If information for registered items has been or is being moved to
   other documents, then, of course, the registration information should
   be changed to point to those other documents. In no case is it
   reasonable to leave documentation pointers to the obsoleted document
   for any registries or registered items that are still in current use.
NEW
   If information for registered items has been or is being moved to
   other documents, then the registration information should be changed
   to point to those other documents. Ensuring that registry entries
   point to the most recent document as their definition is encouraged
   but not necessary as the RFC series meta-data documents the relevant
   relationships (OBSOLETED by etc) so readers will not be misled.
END

> 
> Barry
> 
>