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 16:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C4BF12D7FB; Tue, 31 May 2016 09:16:29 -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 4iYLV2LS4v-Q; Tue, 31 May 2016 09:16:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB5E712D7EC; Tue, 31 May 2016 09:16:25 -0700 (PDT)
Received: by with SMTP id p64so97748262ioi.2; Tue, 31 May 2016 09:16:25 -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=ZguYuTrSKQCy07XA01iZrOGfkfiwiuwQXR08nzXglhY=; b=0C7qHek41eLwD7l8Y1Os2ug7IK+46dnUhcXBFa2l4jnGp7JmcCGY8ismUzO4EK0yak wOnaI9crXq3UJpdL39WhBIZ+9QqMXOlNSjBdjrNGXly3fIJDix85DgxLax4hZnoF6Wft 60g2tF2j03Wb2BhFGxTWGAMbYKGIf1kqVYFBqkJGSofYqmKolo6+UCykjp9bITiuLN1W kOxopQBhIx2sULnQYbLkZOs6HDctrUWJ2nEM7+HdM6oIUAsTJg4xP7lvfK2hX8ewQugT 9kYmcPg/qUPOdt0nIAbCbGcfTKtpzCAFLw2gs+0CKIWkX2mVilv26SPCT4qvuOFrFKxi nVCw==
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=ZguYuTrSKQCy07XA01iZrOGfkfiwiuwQXR08nzXglhY=; b=AlclqiPJ4xSNf6hFj/W5bnHEeUfkNruqKQn+4pCNhcoLO+Kokq3ixLyamokxr3gzQr Ccz0APDouGyxWuLXXq6+CjlI3Pu/IJbbdnE0KPY9f7IoMD8eT06tzBiOPpX7mMhUNOFj e3C7TmzUr9zu76mFi9IT+PFGpcoaBIPnkeXtAUIYiTRFJQW//0NlLtYBZ7kOaNyUZLMr rcLDYsYLiGhDtJud+6SQrs6zHuSG3y2jvUG3JnDcxD7XtWS79MQiiN+LKZcsinAz2j6h P6gcppRbvdutdTCiXSXcdoEl/ohjqrXjvI29luHLOCWmSibskwAs6BQKHOy2ErKhR4+m IqQg==
X-Gm-Message-State: ALyK8tKqQF8rOIXoRbqUZsGlO4eyuiefOo18Icq2dc7WTXIWbJtdTp5EMo7rehIXIhwTHkMVrT7YrUYXDsBjuA==
MIME-Version: 1.0
X-Received: by with SMTP id o126mr27627206iod.70.1464711385116; Tue, 31 May 2016 09:16:25 -0700 (PDT)
Received: by with HTTP; Tue, 31 May 2016 09:16:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 31 May 2016 12:16:25 -0400
X-Google-Sender-Auth: yjxtJfUxA0DiJ5Nh-uYLTWWOhKA
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 <>
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 16:16:29 -0000

> I'm happy to try to study -14 and suggest text, but it won't be
> today.

Well, let me take a first pass at that.  I know what I'd like to say
about expert reviewer guidance, and I don't object to softening the
"you really ought to use these" language a little -- I think I can do
that while still maintaining what we already have rough consensus on.

Look for a -15, probably after Thursday's telechat.


On Tue, May 31, 2016 at 12:09 PM, John C Klensin <> wrote:
> --On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba
> <> wrote:
>> Hi, John.  Thanks for the review, and no worries that it's
>> "late"; I'd rather get this right.
> Thanks.
>> 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.
> I had thought about another category, perhaps Expert Review Type
> 1 and Expert Review Type 2 for two reasons.  One is that "expert
> decides" is really different from "expert process advises in
> getting an adequate specification together, but the final
> decision to register lies with the applicant.  That is a little
> like Expert Review, a little like Specification Required, but,
> because the expert does not have the final word, is a bit like
> FCFS as well.  Your section 4.12 covers alternative options
> reasonably well (I'm trying to be careful about not letting a
> desire for perfection block progress here) but not mixtures of
> them.
> The second is that I, and I know at least some others, have a
> far too large collection of scars from situations in which a BCP
> was issued on a "this is often helpful and you should do it
> unless you have a reason to do something else and are clear what
> you are doing" basis and then turned, a few years later, into a
> rigid requirement that was inescapable in the absence of very
> strong IETF consensus determined after an energy-sapping battle.
> Prior versions of "Writing IANA Considerations..." and RFC 2119
> have been the most obvious sets of guidelines treated that way,
> but there have certainly been others.
> Doing whatever is needed with better guidance to the Experts may
> solve the first problem (but only if it can be made clear that
> it is ok for WGs (or equivalent) to specify situations in which
> the experts get to advise and persuade to the best of their
> ability but have no (or extremely narrow) authority to reject
> anything) but probably does not address the second, especially
> in the presence of the very strong guidance about using one of
> the listed methods I cited in my earlier note.
> I'm happy to try to study -14 and suggest text, but it won't be
> today.
> best,
>     john