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


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

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