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


To: shollenbeck@verisign.com (Hollenbeck, Scott)
Cc: ietf-provreg@cafax.se
From: Bill Manning <bmanning@zed.isi.edu>
Date: Wed, 7 Feb 2001 19:46:58 -0800 (PST)
In-Reply-To: <DF737E620579D411A8E400D0B77E671D7505C4@regdom-ex01.prod.netsol.com> from "Hollenbeck, Scott" at Feb 07, 2001 10:17:37 PM
Sender: owner-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

Home | Date list | Subject list