ICANN ICANN Email List Archives


<<< Chronological Index >>>    <<< Thread Index >>>

FW: Personal comments on Dec 1st draft

  • To: "comments-cwg-naming-transition-01dec14@xxxxxxxxx" <comments-cwg-naming-transition-01dec14@xxxxxxxxx>
  • Subject: FW: Personal comments on Dec 1st draft
  • From: Grace Abuhamad <grace.abuhamad@xxxxxxxxx>
  • Date: Mon, 29 Dec 2014 17:34:37 +0000

Forwarding on behalf of Brian Carpenter while we figure out why this
comment was not posted to the forum as others. -- Grace

On 12/25/14 1:22 PM, "Brian E Carpenter" <brian.e.carpenter@xxxxxxxxx>

>As far as I can see this message is not in the posted archive.
>Naturally, I wish it to be considered.
>   Brian Carpenter
>-------- Original Message --------
>Subject: Personal comments on Dec 1st draft
>Date: Wed, 03 Dec 2014 13:59:50 +1300
>From: Brian E Carpenter <brian.e.carpenter@xxxxxxxxx>
>Organization: University of Auckland
>To: comments-cwg-naming-transition-01dec14@xxxxxxxxx
>Broadly, I'm in favour of some form of organisation of the names
>community outside ICANN's corporate structure, to act as an
>independent voice of the community in reviewing and evaluating
>ICANN's performance of the various IANA Naming Functions. I believe
>that this is distinctly preferable to such review and evaluation
>being carried out by a body or bodies that are part of ICANN's
>corporate structure. In particular, if ICANN ceases to perform
>adequately, such an organisation would be well placed to find
>an alternative provider for the IANA Naming Functions. There is
>no reason we should grant ICANN an indefinite monopoly. (In other
>words I am very much against a solution in which "all NTIA
>responsibilities [are] transferred to ICANN.")
>That said, I have three general comments at the moment. In these I am
>quoting from the summary text, but I have looked through the detailed
>document, and have added some more detailed comments below.
>1. There are a large number of places where the phrase "IANA Functions
>Operator" is used. I suggest that you should always use the full phrase
>"IANA Naming Functions Operator" to avoid any ambiguity or doubt about
>the scope of this proposal. As you know, there are other parties
>involved for the other IANA Functions and they must clearly have equal
>standing from an overall point of view.
>Three examples where this change is needed are:
>> Contract Co. ­ This primary function of this entity (likely a non-profit
>> corporation) is to be signatory to the contract with the IANA Functions
>> Operator.
>> Conducting the IANA Functions Operator Budget Review
>> Managing a re-contracting or rebidding (RFP) process for the operation
>> the IANA Functions
>2. Related to that point, the phrase "exact composition TBD" in the
>description of the Multistakeholder Review Team is not a minor detail.
>To understand this proposal, it is essential to fully understand the
>composition of the MRT. Indeed, unless I missed it, you do not speak of
>how the names community as a whole will relate to and if necessary
>with the other two communities (addressing and protocol parameters).
>3. Considering this:
>> Contract Co. ­ This primary function of this entity (likely a non-profit
>> corporation) is to be signatory to the contract with the IANA Functions
>> Operator. This entity should be lightweight and have little or no staff.
>I haven't understood how a non-profit, zero-staff and presumably almost
>budget-free shell company can sign a contract that has any real power
>over the service provider. What will the penalty clauses say? "If you do
>a bad job, we will sulk" perhaps? I'm not trying to be snarky; I just
>don't see what power an incorporated entity of this kind has beyond
>the moral authority that the names community has in any case.
>Now a few detailed comments on the draft. By the way, thanks for the
>effort put into it; sections 1 and 2 are highly informative.
>> A ­ Background and Introduction
>> Background
>> Most of ICANN¹s work is concerned with the Internet's global Domain
>> Name System,
>That is a claim that needs to be justified. ICANN does spend a lot of
>(and PR) on gTLD policy issues, but we know that the vast majority of
>day to day work is changes to protocol parameter registries. A more
>statement would be better.
>> The numbering facilities ICANN manages include the Internet Protocol
>> address spaces for IPv4 and IPv6, and assignment of address blocks to
>> regional Internet registries.
>It would be more accurate to describe that as an IANA function within
>ICANN, and in fact I would say that the overall management of the
>address spaces is actually performed by IETF standards actions; IANA's
>part is assignments of unicast address space to the RIRs.
>> ICANN also maintains registries of Internet protocol identifiers.
>Again, that is an IANA function within ICANN (and is not an also-ran).
>> 3.4. Changes to existing arrangements
>> The CWG¹s proposed changes to existing oversight and accountability
>> arrangements performed by the NTIA are based on the concept that the
>> individual arrangements do not all have to be carried out by a single
>> entity that would act as a wholesale replacement of the NTIA in these
>> matters. Rather, we envision that a different group or entity would
>> carry out each individual arrangement, replacing the NTIA.
>I want to say that this is absolutely the right thing to do.
>> 3.4.1. NTIA acting as the IANA Functions Contract Administrator ­
>>contracting functions
>> ...
>> The primary function of this new corporation would be to enter into a
>> contract with the IANA Functions Operator for the IANA Functions.
>In this section in particular, it's essential to be clear that this
>is the IANA Naming Functions Operator in every case. It isn't for
>the names community to hold a contract for the other IANA functions.
>The same issues runs through section 3.4.4. IANA Functions Contract
>ICANN and the NTIA and no doubt elsewhere. Please make the proposal limit
>itself throughout to Naming Functions. The other communities aren't
>the names community what to do.
>   Brian Carpenter

Attachment: smime.p7s
Description: S/MIME cryptographic signature

<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy