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 <> Mon, 06 June 2016 20:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0DFF12D18A for <>; Mon, 6 Jun 2016 13:01:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tESkc0vwbfBc for <>; Mon, 6 Jun 2016 13:01:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A70712D1A5 for <>; Mon, 6 Jun 2016 13:01:18 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u56K0h3L008503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 6 Jun 2016 13:00:43 -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 <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Joe Touch <>
Message-ID: <>
Date: Mon, 6 Jun 2016 13:00:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
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: Mon, 06 Jun 2016 20:01:20 -0000

Fair enough. As long as there's enough wiggle room and it's the party
assigned the codepoint and updating the spec that has the responsibility
to work things out, I'm fine with it.

Please let's not dump this on IANA though. They (we) have enough on
their (our) plate.


On 6/5/2016 2:10 PM, Barry Leiba wrote:
>> 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.
> Barry