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

Barry Leiba <> Sat, 04 June 2016 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 605C712D631 for <>; Sat, 4 Jun 2016 11:42:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OLmt-BcK8T86 for <>; Sat, 4 Jun 2016 11:42:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 38ACE12D62E for <>; Sat, 4 Jun 2016 11:42:50 -0700 (PDT)
Received: by with SMTP id t40so109344975ioi.0 for <>; Sat, 04 Jun 2016 11:42:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ZXtLwz8nXA6nqVj5nE+Hh4Id7Rt8WKO3JFVcNw+ZcPw=; b=QpqO/pxz4Pj5C8OoZYtZRxgzC96rdsc04JHBwoTZ/lFI6R/wDNIoXRO5bmjBhNjlbN fGyvtY7ILq4sKyd7l0Htgwcl1UIgKmr6WXSo9odDEn6C/SF2jLdjzsTj4S++00tLV+OH u2ewKpYUhCX9GbevzA5GohznMtM2OPnSROzfnIn6c5Se0NQMOk0iHbMbNy1kF94s0n3q NB3HuLqb/IC6bkWNYJ/kFsnTYS05kQ3ryLGHjVxZ66ojaB4ymzHzLeK7r7jHkUEOJ6PH SLRmXtDnPT2C8/P54wuFizHN0sSY/kphOPOhNN3US6S1kC+TDYTEt7Nkmu5JBhtHI7P1 Ahzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ZXtLwz8nXA6nqVj5nE+Hh4Id7Rt8WKO3JFVcNw+ZcPw=; b=C92zw1AUvNVOl7ZhXoABu21sqrBhhAC2/UUeaZmCo53NYv9Q+BcyKygZThPMWN/Obw G13jpnqJFp0K88+9aDXM+m9auXaB3acwXP6Wf8f6/hphrIXSw7bpzA69zfBa4skUg55i MlgNwpNF5UW3fe6FEmeDk0IVtGVqQg1qNwU7fAlyHhrp+tacy3jFhyBavicNxqAF8hBp PZtkcUU/hp91WEa+a2Vk/Py9YMIxUdjjU6hvXS5R+dlskXBglqiOpCkwuEf1WTQiFI2y zn/fEiug1DHQwJsPmZ3A4eixha1GYS0pm/Hx2y0hWCieVBeWzaF+6w98KLuCg79lksvJ Lmvg==
X-Gm-Message-State: ALyK8tKqCYwwfpK4S2BO6gVrWN79uo8knu9MiUtEWC8BVzn1VQFZq7LRnFTgc8V5Gp+O+tlCboI6uA3HFCL4TQ==
X-Received: by with SMTP id o126mr13308093iod.70.1465065769578; Sat, 04 Jun 2016 11:42:49 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sat, 4 Jun 2016 11:42:48 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Barry Leiba <>
Date: Sat, 4 Jun 2016 14:42:48 -0400
X-Google-Sender-Auth: uTGkqcH7tCa5wd2rgmUV2eXfdKk
Message-ID: <>
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: Stephen Farrell <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: IETF discussion list <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 04 Jun 2016 18:42:54 -0000

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.


On Fri, Jun 3, 2016 at 8:13 PM, Stephen Farrell
<> wrote:
> On 04/06/16 00:35, Brian E Carpenter wrote:
>> That's not realistic. If IANA refers to RFC822, and the programmer has a
>> copy of RFC822 on her disk, that's what she will follow, because RFC text
>> never changes and does not say "I am obsolete".
> I don't get how that applies.
> Do we think there's a programmer who will start from IANA and
> not notice that there are references to 5322 and 2822? If
> there is such a peculiarly myopic programmer, their code will
> likely be crap anyway won't it?
> Or do we think there's a programmer who'll start from RFC822
> and not think "hey, this thing's 43 years old - I wonder did
> anything happen in the meantime?" ;-)
> And anyway the current facts are that folks will much more
> likely depend on stack overflow, not IANA, so the entire question
> of the best reference is pretty much close to moot.
> IMO the only reason any of this matters is when there's a subtle
> difference between the RFCyyyy and RFCxxxx versions of the same
> registered thing and where there's significantly improved text in
> RFCxxxx. In which case... we don't have a problem - RFCxxxx has
> solved it for us by definition.
> All that's to say that there is no need to, and only a downside
> to, forcing document authors to jump through more useless hoops.
> Cheers,
> S.