Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

["James Seng/Personal" <James@Seng.cc>]

Well, when you face with a problem like this such as

a) Mass changing of IP of Nameservers
b) Consistency of Name servers
c) Delete of parent Domain Name
etc

Rather than publishing the design (ie nameserver object + name object
and their relationship), you could specify the problem and make that as
a requirement.

In this case, this requirement

  [10] All registrars MUST be authorized to register objects in the
  registry.  Name server registration MUST be limited to the registrar
  of the name server's parent domain.  Unauthorized attempts to register
  a name server in a parent domain administered by another registrar
  MUST be explicitly rejected.

would become

  [10] The Protocol MUST be able to track changes in nameservers across
  all domain names which is associated with it. No nameserver data
  SHOULD exist in the registry if the parent domain names has cease to
  exist.

-James Seng

----- Original Message -----
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
To: <ietf-provreg@cafax.se>
Sent: Wednesday, February 07, 2001 6:15 AM
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]


> FWIW we had quite a lengthy name server management discussion on the
old RRP
> list some months ago, and truth be told we never came to complete
agreement.
> There are positive and negative aspects of managing name servers as
either
> top-level objects or as attributes of other objects, such as domains.
>
> The attribute idea makes sense in the context of managing a small
number of
> domains, but it gets unwieldy from a management perspective when a
name
> server is hosting thousands or millions of domains.  Cross-registrar
> coordination is also tricky if top level server objects and domain
objects
> can be managed by different registrars -- how do things work if domain
> foo.com must be deleted by one registrar, but another registrar has
> management authority for ns1.foo.com?  If domain foo.com gets deleted,
is it
> a good idea to publish an "orphan" glue record for ns1.foo.com?
>
> Anyway, the current requirements language was thought by me to be the
most
> reasonable compromise based on operational experience.
>
> <Scott/>