RE: 2 points

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

OK, I'll strike the proposed second sentence if no one else has any
arguments to the contrary.

<Scott/>

> -----Original Message-----
> From: Bill Manning [mailto:bmanning@zed.isi.edu]
> Sent: Wednesday, February 07, 2001 10:47 PM
> To: shollenbeck@verisign.com
> Cc: ietf-provreg@cafax.se
> Subject: Re: 2 points
> 
> 
> % > % [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.
> % > 
> % > 	I'd loose the second sentence. 
> % 
> % Why?  The functional implication is that you can end up 
> with A records in a
> % zone without NS records that refer to those A records.  
> I've been told that
> % this won't cause server software like BIND to choke, but 
> it's not optimal.
> % 
> % <Scott/>
> 
> Hum...
> 	First off, can we "loose" the term domain? Or at least 
> 	the concept of "parent"?  I am really trying hard to
> 	make this generic. So that the "backend" database and
> 	its administration et.al. that we are talking about has
> 	three generic components:
> 		The delegation point particulars, e.g. the domain
> 		The description of the publication method, e.g. 
> nameservers
> 		Authorized contacts for each.
> 
> Because the situation is covered in the first sentence. Or there is
> an implied linkage in the second. Either the protocol will be able
> to "manage" nameservers, regardless of delegation data Or, 
> you are mandating
> that "orpahn" nameserver data SHOULD exist w/o an associated 
> delegation
> data. I would expect that, operationally, there would be times when
> namserver data would exist w/o any association to other delegation
> information. (Very temporary)  At no time should delegation 
> particulars or
> nameserver data exist without accompanying authorized contact data.
> 
> 
> --bill