Re: [Ianaplan] A draft for your review

Eliot Lear <lear@cisco.com> Mon, 01 September 2014 16:31 UTC

Return-Path: <lear@cisco.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410B51A03AC for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 09:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Level:
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 ppge-TthEw38 for <ianaplan@ietfa.amsl.com>; Mon, 1 Sep 2014 09:31:30 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAB8F1A035E for <ianaplan@ietf.org>; Mon, 1 Sep 2014 09:31:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2979; q=dns/txt; s=iport; t=1409589089; x=1410798689; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=PWT8Kfj3uhfsOgbWSv80Ob6FWGZOmLfdNoOdFbdwH1w=; b=Q8vCHt2fbb+a6GLNpzfgGSAtmUibnOiskYd7jdHpzq3XqCHUY9MEbJJw rF+82N8CxZiqiFdwz4453oBjeMkQCJQfCXs+UWHiTAcbv8kxr8Jth2rn4 64tp8mdY4ttZ6IiG93vQzeeBQk+xExweTuVlJX9aVqwSz7taR58ayLj2N 4=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqIEAKyeBFStJssW/2dsb2JhbABZhzPMVgGBK3eEAwEBAQMBI1YQCw4KCSECAg8CRgYBDAEHAQGINgilD5RbARePTQeCeYFTAQSTN4FKh1uHN41ng2M7gn4BAQE
X-IronPort-AV: E=Sophos;i="5.04,443,1406592000"; d="asc'?scan'208";a="161401461"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 01 Sep 2014 16:31:26 +0000
Received: from [10.61.212.165] ([10.61.212.165]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s81GVQrY015450; Mon, 1 Sep 2014 16:31:26 GMT
Message-ID: <54049F66.90403@cisco.com>
Date: Mon, 01 Sep 2014 18:31:34 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Eric Burger <eburger@standardstrack.com>, S Moonesamy <sm+ietf@elandsys.com>
References: <54017E09.8060504@cisco.com> <6.2.5.6.2.20140830052032.0c96c880@resistor.net> <E8F176B3-3531-458A-A566-A50EC31CAC16@standardstrack.com> <6.2.5.6.2.20140831175817.0bf0b6d0@resistor.net> <9144DC84-2153-470D-B733-D5522B977EE4@standardstrack.com>
In-Reply-To: <9144DC84-2153-470D-B733-D5522B977EE4@standardstrack.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="Ptd4XJrH788Q082etsslnedNV9734qOFJ"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/GNQiINKsRyihu9S3x4jWQWhAN7w
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] A draft for your review
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Sep 2014 16:31:32 -0000

Hi Eric & SM,

On 9/1/14, 6:14 PM, Eric Burger wrote:
> I agree with you here: the use of the term IANA protocol parameter
> registry is sloppy. Let’s go with: Many IETF protocols make use of
> commonly defined protocol parameters. Implementers use these
> parameters. Implementers are the IETF's primary users of the IETF
> standards and other documents. A globally available registry contains
> the parameter values and a pointer to documentation of the associated
> semantic intent. This registry, the IETF Protocol Parameters Registry,
> provides this service to ensure consistent interpretation of these
> parameter values by independent implementations. Historically, the
> Internet Assigned Numbers Authority has, under contract, operated the
> IETF Protocol Parameters Registry.

There is a particular facet I think we want to make clear: there may
come a time when we need another distributed registry.  It's not that
hard to imagine.  If so, we will need to look at existing structures,
and assign/delegate accordingly.  Names and unicast IP addresses are
examples of protocol registries that have been assigned to other
organizations.

[...]

>> As a general comment, there is the following under "required proposal elements":  "associated references to source documents of specific policies/practices".  A plausible response would be one which could be substantiated with references.  Otherwise (in my opinion), it will look like the IETF is not comfortable with what it has written.
> On the one hand, we have a lot of references to IETF documents. On the other hand, if a casual reader thinks we do not have enough references, we can have more.
>

I may have already lost the plot on this one, but as Eric writes, the
document is sprinkled with references, and there is then a specific
question about references.  I could aggregate all the references into
that question, but the reason the references are where they are is so
that people can spot relevance.

Eliot