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 <> Sun, 05 June 2016 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5B85512D5F8 for <>; Sun, 5 Jun 2016 14:10:04 -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 umAbouekUxps for <>; Sun, 5 Jun 2016 14:10:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1BEAF12D5F6 for <>; Sun, 5 Jun 2016 14:10:03 -0700 (PDT)
Received: by with SMTP id h19so124918443ywc.0 for <>; Sun, 05 Jun 2016 14:10:03 -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=Rw5vFkkokq171R4CXTX92BI3KViy5AsjNeANtx7V/Xw=; b=X8eyllN0t9l0EsKFWtwsWa3ASI7I6ddL+rYh6kE0tQyEaGcEU5k9fxcHrvXbI4rEjj 9BrKVMTrtzh2dzMvFfto66h+m/JwjdLX59UkB65GWJlJIwzua1vQZzRWUXPw9cAjx2tv vE5OvB8SYFAsPvwDj9Sc21O9HTuSB4ln4R7E/PvyUh6LYg9/c0D/QV8/0eJIe60Cgk2t 24WhUhA7LHhqPzs7Z+cIgtm9h5dheJwPrxR9fIVI0nUfbV4Otw9lpA/iOftp00Pm18Jk D3ABmAzkHWCTYxRhNSB2lNmqjRKktI6KeciONtnN4MIXFxxDfkR5i6WScSCEV/EvnR6h R0GQ==
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=Rw5vFkkokq171R4CXTX92BI3KViy5AsjNeANtx7V/Xw=; b=YvPu0AGqNSLrSD1uob09OlXGiDA6Cgb7n+sVhnDT6fmAiuA6UMaMhJe4Ely9Gsji8a D0OAUwCkkN1TmsVWraeDHLGW0hcbXgHn3hLaRsul0Ugj1XonGR4Sj0ej33V8aNOCIO0x D1qJ+o78dwv4G1V7on7dR1w6iy5BPKtudSarakofwoLS4S3VNzhKnJVYVp3RpCPsuvJq ZSjqHRYROFh343Ilxl9LXikUHUTAaukspDWE+ACXroN+g39GEzTq4vuedBL1GmZabMDk X/xmCu2DevJB7nsjtB0Kklc7KRl594eKhQ1er4ssT0SWcfsbaZvoRbhSQ9O3P2L2yxOK ZLXg==
X-Gm-Message-State: ALyK8tJmkDkru+f9uNwT8JQncXVRTJ/Aj4z7hjrRn7Z8O4O0G1uE5oadvfbRmwHqc/2JblMZ0SN1zbfbsHIaJA==
X-Received: by with SMTP id w140mr8815927ybb.129.1465161002229; Sun, 05 Jun 2016 14:10:02 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 5 Jun 2016 14:10:01 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Barry Leiba <>
Date: Sun, 5 Jun 2016 17:10:01 -0400
X-Google-Sender-Auth: DJk6gGZ93SilFtHAg_Mv2CtPhec
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: Joe Touch <>
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: Sun, 05 Jun 2016 21:10:04 -0000

> 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

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