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

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

Michael,

Could you elaborate more fully.  Between the setup of IP PBX and the
assertion that my proposal makes something impossible, I didn't see any
explanation.  It would help if you use a hypothetical E.164 number and
perhaps explain if this was provided through a carrier or not.  Also, is
this extension being assigned an E.164 number also?  Or is this grafting
a non-E.164 number onto an E.164 number?  Would this require all
DNS-resolvers to continue searching beyond the E.164 tree?

More details please.

Mike

> -----Original Message-----
> From: Michael Haberler [mailto:mah at inode.at] 
> Sent: Friday, July 08, 2005 4:10 PM
> To: Michael Hammer (mhammer); Jim Reid
> Cc: enum at ietf.org
> Subject: RE: [Enum] Agenda items for IETF Paris
> 
> 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,
> >
> >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: Otmar Lendl <[email-masked]>
Date: Sat, 09 Jul 2005 04:26:00 -0400

> DNS-resolvers to continue searching beyond the E.164 tree?

The misunderstanding here seems to be in open numbering plans nad
how they relate to E.164 numbers.

Michael gave some examples, I'd like to add a simple one. Our office in
Vienna uses a simple ISDN BRI in point-to-point mode. The number is
+43 1 5056416 which is a valid E.164 number that is dial- and
reachable from the worldwide PSTN. But so is +43 1 5056416 33, 
+43 1 5056416 933, or +43 1 5056416 6, too.

We, as the owner of the head number are free to design our own, variable
length numbering plan behind that number as long as we stay within the
length limit of E.164. Our telco will route calls to +43 1 5056416 [0-9]* 
to us and indicate in the call-setup what exactly the caller
dialled. (I will not go into the territory of overlap dialing here,
there is plenty of fun in the details.)

All those locally defined extensions are valid E.164 numbers. There
is no need to "continue searching beyond the E.164 tree", because
we *are* still in the E.164 tree.

As such, telephone numbers in an open numbering plan behave much more 
like domain names: If I own example.com, then I can put a webserver
at example.com. I'm free to use foo.example.com, bar.foo.example.com
and whatnot as well, as long as I stay within the lenght limits imposed by
the DNS standard.

To continue with the +43 1 5056416 example: The ISDN BRI is connected
to a small cisco router on our side which translates all incoming calls
to SIP. The numbering plan (the information which extensions exist and
where they are routed) is stored in a small database which also drives
the 6.1.4.6.5.0.5.1.3.4.e164.arpa zone.

I can thus create new, valid E.164 numbers by a simple insert into that 
table. ENUM NAPTRs are instantly visible as well. There is real value
in the fact that we have complete control over our ENUM zone.

All this does not mix with carrier enum. Our carrier doesn't even know
what numbers are in use behind our number. All he needs to know
is "route everything matching /^4315056416.*/ in our direction".
And basically that's the information our carrier has to put into
any carrier ENUM tree. In ENUM terms, that will probably be something
like 

$ORIGIN 6.1.4.6.5.0.5.1.carrier.3.4.e164.arpa
@	100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" .
*	100 10 "u" "E2U+sip" "!(^.*)$!sip:\\1 at sbc.my-carrier.at!" .

As for zone-sharing, I think the problem is obvious.

/ol
-- 
< Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer >