From Antoin.Verschuren at sidn.nl Tue Oct 3 10:35:33 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 3 Oct 2006 10:35:33 +0200 Subject: [enum-wg] Proposal for new org-type Message-ID: Hi all, In order for ENUM registries to be correctly distinguished in the RIPE NCC database, I want to propose a new organization type to be used in the organization object. Current organization types are: IANA RIR NIR LIR NON-REGISTRY I would like this list to be extended with the term REGISTRY. I will note the issue tomorow in the ENUM WG, but need consensus to take place here, so please comment either here or tomorrow in the ENUM WG session. 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 at sidn.nl W http://www.sidn.nl/ From saleh at nic.ir Tue Oct 3 12:20:43 2006 From: saleh at nic.ir (alireza saleh) Date: Tue, 03 Oct 2006 13:50:43 +0330 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <4522397B.8010801@nic.ir> Hi, I agree with you about extending the organization type, but I think the REGISTRY can cover many things including ENUM, The more specific term may be the better choice. Alireza Saleh .ir ccTLD Antoin Verschuren wrote: > Hi all, > > In order for ENUM registries to be correctly distinguished in the RIPE > NCC database, I want to propose a new organization type to be used in > the organization object. > > Current organization types are: > IANA > RIR > NIR > LIR > NON-REGISTRY > > I would like this list to be extended with the term REGISTRY. > > I will note the issue tomorow in the ENUM WG, but need consensus to take > place here, so please comment either here or tomorrow in the ENUM WG > session. > > 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 at sidn.nl > W http://www.sidn.nl/ > From jim at rfc1035.com Tue Oct 3 12:28:13 2006 From: jim at rfc1035.com (Jim Reid) Date: Tue, 3 Oct 2006 11:28:13 +0100 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: On Oct 3, 2006, at 09:35, Antoin Verschuren wrote: > I would like this list to be extended with the term REGISTRY. > > I will note the issue tomorow in the ENUM WG, but need consensus to > take > place here, so please comment either here or tomorrow in the ENUM WG > session. I strongly support the idea of having a new organisation type to describe ENUM "registries". I do not support your suggestion for this type to be called REGISTRY. First of all, it's too confusing: isn't an LIR or an RIR a "registry"? And would a DNS registry operator like SIDN (say) be a REGISTRY or an LIR when it gets address space and AS numbers from an RIR? Secondly, it is too specific to define the thing that "owns" an ENUM delegation as a REGISTRY. In the UK (and probably other countries), the entity that oversees the ENUM delegation is a company that has an arms-length relationship with the Administration/ Regulator. That company does not run a registry itself. Instead it will have a contract with a registry operator. There may well be other governance models for ENUM that will be adopted which mean the "ownership" of an ENUM delegation does not go to a registry operator. There would be something else that wasn't a registry in between. I think we need a name for this type that is more neutral and doesn't imply a specific governance model. How about EIR: ENUM Internet Registry? From Antoin.Verschuren at sidn.nl Tue Oct 3 14:10:00 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 3 Oct 2006 14:10:00 +0200 Subject: [enum-wg] Proposal for new org-type Message-ID: Jim Reid wrote: > On Oct 3, 2006, at 09:35, Antoin Verschuren wrote: > >> I would like this list to be extended with the term REGISTRY. >> >> I will note the issue tomorow in the ENUM WG, but need consensus to >> take place here, so please comment either here or tomorrow in the >> ENUM WG session. > > I strongly support the idea of having a new organisation type to > describe ENUM "registries". I was actually going to sugest ENUM-REGISTRY as org type. But RIPE NCC told me they'd favoured the term REGISTRY, probably so they could also use it for other registries not active in the RIR world. Perhaps they have the intention to sell their database to registration organisation for car license plates or whatever. Would thy then need to introduce another org-type ? (License-plate-REGISTRY). So should I change the proposal to be ENUM-REGISTRY ? 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 at sidn.nl W http://www.sidn.nl/ From Niall.oReilly at ucd.ie Tue Oct 3 15:13:40 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Tue, 03 Oct 2006 15:13:40 +0200 Subject: [enum-wg] ENUM WG Agenda at RIPE 53 Message-ID: The current version of the agenda is available at https://www.ripe.net/ripe/meetings/ripe-53/presentations/uploads/ Wednesday/oreilly-enum_wg_agenda.pdf Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From ondrej.sury at nic.cz Tue Oct 3 16:11:08 2006 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Tue, 03 Oct 2006 16:11:08 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <1159884668.16346.32.camel@kaname> On Tue, 2006-10-03 at 14:10 +0200, Antoin Verschuren wrote: > Jim Reid wrote: > > On Oct 3, 2006, at 09:35, Antoin Verschuren wrote: > > > >> I would like this list to be extended with the term REGISTRY. > >> > >> I will note the issue tomorow in the ENUM WG, but need consensus to > >> take place here, so please comment either here or tomorrow in the > >> ENUM WG session. > > > > I strongly support the idea of having a new organisation type to > > describe ENUM "registries". > > I was actually going to sugest ENUM-REGISTRY as org type. > But RIPE NCC told me they'd favoured the term REGISTRY, probably so they > could also use it for other registries not active in the RIR world. What about ccTLD and gTLD registries? (Most of them are LIRs, but there could be some corner cases...) Ondrej. -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3894 bytes Desc: not available URL: From enumvoipsip.cs at schiefner.de Tue Oct 3 16:37:19 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 03 Oct 2006 16:37:19 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <1159884668.16346.32.camel@kaname> References: <1159884668.16346.32.camel@kaname> Message-ID: <4522759F.8070403@schiefner.de> Ondrej, Ond?ej Sur? wrote: >On Tue, 2006-10-03 at 14:10 +0200, Antoin Verschuren wrote: >> I was actually going to sugest ENUM-REGISTRY as org type. >> But RIPE NCC told me they'd favoured the term REGISTRY, probably so they >> could also use it for other registries not active in the RIR world. > > What about ccTLD and gTLD registries? (Most of them are LIRs, but there > could be some corner cases...) I am not entirely sure what you mean, I am afraid. Could you clarify? Thanks and best: -C. From enumvoipsip.cs at schiefner.de Tue Oct 3 16:41:02 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 03 Oct 2006 16:41:02 +0200 Subject: [enum-wg] .8.5.3.e164.arpa launched commercially Message-ID: <4522767E.4090705@schiefner.de> 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 To: 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 From ondrej.sury at nic.cz Tue Oct 3 16:52:52 2006 From: ondrej.sury at nic.cz (=?UTF-8?Q?Ond=C5=99ej_Sur=C3=BD?=) Date: Tue, 03 Oct 2006 16:52:52 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <4522759F.8070403@schiefner.de> References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> Message-ID: <1159887172.16346.44.camel@kaname> On Tue, 2006-10-03 at 16:37 +0200, Carsten Schiefner wrote: > Ondrej, > > Ond?ej Sur? wrote: > >On Tue, 2006-10-03 at 14:10 +0200, Antoin Verschuren wrote: > >> I was actually going to sugest ENUM-REGISTRY as org type. > >> But RIPE NCC told me they'd favoured the term REGISTRY, probably so they > >> could also use it for other registries not active in the RIR world. > > > > What about ccTLD and gTLD registries? (Most of them are LIRs, but there > > could be some corner cases...) > > I am not entirely sure what you mean, I am afraid. Could you clarify? My point was that not only ENUM registries exists in current internet. We are .cz domain registry and while I don't have problem with whatever label we have in RIPE database (we do have LIR atm), we don't exactly fall into LIR category (in it's original meaning - ie. ISP). Hence I could easily imagine that our org-type: would be changed to REGISTRY to match reality a bit more. Ondrej -- Ond?ej Sur? technick? ?editel/Chief Technical Officer ----------------------------------------- CZ.NIC, z.s.p.o. -- .cz domain registry Americk? 23,120 00 Praha 2,Czech Republic mailto:ondrej.sury at nic.cz http://nic.cz/ sip:ondrej.sury at nic.cz tel:+420.222745110 mob:+420.739013699 fax:+420.222745112 ----------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3894 bytes Desc: not available URL: From enumvoipsip.cs at schiefner.de Tue Oct 3 17:13:25 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 03 Oct 2006 17:13:25 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <1159887172.16346.44.camel@kaname> References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> <1159887172.16346.44.camel@kaname> Message-ID: <45227E15.9050602@schiefner.de> Hi Ondrej, > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to REGISTRY to > match reality a bit more. I see. But although LIRs are indeed mostly ISPs AFAIK the term was never strictly meant or used for ISPs only. There is Enterprise LIRs, too - these LIRs do get allocations as well, but make assignments only for own purposes, they do not assign address space further down the food chain. NICs from my PoV would clearly fall under that category - if they became an LIR once. So although I see where you coming from and aiming at, I'd say that in these cases the governing agreement between RIR (RIPE NCC) and LIR (a NIC aka. ccTLD registry) is the standard LIR agreement - so the type "LIR" seems to be more correct to me... Best, -C. From enumvoipsip.cs at schiefner.de Tue Oct 3 17:15:36 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 03 Oct 2006 17:15:36 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <1159887172.16346.44.camel@kaname> References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> <1159887172.16346.44.camel@kaname> Message-ID: <45227E98.30508@schiefner.de> Oh, ... Ond?ej Sur? wrote: > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to REGISTRY to > match reality a bit more. ... I forgot to send a link I had been pointed at (Thanks, Leo!) where some definition for an LIR can be found: http://www.ripe.net/info/faq/membership/newlir-registration.html#3 Best, -C. From leo at ripe.net Tue Oct 3 17:22:54 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 3 Oct 2006 17:22:54 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <1159887172.16346.44.camel@kaname> References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> <1159887172.16346.44.camel@kaname> Message-ID: Hi, I cc'd the Database WG list for input on object syntax. On 3 Oct 2006, at 4:52GMT+02:00, Ond?ej Sur? wrote: [...] > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with > whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to > REGISTRY to > match reality a bit more. One legal entity might run an LIR, a ccTLD registry and an ENUM registry. Whether you want to identify them as a REGISTRY, a DOMAIN- REGISTRY or something else is dependent on what you want to use the org-type to tell people. 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. 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. Thoughts? -- leo vegoda Registration Services Manager RIPE NCC From leo at ripe.net Tue Oct 3 17:22:54 2006 From: leo at ripe.net (leo vegoda) Date: Tue, 3 Oct 2006 17:22:54 +0200 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: <1159887172.16346.44.camel@kaname> References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> <1159887172.16346.44.camel@kaname> Message-ID: Hi, I cc'd the Database WG list for input on object syntax. On 3 Oct 2006, at 4:52GMT+02:00, Ond?ej Sur? wrote: [...] > My point was that not only ENUM registries exists in current internet. > We are .cz domain registry and while I don't have problem with > whatever > label we have in RIPE database (we do have LIR atm), we don't exactly > fall into LIR category (in it's original meaning - ie. ISP). Hence I > could easily imagine that our org-type: would be changed to > REGISTRY to > match reality a bit more. One legal entity might run an LIR, a ccTLD registry and an ENUM registry. Whether you want to identify them as a REGISTRY, a DOMAIN- REGISTRY or something else is dependent on what you want to use the org-type to tell people. 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. 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. Thoughts? -- leo vegoda Registration Services Manager RIPE NCC From Antoin.Verschuren at sidn.nl Wed Oct 4 09:47:26 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 4 Oct 2006 09:47:26 +0200 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type Message-ID: 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 at sidn.nl W http://www.sidn.nl/ From saleh at nic.ir Wed Oct 4 10:23:44 2006 From: saleh at nic.ir (alireza saleh) Date: Wed, 04 Oct 2006 11:53:44 +0330 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <45236F90.7010007@nic.ir> ENUM-REGISTRY or any other terms is good, but, I think it would be better to follow the hierarchy model. Having REGISTRY at the top and more specific label such as org-detail: to describe the what kind of registry as a child. Alireza Antoin Verschuren wrote: > Jim Reid wrote: >> On Oct 3, 2006, at 09:35, Antoin Verschuren wrote: >> >>> I would like this list to be extended with the term REGISTRY. >>> >>> I will note the issue tomorow in the ENUM WG, but need consensus to >>> take place here, so please comment either here or tomorrow in the >>> ENUM WG session. >> I strongly support the idea of having a new organisation type to >> describe ENUM "registries". > > I was actually going to sugest ENUM-REGISTRY as org type. > But RIPE NCC told me they'd favoured the term REGISTRY, probably so they > could also use it for other registries not active in the RIR world. > Perhaps they have the intention to sell their database to registration > organisation for car license plates or whatever. > Would thy then need to introduce another org-type ? > (License-plate-REGISTRY). > So should I change the proposal to be ENUM-REGISTRY ? > > > 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 at sidn.nl > W http://www.sidn.nl/ > From Niall.oReilly at ucd.ie Wed Oct 4 17:07:30 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 04 Oct 2006 17:07:30 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <9EFEFF72-C371-48B7-85A8-43F63586BE67@ucd.ie> 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. It is addressed to the DB and NCC-Services WGs as an inter-WG communication to alert these WG's to expect a consensus in the ENUM WG and a request from ENUM WG for related changes to the RIPE database. On 3 Oct 2006, at 10:35, Antoin Verschuren wrote: > In order for ENUM registries to be correctly distinguished in the RIPE > NCC database, I want to propose a new organization type to be used in > the organization object. > > Current organization types are: > IANA > RIR > NIR > LIR > NON-REGISTRY > > I would like this list to be extended with the term REGISTRY. > > I will note the issue tomorow in the ENUM WG, but need consensus to > take > place here, so please comment either here or tomorrow in the ENUM WG > session. On 4 Oct 2006, at 09:47, Antoin Verschuren wrote: > I can live with ENUM-REGISTRY, REGISTRY, OTHER or no org-type at all. > I cannot live with the org-type NON-REGISTRY. During his presentation in the ENUM WG, Antoin Verschuren made the following proposal. > 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. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From Antoin.Verschuren at sidn.nl Wed Oct 4 17:20:27 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Wed, 4 Oct 2006 17:20:27 +0200 Subject: [enum-wg] Proposal for new org-type Message-ID: 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 at sidn.nl W http://www.sidn.nl/ From enumvoipsip.cs at schiefner.de Wed Oct 4 18:45:32 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Wed, 04 Oct 2006 18:45:32 +0200 Subject: [enum-wg] Documentation of ENUM requests Message-ID: <4523E52C.5010209@schiefner.de> 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/schiefner-enum_request_documentation.pps (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 To: enum-wg at 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-archives/index.html 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 From md at Linux.IT Wed Oct 4 16:22:02 2006 From: md at Linux.IT (Marco d'Itri) Date: Wed, 4 Oct 2006 16:22:02 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: <1159884668.16346.32.camel@kaname> <4522759F.8070403@schiefner.de> <1159887172.16346.44.camel@kaname> Message-ID: <20061004142202.GA11339@wonderland.linux.it> On Oct 03, leo vegoda wrote: > Do people find org-type values like IANA, RIR, LIR and so on useful? No. What would be the point? -- ciao, Marco -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From jim at rfc1035.com Thu Oct 5 00:56:06 2006 From: jim at rfc1035.com (Jim Reid) Date: Wed, 4 Oct 2006 23:56:06 +0100 Subject: [enum-wg] Documentation of ENUM requests In-Reply-To: <4523E52C.5010209@schiefner.de> References: <4523E52C.5010209@schiefner.de> Message-ID: <198FBD2D-DB59-460E-BC28-0C1F8B01EF35@rfc1035.com> On Oct 4, 2006, at 17:45, Carsten Schiefner wrote: > Please be invited to comment at to let the WG know about your > preferrences. Zip file format sucks big time. IMO there is no need for a tarball (note!) until there is a large dataset that needs bulk access and that is generally preferred over fine-grained access. Personally, I would be rather peeved if I was forced to download a big tar file full of irrelevant data to get at the 0.5% that was of interest. Also, the ENUM request data is small -- the odd template or two per delegation -- so the whole subject is probably a non-issue. It would be better if the WG discusses file formats and suchlike once there was a real concern about them. Unless I'm very much mistaken, that point hasn't been reached yet., has it? If nobody's agitating for a solution to this "problem", perhaps it isn't a problem? Having goaded the WG into responding to this troll, I will now stt back and await the flame-fest. :-) From Antoin.Verschuren at sidn.nl Thu Oct 5 09:53:20 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 5 Oct 2006 09:53:20 +0200 Subject: [enum-wg] Proposal for new org-type Message-ID: Marco d'Itri wrote: > On Oct 03, leo vegoda 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 at sidn.nl W http://www.sidn.nl/ From lendl at nic.at Thu Oct 5 10:58:06 2006 From: lendl at nic.at (Otmar Lendl) Date: Thu, 5 Oct 2006 10:58:06 +0200 Subject: [enum-wg] Questions concerning CRUE Message-ID: <20061005085806.GA12719@nic.at> 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 at nic.at) | nic.at Systems Engineer > From heldal at eml.cc Thu Oct 5 11:05:20 2006 From: heldal at eml.cc (Per Heldal) Date: Thu, 05 Oct 2006 11:05:20 +0200 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <1160039121.12528.26.camel@localhost.localdomain> 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? //per -- Per Heldal - http://heldal.eml.cc/ From Antoin.Verschuren at sidn.nl Thu Oct 5 11:10:05 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 5 Oct 2006 11:10:05 +0200 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type Message-ID: 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 at sidn.nl W http://www.sidn.nl/ From Niall.oReilly at ucd.ie Thu Oct 5 11:13:59 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 05 Oct 2006 11:13:59 +0200 Subject: [enum-wg] Thank you Message-ID: 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 From Niall.oReilly at ucd.ie Thu Oct 5 12:15:33 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 05 Oct 2006 12:15:33 +0200 Subject: [enum-wg] Re: Proposal for new org-type In-Reply-To: <1160039121.12528.26.camel@localhost.localdomain> References: <1160039121.12528.26.camel@localhost.localdomain> Message-ID: On 5 Oct 2006, at 11:05, Per Heldal wrote: > This proposal is taking things out of context. Per, I think the context has changed since Antoin posted the text you commented on. 8-) > Should the database contain exceptions for all kinds of registries > which happen to deal with something else than ip-addresses? Antoin's final proposal to use "OTHER" seems to address this difficulty, no? Best regards, Niall O'Reilly University College Dublin Computing Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 From heldal at eml.cc Thu Oct 5 12:27:16 2006 From: heldal at eml.cc (Per Heldal) Date: Thu, 05 Oct 2006 12:27:16 +0200 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <1160044036.12528.35.camel@localhost.localdomain> On Thu, 2006-10-05 at 11:10 +0200, Antoin Verschuren wrote: [snip] > That's why we changed the proposal to change the NON-REGISTRY into > OTHER. Such a cosmetic change is no big deal (except it is pointless). It'll depend on the work involved I guess. It would be a whole different issue if the change involved functionality to specifically support RIPE's work related to the decision to handle e164 delegations. -- Per Heldal - http://heldal.eml.cc/ From enumvoipsip.cs at schiefner.de Thu Oct 5 15:44:15 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 05 Oct 2006 15:44:15 +0200 Subject: [enum-wg] Thank you, me too In-Reply-To: References: Message-ID: <45250C2F.7080805@schiefner.de> Niall O'Reilly wrote: > 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. Although Niall wrote that email - rightly so! - as well on my behalf, I'd nonetheless like to back that with a warm "Me, too!". > For myself, I'ld like to thank my co-chair, Carsten Schiefner, for all his > work in preparation for the meeting. And vice versa, I'd like to thank Niall for dealing with all the puzzle pieces that eventually formed the agenda and, once more, the session chairing. Best, Carsten Schiefner Co-Chair, RIPE ENUM Working Group From Woeber at CC.UniVie.ac.at Thu Oct 5 11:39:16 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 05 Oct 2006 09:39:16 +0000 Subject: [db-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: <1160039121.12528.26.camel@localhost.localdomain> References: <1160039121.12528.26.camel@localhost.localdomain> Message-ID: <4524D2C4.4010404@CC.UniVie.ac.at> I think we should recognize the fact that the network, and thus the NCC's functions, is changing over time. For quite a while the central activity was the IP(v4) Registry. With the agreement to support e164, we start to support a different registry. Thus I agree that NON-REGISTRY - as in the "old" enivironment, is no longer adequate. "I would like this NON-REGISTRY to be changed to OTHER." seems to be a very easonable way forward! Wilfried. 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? > > > //per From lendl at nic.at Fri Oct 6 09:06:56 2006 From: lendl at nic.at (Otmar Lendl) Date: Fri, 6 Oct 2006 09:06:56 +0200 Subject: [enum-wg] Re: [Enum] draft-ietf-enum-uri-00.txt Message-ID: <20061006070656.GJ15701@nic.at> The IETF enum list seems to be broken, but as Paf explained his proposal at the RIPE meeting in A'dam this week, here is a copy of my reply: ----- Forwarded message from Otmar Lendl ----- Date: Thu, 5 Oct 2006 16:21:40 +0200 From: Otmar Lendl To: Patrik F?ltstr?m Cc: IETF ENUM WG Subject: Re: [Enum] draft-ietf-enum-uri-00.txt On 2006/09/28 11:09, Patrik F?ltstr?m wrote: > This document was requested to be published the other day, but > publication seems to take some time. Thanks for the document, here are some question: > > 1. > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Applicability > Statement . . . . . . . . . . . . . . . . . . . 3 The formatting is a bit off (not only here, but also in the rfc-editor repository), could you please submit a version without unwanted line-breaks, and with page breaks? Concerning this example: > 6.2. Different providers for services for the same E.164 > > An organisation have the E.164 +442079460148, but different > organisations handle routing of calls for the number on the Internet > (with the help of SIP) and traditional PSTN. More specifically, the > two providers want to run DNS for the record(s) that refer to the > services they provide. I think I understand the pure DNS mechanics you propose. What I can't see right now is how this proposal fits into the Tier0/Tier1/ITSP/end-user scheme of actors. Where are the zone cuts and who is operating which zone? > The ENUM provider for the +44 country code in this case not only do > delegations on the full E.164 number, but delegations on the service > parameter values, as can be seen below: > > In this example we also include the NAPTR records that with the help > of the 'D' flag refer to the URI records. We also include NAPTR > records according to RFC 3761 [RFC3761] that give backward > compatibility. > > In zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa.: Who do you propose should run that zone? > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > > ;; NAPTR records that refer to URI records > IN NAPTR 1 1 "D" "E2U:sip" ( ; service > "" ; regexp > _sip._e2u ; replacement > ) > > IN NAPTR 1 1 "D" "E2U:tel" ( ;service > "" ;regexp > _tel._e2u ;replacement > ) This record is *important* to the telco running the phone service for this number. They won't want to live with the possibility that users can mess up the telco internal routing. > > ;; NAPTR records for RFC 3761 compatibility > IN NAPTR 1 1 "U" "E2U:sip" ( ;service > "!.*!sip:+442079460148 at sipprovider.net!" ; regexp > . ; replacement > ) In the current model, this record is supposed to be hosted on a user-controlled server. This puts us into a bind: > IN NAPTR 1 1 "U" "E2U:tel" ( ;service > "!.*!sip:+442079460148 at sipprovider.net!" ; regexp > . ; replacement > ) > > ;; Delegations to child zones > _sip._e2u IN NS ns1.example.net. > _tel._e2u IN NS ns1.example.com. Once again, the I-ENUM records are dependent on the management of the pure ENUM zone 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > In zone _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa: > > > $ORIGIN 8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. > _sip._e2u IN URI "sip:+442079460148 at example.net" Shouldn't that be $ORIGIN _sip._e2u.8.4.1.0.6.4.9.7.0.2.4.4.e164.arpa. @ IN URI "sip:+442079460148 at example.net" to indicate where the zone-cut is? ----------------------------- To summarize: If I were to start an ENUM deployment from scratch, this proposal is fine (except, see below). In this case, I'd put the IN NAPTR 1 1 "D" records in the Tier1 zone (autocreated based on *._e2u entries) and just delegate (optionally) the _sip._e2u subdomains to subscribers or ITSPs. That way, the DNS infrastructure of one application can be kept independent from the one of another application. The problem is the legacy 3761 support: For all the delegated domains out there, it is not acceptable for the carriers to go to their subscribers and asks them for a delegation of _tel._e2u. That ain't going to fly. In order to make the transition, current ENUM users need to provision their existing NAPTRs into the registry. That's going to be a headache for everybody who managed to get a 3761-based system up and running. ----------------------------- The showstopper: And then there is the issue of open numbering plans. I can't see how this scheme is supposed to work in a country where PBX operators are free to define their own variable-length dialplan behind their pilot number. Consider the example of enum.at's Vienna office: Our pilot number is +43 1 5056416. That's a normal (i.e. not shortened) Vienna number. We use 2-digit extension, e.g. -33 is my phone. A common scheme is to use prefixes for FAX to Email services. In our case -933 is supposed to deliver an incoming FAX to my mailbox. Our carrier (Telekom Austria) doesn't know or even care about these arrangements. In ENUM terms, right now we have a delegation for 6.1.4.5.0.5.1.3.4.e164.arpa and simply add new extensions to our zone file and be done with it. 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 at sip.telekom.at! *.6.1.4.5.0.5.1.3.4.e164.arpa NAPTR ... "!(.*)!\\1 at sip.telekom.at! Which records should Telekom Austria provision under your scheme? /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > ----- End forwarded message ----- -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From DMenzulskiy at beeline.ru Mon Oct 9 08:45:56 2006 From: DMenzulskiy at beeline.ru (Dmitriy V Menzulskiy) Date: Mon, 9 Oct 2006 10:45:56 +0400 Subject: Ha: Re: [enum-wg] Proposal for new org-type In-Reply-To: <45236F90.7010007@nic.ir> Message-ID: Alireza Saleh ???????? 04.10.2006 12:23:44: > ENUM-REGISTRY or any other terms is good, but, I think it would be > better to follow the hierarchy model. Having REGISTRY at the top and > more specific label such as org-detail: to describe the what kind of > registry as a child. I think, it's good idea: REGISTRY-IANA REGISTRY-RIR REGISTRY-NIR REGISTRY-LIR REGISTRY-ENUM REGISTRY-OTHER NON-REGISTRY WBR, Dmitry Menzulskiy "VimpelCom" JSC DM3740-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at rfc1035.com Mon Oct 9 12:22:42 2006 From: jim at rfc1035.com (Jim Reid) Date: Mon, 9 Oct 2006 11:22:42 +0100 Subject: [enum-wg] Questions concerning CRUE In-Reply-To: <20061005085806.GA12719@nic.at> References: <20061005085806.GA12719@nic.at> Message-ID: On Oct 5, 2006, at 09:58, Otmar Lendl wrote: > 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. Correct. > > * The main difference between CRUE entries and normal delegations are: > > + CRUE records are requested by the carrier, and not the end-user. Correct. > > + CRUE records are validated by public Ofcom block allocation data, > vs. whatever you do for normal user-enum Correct. > > + CRUE records use NAPTRs in the registry vs. normal delegations > based on NS records in the Tier1 zone Correct. > > * 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. Correct. > > 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? Yes. Some are less keen than others to disclose their intentions. I did speak to Robert Schischka about the problems of "open" and "closed" SIP servers on Thursday. If I understood him correctly some Austrian telcos are only allowing favoured telcos to use their SIP servers. I hope this doesn't happen in the UK. But if it does, that would probably be a breach of the UK ENUM codes of conduct, competition policy and so on. > > 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. Correct. In simple terms ported numbers are treated like an end-user delegation. The donor telco may ask for the ported number to be removed from the block. However they don't have to and that makes no difference anyway. The receiving telco will need to prove that they provide service for the ported number: essentially that'll be the same "heavyweight" authentication process for an end-user registration. The donor telco will be told that the number has been ported and given a chance to object. That provides some protection against slamming. > > * 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? A block provisioning interface will be provided. It's a minor tweak to the EPP schema. regexps can be used to populate the URIs. From lendl at nic.at Mon Oct 9 12:53:16 2006 From: lendl at nic.at (Otmar Lendl) Date: Mon, 9 Oct 2006 12:53:16 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM Message-ID: <20061009105316.GA16836@nic.at> 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 at 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 at nic.at) | nic.at Systems Engineer > From Antoin.Verschuren at sidn.nl Mon Oct 9 13:24:41 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Mon, 9 Oct 2006 13:24:41 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM Message-ID: 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 at sidn.nl W http://www.sidn.nl/ From pk at DENIC.DE Mon Oct 9 14:35:56 2006 From: pk at DENIC.DE (Peter Koch) Date: Mon, 9 Oct 2006 14:35:56 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM In-Reply-To: <20061009105316.GA16836@nic.at> References: <20061009105316.GA16836@nic.at> Message-ID: <20061009123556.GA15891@denics7.denic.de> On Mon, Oct 09, 2006 at 12:53:16PM +0200, Otmar Lendl wrote: > 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"). just to avoid misunderstandings: the article on our enum list was about pitfalls with wildcards that co-exist with 'many' real entries that then limit the coverage of the wildcard. A conclusion, not necessarily a recommendationw as, that for a namespace with the given properties, wildcards are a not too well suited substitute for real provisioning. The 'Infrastructure ENUM' case can be different when you do not have a priori knowledge of the namespace's full structure. And, finally, RFC 4592 did not change the ENT specification. -Peter From lendl at nic.at Mon Oct 9 15:45:24 2006 From: lendl at nic.at (Otmar Lendl) Date: Mon, 9 Oct 2006 15:45:24 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM In-Reply-To: References: Message-ID: <20061009134524.GC16836@nic.at> Antoin, On 2006/10/09 13:10, Antoin Verschuren wrote: > 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. draft-ietf-enum-branch-location-record-00 does solve this, as it provides a mechanism how new ENUM application can be directed to their own trees. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From enumvoipsip.cs at schiefner.de Mon Oct 9 16:48:12 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Mon, 09 Oct 2006 16:48:12 +0200 Subject: [enum-wg] Proposal for new org-type In-Reply-To: References: Message-ID: <452A612C.7030109@schiefner.de> Dmitriy, all - Dmitriy V Menzulskiy wrote: > Alireza Saleh ???????? 04.10.2006 12:23:44: > > ENUM-REGISTRY or any other terms is good, but, I think it would be > > better to follow the hierarchy model. Having REGISTRY at the top and > > more specific label such as org-detail: to describe the what kind of > > registry as a child. > > I think, it's good idea: > > REGISTRY-IANA > REGISTRY-RIR > REGISTRY-NIR > REGISTRY-LIR > REGISTRY-ENUM > REGISTRY-OTHER > NON-REGISTRY > > WBR, > > Dmitry Menzulskiy > "VimpelCom" JSC > DM3740-RIPE I believe we should keep things as simple as possible - and according to what's been discussed here on the list and during the session last week, the proposed "OTHER" seems to address everybody's need. Having said that, I'd like to reiterate Niall's call of Wed 4 Oct 2006, 15:07 UTC: === 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. === Best regards, Carsten From enumvoipsip.cs at schiefner.de Mon Oct 9 16:49:24 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Mon, 09 Oct 2006 16:49:24 +0200 Subject: [enum-wg] RIPE 52 draft minutes In-Reply-To: <45193275.10906@schiefner.de> References: <6F570226-3750-4C95-BFC2-C460341907A6@ucd.ie> <440EEB98.4020104@schiefner.de> <45193275.10906@schiefner.de> Message-ID: <452A6174.8070004@schiefner.de> Dear colleagues, Carsten Schiefner wrote: > Dear colleagues - > > First of all, our sincerest apologies for not having posted the minutes > earlier - we definitely see room for improvement here... > > Secondly, a warm "Thank you!" to Alex Le Heux of the RIPE NCC for taking > the minutes. The first draft is available at: > > http://www.ripe.net/ripe/wg/enum/minutes/r52-minutes.html > > Please send in any comments and/or corrections you may have to this list > directly and/or to , the deadline for this is > Tuesday, 3 Oct 2006, 12:00 UTC/14:00 Amsterdam local time. > > Further objections acceped in person at WG session, with immediate > decision on dealing with them at the meeting (could need more time on > list). In the absence of any objections, the minutes will be declared > "final" Monday, 9 Oct 2006. the minutes are now final. Best regards, -C. From Niall.oReilly at ucd.ie Mon Oct 9 21:06:15 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Mon, 09 Oct 2006 20:06:15 +0100 Subject: [enum-wg] Proposal for new org-type In-Reply-To: <452A612C.7030109@schiefner.de> References: <452A612C.7030109@schiefner.de> Message-ID: <5427FD8D-D46E-4578-83DD-20D4CB7A3569@ucd.ie> On 9 Oct 2006, at 15:48, Carsten Schiefner wrote: > Dmitriy V Menzulskiy wrote: >> Alireza Saleh ???????? 04.10.2006 12:23:44: >> > ENUM-REGISTRY or any other terms is good, but, I think it would be >> > better to follow the hierarchy model. Having REGISTRY at the >> top and >> > more specific label such as org-detail: to describe the what >> kind of >> > registry as a child. >> I think, it's good idea: >> REGISTRY-IANA >> REGISTRY-RIR >> REGISTRY-NIR >> REGISTRY-LIR >> REGISTRY-ENUM >> REGISTRY-OTHER >> NON-REGISTRY >> WBR, >> Dmitry Menzulskiy >> "VimpelCom" JSC >> DM3740-RIPE > > I believe we should keep things as simple as possible - and > according to what's been discussed here on the list and during the > session last week, the proposed "OTHER" seems to address > everybody's need. Actually, we MUST keep things as simple as possible. We're dealing with a real, existing database, not with a design exercise. Antoin's proposal is what's on the table: 'OTHER' in place of 'NON- REGISTRY'. Discussion of what would be "better" or a "good idea" is out of scope. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group From Antoin.Verschuren at sidn.nl Tue Oct 10 10:34:37 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Tue, 10 Oct 2006 10:34:37 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM Message-ID: Otmar Lendl wrote: > draft-ietf-enum-branch-location-record-00 does solve this, as it > provides a mechanism how new ENUM application can be directed to > their own trees. But it forces the application to know all countrycodes in a static list, and do an extra lookup. If it would be a queryable dynamic list, it would need an extra lookup too, but at least the application does not need to be countrycode aware, it could just look it up. 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 at sidn.nl W http://www.sidn.nl/ From Niall.oReilly at ucd.ie Wed Oct 11 10:32:27 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Wed, 11 Oct 2006 09:32:27 +0100 Subject: [enum-wg] Concerning Wildcards and I-ENUM In-Reply-To: References: Message-ID: On 10 Oct 2006, at 09:34, Antoin Verschuren wrote: > If it would be a queryable dynamic list, it would need an extra lookup > too, but at least the application does not need to be countrycode > aware, > it could just look it up. So how to fill the gap? Ignoring for a moment the fine structure of +1 and possible other corner cases, and assuming that the Tier-0 zone continues both to be available for transfer and to be a delegation-only zone, the list of country codes could be built dynamically using the following approach. % dig @ns-pri.ripe.net e164.arpa axfr \ | awk '($4 == "NS") && (/^[0-9]/) { print $1 }' \ | sort | uniq Perhaps it's worth considering desirable administrative constraints on the Tier-0 zone, in order to make some such method fornmally (rather than accidentally) possible? /Niall From jim at rfc1035.com Wed Oct 11 11:55:59 2006 From: jim at rfc1035.com (Jim Reid) Date: Wed, 11 Oct 2006 10:55:59 +0100 Subject: [enum-wg] E.164 "country codes" In-Reply-To: References: Message-ID: <69920420-C612-4B87-B220-3B83E247ECBF@rfc1035.com> FWIW, the ITU publishes a list of approved ENUM delegations on their web site. They also have a free download of the list of E.164 country codes. This is available in English, French and Spanish in PDF or Word format at http://www.itu.int/pub/T-SP-E.164A-2006/en. From Antoin.Verschuren at sidn.nl Thu Oct 12 10:07:24 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Thu, 12 Oct 2006 10:07:24 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM Message-ID: Niall O'Reilly wrote: > % dig @ns-pri.ripe.net e164.arpa axfr \ > | awk '($4 == "NS") && (/^[0-9]/) { print $1 }' \ > | sort | uniq > > Perhaps it's worth considering desirable administrative constraints > on the Tier-0 zone, in order to make some such method fornmally > (rather than accidentally) possible? This was sort of what I was thinking about, but not sure if it's a good idea. It would build further on the EBL record which was supposed to be a temporary solution. But now that we see that a demand for more ENUM space might arise, I wonder if it's the right path to do that in the countrycode's zone, or in the e164.arpa zone to allow separation of registries and their authorisation independent of the User ENUM registry, or perhaps in a complete different zone per ENUM application. The latter would require only one lookup, where the first needs 3. Cashing for countrycode discovery could be quite long, as it rarely changes, but NS records in e164.arpa could change more often. I wonder if countrycode discovery could have another benefit for applications besides branche discovery. Perhaps billing (dirty word), legal regime, specific numberplan properties, distance calculation or whatever gadget they might come up with might need countrycode awareness anyway. 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 at sidn.nl W http://www.sidn.nl/ From enumvoipsip.cs at schiefner.de Thu Oct 12 21:54:37 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Thu, 12 Oct 2006 21:54:37 +0200 Subject: [enum-wg] 1.3.e164.arpa consultations Message-ID: <452E9D7D.30306@schiefner.de> Antoin, in your presentation last week you mentioned the deadline of 9 Oct for the consultation on the 1.3.e164.arpa re-delegation to Stichting ENUM Nederland. Any outcome you could already share? Best, -C. From Antoin.Verschuren at sidn.nl Fri Oct 13 09:06:45 2006 From: Antoin.Verschuren at sidn.nl (Antoin Verschuren) Date: Fri, 13 Oct 2006 09:06:45 +0200 Subject: [enum-wg] 1.3.e164.arpa consultations Message-ID: Carsten Schiefner wrote: > Antoin, > > in your presentation last week you mentioned the deadline of 9 Oct for > the consultation on the 1.3.e164.arpa re-delegation to Stichting ENUM > Nederland. > > Any outcome you could already share? No, not yet. Our ministry is now evaluating the responses they got. Some responses might need an official statement from the government so they need some time to prepare that. They will come with an official statement on October 25th, which will also be the approval or non-approval for the redelegation request. >From what I hear unofficially in the market from people that responded, there are no real showstoppers, just some recommendations for the legal entity, some binding rules regarding validation, and no automatic approval for infrastructure ENUM without market consultation. We are happy to discuss these recommendations. I did not hear about oppositions to our plan, but then again I don't know all the responses. We'll see in 12 days. 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 at sidn.nl W http://www.sidn.nl/ From lendl at nic.at Fri Oct 13 11:08:12 2006 From: lendl at nic.at (Otmar Lendl) Date: Fri, 13 Oct 2006 11:08:12 +0200 Subject: [enum-wg] Concerning Wildcards and I-ENUM In-Reply-To: References: Message-ID: <20061013090812.GA11288@nic.at> On 2006/10/12 10:10, Antoin Verschuren wrote: > Niall O'Reilly wrote: > > > % dig @ns-pri.ripe.net e164.arpa axfr \ > > | awk '($4 == "NS") && (/^[0-9]/) { print $1 }' \ > > | sort | uniq > > > > Perhaps it's worth considering desirable administrative constraints > > on the Tier-0 zone, in order to make some such method fornmally > > (rather than accidentally) possible? I support this idea. > > This was sort of what I was thinking about, but not sure if it's a good > idea. > It would build further on the EBL record which was supposed to be a > temporary solution. > But now that we see that a demand for more ENUM space might arise, I > wonder if it's the right path to do that in the countrycode's zone, or > in the e164.arpa zone to allow separation of registries and their > authorisation independent of the User ENUM registry, or perhaps in a > complete different zone per ENUM application. We're still trying to find a solution for alternate ENUM application which has IMHO the following requirements: a) Doesn't work on the user-enum domain level. See my last mail. Summary: that doesn't work with different block delegation schemes for different ENUM applications and open numbering plans. b) Doesn't require full IETF/ITU action for each new application. That's just too slow. c) Enables per-country opt-in. Each country-code should be able to decide whether to opt-in into a new ENUM application specific tree or not, and decide where that tree will be and who is going to manage it. d) As little prior knowledge of numbering plans as possible. e) Efficient lookup strategies. I could not find a solutions which gets full marks on all these requirements. Something has to give. We can't branch at the number level. See a). That's a hard NO GO. We can't (at least initially) use a new apex. -> b). If we branch at the country code, we're violating d). Searching down the tree for an EBL (or the branch itself) violates e). What other options are there? Branching off at a fixed digit? For "normal" country codes, that must be at least 3 digits, though with +87810 and other delegations like that 5 might be the better option. For 3 digits, adding 100 EBL records in +1 isn't that much of a penalty (e.g. for us in +43, we'd just need add 10 EBLs), but doing it at 5 digits means 10.000 EBLs for +1. Manageable, but doesn't win the beauty-contest, either. I just don't see a perfect solution for this problem. The EBL is the least bad idea we could come up with. I'm open to other ideas on where the EBLs should be located in the user-enum tree. > The latter would require only one lookup, where the first needs 3. > Cashing for countrycode discovery could be quite long, as it rarely > changes, but NS records in e164.arpa could change more often. Yeah, but the NS record contents are irrelevant here. > I wonder if countrycode discovery could have another benefit for > applications besides branche discovery. Perhaps billing (dirty word), > legal regime, specific numberplan properties, distance calculation or > whatever gadget they might come up with might need countrycode awareness > anyway. Indeed. That might be helpful for stuff like the ecrit emergency code discovery as well. /ol -- < Otmar Lendl (lendl at nic.at) | nic.at Systems Engineer > From Niall.oReilly at ucd.ie Thu Oct 19 13:21:35 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 19 Oct 2006 12:21:35 +0100 Subject: [ncc-services-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: <9EFEFF72-C371-48B7-85A8-43F63586BE67@ucd.ie> References: <9EFEFF72-C371-48B7-85A8-43F63586BE67@ucd.ie> Message-ID: <386EABC5-487C-4234-BADA-B291DD05B0B0@ucd.ie> On 4 Oct 2006, at 16:07, Niall O'Reilly wrote: > During his presentation in the ENUM WG, Antoin Verschuren made the > following proposal. > >> 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. That was a typo. I'm sorry for the confusion. I should of course have put "12:00 UTC on Thursday, 19 October 2006". As this time has now arrived, and no positive objections to Antoin's proposal have been posted on the ENUM WG mailing list, I therefore now declare consensus in in the ENUM WG in favour of this proposal. On behalf of the ENUM WG, I request the RIPE-NCC to implement Antoin's proposal. I ask the Database and NCC-Services WGs to note this consensus and request the Chairs of these WGs to advise the RIPE-NCC whether there is any reason not to proceed with implementation of this proposal. Best regards, Niall O'Reilly Co-Chair, RIPE ENUM Working Group -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From Woeber at CC.UniVie.ac.at Thu Oct 19 15:09:58 2006 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Thu, 19 Oct 2006 13:09:58 +0000 Subject: [db-wg] Re: [ncc-services-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: <386EABC5-487C-4234-BADA-B291DD05B0B0@ucd.ie> References: <9EFEFF72-C371-48B7-85A8-43F63586BE67@ucd.ie> <386EABC5-487C-4234-BADA-B291DD05B0B0@ucd.ie> Message-ID: <45377926.2090706@CC.UniVie.ac.at> thanks for this alert, Niall! Niall O'Reilly wrote: > > On 4 Oct 2006, at 16:07, Niall O'Reilly wrote: > >> During his presentation in the ENUM WG, Antoin Verschuren made the >> following proposal. >> >>> 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. > > > That was a typo. I'm sorry for the confusion. > I should of course have put "12:00 UTC on Thursday, 19 October 2006". > > As this time has now arrived, and no positive objections to Antoin's > proposal have been posted on the ENUM WG mailing list, I therefore now > declare consensus in in the ENUM WG in favour of this proposal. > > On behalf of the ENUM WG, I request the RIPE-NCC to implement Antoin's > proposal. > > I ask the Database and NCC-Services WGs to note this consensus and > request the Chairs of these WGs to advise the RIPE-NCC whether there is > any reason not to proceed with implementation of this proposal. I have not heard additional input since the DB-WG meeting on Friday morning, so in accordancve with action [DB-AP53.5 WW144] (1) I herewith ask the RIPE NCC to proceed with implementation. > Best regards, > > Niall O'Reilly > Co-Chair, RIPE ENUM Working Group Best regards, Wilfried. (1) Please see item Y., close to the bottom of http://www.ripe.net/ripe/maillists/archives/db-wg/2006/msg00217.html From Niall.oReilly at ucd.ie Thu Oct 19 20:27:33 2006 From: Niall.oReilly at ucd.ie (Niall O'Reilly) Date: Thu, 19 Oct 2006 19:27:33 +0100 Subject: [db-wg] Re: [ncc-services-wg] Re: [enum-wg] Proposal for new org-type In-Reply-To: <45377926.2090706@CC.UniVie.ac.at> References: <9EFEFF72-C371-48B7-85A8-43F63586BE67@ucd.ie> <386EABC5-487C-4234-BADA-B291DD05B0B0@ucd.ie> <45377926.2090706@CC.UniVie.ac.at> Message-ID: On 19 Oct 2006, at 14:09, Wilfried Woeber, UniVie/ACOnet wrote: > thanks for this alert, Niall! [ ... ] > I have not heard additional input since the DB-WG meeting on Friday > morning, > so in accordancve with action [DB-AP53.5 WW144] (1) I herewith ask the > RIPE NCC to proceed with implementation. Thanks for your prompt and helpful response, Wilfried! Best regards, Niall From kewin at acm.org Tue Oct 24 03:18:09 2006 From: kewin at acm.org (Kewin Stoeckigt) Date: Tue, 24 Oct 2006 11:18:09 +1000 Subject: [enum-wg] ENUM Day Australia Message-ID: <453D69D1.5010305@acm.org> Hi all, Please find attached a flyer for the upcoming ENUM Day seminar, which will be held in Sydney on 15 November 2006. The FREE seminar will be jointly conducted by ACMA, AusRegistry International, AARNet and Instra Corporation. More detailed information and links to the ENUM Day website are contained in the flyer. See you on the 15th of November. Kewin P.S. Hope this is not considered to be Spam :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: Australian ENUM Day Seminar.pdf Type: application/pdf Size: 61508 bytes Desc: not available URL: From enumvoipsip.cs at schiefner.de Tue Oct 24 16:51:26 2006 From: enumvoipsip.cs at schiefner.de (Carsten Schiefner) Date: Tue, 24 Oct 2006 16:51:26 +0200 Subject: [enum-wg] Request for trial delegation of the 2.5.e164.arpa Message-ID: <453E286E.4000105@schiefner.de> Francisco, first of all, let me express my happiness to see that also Mexico intends to join in ENUM. I have a question though, regarding your application - in the "SUPPLEMENTAL COMMENTS" section you state: === This is a trial delegation for the +52 code, for the purpose of conducting technical tests. [...] === What kind of technical tests would you think of, where do you see a need for further testing? I specifically ask that question having in mind that both, Netherlands and the Czech Republic, recently revealed plans to go into commercial operations directly, basically leaving out any trial phase as they seem to see no need for further trials. Best, Carsten -------- Original Message -------- Subject: [enum-announce] Fw: NCC#2006103092 [Request for trial delegation of the 2.5.e164.arpa] Date: Tue, 24 Oct 2006 11:19:34 +0200 From: RIPE NCC Staff Reply-To: RIPE NCC Staff To: enum-announce at ripe.net, richard.hill at itu.int ----- Begin forwarded message ----- Date: Mon, 23 Oct 2006 11:50:52 -0500 From: Francisco Arias To: enum-request at ripe.net Subject: NCC#2006103092 Request for trial delegation of the 2.5.e164.arpa Message-Id: <20061023165052.918B9182C2E at mail.nic.mx> ENUM Request Form RIPE NCC Doc-ID: ripe-384 Date: August 2006 % ENUM Request Form % You can use this form to request ENUM delegation of an E.164 country code. % Submit the completed form to . % Please see ripe-385 for instructions on how to complete this form. #[GENERAL INFORMATION]# % % Please do not change the value of the two fields below. request-type: enum form-version: 1.0 #[REQUESTER DETAILS]# % % Please add your contact details. name: Francisco Arias phone: +52 81 8387 5346 fax-no: +52 81 8387 5346 e-mail: farias at nic.mx #[ORGANISATION DETAILS]# % % Which organisation is requesting the delegation? legal-organisation-name: Network Information Center Mexico, S.C. organisation-location: Av. Eugenio Garza Sada 427 Sur. Locales 4, 5 y 6 organisation-location: Col. Altavisa, C.P. 64840 organisation-location: Monterrey, Nuevo Leon, Mexico website: http://www.nic.mx #[DATABASE TEMPLATE]# % % Please complete all of the fields below. domain: 2.5.e164.arpa descr: Network Information Center Mexico, S.C. org: ORG-NICM1-RIPE admin-c: OARG tech-c: FJAC zone-c: GLI nserver: a.ns.mx nserver: b.ns.mx nserver: c.ns.mx nserver: d.ns.mx mnt-by: NICMX-MNT changed: hostmaster at ripe.net source: RIPE #[SUPPLEMENTAL COMMENTS]# % % Please add more information if you think it will help us understand % this request. This is a trial delegation for the +52 code, for the purpose of conducting technical tests. This delegation is given by the CFT authority in Mexico. #[END of REQUEST]# ------------------------------------------------ Francisco J. Arias IT Director Network Information Center M?xico Phone & Fax: +52 81 8387 5346 http://www.nic.mx .MX is the new way to say Mexico The content of this data transmission is confidential, therefore, it shall not be modified, distributed and/or disclosed through any mean without the original sender's previous authorization. Any information, offer or agreement made by the sender of this data transmission, should be consider as personal and not binding for NIC Mexico. ------ End forwarded message ------