[governance] Digital Agenda: Commission welcomes improvements in new IANA contract

[Imran Ahmed Shah]

How it is through another angle? How the IANA functions will be performed
and What will be the ICANN's remaining function.

IANA functions (A) were assigned to ICANN under a contract by DoC, whereas
the ICANN was bound to submit the performance report to DoC on monthly
basis.
However, (with the passage of time) ICANN started other operations/functions
B,C ... including its primary function A.
Now if the DoC assign the Contract of IANA Functions (A) to Contractor-2
(other than ICANN)

What will be the function of ICANN? Ans: Obviously ICANN will be performing
B, C ... functions
and 
How the IANA Functions A will be performed, 
1.	Either a formal request will be sent through DoC or on behalf of Doc
to Contractor-2 and/or 
2.	Registry will contact Contractor-2 directly.

Here the function of ICANN's Involvement in standard operations & functions
will be reduced and most probably, ICANN will not be able to supervise the
root modification requests sending to the Contractor-2 unless if it is
specified in the contract with Registries (Registry Operators Contract to
send their request to ICANN for root modifications/update).

DoC active involvement will become increased as they have to verify &
validate the deliverable services delegated and are in stable operation. 
The performance and progress will remain under the monitoring of DoC and
NTIA. 

The new gTLDs will also require further study about the delegation process.

Thanks

Imran Ahmed Shah

> -----Original Message-----
> From: governance at lists.cpsr.org [mailto:governance at lists.cpsr.org] On
> Behalf Of John Curran
> Sent: Tuesday, November 15, 2011 03:45 AM
> To: Roland Perry
> Cc: governance at lists.cpsr.org
> Subject: Re: [governance] Digital Agenda: Commission welcomes
> improvements in new IANA contract
> 
> On Nov 14, 2011, at 3:16 PM, Roland Perry wrote:
> >
> > I'm trying quite hard to imagine a situation where the IANA contract/
> function is awarded to someone other than ICANN, not because I think it
> might be, or should be, but the contract terms must make some sort of
> sense in the eventuality that it is (otherwise the tendering is a sham).
> 
> Interesting thought exercise.  Since the IANA Function Contract is
> predominantly a recording entity that operates accordingly to the policies
set
> by various bodies, the theory may be that nothing would significantly
change.
> When ICANN goes to implement nearly any change to a registry (e.g. root
> zone change, or delegation of space from the
> IPv6 free pool, or making an entry in one of the protocol registries),
they
> would need to write up the change to send to the IANA operator.
> 
> That's a very simplistic view of the situation, however, and it would
indeed
> be a rather confusing time on day one should the IANA Function Contract be
> awarded to a new entity.  As I noted on this list a few weeks back
(attached),
> it would take significantly effort to establish the necessary "close
> constructive working relationships" called for in the statement of work,
but
> it's not inconceivable.
> 
> FYI,
> /John
> 
> (personal views only)
> 
> ===
> 
> Begin forwarded message:
> 
> > From: John Curran <jcurran at istaff.org>
> > Subject: Re: [governance] IANA contract to be opened for competitive
> > bidding on November 4
> > Date: October 24, 2011 4:29:08 PM EDT
> > To: Norbert Bollow <nb at bollow.ch>
> > Cc: governance at lists.cpsr.org
> > Reply-To: governance at lists.cpsr.org, John Curran <jcurran at istaff.org>
> >
> > On Oct 24, 2011, at 6:59 PM, Norbert Bollow wrote:
> >
> >> John Curran <jcurran at istaff.org> wrote:
> >>
> >>> I know that the multiple interacting agreements can be somewhat
> >>> confusing at first, but they really do exist.
> >>
> >> My main source of confusion, what caused me to think that perhaps the
> >> US government is trying to take some authority back that it had
> >> previously given away (I don't think this anymore) was that I have
> >> read enough RFCs that in my mind the name "IANA" is very strongly
> >> associated with what RFC 2860 is about, while the US Government's
> >> concerns are probably mainly about the DNS root zone (a topic that is
> >> explicitly excluded in RFC 2860). I was quite aware that the US
> >> government had always wanted to retain some control about that, I was
> >> just associating other topics with the name "IANA".
> >
> > If one uses the term "IANA" to refer to the classic "Internet Assigned
> > Numbers Authority" of IAB/IETF/RFCs, and always use the "IANA
> Functions"
> > as the tasks that ICANN performed under contract for DoC/NTIA, then it
> > becomes slightly less entangled.
> >
> >>> One pleasant side effect of this fact is that all of the parties
> >>> need to work with each other in order to build consensus before
> >>> taking action.
> >>
> >> Good point! So the practical path towards a potential transfer of the
> >> IANA function to another entity would presumably involve both the US
> >> government and IAB agreeing about the new entity that it is suitable.
> >
> > Actually, it's an interesting exercise left for the reader... Note
> > that USG has two relationships with ICANN: 1) the AoC, which commits
> > DoC to "a multi-stakeholder, private sector led, bottom-up policy
> > development model for DNS technical coordination" and ICANN to be such
> > an organization, and 2) the IANA Functions contract, whereby ICANN
> > provides specific set of technical recording functions under clear
> > NTIA oversight.  It is not inevitable under a hypothetical award to a
> > non-ICANN party that ICANN's role in technical policy coordination
> > would change in any manner. What is clear is that the final result of
> > any process which required a change to the root zone file or central
> > address registry would ultimately go to a Contractor team other than
> > the current IANA team at ICANN.  The establishment of comparable
> > relationships with the affected parties is uncertain and risky at best
> > (see IANA NOI comments filed by IAB, NRO & ISOC), but that does not
> > mean it couldn't happen with careful preparation and planning.
> >
> > Note that the draft SOW says: "the Contractor, in the performance of
> > its duties, has a need to have close constructive working
> > relationships with all interested and affected parties ... to ensure
> > quality performance of the IANA functions."  I expect that is actually
> > somewhat of an understatement of the requirements in this area.
> >
> > FYI,
> > /John
> >
> > (my views alone - feel free to use, forward, or delete as desired.
> > Only free electrons were disturbed in the creation of this email)
> 
> __________________________________________________________
> __
> You received this message as a subscriber on the list:
>      governance at lists.cpsr.org
> To be removed from the list, visit:
>      http://www.igcaucus.org/unsubscribing
> 
> For all other list information and functions, see:
>      http://lists.cpsr.org/lists/info/governance
> To edit your profile and to find the IGC's charter, see:
>      http://www.igcaucus.org/
> 
> Translate this email: http://translate.google.com/translate_t


____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, visit:
     http://www.igcaucus.org/unsubscribing

For all other list information and functions, see:
     http://lists.cpsr.org/lists/info/governance
To edit your profile and to find the IGC's charter, see:
     http://www.igcaucus.org/

Translate this email: http://translate.google.com/translate_t