- NZNOG - lists.nznog.org

Re: [nznog] enum
by James Jones 04 Jan '09

04 Jan '09

oops..sent correction On 2008-12-23, at 09:16, Leo Vegoda wrote: > On 23/12/2008 5:34, "David Farrar" <dpf(a)ihug.co.nz> wrote: > >> There's been some discussions and trials in the past between >> InternetNZ and the Telco Carrier Forum. As far as I know there are no >> current plans to delegate the domain. >> >> It is worth noting that the ITU will only delegate the domain if >> instructed to by the MED, so the MED would need to be satisfied with >> whomever is proposed to operate it. > > I suppose we'll find out soon enough: > > http://www.ripe.net/maillists/ncc-archives/enum-announce/2008/msg00011 > .html Impressive nameserver diversity in that proposal: nserver: enum1.freedomnet.co.nz nserver: enum1.freedomnet.co.nz Joe _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog -- James Jones Managing Director Freedom Networks +64 6 3678300 +1 413 771 1402 james(a)freedomnet.co.nz

24 47

Re: [nznog] enum
by James Jones 04 Jan '09

04 Jan '09

I am trying as much info as posibble. I would like to see open enum system, in which anyone can register their numbers. I would like to see it back by providers as well. I really don't want anything in return, execcpt to able to have cheaper call routing for everyone. Steve I can understand your dubiousness in regards to the application. I am not trying to hide anything. Also to clarify, I am a contractor for ALU, but I am not tied Telecom. -----Original Message----- From: "Steve Phillips" <steve(a)focb.co.nz> To: "nznog" <nznog(a)list.waikato.ac.nz> Sent: 1/5/09 1:45 AM Subject: Re: [nznog] enum Don Gould wrote: > I'm sorry but I really feel a call to order is required here! Certainly. > I've read over half the posts in this thread and see no reason for false > accusations. False accusations ? the thing I'm finding is that people are asking for more information and we are getting 'yes yes, we will give you the information if you ask for it !' which isn't actually giving anyone anything about the intentions behind the application. This is very typical of commercial entities (and infact, anyone trying to divert attention away from something) when they are about to do something that will not necessarily be in the publics best interest. This has been an exceedingly common tactic in the NZ Internet industry since it started. The lack of any positive from JONES JAMES F and the ability to silently sidestep any real questions on his companies intentions for the enum allocation raise warning bells in my mind. I guess you've got a different outlook. Good for you, at least you're still smiling as you get shafted. > How about outlining how you'd like to see the system used in NZ? I really don't think it will ever get used, which is probably for the best. I also think allocating/activating it with no set plan as to how this is going to be implemented is dangerous. All it would take is a reasonably large carrier (verizon ? etc..) to perform a lookup, get a response and incorrectly route a call and you'd end up with chaos (keeping in mind that this is _supposed_ to be an official way route PSTN allocated numbers via IP). How are number allocations going to be handled ? how about coping with number portability ? do we sub delegate based on the NAD ? if the NAD has control then why is a private/commercial entity looking after the allocation ? is this entity going to charge to gain access to this system (even tho its open ! yay for word games) and if so, how much and will any charges slow adoption ? oh, and answering Craigs questions would also be nice. > How about putting a shout out for support for your ideas? I dont have any ideas other than 'it should be allocated to the MED/DNC/Peter Mott in order to stop this sort of thing from happening. > Seems to me that there are people here who are just jealous that > someone's trying to do something with this enum stuff. Yup, what a wonderful conclusion you've come to. I'd just like to make sure that a system such as enum, that is seen as a standard (with a low uptake, granted) does not fall in to the hands of some crowd that will in all likely-hood exploit it to make $$, prove to me that this is NOT the case and i'll happily shut up. (and yeah, I know there are checks around the allocations and I would _hope_ that they all work swimmingly, but call be a skeptic - especially when there are names such as Alcatel-Lucent and Telecom NZ behind the application based on the original e-mail sent to the list) > How about getting this thread moving back in a positive direction rather > than a pointless flame?! I find anything questioning why a public standard falls under the control of an unknown commercial entity, in order to line someones pockets, to have a reasonably valid point. If you see this as being pointless, then feel free to use your delete button or ignore the thread. I know, doom and gloom - but I have yet to meet anyone that can predict the future and looking back after the fact and saying 'oops, we maybe shouldn't have done that' doesn't really help things move forward. The NZ Internet industry has done that too often in the past, why are we doing it again now ? -- Steve.

1 0

Report on IPv4 address list
by Ian McDonald 02 Jan '09

02 Jan '09

Thought this might interest a few people: http://arstechnica.com/news.ars/post/20090102-the-year-in-ipv4-addresses-al… -- Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz Blog: http://iansblog.jandi.co.nz

2 1

VoIP Peering - was Re: enum
by Richard Naylor 31 Dec '08

31 Dec '08

At 08:52 a.m. 31/12/2008, Scott Howard wrote: >Eventually something is going to be needed to allow for optimal >routing between the multitude of VOIP providers - be that enum or >something else... OK lets cut to the guts of the problem. How do we get VoIP peering sooner rather than later ? Tomorrow, yet another year will have passed. Progress starts today. Assumption 1 - The big T(s) make about 50% of revenue off the PSTN equivalent to about $2.5B, so don't expect any co-operation. Assumption 2 - it has to be neutral - the Govt should NOT be involved. Of course they are welcome to peer, in fact its a surprise that Govt depts don't have inter-Dept peering already, its a bit of a no brainer for them. Maybe GSN was going to get there...... Assumption 3 - it has to be simple, so that VoIP providers and end users can get involved. (besides I'm on holiday and my horizons are sleep, food and beer) Assumption 4 - It should be distributed and scaleable.. (are you peering with your city, your region, your country or the World ?) So we need something NOW, that can be migrated if required. But we shouldn't be waiting on committees or politicians. Richard

4 3

Re: [nznog] enum
by Michael Sutton 30 Dec '08

30 Dec '08

I would suggest that NZNOG community read InternetNZ's ENUM archive there are two major ENUM related reports as well as an Open Source Software that InternetNZ released. I enclose some links to downloads and documents I refer to (see below). ENUM should be activated for New Zealand as it is an enabler which permits systems and network developers to utilize ENUM in a transparent way to the end user but which enhances the phone address lookup and uses the DNS which is already globally implemented. Note The ENUM system also enables PSTN numbers to be entered and used (subject to the rules of the Registry). Here's some points: 1. While an InternetNZ Councilor from 2003 - July 2007* and as Chair of the ENUM Task force I advocated for ENUM to be fast tracked and activated with a Personal User Agent software (UCI PUA service). ENUM has however been frozen since 2006 by agreements between MED, TCF and InternetNZ to delay ENUM which IMHO does not support our interest's of choice through ENUM operation and access. 2. In my opinion the MED should be required by Government to request delegation of 4.6.e164.arpa (ENUM) unto itself. MED should host ENUM on trial servers on their own ip address space which should be used for boot-strap testing and which can then be transitioned with technical delegation, operation and policy being determined on a fast track basis. The Government should include in the MED's key performance indicators measurements to incentivise their role in the implementation of ENUM for New Zealand. 3. There were discussions resulting in the current situation but there has been no ENUM Trial between InternetNZ, the TCF, NAD and MED. 4. In 2005 InternetNZ as part of the then ENUM initiative and research - INZ funded a UCI, PUA, ENUM (ETSI EG 284 004) software prototype which was developed by CatalystIT (extreme programming - shouts to AndrewR) which used the ENUM directory system, but the trial did not activate the 4.6.e164.arpa delegation, which it would in practice, or trial an ENUM authorization and registration process. In connection with this work: The final version ETSI EG 284 004 in September 2007 recommendations stated that UCI & PUA will use the public ENUM e164.arpa as a global directory. The work of InternetNZ and CatalystIT in New Zealand was recognized in reports on this matter to the European Commission and was used during the development of the final ETSI Guide/Standard which was approved in Europe by vote in 2007. The APEC Business Advisory Council's Report to the APEC Leaders in Bussan also included direct reference to this work. Note PUA is a Personal User Agent routing firewall system for client of isp telco services and UCI is an opt-in Universal Communications Identifier. Recently an Italian company undertaking a research and development contract for communication services for blind people (was contracted by the Italian Ministry of Science to implement a system using UCI PUA ENUM) communicated and requested access to InternetNZ's reports and the open source program code that InternetNZ released. 5. InternetNZ has $20,000 allocated for ENUM in the current place holder budget. 6. The ITU will not approve the ENUM delegation application of James Jones as the MED will not send a letter of endorsement to the ITU in support of this application - or will they. Regards Michael Sutton http://www.awacs.co.nz http://www.internetnz.net.nz/proceedings/tf/archive/enum http://www.internetnz.net.nz/proceedings/tf/archive/enum/pua-uci-feasibility -1-1-4-smaller.pdf http://www.internetnz.net.nz/proceedings/tf/archive/enum/Complete%20Enum%20T rial%20Report%20040705.pdf http://www.internetnz.net.nz/proceedings/tf/archive/enum/enumback.html * resigned.

3 3

Alternative Accommodation for NZNOG09
by Skeeve Stevens 26 Dec '08

26 Dec '08

Hey all, Just tried to book a room at Mount Richmond Hotel & Conference Centre (did people realise they only had 44 guest rooms?) and they are fully booked out on 29/1/09 to 30/1/09. I don't know the geography well, but I am wondering if anyone knows anywhere that is close to the venue? ...Skeeve -- Skeeve Stevens, CEO eintellego Pty Ltd - The Networking Specialists skeeve(a)eintellego.net / www.eintellego.net Phone: 1300 753 383, Fax: (+612) 8572 9954 Cell +61 (0)414 753 383 / skype://skeeve -- NOC, NOC, who's there?

2 3

enum
by JONES JAMES F 23 Dec '08

23 Dec '08

Is anyone doing anything with 4.6.e164.arpa domain? James Jones

6 6

Re: [nznog] enum
by lenz 23 Dec '08

23 Dec '08

from what i've seen in europe the registries love it and the users don't really take it. the main problem i've seen there is that the validation process is way too complicated for the normal domain registrar and the customer. the registration numbers in germany and austria are not too impressive either. the swiss guys killed their enum project afaik. cheers lenz > > On Tue, Dec 23, 2008 at 12:56 PM, Nathan Ward <nznog(a)daork.net> wrote: > >> On 23/12/2008, at 12:44 PM, JONES JAMES F wrote: >> > Is anyone doing anything with 4.6.e164.arpa domain? >> > >> http://www.internetnz.net.nz/projects/enum/index.html >> >> Seems to me that it could tie in to TUANZ/INZ stuff. >> >> I'd question whether it's worthwhile going through all the >> bureaucratic nightmare to get a limited lifetime bridge between the >> PSTN and the Internet. >> Why not just use SIP URIs? >> >> -- >> Nathan Ward >> >> >> >> >> _______________________________________________ >> NZNOG mailing list >> NZNOG(a)list.waikato.ac.nz >> http://list.waikato.ac.nz/mailman/listinfo/nznog >> > >

1 0

NZRR Route Registry Update
by NZRR Database Notifications 22 Dec '08

22 Dec '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS9439:RS-ROUTES:AS64526 descr: Route set for Infometrics - AS64526 members: 210.48.109.80/28 admin-c: RPA1-NZRR tech-c: RPA1-NZRR mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20030717 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS64526 descr: advertised to AS9439 by Infometrics Ltd / Gareth Morgan Investments - AS64526 members: 210.48.110.0/26^26-29, 210.48.109.80/28^28-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: mike(a)gmi.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081223 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 22 Dec '08

22 Dec '08

Dear Colleague, This is to notify you that one or more objects in which you are designated for notification have been modified in the NZRR routing registry database. These objects are used to configure the various NZIX route servers (http://nzix.net/) so you can expect the relevant servers to be reloaded in the near future. The reloading of the servers is staggered over a period of time so that if you are peering with both servers at an exchange, you can maintain at least one BGP session at all times and consequently a full set of routes. Diagnostic output: ------------------------------------------------------------ --- PREVIOUS OBJECT: route-set: AS24388:RS-ROUTES:AS38294 descr: Route set advertised to AS24388 by ServerWorks Ltd - AS38294 members: 202.124.127.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: russell(a)serverworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070608 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS38294 descr: advertised to AS24388 by Serverworks Ltd - AS38294 members: 113.130.120.0/22^22-29, 202.124.127.0/24^24-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: russell(a)serverworks.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20081223 source: NZRR ------------------------------------------------------------

1 0