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 <> Fri, 03 June 2016 21:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A5B1B12D9D1 for <>; Fri, 3 Jun 2016 14:13:55 -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 qIUYJDFFs7cv for <>; Fri, 3 Jun 2016 14:13:54 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7A7712D9CE for <>; Fri, 3 Jun 2016 14:13:53 -0700 (PDT)
Received: by with SMTP id t40so90135461ioi.0 for <>; Fri, 03 Jun 2016 14:13:53 -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=Fa6wCKAQyWFIJVmfvrwyFen4RSf0io9kxhuZfINfv6M=; b=M/EIqZxzmzTbNUFTa8UDnOsAEgdFfQ0uyqRq0Y5TDz2mSbdQ9tRPYDNbr05xw2xR6D GXi2qH///Rj3aZ2F8I/5ZQwUmepfZSRqiJGL2V8V86RP/3uV8PH8s3ciAuC5RxmCRPb5 v7TMqia8NoYMkh0OS5wIpiyAf4kKDFZUfYImX3CvyGgbzigLfIgloEdAGnRKBHc33pwZ dsN4U3jtLp0R1UN8BpjRgUcO3zuIdzUwcc3aIZxVg74ZTtr6xUQxE+fa1AwpNs98L7EH fM7qUQBNUaoSKwR+7bUX0TSHK++88mY3IqOH1bzuekutFeyFLghXd0Zjr9Ek+7xzkt+S pR0A==
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=Fa6wCKAQyWFIJVmfvrwyFen4RSf0io9kxhuZfINfv6M=; b=kSZ/sEqhfKRkx/+dtFpthltKU8KnHSEPlsRkvx60KHlwzlcs7RXaOK3IT7yo5JeKc6 5L5CiLyMEBfS2ClGNgwFVb5GWaaIlXHFLD47l9Y4kw0NHl381OG7zyJa1ie9bCYPajzE k2B1REmjwyu6WiLpl03Sbai//7IRB9qYIu5KEvqXm5G5RGIsjJd3pDcb9TaA5r1pBbHb 1PhkagUWmYsZb2FYzUP0vrqBWgZ5i2Wr3yyNp4ZbUBJ7mXEP7rDaEMzWtDCxPohbgZit 8lJaWjdpgLcIFaWsc7HuKLRhGtl5KwU9GZcaMR8XCgg/U4mdMGWtGpQYA2tlfAHPGE1g oVqA==
X-Gm-Message-State: ALyK8tK6/xx7ESMVZpBpzesGgHrmVYjzh2GWG/41aOqcrrpRTyP75Tgw+B7Un2Ve3EdsHVyKflltHvwlN69N1g==
X-Received: by with SMTP id o126mr8426872iod.70.1464988433194; Fri, 03 Jun 2016 14:13:53 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Fri, 3 Jun 2016 14:13:52 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Barry Leiba <>
Date: Fri, 3 Jun 2016 17:13:52 -0400
X-Google-Sender-Auth: Xm0R0Vbka3x6EhjXAY4tfnJYYwU
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: Fri, 03 Jun 2016 21:13:55 -0000

> Otherwise, IMO, this doc should basically say "IANA pointers should be
> updated as deemed useful". In some cases, there's a benefit, but not in
> all cases. E.g., we have docs that obsolete protocols but IANA still
> keeps a pointer to the codepoint. I don't want the new pointer to be to
> the doc that obsoletes them; I would want the pointer to be to the
> original spec.

Of course, yes, and I think the doc does say that: the pointer should
be to the most current definition, and the sentences in question here
do talk about registries and entries that are in current use.  I, too,
would be dismayed if we started pointing references away from the
definition of the code point and toward something that says, "This
isn't used any more."

> I'd prefer to trust the author to do the right thing that to engineer
> this document with an algorithm.

I agree, though we have ample evidence that authors don't always.
This is aiming to give guidance, not to provide any mechanical "do
this and it'll work" algorithm.