October 2006 - enum-wg - mailman.ripe.net

RE: [enum-wg] Concerning Wildcards and I-ENUM
by Antoin Verschuren 09 Oct '06

09 Oct '06

Otmar Lendl wrote: > Corrolary: The ENUM v2 scheme that Patrick and Olof came up with will > neither solve User-ENUM vs. I-ENUM branching, nor will it be suitable > for an I-ENUM deployment in a country with an open numbering plan. > > Please convince me that I'm wrong about this one. Hi Otmar, I have expressed the same worries about it, and Patrick and Olaf considder this a layer nine issue rather than something they're trying to solve. Not only for open numbering plans, but also for block allocations, ENUM v2 offers no solution for the authority over the delegation problem. I considder this the real issue, and even though ENUM v2 will solve direct querying for specific records, the increase in delegation points will not have any value for non fixed length numbers, and might even confuse people even more. But they do have a valid point when they say that any (new) type of operator might claim their own tree to control their ENUM space, and we need a solution for that. I think that differentiating should take place as close to the root as possible to make sure that implementation is the same around the world, and applications know where to query. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

Concerning Wildcards and I-ENUM
by Otmar Lendl 09 Oct '06

09 Oct '06

During Robert's talk on Infrastructure ENUM in Austria I heard some harrumphes on the mentioning of us using wildcard records. While I can see that wildcards are a dangerous issue, I really doubt that we can avoid them in our setting. I've explained the issue recently to the Denic ENUM list; here is an English version of the argument: The basic premise on the Denic list was that end-users should roll out their ENUM zones instead of using wildcards (especially as the new wildcard behavior as defined by RFC4592 can lead to unexpected result due to "empty non-terminals"). In order to roll out a wildcard into individual entries you need to know the number length used within that PBX or more generally, that prefix. This is certainly a non-issue in all countries which have fixed length telephone numbers. Germany and Austria use open numbering plans, though, where e.g. PBX operators are free to devise their own schemes behind their pilot number. For user-ENUM this is not a problem, as the PBX maintainer is also the DNS admin for the ENUM zone: he knows what numbering-plan he has implemented on the PBX, he thus can generate the appropriate (non-wildcard) NAPTR records in his own ENUM zone file. Infrastructure ENUM is different, though: We (as the Registry) see only the number blocks as given from the NRA to the carriers, and not a) the length of numbers assigned to subscribers b) whatever extensions the subscribers themselves add to those numbers. Right now, PBX operators do not have to tell their carriers about extension they provision on their PBXs. They don't even have to be constant length, schemes where -9XX is the FAX box of -XX are common. The same is true for direct calls to voice-mail. In other words, the carriers themselves often don't know the length of telephone numbers within their own blocks. They just know the length of the pilot number they have give out to their customers. This, too can vary quite a bit: Consider Vienna (+43 1), where the current rules say: * "normal" number length is 7 digit. (e.g. +43 1 5056416) * Carriers usually get blocks of 10000 numbers, e.g. +43 1 236* * Customers connected via ISDN PRIs can apply for shorter number, down to 5 digits, e.g. +43 1 59966) * There are two legacy 4 digit numbers, +43 1 4177 and +43 1 4000 (University and City Hall). * In all cases customer are free to define their own extension numbers up to a total number length of 14 digits (under certain circumstances, 15 is legit as well). For the default number length in Vienna, this means e.g. +43 1 5056416 ABCD. There are now two issues: 1) Is there a way for us to learn about the length of numbers in use? 2) If not, can't we just roll out the zone anyway? ad 1): For that to happen, all PBX operators (That need not be an enterprise. A simple ISDN BRI in P2P mode is enough) need to tell their carriers about their installation and the carriers need forward that information (plus all their normal assignment info (which also can vary within a block) to us so that we can generate the proper non-wildcard records. This is extremely unlikely to happen. ad 2) consider e.g. the record *.6.3.2.1.i.3.4.e164.arpa. NAPTR 10 10 "u" "E2U+sip" "!^(.*)$!sip:\\1@enum.sil.at!" . which corresponds to +43 1 236, which is a block owned by Silverserver. This one is provisioned in our I-ENUM database as one single record. Let's assume we roll that out to cover all possible assignement: there are 4 digits Silverserver can assign and 4 more that the customer can add. This means 8 digits, thus 10^8 possible records. Shorter numbers are of course also possible, so we have to add another 10^4 + 10^5 + 10^6 + 10^7 records. A full roll-out of this one single block add thus 111 million NAPTR records to our zonefile. This is not a viable option for us. -------------- Thus: For I-ENUM in Austria, we need wildcards. Corrolary: The ENUM v2 scheme that Patrick and Olof came up with will neither solve User-ENUM vs. I-ENUM branching, nor will it be suitable for an I-ENUM deployment in a country with an open numbering plan. Please convince me that I'm wrong about this one. /ol -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer >

2 1

Questions concerning CRUE
by Otmar Lendl 09 Oct '06

09 Oct '06

Jim, yesterday's session was bit tight in terms of time for questions, thus here they come on the list. There are a few points where I'm not sure I understand the CRUE proposal, so please correct me if I got this wrong: * The registry will not provision any CRUE records just by themselves. * The main difference between CRUE entries and normal delegations are: + CRUE records are requested by the carrier, and not the end-user. + CRUE records are validated by public Ofcom block allocation data, vs. whatever you do for normal user-enum + CRUE records use NAPTRs in the registry vs. normal delegations based on NS records in the Tier1 zone * From the point of the ENUM client which just cares about NAPTR records, there is no difference between Numern->URI mappings provided by CRUE records and normal user-enum NAPTR records. Some more questions: * You said that the registry makes no assumptions on the reachability of the SIP URIs contained in the CRUE record. What about the carriers interested in CRUE? Did you talk to them about their plans? One of the reasons we started the I-ENUM trial here was the fact that some of the operators refused to run open servers and wanted detailed control on whom they peer with. * What about ported numbers? From what I know about the .uk system, Ofcom doesn't hold information about those. * CRUE entries will be provisioned by the number-owning carrier: Will they have to send a CRUE request for every single number, or will there be a block-provisioning interface? If yes, will that make use of the NAPTR regexp feature to have identical NAPTR records for whole blocks? Thanks, /ol -- < Otmar Lendl (lendl(a)nic.at) | nic.at Systems Engineer >

2 1

Thank you
by Niall O'Reilly 05 Oct '06

05 Oct '06

On behalf of both co-chairs, I'ld like to say a warm "thank you" to all who made the RIPE 53 ENUM WG session so interesting by presenting material, and especially to the NCC staff who delivered support services for the meeting: minute-taking, jabber monitoring, and technical support. For myself, I'ld like to thank my co-chair, Carsten Schiefner, for all his work in preparation for the meeting. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Per Heldal wrote: > On Wed, 2006-10-04 at 09:47 +0200, Antoin Verschuren wrote: > [snip] >> I can see a reason for the term "REGISTRY" if RIPE intends to expand >> heir services to more than IP network services, and doesn't feel to >> create a long list of different marketing terms for different >> organisations. I work for a ccTLD registry that is not an LIR, and >> even though that is a clear Internet registry function like IANA, >> RIR or LIR, RIPE currently does not supply a service for that >> function that requires an entry in the DB. >> >> Conclusion: >> I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. >> I cannot live with the org-type NON-REGISTRY. >> >> My prefference would be the ENUM-REGISTRY org-type. > > > This proposal is taking things out of context. The word REGISTRY in > RIPE-terms means an IP-address registry. Nothing more, nothing less. > That your organisation is categorised as NON-REGISTRY by RIPE doesn't > mean that RIPE does not acknowledge your role as a registry in some > other context, just that you're not an ip-addr registry. Should the > database contain exceptions for all kinds of registries which happen > to deal with something else than ip-addresses? That's why we changed the proposal to change the NON-REGISTRY into OTHER. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

2 1

RE: [db-wg] Re: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

leo vegoda wrote: > Do people find org-type values like IANA, RIR, LIR and so on useful? > If not, maybe we just need two values: REGISTRY for IANA, RIRs, LIRs, > TLDs and Tier 1 ENUM operators and NON-REGISTRY for everyone else. > However, if people really find the hierarchical distinctions in the > current org-type values useful, maybe we need some additional > granularity for the different kinds of domain registries? > > If the extra granularity is useful, perhaps we need to allow > organisations to have multiple org-type values? That's probably > preferable to having multiple objects for a single organisation. It depends on what is is supposed to be used for in the DB. If is is needed to distinguish types of organisations when making queries, the types makes sense. But if it's only there to give a label and it is never used, it doesn't. I wouldn't mind changing the "NON-REGISTRY" into "OTHER", like I now have to apply for a RIPE meeting. But on the other hand, if RIPE wants to use it as a differentiation of their customers, and this would be expressed in the RIPE DB, I think ENUM-REGISTRY would be appropriate, and I would also find it logical I can register at a RIPE meeting as "ENUM-REGISTRY". It's then just a customer type. I can see a reason for the term "REGISTRY" if RIPE intends to expand heir services to more than IP network services, and doesn't feel to create a long list of different marketing terms for different organisations. I work for a ccTLD registry that is not an LIR, and even though that is a clear Internet registry function like IANA, RIR or LIR, RIPE currently does not supply a service for that function that requires an entry in the DB. Conclusion: I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. I cannot live with the org-type NON-REGISTRY. My prefference would be the ENUM-REGISTRY org-type. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

4 3

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 05 Oct '06

05 Oct '06

Marco d'Itri wrote: > On Oct 03, leo vegoda <leo(a)ripe.net> wrote: > >> Do people find org-type values like IANA, RIR, LIR and so on useful? >> No. What would be the point? As Leo pointed out: Looking back into the mail archives for 2003 and 2004 I think the original purpose was to let people know how close to the End User the registration on a block of IP addresses was. If my memory is correct, the org-type was introduced after it was felt that status attribute values like "ALLOCATED-BY-IANA" or "ALLOCATED-BY-RIR" would overburden the status attribute syntax unnecessarily. One of the possible functionality could be that you'd not like to contact certain organisations holding numberblocks when abuse comes from them since you will know these numbers are distributed in a specific fashon, and you'll probably be not reaching an end user. Don't know if such routines are used. Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

Documentation of ENUM requests
by Carsten Schiefner 05 Oct '06

05 Oct '06

Dear colleagues, on 3 Sep I have sent the email quoted below to the list. Other than stated in the last sentence, we felt it necessary - in particular in the absence of any so far - to solicit for more input and therefore to extend the discussion period. I have just given a short, one slide presentation in the ENUM WG session which is (temporarily only?) available at: https://www.ripe.net/ripe/meetings/ripe-53/presentations/uploads/Wednesday/… (PPS, no PDF yet). Please find a TXT version here: Advantages Disadvantages ZIP file containing Less hits when searching, Potentially large ZIP all documents concept of a „single file file to download for per case“, easy just a small piece maintenance: just put of information additional stuff in the ZIP file Separate files, all Good overview, well Many hits when linked on a structured filing, concept searching, per-country basis we had already potentially confusing – maybe still not all relevant documents returned Please be invited to comment at to let the WG know about your preferrences. Regards, Carsten Schiefner (for the ENUM WG Co-Chairs) -------- Original Message -------- Subject: [enum-wg] Documentation of ENUM requests Date: Sun, 03 Sep 2006 15:38:21 +0200 From: Carsten Schiefner <enumvoipsip.cs(a)schiefner.de> To: enum-wg(a)ripe.net Dear colleagues, this is to start a discussion - if necessary - on how the RIPE NCC is supposed to document ENUM requests. As a short recap: 1.6 of the "IAB Instructions to the RIPE NCC Regarding operation of the domain e164.arpa ("ENUM")" [http://www.ripe.net/enum/instructions.html] mandates that "all communication regarding the application for a specific delegation is to be publicly archived". That used to be done from the overview page at: http://www.ripe.net/enum/request-archives/ by a link to the respective E.164 CC specific page, eg. Germany at: http://www.ripe.net/enum/request-archives/enum-request-arch+49/ An archived snapshot of the overview page is available at: http://web.archive.org/web/20030826073846/http://www.ripe.net/enum/request-… The RIPE NCC has now proposed a way of documentation where - instead of having a separate page per E.164 CC request - the overview page links to ZIP archives that would contain all sorts of communication like emails, scanned letters and faxes etc. pp. I intend to set the deadline for this discussion to the WG session at RIPE 53 - please be invited to voice any concerns, suggenstions etc. here on the list until then. Best, Carsten Schiefner

2 1

RE: [enum-wg] Proposal for new org-type
by Antoin Verschuren 04 Oct '06

04 Oct '06

Niall O'Reilly wrote: > This message has two purposes. > > It is addressed to the ENUM WG with the purpose of determining > consensus in this WG on the proposal from Antoin Verschuren. To let there be no misunderstanding, the final proposal with most consensus so far is: >> In order for ENUM registries to not be misinterpreted in the RIPE >> NCC database, I want to propose to change an organization type to be >> used in the organization object. >> Current organization types are: >> >> IANA >> RIR >> NIR >> LIR >> NON-REGISTRY >> >> I would like this NON-REGISTRY to be changed to OTHER. > > I will declare consensus in the ENUM WG unless objections to Antoin's > proposal are posted on the ENUM WG mailing list before 12:00 UTC on > Thursday, 18 October 2006. Regards, Antoin Verschuren Technical Advisor Policy & Business Development SIDN Utrechtseweg 310 PO Box 5022 6802 EA Arnhem The Netherlands T +31 26 3525510 F +31 26 3525505 M +31 6 23368970 E antoin.verschuren(a)sidn.nl W http://www.sidn.nl/

1 0

.8.5.3.e164.arpa launched commercially
by Carsten Schiefner 03 Oct '06

03 Oct '06

Dear ENUM WGers, it was with great pleasure when I read Juhani's email quoted below. Congratulations to FICORA and a prospering future to all coming ENUM efforts in Finland! Best, Carsten (on behalf of the ENUM WG Co-Chairs) -------- Original Message -------- Subject: [centr-ga] .8.5.3.e164.arpa launched commercially Date: Tue, 3 Oct 2006 12:35:05 +0300 From: Juselius Juhani <juhani.juselius(a)ficora.fi> To: <ga(a)centr.org> Dear Colleagues, Ficora launched .8.5.3.e164.arpa user ENUM into public commercial operation yesterday after succesfull pilot phase that started in 2003. The database was cleared between the pilot phase and commercial operation and thus there are no delegations at the moment. Our next aim is to get as much support from telcos and registrars for ENUM as possible. Currently I'm optimistic for their support since we are having good discussions with all major Finnish telcos. Kind Regards, Juhani

1 0