Subject: AW: [Enum] Re: D3S details redux

From: "Stastny Richard" <[email-masked]>
Date: Tue, 17 Sep 2002 14:53:22 +0200

MM and Lawrence wrote:

	>Not really. The key has to be database specific. If this wasn't the case
	>then it would be very hard to use ENUM with other databases beyond DNS.
	
	This has me perplexed - I don't think I understand the answer.

	Richard: Me too.
	 
	I think that the key should NOT be database-specific as generated by the output
	of the first well known rule and the output of non-terminal regexp processing.
	
	Otherwise, it's very hard to use another database, which is a major feature
	of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition the
	issues so that one could data hide - e.g. the database-specific forms
	are hidden
	within the rule retrieval step (step 2 in section 3.3 of ddds-07.txt).
	
	Richard Just siiting in the ITU SG2/Q1 Rapp Meeting and discussing alternate Roots
	or TLDs for ENUM, I do not want to see .e164.arpa IN the tree, even
	if I myself prefer e164.arpa. But if the ENUM root changes, I normally would
	not care in the Tier 1 and 2. But in the case I have references to the root, I have
	a problem. This is not modular design.
	 
	regards
	Richard

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Mealling <[email-masked]>
Date: Tue, 17 Sep 2002 11:00:21 -0400

On Tue, Sep 17, 2002 at 02:53:22PM +0200, Stastny Richard wrote:
>> I think that the key should NOT be database-specific as generated by the 
>> output the first well known rule and the output of non-terminal regexp 
>> processing.
>  
>> of D3S. No data hiding is bad design, IMHO, and D3S was meant to partition 
>> the issues so that one could data hide - e.g. the database-specific forms
>> are hidden within the rule retrieval step (step 2 in section 3.3 of 
>> ddds-07.txt).
>  
> Richard Just siiting in the ITU SG2/Q1 Rapp Meeting and discussing 
> alternate Roots or TLDs for ENUM, I do not want to see .e164.arpa IN 
> the tree, even if I myself prefer e164.arpa. But if the ENUM root changes, 
> I normally would not care in the Tier 1 and 2. But in the case I have 
> references to the root, I have a problem. This is not modular design.

You shouldn't have 'e164.arpa' internal to your tree. You can but you
don't need to. What we're talking about here are non-terminal NAPTRs.
If you NAPTR is terminal then the output of the regexp is the URI you
wanted. If you want to delegate further then just use an NS record for
the delegation. Non-terminal NAPTRs in most cases do the same thing an
NS record does. The exception is that there is an actual rewrite of the
domain-name being queried (much like what DNAME can do). I.e. if you
had an NS record delegation the nameserver being delegated to would
have to be authoritative for the domain. But with a non-terminal NAPTR
you can send the client off to "bugglewort.its-really-cold-here.aq"
to get the next set of NAPTRs. Either way, you never have to have
the root in a NAPTR rewrite field unless you really want it for some
unknown reason.

-MM

-- 
--------------------------------------------------------------------------------
Michael Mealling |      Vote Libertarian!       | urn:pin:1
[email-masked]      |                              | http://www.neonym.net
--------------------------------------------------------------------------------
!! The Trailblazer spacecraft is going to the Moon! And for just $2500 a gram !!
!! you can send something along with it! Business cards, momentos, cremains,  !!|| anything! See http://www.transorbital.net for details!                     !!