[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From: "Hollenbeck, Scott" <shollenbeck@verisign.com>
Date: Wed, 7 Feb 2001 12:13:12 -0500
Sender: owner-ietf-provreg@cafax.se
Subject: RE: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]

(Sorry if this is a duplicate message for anyone -- I sent it to the list
earlier today, but it doesn't appear to have been redistributed yet.)

Good point.  I'd like to keep the first sentence of the current wording in
it's own requirement, though, because it deals with client privileges.  I'd
also like to suggest a rewording of your rewording because the "MUST be able
to track changes" phrase sounds (to me) like a requirement for keeping state
information in the protocol.  Would you (and everyone else) be OK with this:

[10] All registrars MUST be authorized to register objects in the registry.

[11] The protocol MUST provide services to manage name servers associated
with multiple domains.  No name server data SHOULD exist in the registry
without an associated parent domain.

<Scott/>

> -----Original Message-----
> From: James Seng/Personal [mailto:James@Seng.cc]
> Sent: Wednesday, February 07, 2001 9:28 AM
> To: Hollenbeck, Scott; ietf-provreg@cafax.se
> Subject: Re: draft-hollenbeck-grrp-reqs-06 [Was Re: Interim Meeting]
> 
> 
> 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/>
> 
> 

Home | Date list | Subject list