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

Joe Touch <touch@isi.edu> Sun, 05 June 2016 20:38 UTC

Return-Path: <touch@isi.edu>
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 2A76C12D620 for <ietf@ietfa.amsl.com>; Sun, 5 Jun 2016 13:38:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham 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 pAhmnw19jO9h for <ietf@ietfa.amsl.com>; Sun, 5 Jun 2016 13:38:14 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 4283112D618 for <ietf@ietf.org>; Sun, 5 Jun 2016 13:38:14 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id u55KbHME023975 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 5 Jun 2016 13:37:19 -0700 (PDT)
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>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
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> <5751D5E8.6030803@cs.tcd.ie> <CALaySJ+3jorRopPKNHjy19fo1v1=dZEHarMJ1-gB89vNbkFxaw@mail.gmail.com> <5751ED8B.4020508@isi.edu> <9b7a1b04-f767-517a-bd84-28c030695dfc@gmail.com> <57521D24.40700@cs.tcd.ie> <CAC4RtVBMA42Ke_m6ked9GtUTdGSdg-Jjxp5ibiWBDdG+p2y-2w@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <57548D7B.5020702@isi.edu>
Date: Sun, 5 Jun 2016 13:37:15 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <CAC4RtVBMA42Ke_m6ked9GtUTdGSdg-Jjxp5ibiWBDdG+p2y-2w@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-MailScanner-ID: u55KbHME023975
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/51EdW0Gws31e5rIPsSDaUVUJ_gM>
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: Sun, 05 Jun 2016 20:38:15 -0000


On 6/4/2016 11:42 AM, Barry Leiba wrote:
> I just find it fascinating and disturbing that at least two respected
> IETF participants think it's perfectly fine to leave stale references
> around, especially when it's trivially easy to fix them -- in the vast
> majority of cases taking but one sentence in the IANA Considerations.
> I'm simply flabbergasted.  This isn't "useless hoops"; it's simple and
> sensible updates that rarely take any effort.

Consider that RFC6335 specifically limits changes to at least one IANA
registry to the assignee. IMO, that's the right answer for all
registries with assignees. If the ISOC/IETF are the assignee, then they
can do whatever they want.

Further, producing an updated RFC does not immediately update the
deployed codebase. It might be appropriate to include the new RFC too,
but not in all cases.

Case in point: TCP MD5. This was obsoleted by TCP-AO, but the TCP option
number for TCP MD5 should not be changed to point to AO. It might be
appropriate to add a note that this codepoint represents an obsoleted
protocol or even to point to the new one - or not. It depends on the
codepoint.

Overall, the point is that "it depends". Setting a single rule to
"update" is an algorithm. I repeat my previous advice:

"I'd prefer to trust the author to do the right thing that to engineer
this document with an algorithm."

Joe