Re: [Ianaplan] I-D Action: draft-lear-iana-icg-response-00.txt

Eliot Lear <lear@cisco.com> Thu, 11 September 2014 14:03 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 5B1DB1A0023 for <ianaplan@ietfa.amsl.com>; Thu, 11 Sep 2014 07:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.153
X-Spam-Level:
X-Spam-Status: No, score=-16.153 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=-1.652, 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 HokPzFVCTLEJ for <ianaplan@ietfa.amsl.com>; Thu, 11 Sep 2014 07:03:56 -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 14F1D1A6F58 for <ianaplan@ietf.org>; Thu, 11 Sep 2014 07:03:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4380; q=dns/txt; s=iport; t=1410444227; x=1411653827; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=u1BdFJa7O2pZ2GbtleHXoh0kklCO0VnSNlDxMqrlo5Y=; b=V7DLMpiW8payl6NTuqSbmohZp1SgVycxWPPPEHVuzT/UbUFRAAFFj/Gm Crm665mxfERz0LctPaBeA63z7KLSQCWMF1mR4zNcPTtXJSRJzVAfEf7R/ RILLcIj5MitNoeKnAZ1a3psFWn9FiLaX5KuFI/LkXc/QG5juobxxQeAEV w=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApAFAD6rEVStJssW/2dsb2JhbABfg2BXAYJ7xU6HSQGBJniEAwEBAQMBHQZPBgEQCxgJFgsCAgkDAgECAUUGDQEHAQEFC4gmCA2pJpU5ARePTQeCeYFTAQSPM4QcgUqHY4dDjXaDYzsvAYJOAQEB
X-IronPort-AV: E=Sophos;i="5.04,506,1406592000"; d="asc'?scan'208";a="173647327"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 11 Sep 2014 14:03:45 +0000
Received: from [10.61.214.144] ([10.61.214.144]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8BE3jJd032703; Thu, 11 Sep 2014 14:03:45 GMT
Message-ID: <5411ABC0.8010506@cisco.com>
Date: Thu, 11 Sep 2014 16:03:44 +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: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <20140830063916.1613.19503.idtracker@ietfa.amsl.com> <540CC133.8070105@gmail.com> <54104F40.90308@cisco.com> <5410CF00.5000506@gmail.com>
In-Reply-To: <5410CF00.5000506@gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="2MPthJKio9VSq1BadiVCCrDxjBLSDUIpR"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/frvdAKIGsv45N14eBxBcMyUmFbs
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] I-D Action: draft-lear-iana-icg-response-00.txt
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: Thu, 11 Sep 2014 14:03:59 -0000

Hi Brian,

On 9/11/14, 12:21 AM, Brian E Carpenter wrote:
> Thanks Eliot. I have trimmed what follows to points where
> something still seems to be open; otherwise I'm happy with your
> responses.

>
> Yes. I was confused. I do think that coordination with the ASO needs to be
> mentioned with regard to special purpose addresses.

Ok.  I think I agree because it is possible that the IETF might for some
reason need to mark previously allocated unicast address space as
special purpose addressing, based on whatever circumstances develop. 
This has in effect happened previously, and so it is worth
mentioning.    Therefore, I propose the following text:

       The IETF has established registries with IANA for special
        IPv4 and IPv6 assignments.  These are specified
        in [RFC6890].  The IETF    coordinates such
        assignments with the RIRs.
       
> ...
>>>>    A.  Policy Sources
>>> ...
>>>>    o  Which IANA service or activity (identified in Section I) is
>>>>       affected.
>>>>
>>>>    IETF Respponse: The protocol parameters registry.
>>> Add: This includes technical reservations in the IP address registry
>>> and the domain name registry as noted above.
>> This issue requires more input, in my opinion.
> Yes, it's a delicate point of phrasing but I think the point
> needs to be made somehow. To be specific, I am referring to
> at least the following:
>
> http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1
> http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml#iana-ipv6-special-registry-1
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml#special-use-domain

I think this is now covered above.
>
>>>>    The IAB provides oversight of the protocol parameter registries of
>>>>    the IETF, and is responsible for selecting appropriate operator(s)
>>>>    and related per-registry arrangements.  Especially when relationships
>>>>    among protocols call for it, many registries are operated by, or in
>>>>    conjunction with, other bodies.  Unless the IAB or IETF has concluded
>>>>    that special treatment is needed, the operator for registries is
>>>>    currently ICANN.
>>> Add:
>>>
>>> Day to day responsibility for declaring IETF consensus on technical decisions,
>>> including those that affect IANA, lies with the IESG. The IESG members are
>>> also appointed by the NOMCOM process described above.
>> The question is who provides oversight and accountability.  That is not
>> a function for the IESG, but for the IAB.  I have no problem including
>> this text elsewhere, if you can tell me where that "elsewhere" should be ;-)
> Well, I would include the IESG in "oversight" because they are the first
> point of appeal after the WG chair. So I think we disagree on where
> this fits.
>
> That said, it could be fitted into the response to
>       o A description of the customer(s) of the service or activity.
>        [N.B. the IETF response has swapped this question with the next.]
> where you mention the IESG.

I've accordingly amended the text in that section.
>
> Nit alert: I just noticed that you have "the Internet Engineering Steering
> Community", which is an amusing concept ;-).
>

Thanks.

Eliot