Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01

Barry Leiba <barryleiba@computer.org> Mon, 14 December 2015 14:25 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9CAC1A1AE1 for <gen-art@ietfa.amsl.com>; Mon, 14 Dec 2015 06:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 MgS2FHtaqJH6 for <gen-art@ietfa.amsl.com>; Mon, 14 Dec 2015 06:25:57 -0800 (PST)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 1D6B31A1ADC for <gen-art@ietf.org>; Mon, 14 Dec 2015 06:25:57 -0800 (PST)
Received: by vkca188 with SMTP id a188so155234776vkc.0 for <gen-art@ietf.org>; Mon, 14 Dec 2015 06:25:56 -0800 (PST)
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:content-type:content-transfer-encoding; bh=6kBJQLqR3AVggRJ7s5VpDrPOxjL49tVoi9WtQeQBZV4=; b=hVyg9w7YQzcc6sc/cBoiXyWvbRZ76FD3AGpaQpxY9ABGNVqoyVxPgbhdBZyl6iVlK0 YaBB9RmKcSVZWSOBMt33+op23p5Q9NdBxUfhmUeclowWCFVq6pCKIVEzXr7HwUVdyYoW iW5TYz8IoRP6cgHbezbrFIMg+/F3sy/BujwXefgME+SoqflE68X8kbpz4R7emBCCN0uZ ZTm0LCpMjiMBGrNP8jWv4ZgN7sPMKNtPW1LU1Wtnkoj3ZKfWUfZ64htgdg7KSgqX9yed YgBceqz7mIj9jU2PFnstcYwOm87AguvYU3OGpkzSDieACRaLXaa8coA0otM3CPRMW22A dyjA==
MIME-Version: 1.0
X-Received: by 10.31.21.212 with SMTP id 203mr7185177vkv.133.1450103156324; Mon, 14 Dec 2015 06:25:56 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.31.182.211 with HTTP; Mon, 14 Dec 2015 06:25:55 -0800 (PST)
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA6BEC64BE@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA6BEC64BE@AZ-FFEXMB04.global.avaya.com>
Date: Mon, 14 Dec 2015 09:25:55 -0500
X-Google-Sender-Auth: ZgjAFPQ48eNoRH6sia2AzXREMlc
Message-ID: <CALaySJ+gQYU5=qqza71HC+7r6LY5qJLLOViD4FWUSX4t85xq0Q@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/VHbvK7TwELQMfbklkspfqLPZ87I>
Cc: General Area Review Team <gen-art@ietf.org>, "draft-leiba-netmod-regpolicy-update.all@tools.ietf.org" <draft-leiba-netmod-regpolicy-update.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART Review of draft-leiba-netmod-regpolicy-update-01
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Dec 2015 14:25:59 -0000

> The problem is that the “IETF Review” policy is not restricted to
> Experimental RFCs which seems to be the motivation of the document.
> Informational RFCs can also be subject to IETF Review for example. The IANA
> Considerations section does either instruct IANA to consider only Standards
> Track and Experimental RFCs. I believe that this needs to be clarified in
> Section 2, and the registry be marked “IETF Review – see [RFC XXXX]” so that
> people asking for allocation be directed to the clarification of the policy.

I believe that no clarification is needed.  There's no reason at all
to put restrictions on registrations beyond what IETF consensus is at
the time the registration is requested.  Should IETF consensus be to
accept a registration from an Informational document, that's fine.
Perhaps it's not likely, but that'd be up to the consensus of the
IETF, which is the point here.

The non-normative text you cite describes what prompted us to do this.
The normative text is the description of IETF Review in BCP 26.

Barry