About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section

Re: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt

  • To: Patrik Fältström patrik@localhost, IETF ENUM WG enum@localhost
  • From: Otmar Lendl lendl@localhost
  • Date: Mon, 6 Nov 2006 23:17:35 +0100
  • Mail-followup-to: Otmar Lendl lendl@localhost, Patrik Fältström patrik@localhost, enum-wg@localhost, IETF ENUM WG enum@localhost

[quick reply to just answer some question on open numbering plans.]

On 2006/11/06 22:11, Patrik Fältström patrik@localhost wrote:
> On 6 okt 2006, at 00.06, Otmar Lendl wrote:
> 
> >In I-ENUM, Telekom Austria (were they to take part in our trial) would
> >use wildcards to direct calls to their ingress point, e.g. by
> >
> >6.1.4.5.0.5.1.3.4.e164.arpa  NAPTR ... "!(.*)!\\1@localhost
> >*.6.1.4.5.0.5.1.3.4.e164.arpa  NAPTR ... "!(.*)!\\1@localhost
> >
> >Which records should Telekom Austria provision under your scheme?
> 
> If I understand you correctly, Telekom Austria is running telephony  
> for the number +43 1 5056416, but then you as a user of that number  
> can add whatever digits you want as "extensions" as the routing is  
> prefix based. I presume as long as the number of digits totally is  
> fewer than 15 :-)

Correct. 

> Can you "port" that prefix from Telekom Austria to someone else?

Yes.

> Today, as you point out, there should be a zone  
> 6.1.4.5.0.5.1.3.4.e164.arpa in which you instead of "just" having  
> NAPTR records for the name of the zone, you have NAPTR for the  
> extensions you have.
> 
> Example (not open numbering plan):
> 
> 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ...
> 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ...
> 6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ...
> 
> With open numbering plan:
> 6.1.4.5.0.5.1.3.4.e164.arpa. IN SOA ...
> 6.1.4.5.0.5.1.3.4.e164.arpa. IN NS ...
> 3.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ...
> 4.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ...
> 5.3.6.1.4.5.0.5.1.3.4.e164.arpa. IN NAPTR ...

Correct. This actually quite efficient as you just have to maintain
a single zone for the full PBX and not one per extension.

(On the other hand, this s*cks for us as the ENUM registry as 
we can only sell a single delegation to big corporate PBXs.)

> How do you handle number portability for these numbers (that end with  
> 33, 34 and 35)? Can they be ported one at a time, or just the whole  
> block at the same time?

Porting is only possible at the number level, not on the extension
level. For that example, we can take +43 1 5056416 plus all
existing extensions to a different operator, but we can't port
out individual extensions like +43 1 5056416 33.

(This is similar to the email/domain porting question that
came up here at the ietf meeting just now: Domains can be "ported",
and take all email addresses with them.)

> Good discussion, lets continue.

Indeed.

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




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community