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

Alissa Cooper <alissa@cooperw.in> Fri, 24 October 2014 23:35 UTC

Return-Path: <alissa@cooperw.in>
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 690301A1ACA for <ianaplan@ietfa.amsl.com>; Fri, 24 Oct 2014 16:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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_LOW=-0.7] 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 XlKEoNL65eOh for <ianaplan@ietfa.amsl.com>; Fri, 24 Oct 2014 16:35:53 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34E7C1A19E9 for <ianaplan@ietf.org>; Fri, 24 Oct 2014 16:35:53 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 95165209CC for <ianaplan@ietf.org>; Fri, 24 Oct 2014 19:35:52 -0400 (EDT)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 24 Oct 2014 19:35:52 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:subject:message-id:date:to :mime-version; s=mesmtp; bh=t2xm2mwIeDvMEvEFmgGhE2pZnuE=; b=xSy8 ndlopexKThlz8QPCVkbQjJo2yxdDQA4bJFGyDpzd0Sifa8j6i7JTznHMx/n9vYAX +9thIWqUBIe7ihgNC86fGalGx/7wOCTkLWgmG+f7nqmlZeBQsTmtSR4EMo6+HTKF xe7OhX7Kbug1YrcJ6o1I5DLhLUlaEP4WNVbOfxQ=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type:subject :message-id:date:to:mime-version; s=smtpout; bh=t2xm2mwIeDvMEvEF mgGhE2pZnuE=; b=J94OPVGiDW8g76TmIn5YNkFq9qb0E0TdWB1VclU5/WkW3klV gKJHZtefTmBReQJq+X7GipiCrjb2QDSIK1Kzipuo3X+QVvgu5SEt6kQf5t+4JeGY wKK9FhTLFwgoj2C6kxwqlomQuwEMZVc6Bu4dCLkysbeX4xxEUeg35B0NysY=
X-Sasl-enc: 1tV7vqPsVf9B/5A8lffjn71GqZ6XuZ15BtOW6LsXKiE5 1414193751
Received: from sjc-vpn5-1417.cisco.com (unknown [128.107.239.234]) by mail.messagingengine.com (Postfix) with ESMTPA id 9D819C00008 for <ianaplan@ietf.org>; Fri, 24 Oct 2014 19:35:51 -0400 (EDT)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E486C513-59E6-4ACA-B81C-9277EF8A2E87"
Message-Id: <E74C02CC-8A35-4057-95E4-14925B332456@cooperw.in>
Date: Fri, 24 Oct 2014 16:35:53 -0700
To: ianaplan@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/dF5nJx0G1ZFVGtC1OMvd8GmfJZ8
Subject: [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: Fri, 24 Oct 2014 23:35:56 -0000

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.

=

"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.

=

"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.

=

"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."

=

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


== 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.”


== 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.

=

"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]; 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]; and”

=

"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. 


== 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.”


=== Nits ===

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.

Abstract:
s/This document contains the a draft response to a request/This document contains a response to a request/

s/names and addresses/domain names and numbering resources/

Section 1:
s/protocol registries function/protocol parameters registries function/

Section 2:
s/globally available registry/globally available registries/

s/assoicated/associated/

s/operates an open and transparent manner/operates in an open and transparent manner/

s/in RFCs in [RFC6220] and [RFC5226]/in [RFC6220] and [RFC5226]/

s/[RFC7282]/[RFC7282]./

s/an someone/someone/

s/IETF Response: the protocol parameters registries./IETF Response: The protocol parameters registries./

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

s/intellectual property rights; the IAOC/intellectual property rights, the IAOC/

s/issuees/issues/

s/{We will have an open discussion, make changes based on that discussion, and then conduct a Last Call to confirm that there is rough consensus for the proposal.}//