- enum-wg - mailman.ripe.net

RIPE 52 draft minutes
by Carsten Schiefner 09 Oct '06

09 Oct '06

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 <enum-wg-chair(a)ripe.net>, 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. Best, Carsten (on behalf of the ENUM WG Co-Chairs) === ENUM Working Group Minutes from RIPE 52 RIPE Meeting: 52 Working Group: ENUM Status: Draft Revision Number: 1 * content to enum-wg-chair(a)ripe.net * format to webmaster(a)ripe.net RIPE 52 - Ceylon Intercontinental Hotel - Bosphorus II - 20060427 - 14:00-15:30 Session Chair: Niall O’Reilly Scribe: Alex Le Heux (RIPE NCC) Jabber: Catherine Carr (RIPE NCC) Webcast and Feedback Archives: http://www.ripe.net/ripe/meetings/ripe-52/sessions-archive.html A: Chair - Start: 14:04 Administrivia: Welcome, Scribe, Jabberwok Niall O'Reilly: Welcome everyone. B: Chair - Start: 14:05 Minutes ENUM-WG at RIPE 51 Niall O'Reilly: There were no extra comments. Any objections? Silence. Minutes RIPE 51 approved. C: Chair - Start: 14:06 Review Action List Niall O'Reilly: 51.2: Carsten has let the RIPE NCC know the missing links and the RIPE NCC is following up -> Action Item 52.1 51.3: Not needed. Done. Niall O'Reilly: Please do boring stuff in between the meetings, so we can do interesting stuff at the meetings. 51.7: Thanks to everyone who helped the Austrians with testing the +43780, lots of people did. They couldn't come, but sent apologies. D: Chair - Start: 14:07 Short News (if any) Carsten Schiefner: No short news really. There is some news about IETF ENUM WG about standardisation. IETF takes infrastructure ENUM into account as well now. Two ideas: 1. Separate .arpa domain; 2. Follow the Austrian approach, branch location register in the normal e164.arpa tree. The problem is that there is only public user ENUM in e164.arpa, which isn't very helpful for infrastructure providers because in public user ENUM it is the user who decides first of all if he or she wants to be part of ENUM and register the phone number as ENUM domain, and secondly, the Infrastructure provider has no control over what the user puts there. For peering purposes there needs to be some infrastructure ENUM in place. The Dallas treaty solved this in Dallas: Short term: Follow branch location register approach. Long term: Separate 2nd level domain in .arpa. E: Leo Vegoda - Start: 14:10 RIPE NCC ENUM Report Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-ncc-upd… Daniel Karrenberg: A comment: Total queries we get at the e164.arpa service is not the total ENUM queries. We should probably add a sentence saying so, before we see strange things in the media. Jim Reid: Are the statistics for the RIPE NCC's e164.arpa servers? Leo Vegoda: Yes, only the NCC's servers. Carsten Schiefner: Intention to gather other statistics from the other e164.arpa operators? Leo Vegoda: We didn't do that this time. From the minutes of RIPE 51 I thought just the RIPE NCC's statistics were enough. If there is demand, we can try to put something together. Niall O'Reilly: That's what you were asked for this meeting. It would be good maybe for RIPE 53. Action item 52.2 -> Widen the stats. Carsten Schiefner: Documentation of communications in a zip file proposal is fine for me. Is that fine with the group? Niall O'Reilly: To the list. Action item 52.3 -> Stimulate that on the list. F: Gerhard Schröder - Start: 14:22 Follow-up on the Plenary presentation: ENUM and Security Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-plenary-enum… Niall O'Reilly: Are there questions from the group? Gerhard Schröder: Introduction to his plenary presentation. Maybe the presentation was at the wrong place. When we made the transit from classic telephony to SIP+ENUM, we wanted to know what the risks were. We have a lot of experience in ISDN telephony in security and misuse. Patrik Fältström, Cisco: A comment: You talked about infrastructure ENUM. In the IETF people think infrastructure ENUM are records that are visible in the public DNS. That's not the same definition as you use. PRESENTATIONS Karen Mulberry - Start: 14:26 G1: +1 Trial Presentation is at: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-1.pdf Carsten Schiefner on Slide 4: Does the trial have an end date set already? Karen Mulberry: the idea is to have the trial run for 6 months, we need a waiver and numbers from the FCC. After that it takes 30 days. So we don't know when it begins and when it ends. Canada is also looking at starting a trial. Niall O'Reilly: Will you come often to the RIPE Meetings? Your timing is very good! Karen Mulberry: I'd love to! Martin Felt: Carriers are interested in interconnecting in North America, that needs to be solved and how ENUM will be used. The US Government guidelines state that there won't be infrastructure ENUM. In your mind, will that prevent everyone to come together? Karen Mulberry: The value is in the infrastructure ENUM, not really in the user ENUM today. Maybe in the future, but not right now. In essence what the USG said is that we authorised a delegation and we'll take it away if you don't do what we say. There will be an industry discussion about how to proceed, but first we will proceed with the e164.arpa trial as that will educate the government organisations and satisfy them. Daniel Karrenberg: In your trial there's not a lot of info about verification. Are you trialling that as well? Karen Mulberry: Two providers that are authentication/verification agents. We have lot of different databases that drive the public network. They are looking at what process to use, but we will work through it. Daniel Karrenberg: It will be in the trial? Karen Mulberry: Yes is will. It's also the concern of the FTC. Daniel Karrenberg: Two organisations that see business in this? Karen Mulberry: Yes, two ISPs that see opportunity in this. Gerhard Schröder: Thank you Karen. One slide shows privacy/security! Thank you for this! I'd like to propose to add this security feature to the working list. Niall O'Reilly: I'm not sure what you have in mind. Gerhard Schröder: It would be worthwhile to discuss security and privacy Issues in the WG. Niall O'Reilly: This is a problem of telco and data protection regulators. But it would be interesting to hear what is developing. We won't put this on our WG action list, but we will be making a call for the agenda at RIPE 53 with some interesting people. The privacy experts are not in the room, we're all technical people. Gerhard Schröder: It's also a feature of a product. Karen Mulberry: In the US we're talking about contact info and DNSsec. We're not sure if we're going forward with that. Patrik Fältström, Cisco: When I hear people talk about privacy and ENUM, I feel that no fingerpointing is important. There are people in this room that mix up the ability of one organisation to find out what customers that a competitor has with the ability of organisation to know information about individuals. Gerhard Schröder: Will DNSsec able to solve all sec features for ENUM? With DNSsec we can't make a trusted tree, just a trusted chain. We need to deal with the security for each user. Niall O'Reilly interrupts: We are out of time, let's move this to the mailing list. We don't have time to explore these questions in any meaningful way. Thank you Karen. Jim Reid - Start: 14:56 G3: Test bed numbers Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-testbed… Jim Reid: Does the WG care about a test bed, should we try to progress it? Working Group hums: <not really> Niall O'Reilly: Action Item 51.5 stays open for now. Niall O'Reilly: Would it help to have some allocations from other regulators? Jim Reid: Yes, it doesn't matter which numbers we get, just where they terminate. Niall O'Reilly: From the point of diversity? Jim Reid: I don't know. Niall O'Reilly: Let's move this to the mailing list. Jim Reid - Start: 15:01 G2: +44 Update Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-44.pdf Martin Felt: Is CRUE temporary? Jim Reid: I'm not sure. Peter Koch: Are the specifications for CRUE are available? Are there wildcards? Jim Reid: No wildcards, the specifications will be available, it's not yet as the website isn't up yet. Jay Daley, Nominum: It will be available in 4 weeks. Jim Reid: If you want a copy, let me know, I'll send it. Andreas Bäß - Start: 15:07 G4: +49 Commercial Operations Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-49.pdf Niall O'Reilly: 5600 domains? Are those multiblocks or all the same? Andreas Bäß: I've not checked, so there are blocks in there too. Niall O'Reilly: Validation is for a year. Coupling the timers for validation with quarantining between number holder before reassigning to customers? Andreas Bäß: No idea how the quarantining is done, so no. Daniel Karrenberg: I'm a happy +49 customer. I had several calls of people who had used ENUM to find the sip gateway. Any idea how many complaints about authentication? Andreas Bäß: So far none. Conor Daly - Start: 15:20 G5: +353 Commercial Operations Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-353.pdf No questions. Interaction with other WGs Peter Koch - Start: 15:23 X1: Walking E164.ARPA Presentation is at: URL: http://www.ripe.net/ripe/meetings/ripe-52/presentations/ripe52-enum-still-c… Daniel Karrenberg: Why the short TTLs on NAPTR records? Peter Koch: Probably for follow me services. Ed Lewis: Low TTLs are a disaster. All: <agree> Daniel Karrenberg: A comment: NAPTR records for non-leaf nodes can be real and useful. Some people have shorter numbers. Niall O'Reilly: Do you want Leo to talk to Andrei about DNS quality, the availability of servers? Peter Koch: It was a customer server, not a Tier1 server. It had 5000 delegations though. Niall O'Reilly: Let's move this to the list. Carsten Schiefner - Start: 15:34 X2: DNS-WG-AP-51.5 Niall O'Reilly: This was action 51.6 in this WG, 51.5 in DNS WG Carsten Schiefner: The RIPE NCC will put e164.arpa under the reverse delegation checker regime. Still need discussion about what to do when a lame delegation is detected. Niall O'Reilly: Close action? Or keep open? Carsten Schiefner: Close it. AOB None Action Items Number Who Item 51.5 Jim Reid Stimulate discussion on testbed numbers/ranges. 52.1 RIPE NCC Follow up on the missing links reported by Carsten, pending the discussion in 52.3. 52.2 RIPE NCC Widen the e164.arpa server statistics to include other servers than just those of the RIPE NCC. 52.3 Carsten Schiefner Stimulate discussion on the list about the format of the communications documentation on the site (currently .zip). [Meeting closed.]

1 1

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 04 Oct '06

04 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