Subject: RE: [Enum] Agenda items for IETF Paris

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Fri, 08 Jul 2005 14:06:40 -0400

Jim,

I have yet to see a persuasive argument for why all the political
requirement, control, manipulation, administration, policy, ... aspects
can't be built around a simple technical model.  The administrative tail
seems to be wagging the dog.  

Whatever happened to Occam's Razor?

Mike

> -----Original Message-----
> From: Jim Reid [mailto:jim at rfc1035.com] 
> Sent: Friday, July 08, 2005 1:41 PM
> To: Michael Hammer (mhammer)
> Cc: Michael Haberler; enum at ietf.org
> Subject: Re: [Enum] Agenda items for IETF Paris
> 
> On Jul 8, 2005, at 17:29, Michael Hammer ((mhammer)) wrote:
> 
> > Pardon my inexperience with DNS mechanisms, but why can't a 
> lookup of 
> > a domain at: 1.2.3.4.5.5.5.1.0.2.1.e164.arpa return an 
> OPT-IN User RR 
> > (which may or may not be there) and a Carrier RR 
> identifying a border 
> > controller?
> 
> Because these are two different things which will presumably 
> be controlled and manipulated by different entities according 
> to different, possibly mutually exclusive, requirements.
> 
> There's nothing in the DNS protocol to prevent these RRs 
> co-existing in the same zone of course. And if they did, a 
> DNS lookup could return both. However just because something 
> is possible doesn't mean it could or even should be done. 
> From a purely technical perspective, the answer to your 
> question is the DNS lookup could return both these RRs. But 
> for all sorts of practical reasons -- administrative, policy, 
> operational, content management, synchronising and managing 
> access control to the zone, etc, etc -- this is unlikely to 
> be a wise or desirable outcome.
> 

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Michael Haberler <[email-masked]>
Date: Fri, 08 Jul 2005 16:10:29 -0400

Michael,
lets call your proposal "zone cohabitation" (which is very close to the 
CNAPTR proposal which was on the CC1 LLC mailing list a while ago).

I think it would work in theory - however:
In practice, it would prevent delegation to a user-operated nameserver at 
the number level, forcing the Tier1 nameservers contain all NAPTRs, with 
all consequences.

Lets assume your user deploys an Innovaphone IP PBX (www.innovaphone.de) . 
This box inlcudes a user (lets call it "Tier3") nameserver. You add an 
extension, corresponding NAPTR record appears automatically.

There are many more useful examples for such applications, and I believe 
your proposal makes them impossible - I doubt that Carrier POI information 
can be reasonably administered in such a scenario.

The concept of zone ownership gets in the way, which is why I propose 
different zones - small burden on the Carrier-ENUM aware resolver, no 
burden on User ENUM tree shape.

-Michael
At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote:
Jim,

---

From: Michael Haberler <[email-masked]>
Date: Fri, 08 Jul 2005 20:36:12 -0400

At 20:06 08.07.2005, Michael Hammer \(mhammer\) wrote:
Jim,
I have yet to see a persuasive argument for why all the political
requirement, control, manipulation, administration, policy, ... aspects
can't be built around a simple technical model.  The administrative tail
seems to be wagging the dog.
Ah, I guess I see the knot...
Could it be that you are assuming:
- a closed numbering plan (fixed number length)
- maybe a scenario where all RR's are held in the Tier1 nameservers?
and think about a scheme where authorization to enter a particular record 
type at the number level could be given to different parties ?

that would probably work, BUT - not all countries have a fixed numbering 
plan - among them Germany and Austria. Coming back to my example:

+43 59966 is a valid number, as is +43 59966-0 (a convention to reach the 
switchboard).
+43 58866-12345678 is valid as well, and anything in between.

In such a situation you would typically have a delegation at +43 59966 to 
point to your own ("Tier3") nameservers. That is in fact very useful - I'd 
have to check but I assume that most PBX-type delegations under +43 use 
that scheme. As I mentioned, actually enlightened IP PBX manufacturers use 
this method.

I assume this to be incompatible with carrier type records at or under +43 
59966 - no carrier fiddling in user-operated zones, please.

-Michael