Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis

Barry Leiba <barryleiba@computer.org> Thu, 23 October 2014 14:17 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47EEE1A9144; Thu, 23 Oct 2014 07:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 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, HTML_MESSAGE=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 qKhlH2RI8siP; Thu, 23 Oct 2014 07:17:38 -0700 (PDT)
Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FEF11A9143; Thu, 23 Oct 2014 07:17:37 -0700 (PDT)
Received: by mail-lb0-f170.google.com with SMTP id u10so1154220lbd.1 for <multiple recipients>; Thu, 23 Oct 2014 07:17:35 -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:content-type; bh=MVfk9EjGgcCjM9LREidPni84vWzS7NgvnlnyWtiO8b8=; b=f74cNFlY0tzIT0lRZNcrKXoxQUW+JjmFphBt0S5xbUSyTlEBZwaiICyD1IqRH7jz5k KGEQrDxw0o3tUYUMQmWS0kYu4oPQHwr71urirDlzwdppVLnahMJHSTJKdk8X5KVlX81p aTs1Z3b4lFowiyfx7yEcBX8f6QWh0n4mGBioc8bZXVn05BrC6V2506VOD+5YDzSJYOnD z1dsflT6jh8tBgGkahKRxC5NOtAE4DUtGP5v3l56N7lEO+97pwRynXlS1qtyWatf7isg iKbDgkl1fAI2+3Qs00VkpzI8HPaqhHU/0PVODuZjFs/vjR29n+3lEZfEjVLquTjFligq 8dpA==
MIME-Version: 1.0
X-Received: by 10.152.4.132 with SMTP id k4mr5441954lak.1.1414073855443; Thu, 23 Oct 2014 07:17:35 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.152.8.103 with HTTP; Thu, 23 Oct 2014 07:17:35 -0700 (PDT)
In-Reply-To: <052301cfeeca$a8914190$f9b3c4b0$@gmail.com>
References: <051b01cfeec7$c5339b70$4f9ad250$@gmail.com> <CALaySJLpKaaZUUD0DVKpi1ox_JiVOL3HROJ5wOfE_jkwshzvdA@mail.gmail.com> <052301cfeeca$a8914190$f9b3c4b0$@gmail.com>
Date: Thu, 23 Oct 2014 10:17:35 -0400
X-Google-Sender-Auth: JTaM74I-Zc6PzLZssxW3VvwgkyE
Message-ID: <CALaySJJCg6BABDMXnu=eWD3j6haHR5qZb3-UxLSh090apnC5pw@mail.gmail.com>
Subject: Re: Gen-ART LC review of draft-leiba-cotton-iana-5226bis
From: Barry Leiba <barryleiba@computer.org>
To: Roni Even <ron.even.tlv@gmail.com>
Content-Type: multipart/alternative; boundary="089e013d1b5ed708f8050617b917"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/NUZjSCGMasN6OlmvN2SnBO7oWKM
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-leiba-cotton-iana-5226bis.all@tools.ietf.org" <draft-leiba-cotton-iana-5226bis.all@tools.ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Thu, 23 Oct 2014 14:17:39 -0000

>
> I think that this is a point that should be made for anyone that needs to
> specify the registration policy. My feeling is that when the document is
> develop the focus is on the specified registry without looking at similar
> ones. Maybe the document should suggest that the IESG or document shepherd
> will try to verify that consistency was checked.
>
>
I'm very wary of suggesting that people copy registration policies from one
registry to another.  Mindless consistency between related registries in
specifically a non-goal here: the important point is that the policy for
each registry should be selected with though, and should apply to the needs
of *that* registry, even if that makes related registries differ.  I think
the document is clear about that.

We get ourselves in trouble when a batch of registries are all given the
same policy, and that policy turns out to be right for some and wrong for
others.

Barry