Re: [ga] FYI: Staff Draft towards Mission Statement

[k@widgital.com (Kristy McKee)]

After reading both, the mission referred to by Alexander (below) and that 
written by Karl (below).  I certainly find more value in Karl's.

Karl included what is necessary to accomplish the non-technical goals set 
forth in the white paper, while the other overcomplicated each portion of 
action necessary...  and added procedures to processes that were once 
streamlined and should be again...

:)

~k


At 02:47 AM 3/8/2002 -0800, Karl Auerbach wrote:
>On Fri, 8 Mar 2002, Alexander Svensson wrote:
>
> > ICANN Staff Draft: Toward a Statement of the ICANN Mission (7 March 2002)
> > http://www.icann.org/general/toward-mission-statement-07mar02.htm
>...
> > What ICANN Does
>
>Which is quite a different matter than what ICANN ought to do.
>
>I won't be nearly as prolix as ICANN's staff.  One could presume that
>their salaries are based on the word count of their productions. ;-)
>
>Here's my rather shorter list of things that ICANN ought to do.  Please
>pardon the shorthand form.
>
>                 --karl--
>
>1 Allocation of IP addresses
>
>1.1 Is a very complex issue
>
>1.1.1 it is a mix of technical and economic factors and there is very
>little understanding of these issues outside of those who are directly
>involved in the address allocation or routing systems of the Internet.
>
>1.1.1.1 The economic ramifications are generally under appreciated.
>
>1.2 The most basic goal is adherence to the principles of CIDR.
>
>2 DNS Tasks
>
>2.1 Hint file publication
>
>2.2 Root zone entry admission and maintenance (i.e. who gets an entry in
>the root zone and to where should the delegation records point.)
>
>2.3 Periodic root zone file construction, distribution, disaster data
>preservation.
>
>2.4 Root server operation (direct or indirect)
>
>2.5 Root server placement (involves question of "anycast" routing
>technology.)
>
>2.6 Root zone dissemination
>
>2.7 Failure/error monitoring
>
>2.8 Preservation of historical versions of zone files/delegations.
>
>2.9 Huge open question: To what extent should ICANN reach into TLD
>registration systems?
>
>2.9.1 Most basic: escrow/data protection and recovery
>
>2.9.2 Less basic: whois gathering and accuracy
>
>2.9.3 Registry-registrar protocols
>
>2.9.3.1 (Note, registry/registrar model is not only one possible.  E.g. it
>is possible to represent domain name "ownership" by a digital certificate
>[non-repudiation of transfers requires support from by a transfer agent
>[who needs not know the subject matter of the certificate], much like a
>"bearer bond".)
>
>2.9.4 Least basic: DNS consumer rights, UDRP
>
>
>--
>This message was passed to you via the ga@dnso.org list.
>Send mail to majordomo@dnso.org to unsubscribe
>("unsubscribe ga" in the body of the message).
>Archives at http://www.dnso.org/archives.html

--
This message was passed to you via the ga-full@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga-full" in the body of the message).
Archives at http://www.dnso.org/archives.html