Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01

Eliot Lear <lear@cisco.com> Sat, 25 October 2014 06:35 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 7EE7A1A710D for <ianaplan@ietfa.amsl.com>; Fri, 24 Oct 2014 23:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 vZl0V0XP1H4Z for <ianaplan@ietfa.amsl.com>; Fri, 24 Oct 2014 23:35:38 -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 041011A7034 for <ianaplan@ietf.org>; Fri, 24 Oct 2014 23:35:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25126; q=dns/txt; s=iport; t=1414218938; x=1415428538; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=Ensyfvx1y31Hug3K1fRrWoZHWEpr5jkR80yfjIlDREg=; b=bIhwe+x/lNBVaZXnk55qtTK5SRMNxgRBEtvGWzvgT6fcWE04jjggCZpY DUHQim4INzmK5q1FbLVthOa4zBgwNfCPFbheJtXP28E9xqblBUnT3wkO1 EEVe04xCPe3/fjNUR3AJ+t7BxlrK5ZdTsFao9Fxjvwfm9jveMPC1drPDT E=;
X-Files: signature.asc : 486
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwEAOxDS1StJssW/2dsb2JhbABcg2JYgwbKOIdLAoEeAX2EAgEBAQMBI1UGCwkCGAkWCwICCQMCAQIBRQYBCQMIAQEQC4gZCQ2YDpxflHABAQEBAQUBAQEBAQEBARqQX4J3gVQBBI9nhCyBUGiHEoExPIMNgnKKQIQAg3o7L4JLAQEB
X-IronPort-AV: E=Sophos;i="5.04,785,1406592000"; d="asc'?scan'208,217";a="223533594"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 25 Oct 2014 06:35:35 +0000
Received: from [10.61.108.74] (dhcp-10-61-108-74.cisco.com [10.61.108.74]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s9P6ZYVm008645; Sat, 25 Oct 2014 06:35:34 GMT
Message-ID: <544B44BD.7030805@cisco.com>
Date: Sat, 25 Oct 2014 08:35:41 +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: Alissa Cooper <alissa@cooperw.in>, ianaplan@ietf.org
References: <E74C02CC-8A35-4057-95E4-14925B332456@cooperw.in>
In-Reply-To: <E74C02CC-8A35-4057-95E4-14925B332456@cooperw.in>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="LLlK3A7NAFALKLxIqULHrvPUXagXKNNk7"
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/rTgewAX9n60-zO42ThMhxuYBLQQ
Subject: Re: [Ianaplan] Review of draft-ietf-ianaplan-icg-response-01
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: Sat, 25 Oct 2014 06:35:43 -0000

Hi Alissa,

Thanks for your thorough review.  Please see below regarding proposed
disposition of your comments.


On 10/25/14, 1:35 AM, Alissa Cooper wrote:
> All,
>
> I’ve reviewed draft-ietf-ianaplan-icg-response-01 and my review
> comments are below. Many thanks to Eliot and others for your work on this.
>
> Alissa
>
>
> === Substantive comments ===
>
> == Response to Section I:
>
> "The IETF uses the IANA protocol parameter registries to implement
> such registries.”
>
> I don’t understand what the above sentence means.

Yes, I caught this as well.  My proposal is as follows:

>        The IETF uses the IANA
>         protocol parameter registries to store this information  in a
>         public location.

>
> =
>
> "The IANA protocol parameter registry operator maintains the protocol
>    parameters registry for the IETF in accordance with all relevant IETF
>    policies, in accordance with the Memorandum of Understanding"
>
> This is the first place where the MoU is mentioned, and it is simply
> called the MoU, which may not be descriptive enough. I would suggest 
>
> s/the Memorandum of Understanding/a Memorandum of Understanding
> established between the IETF and ICANN/
>
> and adding a citation to the MoU.

Propose to change as suggested above unless there are objections.

>
> =
>
> "The protocol parameter registries are the product of IETF work.”
>
> This seems like an under-specified answer. For example, the IP address
> space registries could certainly be considered to be the product of
> IETF work. But I did not think it was the intent to cover them in this
> transition plan document. I apologize if there has been discussion of
> this on the list that I missed, but I feel like the answer to this
> question is specifically our opportunity to explain exactly what is
> covered by this particular transition plan, and “the product of IETF
> work” is a rather vague answer.

That is covered in the earlier text to which you suggested an edit, and
we are attempting to be concise.  The clear point we wish to bring
forth, and this has been discussed, is that the protocol parameter
registries are really an integral part of IETF standards.

>
> =
>
> "We will continue to coordinate with ICANN regarding those changes."
>
> In all of the bullets listed in this part of the response, I’m curious
> if we really mean “IANA functions operator” where we are presently
> using “ICANN."

In this case, the GNSO, ccNSO, SSAC, and perhaps the ICANN board all may
have an interest.  In fact we have a liaison manager who sits on the
board for technical advice.

>
> =
>
> Why is the recently implemented audit not mentioned in response to the
> question about a description of the oversight mechanism?

Happy to include, and would invite proposed text.

>
>
> == Response to Section II:
>
> "IETF Response: all policy sources relating to the protocol
> parameters registry have been specified in II.A."
>
> This is not really answering the question posed in the RFP. The
> question in the RFP is whether there are some policy sources described
> in answering Section II.A that are not covered by the oversight
> mechanisms to be described in response to Section II.B. I would suggest:
>
> “IETF Response: All policy sources relating to the protocol parameters
> registries are affected.”

I have no objection to the change.
>
>
> == Response to Section III:
>
> "To address a desire by some members of the IETF community to have
>    mechanisms that allow for additional dispute resolution between the
>    IETF and the current IANA protocol registries operator, the IAOC is
>    asked to conclude a supplemental agreement regarding jurisdiction and
>    any necessary dispute resolution mechanisms that are mutually
>    acceptable to the parties."
>
> First, I think the bit about “some members of the community” is
> unnecessary. This document with either have rough consensus or it
> won’t. Second, I think the asks to the IAOC should all follow the same
> standard, which is articulated in the prior paragraph — engaging the
> relevant parties to make [fill-in-the-blank] happen. So for this
> sentence, my suggested edit is:
>
> “The IAOC is asked to engage with the IANA functions operator
> regarding jurisdiction and
>    any necessary dispute resolution mechanisms that are mutually
>    acceptable to the parties."
>
> We should leave it up to the IAOC to decide how to effectuate this.

I have removed "some members of".
>
> =
>
> "To address concerns regarding appropriate contingencies to
> transition to another operator, IAOC is asked to conclude a
> supplemental agreement that- 1. captures provisions C.7.3 and I.61 of
> the current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract
> <http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>];
> and"
>
> Similar to my comment above, I think this should align with the other
> bits about the IAOC, i.e.,
>
> "To address concerns regarding appropriate contingencies to
> transition to another operator, the IAOC is asked to engage with the
> IANA functions operator regarding: 1. maintaining the IANA functions
> operator's obligations established under provisions C.7.3 and I.61 of
> the current IANA functions contract between ICANN and the NTIA
> [NTIA-Contract
> <http://tools.ietf.org/html/draft-ietf-ianaplan-icg-response-01#ref-NTIA-Contract>];
> and”

I have no problem with the wording change above.
>
> =
>
> "requires the transfer of any associated marks and identifiers to a
> subsequent operator."
>
> I continue to be against the inclusion of this provision in the
> transition plan. It implicitly requires there to only ever be one
> operator in the future, and it is not in the IETF’s interest to force
> that to be the case. That may have been in NTIA’s interests, but we
> have different needs from NTIA. 
>

Based on what you wrote above I had previously misunderstood your
concern.  I propose a small change for this response with the
expectation that we will engage others in the process of further
developing a consolidated response:

"requires the transfer of any associated marks and identifiers
tosubsequent operators."

Clearly there will need to be additional discussion with the RIRs in
particular about iana.org.

>
> == Response to Section IV:
>
> "What is necessary as part of transition is the completion
> of supplemental agreement(s) discussed in the previous section of
> this RFP.”
>
> Per my comments above, I don’t think we should specify the form of the
> output of the IAOC’s work. My suggestion:
>
> "What is necessary as part of transition is the completion of the
> IAOC’s engagements discussed in the previous section of this RFP to
> the satisfaction of the IAOC.”
>

I do not believe this is sufficiently clear for our intent to be
understood and prefer the original text.
>
> === Nits ===

Thanks for catching them.  I've only left in the ones for which there is
something to add.
>
> In general, I think we should use the term “protocol parameters
> registries” in the plural rather than the singular, and use it
> consistently throughout the document.
>
I've made this change.  Please review in the next version as there were
a lot of edits.

> s/No changes are required, as over the years/No changes are required.
> Over the years/

This text has changed.

Eliot