Thank you
Walu and McTim
This will be a good opportunity for Kenyan stakeholders, (we are
very active in
both ICANN and IGF spaces) to input and wish to encourage more
comments online
as well as during the meeting on Tuesday.
Comments are requested along these 6 areas/aspects:
· In light of technology changes and market developments, should the IANA functions continue to be treated as interdependent technical functions? For example, does the coordination of the assignment of technical protocol parameters need to be done by the same entity that administers certain responsibilities as sociated with root zone management? Please provide specific information to support why or why not, taking into account security and stability issues.
· The performance of the IANA functions often relies upon the policies and procedures developed by a variety of entities within the Internet technical community such as the IETF, the RIRs and ccTLD operators. Should the IANA functions contract include references to these entities, the policies they develop and instructions that the contractorfollow the policies? Please provide specific information as to why or why not. If yes, please provide language you believe accurately captures these relationships.
· previously raised by some governments and ccTLD operators and the need to ensure the stability of and security of the DNS, are there changes that could be made to how root zone management requests for ccTLDs are processed? Please provide specific information as to why or why not. If yes, please provide specific suggestions.
· -Broad performance metrics and reporting are currently required under the contract.\7\ Are the current metrics and reporting requirements sufficient? Please provide specific information as to why or why not. If not, what specific changes should be made?
· Can process improvements or performance enhancements be made to the IANA functions contract to better reflect the needs of users of the IANA functions to improve the overall customer experience? Should mechanisms be employed to provide formalized user input and/or feedback, outreach and coordination with the users of the IANA functions? Is additional information related to the performance and administration of the IANA functions needed in the interest of more transparency? Please provide specific information as to why or why not.
· Should additional security considerations and/or enhancements be factored into requirements for the performance of the IANA functions? Please provide specific information as to why or why not. If additional security considerations should be included, please provide specific suggestions.
best Alice,
--- On Sat, 3/26/11, McTim <dogwallah@gmail.com> wrote:
@McTim,
True, ICANN says more else the same thing; but think about it, maybe ICANN says what we ask it to say and they reflect our thoughts and aspirations. That is the nature of a multistakeholder, bottom up organisation that ICANN is.
walu.
nb: also refer to my original message and you will see that I never claimed exclusive rights to these comments. I simply digested the same for the local community.
--- On Sat, 3/26/11, McTim <dogwallah@gmail.com> wrote:
From: McTim <dogwallah@gmail.com>
Subject: Re: [kictanet] STAKEHOLDERS COMMENTS ON IANA FUNCTIONS-my comments
To: "Walubengo J" <jwalu@yahoo.com>
Cc: "KICTAnet KICTAnet" <kictanet@lists.kictanet.or.ke>
Date: Saturday, March 26, 2011, 5:04 PM
On Sat, Mar 26, 2011 at 4:42 PM, Walubengo J <jwalu@yahoo.com> wrote:--
Wambua,
I wont make it for the meeting but plse register my comment on the above as follows:
1. No single government should have oversight powers over IANA functions(core operational functions of the Internet).
That's what the original White Paper said...it's just 20 years later now.
NB: IANA functions are administrative, not operational.
2. It is therefore best that the US government relinquishes oversight powers over the IANA function in a progressive manner i.e. by moving its relationship with ICANN over IANA function from the current "Contractual" agreement to a "Cooperation" agreement locally known as an MOA and eventually an non-legal agreement sometimes known as an MoU
that's what ICANN says too:
Cheers,
McTim
"A name indicates what we seek. An address indicates where it is. A route indicates how we get there." Jon Postel
_______________________________________________ kictanet mailing list kictanet@lists.kictanet.or.ke http://lists.kictanet.or.ke/mailman/listinfo/kictanet This message was sent to: alice@apc.org Unsubscribe or change your options at http://lists.kictanet.or.ke/mailman/options/kictanet/alice%40apc.org