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

"Ben Campbell" <> Sat, 04 June 2016 22:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5EAEB12D0BB for <>; Sat, 4 Jun 2016 15:59:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.325
X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Bhi1148iY9eW for <>; Sat, 4 Jun 2016 15:59:28 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C135712D694 for <>; Sat, 4 Jun 2016 15:59:28 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u54MxLKT091220 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 4 Jun 2016 17:59:21 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: "Ben Campbell" <>
To: "Barry Leiba" <>
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: Sat, 04 Jun 2016 17:59:21 -0500
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_MailMate_E0CCEA18-BC98-46FD-B428-9BA6C9339DA9_="
X-Mailer: MailMate (1.9.4r5234)
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 22:59:32 -0000

On 4 Jun 2016, at 13:42, 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.

I have to agree with Barry on this one.

RFCs and IANA registries are for the _readers_, not the authors. I don't 
understand the objection to asking the author to do a little more work, 
to save work for the reader.  Typically there are many more readers than 
authors (one hopes). And readers commonly don't pay attention to all 
that "updated by" and "obsoleted by" stuff at the top of the RFC. In 
general, it's in the best interest of readers for IANA to point to the 
most up-to-date specification for a code point.

I'm okay if that guidance is not strict, that is along the lines of  
"it's a good idea..."  or "It is helpful to readers if..."

If people think that readers don't use the registries to find the specs, 
that opens up much bigger questions about required author hoop-jumping.


> Barry
> 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.