Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

John C Klensin <john-ietf@jck.com> Tue, 31 May 2016 16:09 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36312B03F; Tue, 31 May 2016 09:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j639F3GrHdEc; Tue, 31 May 2016 09:09:15 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B179512B014; Tue, 31 May 2016 09:09:15 -0700 (PDT)
Received: from [198.252.137.10] (helo=JcK-HP8200.jck.com) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1b7mED-000A8k-H3; Tue, 31 May 2016 12:09:13 -0400
Date: Tue, 31 May 2016 12:09:08 -0400
From: John C Klensin <john-ietf@jck.com>
To: Barry Leiba <barryleiba@computer.org>
Subject: Re: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
Message-ID: <2DDD5AAEE9DBD5FEFD977C01@JcK-HP8200.jck.com>
In-Reply-To: <CALaySJKEbX_c6H9FhRWqR8LuYHsQW5CO7MawiCa7e61fWDeffQ@mail.gmail.com>
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com> <082738522924E12368BD0EF9@JcK-HP8200.jck.com> <CALaySJKEbX_c6H9FhRWqR8LuYHsQW5CO7MawiCa7e61fWDeffQ@mail.gmail.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/svAo8WtBomD5XMoOFLCZWkAZJ5c>
Cc: draft-leiba-cotton-iana-5226bis@ietf.org, IETF discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 May 2016 16:09:17 -0000


--On Tuesday, May 31, 2016 11:08 -0400 Barry Leiba
<barryleiba@computer.org> 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