FW: Personal comments on Dec 1st draft
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> wrote: >Grace, > >As far as I can see this message is not in the posted archive. >Naturally, I wish it to be considered. > >Regards > 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 >>of >> 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 >negotiate >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 >effort >(and PR) on gTLD policy issues, but we know that the vast majority of >IANA's >day to day work is changes to protocol parameter registries. A more >factual >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 >between >ICANN and the NTIA and no doubt elsewhere. Please make the proposal limit >itself throughout to Naming Functions. The other communities aren't >telling >the names community what to do. > >Regards > Brian Carpenter > > > > > > Attachment:
smime.p7s |