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 <barryleiba@computer.org> Tue, 31 May 2016 16:16 UTC

Return-Path: <barryleiba.mailing.lists@gmail.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 4C4BF12D7FB; Tue, 31 May 2016 09:16:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.401
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 4iYLV2LS4v-Q; Tue, 31 May 2016 09:16:27 -0700 (PDT)
Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB5E712D7EC; Tue, 31 May 2016 09:16:25 -0700 (PDT)
Received: by mail-io0-x235.google.com with SMTP id p64so97748262ioi.2; Tue, 31 May 2016 09:16:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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 10.107.140.132 with SMTP id o126mr27627206iod.70.1464711385116; Tue, 31 May 2016 09:16:25 -0700 (PDT)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.107.140.78 with HTTP; Tue, 31 May 2016 09:16:25 -0700 (PDT)
In-Reply-To: <2DDD5AAEE9DBD5FEFD977C01@JcK-HP8200.jck.com>
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com> <082738522924E12368BD0EF9@JcK-HP8200.jck.com> <CALaySJKEbX_c6H9FhRWqR8LuYHsQW5CO7MawiCa7e61fWDeffQ@mail.gmail.com> <2DDD5AAEE9DBD5FEFD977C01@JcK-HP8200.jck.com>
Date: Tue, 31 May 2016 12:16:25 -0400
X-Google-Sender-Auth: yjxtJfUxA0DiJ5Nh-uYLTWWOhKA
Message-ID: <CAC4RtVAfots-C5JVg-vVMeYiXjFHV1P-x+kudHCqScG8j-cJfQ@mail.gmail.com>
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 <barryleiba@computer.org>
To: John C Klensin <john-ietf@jck.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/4u4k1pNtqWfZr393o5GW5qsRT5k>
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: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.

Barry

On Tue, May 31, 2016 at 12:09 PM, John C Klensin <john-ietf@jck.com> wrote:
>
>
> --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
>
>