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

tom p. <daedulus@btconnect.com> Mon, 06 June 2016 10:22 UTC

Return-Path: <daedulus@btconnect.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 CCD9112D0D8 for <ietf@ietfa.amsl.com>; Mon, 6 Jun 2016 03:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.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 zY3i6Zzlv05A for <ietf@ietfa.amsl.com>; Mon, 6 Jun 2016 03:22:18 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58A812B022 for <ietf@ietf.org>; Mon, 6 Jun 2016 03:22:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RETiMwix7Y0H3l2w86f5My50Vz0r+FN+tMNJ9Z7Vyvk=; b=aSRkFVfKgEX4a/Og8ahDig31/V92ixpUoWgDrdc2dw4MAZp54eTcTncv7fVYks76RyJSRL0SyvWwo0curA+/c2laeE0JFg/SdVbiB1JBtwbvj3Kmej+iOVC0kih2pmL/1neC85fOQOjFJVnmxoz4pU9/wFXxXVHK3vN/MfRlu4Y=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=daedulus@btconnect.com;
Received: from pc6 (109.145.193.232) by HE1PR07MB1561.eurprd07.prod.outlook.com (10.169.123.11) with Microsoft SMTP Server (TLS) id 15.1.511.8; Mon, 6 Jun 2016 10:21:56 +0000
Message-ID: <003701d1bfdd$0e0f0cc0$4001a8c0@gateway.2wire.net>
From: "tom p." <daedulus@btconnect.com>
To: Barry Leiba <barryleiba@computer.org>
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> <57548D7B.5020702@isi.edu> <CALaySJL_aUv751Z9xdSWib4vbnqK-ymzg7gLWqk8+Q1uo_MYRA@mail.gmail.com>
Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
Date: Mon, 06 Jun 2016 11:20:16 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [109.145.193.232]
X-ClientProxiedBy: DB4PR06CA0047.eurprd06.prod.outlook.com (10.160.40.175) To HE1PR07MB1561.eurprd07.prod.outlook.com (10.169.123.11)
X-MS-Office365-Filtering-Correlation-Id: ec639023-50dd-45ba-1de0-08d38df46348
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 2:Jwt+GaYXQ94sHM2YMBurRWvUYifUqPIe+9rDdz+OpyVSfOX/aY7DATWVhcjybAgmfrpL/u0Bj7x8guvNPRgQeB1nXXdvXFOorlmTkv25bK0gsNeo1XdQH4YkRCjHcOyvMMeT4zg1uL8OjXRKo3irl8R47oYghu4xEwwQfbohrSalFP/U2WguwqIogxf56O9u; 3:lEjSItZ+51Nw6IRMK/9T7dG3Uq0DVMDj7rx6dd3sy2jRA+tW/5uN0G7PPTj787V24+8sXY7nUVfJhOd2miGqfat145PPHpHf2XDesO9EJcoxSSsQRU581FbYilbaoCDL; 25:2Mejc7Y5qteJP9I7gfwD7VKVQEtR3xH4VVHk7ST+lrxuMcybjctW4N9bKYrNrhLv5mp8NsF3+TK2+Pp4XAZBVcANvtgvTmzwH4//DZVOfOvvkfkGUTL8TY0ZHhFV50dMjKhGLF9zTfyijo8wtzXXHjI3HWcNKmlCv0AHB7IRJre2no88KkZlxJUuIuY65DOhaFtNiAxw7sgOeY1ztdSCabjNML167JwIil96ErHpW/7U3UBVMPARTAagn3iyOKLtMN1keMUYEZsbPbh/8NhWEhxprRNcyWv8yTW//Yxv0zgbrSNvoWFPmSMaoqZBWvlGE0NtuY8GTyrzZS9wOtj9Zcdta+tJLcYhs1ShivABz/kEOCnsYMxRjFRZFGgtd+BLIECBpFkKcdbdfjKIAfXu1baM0P/yC3Q2zZ+D71TcYeA=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:HE1PR07MB1561;
X-Microsoft-Antispam-PRVS: <HE1PR07MB15611C32CB1A265EC9602DA3C65C0@HE1PR07MB1561.eurprd07.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:HE1PR07MB1561; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB1561;
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 4:Qjm2x0pigeLXAQR3yFVsoGhvCBhvpUk1CP4Z9at6sMBM8TfcinF9I4zsHHcqdTEm50DeT/1vyHySZQh8Nuel7EAecD+l9wee02NvU1RO7AEd6u+grJK6XyKyBoM6rR5LhsGCs5RqGbzkJdxDnML0GMPOegIaKjvnJqRtJFRDdeGhMnfYvpH08QYUTvNeRgTybQeUhzIvau57U9ifOK/8DJL8zR0oXjF65t0+nouxCPSUCgnUIGtkYWvPAbe120Jx1K2hiabxIUd/xOkwwl19GRgE6bWuoyUQVQKDAssCjUSmsgR0QJ9NDGIPJRuS0IG8JtdSJYbaO9tlNXRPx/2PksUVSoE6Ob/DRp1wrzP5xZMDo/XVo/TBgotdkgOpJROT
X-Forefront-PRVS: 096507C068
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(13464003)(377454003)(189002)(51444003)(199003)(92566002)(230700001)(77096005)(6116002)(3846002)(50466002)(1456003)(5004730100002)(84392002)(68736007)(586003)(5008740100001)(2906002)(8676002)(81166006)(230783001)(93886004)(81156014)(9686002)(50226002)(4326007)(116806002)(33646002)(47776003)(66066001)(44736004)(19580405001)(106356001)(19580395003)(110136002)(105586002)(101416001)(14496001)(189998001)(1556002)(97736004)(44716002)(61296003)(62236002)(86362001)(5820100001)(76176999)(81816999)(42186005)(81686999)(50986999)(23676002)(74416001)(7726001)(4720700001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1561; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: 1;HE1PR07MB1561;23:onGFWAjZVu1z1Iwhr2d0NgJmBdiUaFyf60NOgy8UFRv7IOZhn9A/PzGuCEjdZemmDYSihxHo7578w5k/ZxJJ7hwI5hsd8YLF0g52Se/sAg0oVagk2TsLpEBkqdUOb7FolhVn5t9AgPWq8az34pc2tc/VdkPXmGfg2U4PwEuZiBgWvjomvaLwnpYbiurP4wDpagjSZUsGqkSjNKRHbB/ZTU4V1fmeKH9zIHRbfVhT0v1ePjAjTNIQpeH3uQQ4bfTBeVIn7zz9v3l/z6qLtOjHgAJSiToCMLIb7ENCq+c2HDtOSdxOXy89X1OK/AVT8+uPj/dh457PooVnIF0O2EA+AALWOUBNxO2f0ahQBRhazTPZbuOtlGPwERhyTE7JAPcUyY8SzmJlkniNJ8R4L7ZHCpxhZpVF2J2tkxuhU+cd0A2Jt/2fptRMXn/q58EP2yHbbrDBNqCegSnns6HaIMSWB5vpbI3QL0JpTGj3nU3GdsQ1MIH+Nk2uSCUT1x9fFvf+127KkZ4jF+3/O17JhBW77I0w4eMgYbgiKN5iAEKByGTKOHQ4XMVJqWQEwSwkOnoeI3XBIxPaY16DfHKhYTRWWOvfSLKsfMhMQC7wGnPUQJdPgZ0EbUheIMzWGdyi9rhKq9K9td1a7GZJuekhditbfIwnaiBK0vF7gdr+QF7dvRYWnuoI+HK5DuaTjBeiEgzA+yBQYuIBxFWr7LFBh/wZi+eWXeKHD63S2tB0Z2k6veK8WEuH+bYUJFAEBQnIbJSwHQXBSKpcqOIGR8afegV6SVclBhj0fMxPKQSg+mfC84rcfUUpZp1Yy67+zlG29wcsQVFnlOWfYnYg82F0CF+qNYEORC3KuEhMQxWrkfETCjPrkTNwIlIIeN+KBXuK6/jvcDmgWx3lO4J7jXZUUB8m4ADmCiRq4UmQdb3kOFPt/queyf1zHodsQPUn6uHtyUjvAZRvzuma1/pX/DMInspg1A61l0DRT/sYi1CKDjT8ls8JUBwQFcBYpdNzqQGk06xZUyU7jsiq4Srkb30RKRlLPyjWzYsfRkbHL73hU7HMT+jALOtcejScl8RX4RDIOF7aJR+RGlD9KUHRI/6LQj1m/jzpOq5DC/vWIEXj/ZqLb9STbJ6j+SFNqa2jeD4QcPf4RpzRzvIQ82qvAx2DO+UeFuGk2HBAltreiJRZMOm068g1n/UtsOGsVkxKNyPmNd2evJwwZ8XcPdm2WZ/ORpV7JsAU0xKAsfFjmnh+cNmRLEcqMqfnSMorI0P49UqGTRKIt+++2TsVN1kO9QyakcjDcRZuYBAA8n5COavOH/ehKuK0nxdUfwr9GzygbhNqISLm+rmgRffafV2PkFSw+PWjy6F32nEgMmfIH5Z4zKu6rScOMBKZ02gJheyuGwYBbpM7
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB1561; 5:men7OCRSUlZ+IO22beC+B0BZ7ZgS/nyO/ZC6xz1P9eEGVd++6tB0z066PVJeAukI9/xezCMLpJ2WmNYSaRGO1Ce/p7hNWqqoHM5tAEDkaiDZpfDNmRvLflMyGgDhze0ILCRstfOeqP/FAwwYOmBdVA==; 24:i4P+UijTx0hZqYta/Xi+oVv76TxusDjZ/32ofXpR2B/qMsqMJ/Sux4CZjUGyUqcffa39oJfj6O5yFPWEhHcMWhILTH88YhK2MOVfPXiddR0=; 7:id+w2Jchaow/OVDcOOIoROhFXM1BjB7jA3O13PBqv0BNuoC2X3KCFee29NHNLul9uzoVePt1SL3/ZMdiX2ul5bCqtdhbbW1DGQzzmqpKU3U4X0d7ZPTWbaTpQ+0lY+RnViV3sWDfnPV+1NxkLYld8+YJ+MMGg5vhhaEUtipGrR10Oo/MfXozyv0wD+p+i4mW1/usOJtn8SADNH0LwwBhiFQoTryv0tlNkCkU9bFbAYc=
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2016 10:21:56.3141 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1561
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/sEGWSSAsT7OrQZiQBg2tVlNjFfU>
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: Mon, 06 Jun 2016 10:22:21 -0000

----- Original Message -----
From: "Barry Leiba" <barryleiba@computer.org>
To: "Joe Touch" <touch@isi.edu>
Cc: "IETF discussion list" <ietf@ietf.org>
Sent: Sunday, June 05, 2016 10:10 PM

> > 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.
>
> Sure, this is a very different situation.  The most current
> documentation for the code point for TCP MD5 is the obsolete document.
> So that's fine.  TCP AO will have a new code point, with a current
> reference.  As I've said before, the "in current use" clause is what
> applies here: It's not just that the documentation for TCP MD5 has
> been updated and we're thinking about whether we should point the
> reference to the new document.  It's that TCP MD5 itself has been made
> obsolete.
>
> Yes, as you say (and as I say), the point is to do what's right.  I
> contend that in most cases, the right thing is to update the reference
> *when we produce a more current reference*.  If we have not done that,
> then we should not do that.
>
> And also as you say (and as I say), we always want to leave
> flexibility to use our heads and do the right thing.  That's why I'm
> very happy to move away from the "in no case" phrase, to something
> such as "in most cases."  I pretty much *always* want to allow people
> to make sensible judgments, and not to stand behind firm, inflexible
> rules.

At the risk of making an abstract discussion concrete, RFC7001 provides
an example of how not to do it.  It caused IANA to update the pointers
to RFC7001 in many places but RFC7001 did not contain the relevant
information on the registries, their fields, policies etc.  Nor did
the RFC that RFC7001 obsoleted.  You had to go back to the RFC that were
superseded by the RFC that were obsoleted by RFC7001, add in the
updates,
and piece together the information you needed.  Hence RFC7601 (which
used the then current draft-leiba-cotton as its guide).  Compare the
IANA Considerations in RFC7601 with those in RFC7001 and you can see
what an expert author might come up without further, careful
consideration, such as that provided by APPSAWG in March 2015:-)

I think that the pointer should be to where the information about the
registry is held, the fields, policy etc and if that is not reproduced
in an obsoleting document, then the reference should stay to the
obsoleted document.  It is easy to check for updates against a document
via rfc-index and, like checking for errata, it is something you have to
do before you can rely on an RFC; going in the opposite direction, back
in time, is harder.

Of course, present day ADs do not regard the addition of an entry to a
registry as a document update to the RFC that is the current definition
of the registry so it is crucial that IANA separate references for new
values in a registry from the reference for the registry as a whole -
which IANA well understands.

If the information about the registry is carried forward, then there is
no
problem and that is the best solution; but not all authors do that (see
above).

Tom Petch

> Barry
>