Re: ISO 3166 recomendations.

["D. Chiodo" <djc@microwave.com>]

About the only thing I would add is a requirement that any potentiaol TLD
delgatee, would have to declare the TLD as either "public" or "private",
with requirements that one declared "public" publish their fees, not
discriminate, etc, etc, and in exchange have a lower registration fee,
possibly with some sort of schedule where up to half of it could be
refunded on a matching basis as they take registrations. "Private" TLDs
could do whatever they wanted, but would have to pay a higher unrefundable
fee. 

On Tue, 24 Dec 1996, Simon Higgs wrote:

> Date: Tue, 24 Dec 1996 14:29:05 -0800
> From: Simon Higgs <simon@higgs.com>
> To: "D. Chiodo" <djc@microwave.com>
> Cc: Kevin Brown <kevinbr@netcomm.ie>, "Rick H. Wesson" <wessorh@ar.com>,
>     iahc-discuss@iahc.org
> Subject: Re: ISO 3166 recomendations.
> 
> At 11:25 AM -0500 12/24/96, D. Chiodo wrote:
> 
> > Defining (or reemphasizing) what party will administrate the root zone.
> >
> 
> Mandatory.
> 
> > Defining connectivity and reliablity specifications for the primary root
> > zone server, and set a time limit within which the current operator must
> > bring the server within compliance if it is not. (Since my suggestion for
> > this would be leased line connectivity, via differing carriers, to at
> > least 3 of the NAPs with full defaultless routing, a double-redundant
> > power supply, an alternate server ready to use at all times, and a
> > bi-daily tape backups (once immediately before root zone updates, once
> > immediately after, I have a good idea NSI might need to make some
> > enhancements)
> >
> > Defining what will happen to the .COM zone. (My suggestion would be a
> > phased retirement, and a 5 year moratorium on its recreation)
> >
> 
> The contract expires in 1998. If NSI continue beyond then in any other
> capacity other than as a shared registrar COM/ORG/NET there will be
> major problems resulting in government intervention. But I think Marty
> Modell's idea (renegotiation at the annual renewal) is brilliant if it
> could shorten NSI's exclusive term.
> 
> > Defining a process whereby qualified companies and organiations could
> > apply for registration of a zone within the root (TLD), what those
> > qualifications are. I would suggest a moderate fee to be placed in a fund
> > for root server operation, upkeep, and administration (including these
> > registration procedures)
> 
> That is what the IAHC is supposed to be doing. :-)
> 
> > Defining what should happen with the "list" of organizations that have
> > attempted to register and use TLDs in advance of this policy. (My
> > suggestion would be to permit them to apply and give them preference over
> > other organizations requesting the same TLD's, but to not relax any of the
> > requirements, qualifications or fees.)
> >
> 
> Sounds reasonable.
> 
> > I would suggestions that the qualifications for registration of a server
> > for a TLD zone include:
> >
> >  One primary zone server, configured and ready to operate, which must be
> > operating on a multihomed network with a defaultless routing
> > configuration.
> >
> >  Some combination of secondary servers:
> >   3 secondary zone servers, none of which is to be on the same network or
> > backbone as the primary, nor each other.
> >   2 secondary zone servers, one of which may be on the same backbone or
> > network as the primary. Both networks must be multihomed to different
> > backbones, and have a defaultless routing configuration.
> >   1 secondary zone server, not on the same network as the primary. Both
> > the primary and the secondary must be on networks with direct connections
> > to at least two NAPS, and be operating in a defaultless routing
> > configuration.
> >
> 
> See http://ds.internic.net/rfc/rfc2010.txt
> 
> > All servers must have at least single-redundancy backup power.
> >
> > A published working email address for the technical administrator of the
> > primary zone server, that must work even if all servers for the TLD fail.
> > (IE, it must be in some _other_ domain, and must not forward to or
> > otherwise rely on the served TLD)
> >
> > A published working phone number for the technical administrator.
> >
> 
> It's all in whois.
> 
> > I'm starting to wander. I'm sure IAHC and the net community can form a
> > reasonable set of qualifications for TLD servers. But yes, IAHC and IANA
> > need to make a positive step to prevent the existence of multiple root
> > servers all over the place, which would turn the net into a "spotty, at
> > best" method of communication. And I think if they define who runs the
> > root DNS, and a method for appplying for delegation of TLD zones, I think
> > the "registries" will figure out how to work on their own.
> >
> > Everyone is throwing this "registry" buzzword around, and it ISNT the
> > issue. The issue is what TLD zones will be delegated, who they will be
> > delegated to, and how. Put the technical details in place, assign the
> > authority, and the suits will figure out the administrative details for
> > their organizations.
> >
> 
> You're not kidding. I'm biased, but the proper way to do the TLD admin
> is at: http://ds.internic.net/internet-drafts/draft-higgs-tld-cat-03.txt
> Note this doesn't completely cover registry admin, as that is an
> entirely seperate issue.
> 
> 
> 
> Simon
> 
> --
> If at first you don't succeed, skydiving is not for you.
> 
> 
>