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