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 <> Tue, 31 May 2016 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55E3012D600; Tue, 31 May 2016 08:08:42 -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 xyIfj1Tyg0Dv; Tue, 31 May 2016 08:08:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3B0A912D5D2; Tue, 31 May 2016 08:08:39 -0700 (PDT)
Received: by with SMTP id c127so191270009ywb.1; Tue, 31 May 2016 08:08:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=Hz00E6Zt/y9eVK/+0peAMqckftB+e3Soq6b0LHhaCiE=; b=KxolDNXzSTP1OFe0qsZeozQLT/dJdRacZ0q26cRSgyrXppA8l7aa5qtWDeJGF0P/+6 /iNbylGOQv/CaGn8kxzzDHl1q/qaQItG29ZZ0IpD38sERq2thrC7d/h4Vc5eAckhgew9 mlOFtwRZ3+dMh7Eyrv8VOEFudKUg/f6mJMJRQSN60QycOHN96voP8diLgaqedo250OqM 1SqxWbsJ047XbftVlMvEKeSnXU+8X36ApRPyfg2TMMAFhz6mTzuLNpS2FD2JLr8Kk9ZE axLxoE30Oi0NPrbTVUSAp49sUKGELozc4ijyE4ydtfLOCxP8JCnF6vsJb58Iw+YlOS0w yzgg==
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:date :message-id:subject:from:to:cc; bh=Hz00E6Zt/y9eVK/+0peAMqckftB+e3Soq6b0LHhaCiE=; b=UhFmeX3V52r2LJxPFwWVo6gRm1Wg4S3Fhs5YbaaXF62N3QKaMZsbpvnZ1fmkuWBrxg 8fTohJReIHkEnCrTEPfg8jPfDpTwuhTEKQE72kpl/LYibjMsUToSiHFOwJRzoy21avwX zEa+AJGZ75Ai6NyT8PClELVmLKAA9ojpuq0X8HpfujYY0JeuiqIxBBARWafZitCoZS2B Y9u3GGYI3b0yD+ewKzF62XF6Z+lU5Csd3yr6dPzYPKcI6wKu6Pdj6rWYW9tC9O+Mo7vP gQlvClpfUgXktma1/08Opq7irtJX8LLzeMdy+5Db2Zxf6gT527Fn6nY+wxzu3vXufM6t 9TAw==
X-Gm-Message-State: ALyK8tJxCsGsAdpyEz+3zFkm3iAtlUNUQ+ao2A7tNvmCaNTwTY8/KYu8muRwmP5SVe/N9gkOo2cyXdifWE7g4A==
MIME-Version: 1.0
X-Received: by with SMTP id k65mr6832164ybf.134.1464707318365; Tue, 31 May 2016 08:08:38 -0700 (PDT)
Received: by with HTTP; Tue, 31 May 2016 08:08:38 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 31 May 2016 11:08:38 -0400
X-Google-Sender-Auth: iYmm7KBFVB9bUCG-RUYZIc5sins
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
From: Barry Leiba <>
To: John C Klensin <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:, IETF discussion list <>, IETF-Announce <>
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: Tue, 31 May 2016 15:08:42 -0000

Hi, John.  Thanks for the review, and no worries that it's "late"; I'd
rather get this right.

I thought that what you're asking for is covered by very strongly
pressing for instructions/guidance to the designated expert(s), and
I'm very happy to expand that text to be more clear about some of the
variations that guidance might take.  I'd much prefer that to any
attempt at multiple versions of expert review, because I think that
any number of those we come up will will engender others that other
people will think of, and there'll be too many.

Rather, if we talk more about the things to consider in guiding the
DE, I think we'll be in a better place.  If you give me your opinion
on whether you think that's a good path and could resolve your
concern, I'll work on text to try out.


On Tue, May 31, 2016 at 10:19 AM, John C Klensin <> wrote:
> Apologies for this coming in at the last minute, but the volume
> level on the IETF list about unrelated issues (mostly the IETF
> 100 issues) and some other priority topics have prevented me
> (and possibly others) to give this document the attention it
> deserves or noticing that the nominal cutoff had come and gone.
> I note the Gen-Art review showed up after 17 May, so probably
> others are suffering from the same problem.
> This is an old and much-reviewed document.  It has undergone
> significant refinement with each iteration.   I think many of us
> who have been too busy to do active reviews in this round have
> proceeded on the assumption that issues raised in prior
> reviews/Last Calls have been addressed.
> Unfortunately, based on very quick skimming, at least one
> important one -- IIR discussed at some length earlier -- has not
> been reflected (at least in -13).  I have no idea whether that
> reflects a more general problem.  The issue is the possibility
> of a  13th well-known policy, especially in combination with the
> "not strictly required... strongly recommended ... not without
> good reason and explanation" language.  The latter is only a
> half-step away from a rigid "have to pick one of these" policy,
> with that step historically taking the form of a single AD
> saying "you haven't proven that none of these options will work
> to my satisfaction" and then insisting on it.  Because we've got
> counterexamples, that is a bad way to set standards.
> The specific cases I have in mind involve expert review and
> parameters that have a way of becoming controversial, in part
> because having two values that are really approximations of the
> same thing can be (for those parameters) confusing and
> destructive or when the role of the expert is really to advise
> on getting the right information into the registrations rather
> than deciding whether a registration is acceptable or not.  For
> either of those situations, a single designated expert-Tsar may
> not be appropriate.  If the person is hyper-responsible and
> extremely knowledgeable, the stress and blame levels are likely
> to get too high.  If not, well, appeals are an undesirable way
> to resolve registration disputes, not only because of the time
> and resources they take but because some (many?) registrants are
> likely to decide that code point squatting is a better model
> than working through the IETF process.
> Recommendation: Either create another option that recognizes the
> many flavors of expert review, including the possibility of
> teams who are required to reach at least rough consensus or
> soften the "use these unless you can prove otherwise" language
> cited above to make it clear that there are likely to be
> variations on a few of these approaches, notably Expert Review,
> that, if well-documented and reasonably well-justified, are
> still considered within the scope of that category and
> conforming/ consistent with the document and its recommendations.
> Again, essentially these same comments have been made in Last
> Calls on earlier versions of this document and are hence part of
> the record the IESG should be considering.
> Again, sorry to be flagging this, and reminding people of the
> earlier discussions, at such a late date.
>     best,
>     john
> --On Tuesday, April 19, 2016 07:16 -0700 The IESG
> <> wrote:
>> The IESG has received a request from an individual submitter
>> to consider the following document:
>> - 'Guidelines for Writing an IANA Considerations Section in
>> RFCs'   <draft-leiba-cotton-iana-5226bis-12.txt> as Best
>> Current Practice
>> The IESG plans to make a decision in the next few weeks, and
>> solicits final comments on this action. Please send
>> substantive comments to the mailing lists by
>> 2016-05-17.