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

[Rick Wesson <wessorh@ar.com>]

Elisabeth,

why would you add "IPv6 deployment?" How is it ICANN or IANA's job to
become an advocate of a addressing scheme?

-rick


On Fri, 8 Mar 2002, Elisabeth Porteneuve wrote:

>
>
> Thank you very much Karl for this excellent synthesis.
>
> I add:
>
> 1.3 IPv6 deployment
>
> Elisabeth Porteneuve
> --
>
> -----------------------------------------------------------------
> Date: Fri, 8 Mar 2002 02:47:11 -0800 (PST)
> To: Alexander Svensson <alexander@svensson.de>
> cc: ga@dnso.org
> Subject: Re: [ga] FYI: Staff Draft towards Mission Statement
> From: "Karl Auerbach" <karl@CaveBear.com>
> X-Delivery-Agent: TMDA/0.48 (Python 2.2 on linux2)
>
> 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@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