- NZNOG - lists.nznog.org

WLG Power Woes
by Jonathan Brewer 10 Dec '07

10 Dec '07

Hi Folks, >From the amount of up/down alerts I've seen from monitored subscriber sites in the past couple of minutes, I'd say the Wellington grid is experiencing some significant issues right now. Regards, Jonathan Brewer -------------------------------- Araneo Limited 232A Left Bank 116 Cuba Street Wellington 6011 ph: 04 978 7350 fx: 04 978 7355 mb: 021 345 054 www.araneo.net.nz <http://www.araneo.net.nz/> --------------------------------

2 1

Significant power outage in Wellington
by Simon Blake 09 Dec '07

09 Dec '07

Power to a good chunk of central Wellington went out around 3:58pm this afternoon. Seems to be between Customhouse Quay and Courtenay Place, we've seen at least these buildings down: -- Date: Mon, 10 Dec 2007 16:15:22 +1300 Subject: tentative list of power affected sites Willbank House (57 Willis St) BDO House, 99-105 Customhouse Quay Guardian Trust House (15 Willeston St) Cigna House (28-48 Mercer St) Economous Building/Hibernian House (4 Bond St) Perpetual Trust House (111-115 Customhouse Quay) Computerland House (154 Featherston St) Todd Building (95 Customhouse Quay, cnr Customhouse and Hunter) Synergy House (Queens Wharf) Optimation House (1-13 Grey St) HP Tower/Hotel Intercontinental (163-175 Featherston St) Lumley House (3-11 Hunter St) Exchange Place (5-7 Willeston St) Willeston Centre (22-28 Willeston St) NZX Centre (11 Cable St) United Building (107 Customhouse Quay) CMC Building (89 Courtenay Place) Conservation House (18-32 Manners St) Sovereign House (34 Manners Street) MSO House (19 Edward St) BNZ Trust House (50 Manners St) Axon House (1 Willeston St) NEC/Panasonic House (40 Taranaki St) Cheers Si

3 2

Re: [nznog] NZNOG '08 Talks
by Ewen McNeill 09 Dec '07

09 Dec '07

In message <eedb5d410712091222j7181d91eja34beb9c8ec64727(a)mail.gmail.com>, "Neil Fenemor" writes: >As some of you will have noticed, we're getting more of the talks confirmed >and up for NZNOG'08. However there is still a spot for you to speak. There are also still a few speaking slots at the Sysadmin Miniconf (held on the Wednesday); details here: http://nznog.miniconf.org/ (We're a little behind on the draft programme, as we're still waiting on a few speakers to provide titles/abstracts.) I'd be particularly interested in someone to speak on content distribution networks, and someone to speak on deploying IPv6-aware applications, but proposals for anything related to ISP systems administration will be gratefully received. Please email proposals and any questions to <talks08(a)nznog.miniconf.org> Ewen

1 0

NZNOG '08 Talks
by Neil Fenemor 09 Dec '07

09 Dec '07

Hi, As some of you will have noticed, we're getting more of the talks confirmed and up for NZNOG'08. However there is still a spot for you to speak. While the majority of the talks are 30 minutes, we are able to accommodate 20 minutes, or if you prefer a 5 minute lightning talk. If you're interested in talking, feel free to email myself, or the program committee on prog08(a)nznog.org For all your NZNOG'08 needs, visit http://conference.nznog.org/ Look forward to hearing from you. Cheers, neil NZNOG'08

1 0

APNIC Training - next week.
by Jonny Martin 04 Dec '07

04 Dec '07

For those of you who haven't already found out, APNIC are running training in Wellington and Auckland next week: Wellington, 11 December: http://www.apnic.net/training/registration/ 2007/register-20071211.html Auckland, 13 December: http://www.apnic.net/training/registration/ 2007/register-20071213.html Training will be the Extended Internet Resource Management Essentials (IRME), followed by a hostmaster consultation session the following morning in each location. The IRME course won't be covered at NZNOG08, so this is your chance to attend the training. This is a good course for anyone who works at an organisation that currently holds, or is looking at obtaining APNIC allocations. To those of you who think you know it all already, well I don't believe you! :). Cheers, Jonny.

1 0

New Zealand Meraki Experiences?
by Hamish MacEwan 04 Dec '07

04 Dec '07

Hi, Anyone have any experience with the Meraki wireless mesh networking system, formerly MIT's RoofNet, in the New Zealand environment that they would be prepared to share with a group interested in investigating the technology? http://meraki.com/about/ http://www.technologyreview.com/Infotech/19260/?a=f Hamish. -- http://del.icio.us/Hamish.MacEwan http://urltea.com/3jm?GoogleSharedItems

2 2

NRO Number Council election: Call for nominations
by Elly Tawhai 03 Dec '07

03 Dec '07

[Apologies for duplicates] Dear colleagues This is a call for nominations of individuals from the Asia Pacific region to serve on the NRO Number Council. As of 31 March 2008 one Asia Pacific Number Council seat will become vacant. This seat will be filled until 31 December 2009 by an individual nominated through this open call. The selection process will involve an open election to be held during the APNIC 25 Open Policy Meeting in Taipei, Taiwan on Friday 29 February 2008. The elected individual must be willing to serve an 18-month term beginning 1 April 2008. * Deadline for nominations: 24 January 2008 * Election scheduled for: 29 February 2008 There will also be an online voting facility available to APNIC members through MyAPNIC. This service will open on Wednesday 13 February 2008 and close at 09:00 UTC+8, Wednesday 27 February 2008. More information on how to cast your vote online will be available in MyAPNIC over the coming weeks. For full details on the position and how to nominate please see: http://www.apnic.net/community/nro/nc/call-nomination.html Please note that the NRO Number Council representatives now fulfil the role of ICANN's ASO Address Council. Responsibilities of NRO NC representatives are outlined in the ASO Memorandum of Understanding at: http://www.nro.net/documents/aso-mou.html With best regards APNIC Secretariat --------------------------------------------------------------------- APNIC Secretariat email: secretariat(a)apnic.net http://www.apnic.net sip: info(a)voip.apnic.net phone: +61 7 3858 3100 ---------------------------------------------------------------------

1 0

APNIC IPv6 transit exchange
by Terry Manderson 28 Nov '07

28 Nov '07

Dear NZnog Colleagues, APNIC is facilitating IPv6 adoption in the Asia Pacific region with an IPv6 Transit Exchange. This will allow APNIC to support IPv6 and at the same time expand IPv6 awareness, use, and understanding of IPv6 in the Asia Pacific region. The IPv6 Transit Exchange is a Reasearch and Development effort and will continue to run for as long the participants require the service, however a horizon may be set when commercial providers offer native IPv6 services in a commercial relationship. APNIC will additionally advertise prefixes and negotiate peers for both 2byte and 4byte Autonomous System numbers (AS) to ipv6 neighbors of this service. The preference for the IPv6 exchange is that is an MLPA style service. That is, we will re-advertise all routes presented to us. And the more routes you are willing to advertise the better! As such, any organisations willing to offer full transit will be greatly appreciated. Any organisation with an IPv6 prefix is welcome, and encouraged to join. Please see the following link for more information: [http://icons.apnic.net/index.php? option=com_content&task=view&id=3432&Itemid=94] Cheers, Terry -- Terry Manderson email: terry(a)apnic.net Network Operations Manager, APNIC sip: info(a)voip.apnic.net http://www.apnic.net phone: +61 7 3858 3100

1 0

NZRR Route Registry Update
by NZRR Database Notifications 28 Nov '07

28 Nov '07

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:AS23655 descr: advertised to AS24388 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070801 source: NZRR REPLACED BY: route-set: AS24388:RS-ROUTES:AS23655 descr: advertised to AS24388 by Snap Internet - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071129 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 28 Nov '07

28 Nov '07

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:AS23655 descr: advertised to AS9439 by Snap Internet Limited - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.36.220.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070801 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS23655 descr: advertised to AS9439 by Snap Internet - AS23655 members: 132.181.0.0/16^16-29, 138.75.0.0/16^16-29, 153.111.0.0/16^16-29, 123.255.0.0/18^18-29, 202.124.96.0/19^19-29, 203.86.192.0/20^20-29, 202.174.112.0/21^21-29, 210.5.48.0/21^21-29, 202.49.72.0/22^22-29, 202.49.92.0/22^22-29, 202.50.104.0/22^22-29, 202.50.124.0/22^22-29, 202.164.28.0/22^22-29, 202.27.186.0/23^23-29, 202.36.178.0/23^23-29, 202.36.218.0/23^23-29, 202.37.96.0/23^23-29, 202.37.100.0/23^23-29, 202.37.124.0/23^23-29, 202.49.90.0/23^23-29, 202.49.120.0/23^23-29, 210.55.30.0/23^23-29, 210.55.206.0/23^23-29, 192.156.225.0/24^24-29, 202.36.170.0/24^24-29, 202.37.114.0/24^24-29, 202.49.115.0/24^24-29, 202.49.125.0/24^24-29, 202.49.187.0/24^24-29, 202.50.117.0/24^24-29, 202.50.169.0/24^24-29, 202.146.186.0/24^24-29, 203.96.112.0/24^24-29, 210.7.40.0/24^24-29, 210.54.15.0/24^24-29, 210.55.4.0/24^24-29, 210.55.7.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: noc(a)snap.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071129 source: NZRR ------------------------------------------------------------

1 0

Xtra Mail Admin Contact Off List re White List
by Don Gould 27 Nov '07

27 Nov '07

If any one knows how I get babyonthemove.co.nz white listed with Xtra's email system could they please contact me. At present the 25 franchises who have broadband accounts with Xtra are finding that email forwarded to their @xtra.co.nz account is going missing. We have set up their addresses so that the email is forwarded automatically to their relivant xtra account. If others have tried this sort of thing and discovered that you just can't do it this way then I'd like to know. eg. east.chch(a)babyonthemove.co.nz --> whatever(a)xtra.co.nz west.chch(a)babyonthemove.co.nz --> whoever(a)xtra.co.nz We did this because we didn't want to have to explain to each franchise holder how to set up Outlook or Thunderbird to retrieve mail from the the babyonthemove.co.nz mail server. WHY THIS LIST/NOT THIS LIST PLEASE! I've already rung level 1 support. The first person I spoke to told me "you're not with us", after she's asked me for my phone number, despite my explaining who I was and why I was calling. To her credit she did not cut me off, she put me through to a broadband helpdesk person who did not know what a 'white list' was. He also didn't cut me off, and put me though to a person who did at least know what a white list is. He referred me to http://xtra.co.nz/help/0,,4155-7793692,00.html which referred me to http://help.yahoo.com/l/us/yahoo/mail/yahoomail/postmaster/bulk.html which I filled out. It then sent me a 1200 word email about spam. That was the point I felt I'd read enough, talked to enough people who were clearly not in control of the situation and wanted to speak to a person who has actually been through this process and can tell me if I'm chasing my tail or actually in the right direction. Or, do I have to simply bite the bullet and make everyone set up mail readers? Cheers Don -- Don Gould 2/59 Peverel Street, Riccarton, Christchurch, New Zealand Phone: +64 3 348 7235 - Mobile: +64 21 114 0699 www.thinkdesignprint.co.nz

6 7

Small interruptions to APE at L48 Sky Tower over the next week
by Simon Blake 27 Nov '07

27 Nov '07

Hi all Most affected parties should already be aware, but I'll repeat it here in case the change control messages didn't get to the right people - we're replacing gear on L48 over the next week. Between 12:01 and 6:00 on Thursday 28 through Dec 5, (excluding Saturday and Sunday morning), there will likely be short interruptions to every connection to the Citylink cabinet on L48. More info at http://news.clnz.net/2007/11/16#Level-48-Sky-Tower-Project Cheers Simon

2 2

NZRR Route Registry Update
by NZRR Database Notifications 27 Nov '07

27 Nov '07

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:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071108 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071128 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 27 Nov '07

27 Nov '07

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: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071108 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.162.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071128 source: NZRR ------------------------------------------------------------

1 0

APNIC 25 Call for Proposals
by Elly Tawhai 25 Nov '07

25 Nov '07

APNIC 25 25 February - 29 February 2008 Howard Plaza Hotel Taipei, Taiwan Dear colleagues Special Interest Groups (SIGs) will be held at the 25th APNIC Open Policy Meeting. We invite you to submit proposal presentations for these sessions. There are two types of presentations: - Policy proposal (P) A proposal which requires feedback and community consensus before it can proceed. - Informational (I) Typically a status report delivered to convey information to the audience. Informational presentations may be presented in SIG sessions. * Submitting policy proposals To submit a policy proposal before the 28 January 2008 deadline, you have two options: 1. Use the online form at: http://www.apnic.net/cgi-bin/policy_proposal.pl 2. Send your proposal in TEXT format to the appropriate SIG Chair, CCing <sig(a)apnic.net>. * Submitting informational proposals Send your proposal in TEXT format to <program(a)apnic.net>, preferably before 28 January 2008. Agenda slots will be allocated on a first-come first-served basis, so it is advisable to submit your proposal as soon as possible. More information ---------------- SIG archives and guidelines for presenters are available at: http://www.apnic.net/meetings/archive/sigs/ SIG chairs can be contacted at: * Policy SIG <sig-policy-chair(a)apnic.net> * Database SIG <sig-db-chair(a)apnic.net> * DNS operations SIG <sig-dns-chair(a)apnic.net> * IPv6 technical SIG <sig-ipv6-chair(a)apnic.net> * IX SIG <sig-ix-chair(a)apnic.net> * NIR SIG <sig-nir-chair(a)apnic.net> * Routing SIG <sig-routing-chair(a)apnic.net> We look forward to seeing you in Taipei! Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Internet Resource Analyst/ Liaison (Australasia), APNIC sip: helpdesk(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________

1 0

An explanation of what went wrong at Mayoral Drive on 4/11
by Matthew Poole 21 Nov '07

21 Nov '07

ComputerWorld article. http://s0.tx.co.nz/at/tep34n279457j138688i194855f2c4680224a4t9s4z During testing a UPS failed to start a generator, then its batteries went flat and the systems it was feeding had to be restarted. Fire and Police were hit hard because they'd only very recently consolidated to a single database from three region-based ones, and hadn't had a DR drill (one was planned) so it was the first time they'd actually done a cut-over. That sod Murphy strikes again! -- Matthew Poole "Don't use force. Get a bigger hammer."

9 14

Re: [nznog] An explanation of what went wrong at Mayoral Drive on 4/11
by Russell Sharpe 20 Nov '07

20 Nov '07

I agree with you on that as well as my comments Peter :| -----Original Message----- From: Peter Mott [mailto:peter(a)mott.co.nz] Sent: Wednesday, 21 November 2007 20:02 To: Russell Sharpe Cc: 'NZNOG' Subject: Re: [nznog] An explanation of what went wrong at Mayoral Drive on 4/11 On 21/11/2007, at 7:45 PM, Russell Sharpe wrote: > IMHO. This type of incident enforces my feeling that some providers > are only interested in profits, not customer service. :( and a gross > lack of investment More likely due to a lack of ... * personal ownership of having it stay going * basic problem solving skills * understanding of how it works * consequences for when you screw up Blame management if you want, but I would start with parents and schools. Time for a beer. regards Peter Mott -/-

1 0

Re: [nznog] An explanation of what went wrong at Mayoral Drive on
by Stewart Fleming 20 Nov '07

20 Nov '07

> -----Original Message----- > From: nznog-request(a)list.waikato.ac.nz > [mailto:nznog-request(a)list.waikato.ac.nz] > Sent: Wednesday, 21 November 2007 12:00 p.m. > Message: 2 > Date: Wed, 21 Nov 2007 09:38:51 +1300 (NZDT) > From: Matthew Poole <matt(a)p00le.net> > Subject: [nznog] An explanation of what went wrong at Mayoral Drive on > 4/11 > To: NZNOG <nznog(a)list.waikato.ac.nz> > Message-ID: <Pine.LNX.4.62.0711210935340.8793(a)maverick.blakjak.net> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > > ComputerWorld article. > http://s0.tx.co.nz/at/tep34n279457j138688i194855f2c4680224a4t9s4z > > During testing a UPS failed to start a generator, then its > batteries went flat and the systems it was feeding had to be > restarted. Interesting that there was a similar power-related failure of emergency systems in the South Island a few days after this incident. And that a similar incident occurred at the Telecom Dunedin exchange about 6 months ago (UPS test, generator started, sparked, caused a fire, fire happened to be in same room as mains cutover switch...UPS ran flat.)

1 0

NZNOG 2008 registrations are up/up
by Jonny Martin 20 Nov '07

20 Nov '07

The NZNOG 2008 website is up and registrations are now open. http://conference.nznog.org Hope you can make it to Dunedin, Jan 23-25 2008! Cheers, Jonny.

3 2

Re: [nznog] An explanation of what went wrong at Mayoral Drive on 4/11
by Matthew Poole 20 Nov '07

20 Nov '07

On Wed, 21 Nov 2007, Jeremy Strachan wrote: > > "during testing" means someone must have been onsite - to check the > generator started?? > > or are the dumb enough not to do that ... because of staff cuts ... > Who know? One would HOPE that they'd have engineers on-site for testing of critical components. Still, this is far more of an explanation that I'd ever expected to be given! -- Matthew Poole "Don't use force. Get a bigger hammer."

1 0

NZRR Route Registry Update
by NZRR Database Notifications 19 Nov '07

19 Nov '07

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: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.54.142.0/23^23-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071113 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.54.142.0/23^23-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071120 source: NZRR ------------------------------------------------------------

1 0

Security alert - http://www.bugmenot.com/ offering username/passwords online
by Paul England 12 Nov '07

12 Nov '07

Hi everyone, I just thought I'd share this with everyone as we recently found that some of our domains were on this website... It's the first website of it's kind that I've ever come across and personally I'm concerned that it's going to grow in popularity. There is an automated system to allow systems admins to block their domains from this website... definitely worth doing. Cheers - Paul England

9 13

NZRR Route Registry Update
by NZRR Database Notifications 12 Nov '07

12 Nov '07

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: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071113 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 210.54.142.0/23^23-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071113 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 12 Nov '07

12 Nov '07

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: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071004 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9889 descr: advertised to AS9560 by Maximum Internet Ltd - AS9889 members: 123.100.64.0/18^18-29, 124.198.128.0/18^18-29, 202.89.32.0/19^19-29, 203.89.160.0/19^19-29, 202.55.96.0/20^20-29, 202.189.160.0/21^21-29, 210.55.100.0/22^22-29, 210.55.104.0/22^22-29, 117.53.150.0/24^24-29, 192.138.251.0/24^24-29, 202.6.5.0/24^24-29, 202.27.8.0/24^24-29, 202.27.204.0/24^24-29, 202.36.70.0/24^24-29, 202.36.227.0/24^24-29, 202.37.72.0/24^24-29, 202.37.162.0/24^24-29, 202.37.181.0/24^24-29, 202.49.141.0/24^24-29, 202.150.102.0/24^24-29, 203.12.15.0/24^24-29, 203.97.42.0/24^24-29, 210.54.13.0/24^24-29, 210.54.142.0/24^24-29, 210.55.169.0/24^24-29, 210.55.214.0/24^24-29, 210.55.230.0/24^24-29, 203.167.219.56/29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)maxnet.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071113 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 07 Nov '07

07 Nov '07

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: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071108 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 07 Nov '07

07 Nov '07

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:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.89.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.33.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071108 source: NZRR ------------------------------------------------------------

1 0

InternetNZ launches public consultation on Internet peering
by Dean Pemberton 07 Nov '07

07 Nov '07

Hi all. InternetNZ is asking for public consultation on Internet Peering. There are a number of interesting things in this email, my apologies for its length. The first is the InternetNZ Peering Report which can be downloaded at http://peering.internetnz.net.nz/wp-content/uploads/2007/11/issues-regardin… And the second are the 8 questions which InternetNZ is asking for submissions on. People are welcome to send in their own submissions, and if the discussion is within the AUP then feel free to voice them here too. I look forward to the discussion. =) I've included the original RTF document as text below inline with the list rules. Dean -------- Original Message -------- InternetNZ launches public consultation on Internet peering For immediate release 7 November 2007 InternetNZ (the Internet Society of New Zealand Inc) today launches a public consultation on Internet peering, a subject that relates to the performance and reliability of the Internet. This follows the release of a report commissioned by the Society entitled “Issues regarding Internet peering and interconnection in New Zealand”. Some key issues identified in the report include conflicting interpretations of the term peering, cost of transit, lack of reliable internet traffic data and statistics and the challenges faced by content providers InternetNZ invites comments on any issues presented in the report and what further steps should be considered in progressing peering and data interconnection issues in New Zealand. A consultation document is attached and submissions have been invited either by email in response to that document, or at the website http://peering.internetnz.net.nz, where comments can be attached to the individual questions. The mission of InternetNZ is to protect and promote the Internet in New Zealand. InternetNZ is a public policy advocate for Internet and telecommunications issues that further an open and uncaptureable Internet. InternetNZ promotes neutral peering and neutral peering exchanges on the basis that it provides diversity for the Internet network and assists in improving network performance. For further information contact: Richard Wood Communications and Research Officer InternetNZ richard(a)internetnz.net.nz 0274 974 837 ----------Attachment------- InternetNZ Invites Comment on Peering Consultation Document - 7 November 2007 ------------------------------------------------- InternetNZ (the Internet Society of New Zealand Inc) has commissioned a report "Issues regarding Internet peering and interconnection in New Zealand", which examines the state of peering and related issues in New Zealand. The report can be found here: http://peering.internetnz.net.nz/wp-content/uploads/2007/11/issues- regarding-internet-peering-and-interconnection-in-new-zealand-099.pdf InternetNZ invites comments on any issues presented in the report and what further steps should be considered in progressing peering and data interconnection issues in New Zealand. Submissions must be received by 5pm, Friday 7 December. InternetNZ is also inviting comments and discussion online at the website http://peering.internetnz.net.nz Background --------------- The mission of InternetNZ is to protect and promote the Internet in New Zealand. InternetNZ is a public policy advocate for Internet and telecommunications issues that further an open and uncaptureable Internet. InternetNZ promotes neutral peering and neutral peering exchanges on the basis that it provides diversity for the Internet network and assists in improving network performance. In March 2008 InternetNZ commissioned an external working group chaired by Dr Murray Milner to undertake a wide ranging industry consultation on peering and related issues. The terms of reference were as follows; • To facilitate industry discussion on issues relating to Internet peering in New Zealand inclusive of all interested and affected stakeholders and in a collaborative fashion. • To establish policies and principles that will expedite an industry-wide agreement on peering and local interconnection of data. The findings and recommendations contained in "Issues regarding Internet peering and interconnection in New Zealand" do not represent InternetNZ policy but are designed to provide a framework for a wider industry debate on peering and data connection issues. Following the public consultation process, InternetNZ will publish a final report that will incorporate feedback from public submissions To assist the feedback process, outlined below are a list of specific questions based on the findings and recommendations raised in the report Questions ------------ 1. Peering: Interpretation and Definition The term peering is open to many interpretations. The report identifies the differences in what is meant by the word "peering" and says that emotive responses flowing from historical events can be overcome by defining as far as possible what peering means. Do you agree with definition of peering that is proposed in the report. If not, what would be more appropriate? 2. Cost of Transit International benchmarking suggests the cost of transit is relatively high in New Zealand. Do you agree? Specifically, is there a market failure or evidence of SMP (significant market power) with regard to the cost of transit? Should government conduct an investigation regarding the price of transit? And finally should Government regulate the price of transit? 3. The state of networking - lack of reliable data The report highlights the difficulty in having any informed debate about the state of networking in relation to local, national and international data interconnection in New Zealand, without access to reliable Internet traffic data and statistics. Do you support the need for an initiative that would collect and make available on an aggregated basis, New Zealand Internet traffic flows and volumes? If so who should collect that data? Specifically; the Telecommunication Carrier's Forum, Commerce Commission, Ministry of Economic Development, InternetNZ, or other? 4. Rich Media Content Distribution The report identifies the challenges faced by content providers, particularly the distribution of audio and video files. What initiatives with regards to peering and data interconnection would assist the growth and viability of the NZ digital content industry? 5. Consumer Pricing Strategies The report suggests consumer pricing strategies that differentiate between national and international traffic might encourage a greater take-up of New Zealand-sourced content. Do you agree? 6. Telecom Local Peering Proposal The report has noted a significant industry development with regards to Telecom's Local Peering Proposal, which has been the subject of industry discussions since April 2007. Do you support the proposals put forward in Telecom's local peering initiative? 7. Peering Code of Practice The report is neutral at this time on whether a Peering Code of Practice could be a useful mechanism to progress industry cooperation on peering and data connection issues. Do you support the need for a specific self regulatory industry initiative such as a Code of Practice to manage and develop consensus on peering and data connection issues? Failing that, should Government consider some form of regulation? 8. Other Please comment on any other issues in the report that you feel are not covered by the above questions. ------------ Please forward submissions to richard(a)internetnz.net.nz. InternetNZ will publish all submissions on its website at www.internetnz.net.nz and considers you have consented to this by filing your submission

1 0

Spam & NZ Anti Spam law issues.
by Skip Parker 05 Nov '07

05 Nov '07

Hi, I hope this email is not too far off List Topic, however i have a question that I would like some feedback for from NZ ISP's. (I believe its been raised before) A number of my customers run Email List Services which sends out various messages to a subscribed customer base (compliant with the NZ Anti Spam Laws etc). The issue we have is that while we have done ALL we can to adhere to good internet etiquette, we seem to be loosing the battle to send legitimate emails to our customers. In the last month ive been discussing these issues with many ISP's and the range of responses are "Sure heres how you can make it work" to "Go Away we dont want to deal with this". What I'm wondering is this. If we setup a whitelist service that had a set of guidelines, would ISP's look at adopting it in their Firewall/Spam filtering services. Some guidelines for such a service would be: - New Zealand Based List Servers Only - New Zealand Anti Spam law compliant - Correct DNS and Fixed IP Address configured - Agreed Email Delivery Speeds (i.e x number of messages per hour) - Agreed Email Volumes (i.e x number of bulk message sent per day) - Server/Service Administrator Details registered for contacting etc - Security Compliance etc.. Keen to hear any feedback and suggestions. I think i speak for a number of content providers when i say that we want to work with ISP's and provide a service that works for both our Customers and you guys as ISP's. Skip Parker skip(a)ignition.net.nz

9 11

BBBZZZZZTTTT: Where did all the lights go?
by Dean Pemberton 04 Nov '07

04 Nov '07

Anyone get effected by the Telecom power outage? Dean

8 9

[Apnic-announce] APNIC additional IPv4 address blocks
by Elly Tawhai 01 Nov '07

01 Nov '07

Dear colleagues The information in this announcement is to enable the Internet community to update network configurations, such as routing filters, where required. APNIC received the following IPv4 address blocks from IANA in October 2007 and will be making allocations from these ranges in the near future: 114/8 115/8 Reachability and routability testing of new prefixes will commence soon. The daily report will be published at the usual URL: http://www.ris.ripe.net/debogon For more information on the resources administered by APNIC, please see: http://www.apnic.net/db/ranges.html For information on the minimum allocation sizes within address ranges administered by APNIC, please see: http://www.apnic.net/db/min-alloc.html Kind regards, Elly ________________________________________________________________________ Elly Tawhai email: hostmaster(a)apnic.net Internet Resource Analyst/ Liaison (Australasia), APNIC sip: helpdesk(a)voip.apnic.net http://www.apnic.net/helpdesk phone: +61 7 3858 3188 fax: +61 7 3858 3199 ________________________________________________________________________

1 0

Re: [nznog] The day the routers died
by Scott Weeks 01 Nov '07

01 Nov '07

Once, back when I was working on a global network, myself, some folks from Europe and some folks from your part of the world were all working on a big problem together and I kept hearing the guys from your part of the world snicker every time the Europe guys said 'rooter'. Being from Hawaii, I didn't get it. Later, it was explained to me. Now every time I hear the Europe guys say 'rooter' I laugh and everyone now looks at me strangely. ;-) scott --- danclarknz(a)gmail.com wrote: haha the 'Rooter' ;-) --------------------------------- On 11/1/07, Philip D'Ath <pid(a)ifm.net.nz> wrote: > > Not on topic, I know, but this is very entertaining and will appeal to > people on this group. > > http://www.youtube.com/watch?v=_y36fG2Oba0

1 0

IPv6 tunnel appliance beta testers wanted
by Nathan Ward 31 Oct '07

31 Oct '07

Righty, As many of you know, I've been working on building some little tunnelling appliances to push IPv6 over IPv4 using well known protocols (6to4 and Teredo). Both 6to4 and Teredo benefit from having relays in as many places as possible. Cisco currently supports 6to4. I'm not sure if anyone else does. Noone supports Teredo. With both 6to4 and Teredo being built in and enabled by default on Vista (and enable-able on XP SP2), the amount of tunnelled IPv6 traffic on the Internet is increasing. I recently posted on the v6ops IETF mailing list about Azureus's support for IPv6 - when I use this client, over half of my DHT peers are IPv6 peers, and 99% of them were over tunnelled IPv6, either with 6to4 or Teredo. So, in light of this, I've put together a small FreeBSD based image for Soekris hardware. This does Teredo and 6to4, and also BGP. It does some funky tricks to hook all of these boxes together, tunnelling over IPv4. So, you get interconnection with many other networks over IPv4 best paths and existing IPv4 transit. I'm also expecting to be able to get you on to the v6IX (Citylink's IPv6 peering) as well if you (or your transit provider) are an existing IPv4 peer at APE or WIX. This software will be freely available when it's ready. Here's the best bit: Thanks to InternetNZ, I'll soon have have 6 boxes to do a live test of the code, and hopefully more down the line when it's ready to go for real. So, I'm looking for people who are running networks that fit one (or more) of the following: - Large numbers of end users - Lots of content on IPv6 (yeah, I'm dreaming) - Universities (or other large private networks) It doesn't matter if you have some IPv6 deployed, or if you only have IPv4 deployed, or if you haven't even thought about IPv6 deployment yet. What I need from you: - A shelf somewhere, and an IEC C13 (a.k.a. jug plug) cable/outlet. - An IPv4 address or two. - A 10/100 ethernet port (or two if you're keen on resiliency). - The ability to statically route a couple of IPv4 addresses at your box. - Also useful (but not necessary!) is an IPv6 allocation, and some form of transit internationally (a free IPv6 tunnel from somewhere overseas is fine- native transit isn't required) What you get: - 6to4 relay - Teredo relay - IPv6 interconnection to other people with these boxes Impacts: - If it breaks, you might end up with customer IPv6 traffic being impacted. (ie. not that much impact at all, right now) I'm working right now on some deployment pictures and all that noise, so there's more info coming. Please let me know if you're interested, or if you're interested but have some concerns, or, whatever. I'm wanting to get boxes in fairly soon - ie. before xmas brownouts. Integration is pretty minimal if you have an IPv4 network - plug in and point a route or two. It's only slightly more if you have an IPv6 network. Cheers! -- Nathan Ward Braintrust Ltd.

1 0

The day the routers died
by Philip D'Ath 31 Oct '07

31 Oct '07

Not on topic, I know, but this is very entertaining and will appeal to people on this group. http://www.youtube.com/watch?v=_y36fG2Oba0

3 2

[nznog-owner@list.waikato.ac.nz: Re: DNS lookup false positives with: com.co.nz > 208.73.212.12 > information.com]
by Richard Haakma 29 Oct '07

29 Oct '07

On Tue, Oct 30, 2007 at 09:43:32AM +1300, Paul Adshead wrote: > Are any others being affected by the fools who have registered "com.co.nz"? > > It's been setup as a 'catch all' search engine, for the 'append parent DNS > suffix' queries. So a lookup on "abcd.com" that should fail, comes back > successful from "abcd.com.co.nz"... :-( I add a line search . in /etc/resolv.conf in my mail servers to fix this sort of stuff. All email addresses should be fully qualified. Regards, RH.

1 0

DNS lookup false positives with: com.co.nz > 208.73.212.12 > information.com
by Paul Adshead 29 Oct '07

29 Oct '07

Are any others being affected by the fools who have registered "com.co.nz"? It's been setup as a 'catch all' search engine, for the 'append parent DNS suffix' queries. So a lookup on "abcd.com" that should fail, comes back successful from "abcd.com.co.nz"... :-(

4 3

114/8 and 115/8 allocated to APNIC
by Leo Vegoda 28 Oct '07

28 Oct '07

Hi, The IANA IPv4 registry has been updated to reflect the allocation of two /8 IPv4 blocks to APNIC in October 2007: 144/8 and 115/8. You can find the IANA IPv4 registry at: http://www.iana.org/assignments/ipv4-address-space Please update your filters as appropriate. Regards, Leo vegoda Manager, Number Resources - IANA

1 1

NZRR Route Registry Update
by NZRR Database Notifications 28 Oct '07

28 Oct '07

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: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20070928 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17746 descr: advertised to AS9560 by Orcon Internet Ltd - AS17746 members: 60.234.0.0/16^16-29, 121.98.0.0/16^16-29, 156.62.0.0/16^16-29, 202.150.96.0/19^19-29, 203.99.0.0/19^19-29, 203.96.192.0/20^20-29, 219.88.128.0/20^20-29, 219.88.240.0/20^20-29, 116.199.208.0/21^21-29, 210.54.56.0/21^21-29, 202.127.8.0/22^22-29, 210.54.148.0/22^22-29, 210.55.12.0/22^22-29, 202.37.82.0/23^23-29, 202.175.142.0/23^23-29, 192.203.216.0/24^24-29, 202.27.77.0/24^24-29, 202.36.170.0/24^24-29, 202.37.19.0/24^24-29, 202.37.173.0/24^24-29, 202.37.194.0/24^24-29, 202.49.187.0/24^24-29, 202.49.233.0/24^24-29, 202.49.246.0/24^24-29, 202.50.167.0/24^24-29, 202.50.246.0/24^24-29, 202.95.250.0/24^24-29, 202.174.160.0/24^24-29, 203.86.200.0/24^24-29, 210.54.12.0/24^24-29, 210.55.1.0/24^24-29, 210.55.8.0/24^24-29, 210.55.199.0/24^24-29, 202.27.188.128/25^25-29, 210.55.0.0/25^25-29, 210.55.180.128/26^26-29, 210.55.193.64/27^27-29 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: ricky.tipper(a)team.orcon.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071029 source: NZRR ------------------------------------------------------------

1 0

Youtube in NZ?
by Joel van Velden 25 Oct '07

25 Oct '07

Does anyone know anything about todays launch of a New Zealand portal on Youtube and in particular talk of a local youtube server? -Joel

3 2

[Fwd: Academic Study - Telephone Interview]
by Gerard Creamer 23 Oct '07

23 Oct '07

The following came into the info (at) nznog email address. Usually such things make their way to the recycle bin (it used to be the deleted, but we've gone PC /and/ green). This one looked like it might be of interest to someone and possibly even on topic for the list, so if it is something of interest to you please contact the person directly. If I'm wrong please flame me without regard for my feelings (as feeling are definitely off topic :^) Regards, Gerard -------- Original Message -------- Subject: Academic Study - Telephone Interview Date: Wed, 24 Oct 2007 14:54:33 +1300 From: Juan Gan <ganju908 (at) student.otago.ac.nz> To: info (at) nznog.org Hi, My name is Juan-Jim Gan and I am a student at the University of Otago. I am currently conducting a study on the Telecommunication Policymaking in New Zealand ─ specifically dealing with issues of the LLU (Local Loop Unbundling). While conducting my research, I stumbled upon NZNOG - an online community of network operators, predominantly in the Internet and Online Services area. This study could benefit from getting feedback from people within this community (people who are either directly or indirectly related to the LLU). I would like to ask for your permission to talk to someone from this community [via a short telephone interview] with regards to their view on the LLU. The participant could be anyone with an interest in the LLU. Information gathered from this interview could be very valuable for my study on the LLU. I would really appreciate it if you [or anyone from the community] agree to participate in this study. Participation in this study is entirely voluntary and you may choose not to participate or to withdraw your consent to be in the study, for any reason, at any time. Materials gathered from this interview will not be published. If you are interested in taking part in this study, please contact me via e-mail to arrange a suitable time to conduct the interview. My supervisor, Dr. Michael Bourk will be supervising this study. If you have any questions, please do not hesitate to contact either myself or Dr Bourk. Dr Bourk could be contacted on 03 ? 479 5751 or via email at Michael.bourk (at) otago.ac.nz. Your involvement in this study would be greatly appreciated. Thank you, Juan-Jim Gan -- Netspace Services Limited http://www.netspace.net.nz Phone +64 4 917 8098 Mobile +64 21 246 2266 Level One, 220 Thorndon Quay, Thorndon PO Box 12-082, Thorndon, Wellington 6004, New Zealand

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Oct '07

23 Oct '07

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:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 116.90.129.0/24^24-29, 116.90.131.0/24^24-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071003 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS9503 descr: advertised to AS9439 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 23 Oct '07

23 Oct '07

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: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 123.108.144.0/21^21-29, 192.173.16.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 116.90.129.0/24^24-29, 116.90.131.0/24^24-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071003 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS9503 descr: advertised to AS9560 by FX Networks - AS9503 members: 131.203.0.0/16^16-29, 161.29.0.0/16^16-29, 161.65.0.0/16^16-29, 166.65.0.0/16^16-29, 202.53.176.0/20^20-29, 202.191.32.0/20^20-29, 210.48.160.0/20^20-29, 116.90.128.0/21^21-29, 123.108.144.0/21^21-29, 202.46.176.0/21^21-29, 202.78.240.0/21^21-29, 203.190.208.0/21^21-29, 202.37.48.0/22^22-29, 202.59.4.0/22^22-29, 202.6.116.0/23^23-29, 202.124.106.0/23^23-29, 192.88.85.0/24^24-29, 192.122.171.0/24^24-29, 192.133.31.0/24^24-29, 192.195.219.0/24^24-29, 202.20.97.0/24^24-29, 202.36.119.0/24^24-29, 202.36.218.0/24^24-29, 202.46.190.0/24^24-29, 202.49.106.0/24^24-29, 202.50.247.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: noc-minor(a)fx.net.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071024 source: NZRR ------------------------------------------------------------

1 0

Re: [nznog] Re Yahoo and Spam...
by jwkckid1＠ix.netcom.com 22 Oct '07

22 Oct '07

Lenz and all, I am sorry you take the view you do regarding my suggestion. Very unfortunate. None the less, with the amount of spam Yahoo.com and Yahoo.de sems to allow is a huge waste of bandwidth which effects directly the stability of the Internet not to mention irritates unsuspecting users. Hence in part my suggestion. Unless there is a bonified threat of some sort, expecting mass spammers like Yahoo and AOL to curtail their network traffic accordingly, will never occur. However our members routienly block all AOL traffic/Email and all Yahoo.de traffic/Email currently, and have for some time. I suspect they will continue to do so for the forseeable future. -----Original Message----- >From: lengsc(a)coretech.co.nz >Sent: Oct 22, 2007 4:39 PM >To: nznog(a)list.waikato.ac.nz >Subject: Re: [nznog] Re Yahoo and Spam... > >hi, > >i see IMHO no use in spamming ICANN for things that that far away from >their responsibilities like this issue. drop the server in blacklists, >try to raise awarenes for the problem at the companies (spam the board >of yahoo/aol) or do something alike. ICANN has nothing to do with >mailservers and ICANN can not take down any address because they >manage the root not the respective second level domains.yahoo.com is >registered via markmonitor but i am pretty shure that they will not >take down the domain as well. >the approach you suggest is a bit kindergarden like and shows very >little knowledge of the different responsibilities in the internet. > >greets >lenz > >Quoting jwkckid1(a)ix.netcom.com: > >> Mark, >> >> Yahoo and AOL are famous for not addressing Spam or >> any abuse complaints. I have in the recent past suggested >> to ICANN that these sites be taken down unless or until >> they actually address abuse concerns in a direct and meaningful >> way and not with "Canned Email responses". Of course >> ICANN has refused to address this situation with Yahoo or >> AOL as well as Google, simply because of the presence in >> which these Domain names represent, which is IMHO besides >> the point. So I would suggest that every time you get >> one of the "Canned Email responses" you direct it to >> the ICANN bod or vint Cerf at the Email addresses I >> CC'ed this response to, until a ligitimate solution is >> effected. >> >> -----Original Message----- >>> From: Mark Foster <blakjak(a)blakjak.net> >>> Sent: Oct 19, 2007 6:49 PM >>> To: nznog(a)list.waikato.ac.nz >>> Subject: [nznog] Re Yahoo and Spam... >>> >>> Learned NZNOGrs, >>> >>> Some advice, please. >>> >>> Recently an email address that comes to me was sent some Unsolicited >>> Commercial Email from (apparently) a UK based outfit that sells (print) >>> magazine subscriptions. >>> >>> The headers contain this: >>> >>> Received: from smtp107.biz.mail.re2.yahoo.com >>> (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) >>> by mx.blakjak.net (Postfix) with SMTP id 8C508500D4 >>> for <dest(a)address>; Tue, 16 Oct 2007 12:02:52 +1300 (NZDT) >>> >>> They contain additional Received: headers which would imply that Yahoo >>> themselves received the message via SMTP from an AOL IP address that >>> Traceroute implies is likely in the UK as well. >>> >>> So I took a full-headers copy of the message and forwarded the complaint >>> to the relevant abuse contacts for both Yahoo and AOL. >>> >>> AOL, i've heard nothing (unsuprising). Yahoo, I had a response within 2-3 >>> days which basically absolved them of responsibility, as follows: >>> >>> --8<-- >>> >>> Thank you for writing to Yahoo! Mail. >>> >>> I understand your frustration in receiving unsolicited email. While we >>> investigate all reported violations against the Yahoo! Terms of Service >>> (TOS), in this particular case the message you received was not sent >>> through the Yahoo! Mail system. >>> >>> Yahoo! has no control over activities outside its service, and therefore >>> we cannot take action. You may try contacting the sender's email >>> provider, by identifying the sender's domain and contacting the >>> administrator of that domain. The sender's provider should be in a >>> better position to take appropriate action against the sender's account. >>> >>> The email message itself does contain some information relating to the >>> sender's identity. Yahoo! includes the originating Internet Protocol >>> (IP) address in the full Internet headers of all messages sent through >>> Yahoo! Mail, so that we will have information regarding the origin of >>> messages sent through our system. The originating IP address should be >>> located in the very last "Received" line of the full Internet headers >>> and corresponds to the sender's Internet Service Provider (ISP). >>> >>> Please see the following URL for more assistance: >>> >>> http://help.yahoo.com/help/us/mail/spam/spam-05.html >>> >>> Once you have identified the IP address, you can conduct an IP lookup to >>> determine which ISP provides this person with Internet access. One such >>> lookup tool you may want to try is: >>> >>> http://www.arin.net/whois/ >>> >>> You can then attempt to contact that ISP to report any abuse activities >>> occurring within their service. >>> >>> Please let us know if you still need assistance so I may assist you >>> further. >>> >>> Your patience during this process is greatly appreciated. >>> >>> Thank you again for contacting Yahoo! Mail. >>> >>> Regards, >>> >>> --8<-- >>> >>> I responded back indicating my understanding as being: >>> >>> - That my MTA received it from Yahoo, thus they relayed it... >>> - That headers below the line where my MTA actually is involved, are often >>> untrustworthy... >>> >>> I got a very-slightly-reworded version of exactly the same canned response >>> back. >>> >>> >>> So despite the fact that the sender is very clearly using Yahoo for SMTP >>> (which, one would hope, would establish the sender as a Yahoo! Mail >>> customer), they're pleading ignorance and/or innocence. >>> >>> Any other players had similar dealings with Yahoo (or other free mail >>> providers) ? At what point can the provider realistically abdicate from >>> responsibility when it comes to spam? >>> >>> And the obvious question: Is it fair to expect more from them? Or am I >>> resigned to accept either periodic junk relayed by Yahoo because they >>> can't be held responsible for what individual customers do? (And because >>> in this example, the collateral damage of blackholing them is probably >>> unacceptable? >>> >>> Cheers >>> Mark. >>> >> ======= >> >> 'Regards, >> Jeffrey A. Williams >> Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) >> "Obedience of the law is the greatest freedom" - >> Abraham Lincoln >> >> "Credit should go with the performance of duty and not with what is very >> often the accident of glory" - Theodore Roosevelt >> >> "If the probability be called P; the injury, L; and the burden, B; liability >> depends upon whether B is less than L multiplied by >> P: i.e., whether B is less than PL." >> United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] >> =============================================================== >> Updated 1/26/04 >> CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of >> Information Network Eng. INEG. INC. >> ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com >> ======= 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

4 3

Re: [nznog] Re Yahoo and Spam...
by jwkckid1＠ix.netcom.com 22 Oct '07

22 Oct '07

Mark, Yahoo and AOL are famous for not addressing Spam or any abuse complaints. I have in the recent past suggested to ICANN that these sites be taken down unless or until they actually address abuse concerns in a direct and meaningful way and not with "Canned Email responses". Of course ICANN has refused to address this situation with Yahoo or AOL as well as Google, simply because of the presence in which these Domain names represent, which is IMHO besides the point. So I would suggest that every time you get one of the "Canned Email responses" you direct it to the ICANN bod or vint Cerf at the Email addresses I CC'ed this response to, until a ligitimate solution is effected. -----Original Message----- >From: Mark Foster <blakjak(a)blakjak.net> >Sent: Oct 19, 2007 6:49 PM >To: nznog(a)list.waikato.ac.nz >Subject: [nznog] Re Yahoo and Spam... > >Learned NZNOGrs, > >Some advice, please. > >Recently an email address that comes to me was sent some Unsolicited >Commercial Email from (apparently) a UK based outfit that sells (print) >magazine subscriptions. > >The headers contain this: > >Received: from smtp107.biz.mail.re2.yahoo.com >(smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) > by mx.blakjak.net (Postfix) with SMTP id 8C508500D4 > for <dest(a)address>; Tue, 16 Oct 2007 12:02:52 +1300 (NZDT) > >They contain additional Received: headers which would imply that Yahoo >themselves received the message via SMTP from an AOL IP address that >Traceroute implies is likely in the UK as well. > >So I took a full-headers copy of the message and forwarded the complaint >to the relevant abuse contacts for both Yahoo and AOL. > >AOL, i've heard nothing (unsuprising). Yahoo, I had a response within 2-3 >days which basically absolved them of responsibility, as follows: > >--8<-- > >Thank you for writing to Yahoo! Mail. > >I understand your frustration in receiving unsolicited email. While we >investigate all reported violations against the Yahoo! Terms of Service >(TOS), in this particular case the message you received was not sent >through the Yahoo! Mail system. > >Yahoo! has no control over activities outside its service, and therefore >we cannot take action. You may try contacting the sender's email >provider, by identifying the sender's domain and contacting the >administrator of that domain. The sender's provider should be in a >better position to take appropriate action against the sender's account. > >The email message itself does contain some information relating to the >sender's identity. Yahoo! includes the originating Internet Protocol >(IP) address in the full Internet headers of all messages sent through >Yahoo! Mail, so that we will have information regarding the origin of >messages sent through our system. The originating IP address should be >located in the very last "Received" line of the full Internet headers >and corresponds to the sender's Internet Service Provider (ISP). > >Please see the following URL for more assistance: > > http://help.yahoo.com/help/us/mail/spam/spam-05.html > >Once you have identified the IP address, you can conduct an IP lookup to >determine which ISP provides this person with Internet access. One such >lookup tool you may want to try is: > > http://www.arin.net/whois/ > >You can then attempt to contact that ISP to report any abuse activities >occurring within their service. > >Please let us know if you still need assistance so I may assist you >further. > >Your patience during this process is greatly appreciated. > >Thank you again for contacting Yahoo! Mail. > >Regards, > >--8<-- > >I responded back indicating my understanding as being: > >- That my MTA received it from Yahoo, thus they relayed it... >- That headers below the line where my MTA actually is involved, are often >untrustworthy... > >I got a very-slightly-reworded version of exactly the same canned response >back. > > >So despite the fact that the sender is very clearly using Yahoo for SMTP >(which, one would hope, would establish the sender as a Yahoo! Mail >customer), they're pleading ignorance and/or innocence. > >Any other players had similar dealings with Yahoo (or other free mail >providers) ? At what point can the provider realistically abdicate from >responsibility when it comes to spam? > >And the obvious question: Is it fair to expect more from them? Or am I >resigned to accept either periodic junk relayed by Yahoo because they >can't be held responsible for what individual customers do? (And because >in this example, the collateral damage of blackholing them is probably >unacceptable? > >Cheers >Mark. > ======= 'Regards, Jeffrey A. Williams Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!) "Obedience of the law is the greatest freedom" - Abraham Lincoln "Credit should go with the performance of duty and not with what is very often the accident of glory" - Theodore Roosevelt "If the probability be called P; the injury, L; and the burden, B; liability depends upon whether B is less than L multiplied by P: i.e., whether B is less than PL." United States v. Carroll Towing (159 F.2d 169 [2d Cir. 1947] =============================================================== Updated 1/26/04 CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1(a)ix.netcom.com

2 1

Of interest - Yahoo mail issues
by Michael J. Densem 22 Oct '07

22 Oct '07

Hi, This is simply some information that may be of interest to those who have had/are having issues with Xtra email since the change over to Yahoo! I had problems with their servers rejecting email from my servers back in August (when Xtra changed to Yahoo for email services). I filled out all the suggested documents and requests to have my server(s) white-listed. Today (23 Oct) I finally had a response (see email below). No further comment! - just FYI -----Original Message----- From: Yahoo! Mail [mailto:mail-abuse-review(a)cc.yahoo-inc.com] Sent: Tuesday, 23 October 2007 7:45 a.m. To: Michael J. Densem Subject: Yahoo! Customer Care - monitor results... (KMM59108720V785******) Hello Mike, We appreciate your patience. We have recently concluded the monitoring of your company's mailings. Based on the information we have gathered, it appears that our users deem that the mailings from your IP address(es) are being directed to the correct folder and we cannot systematically exempt your mailings from our SpamGuard technology for: 202.174.***.*** 202.174.***.*** 202.174.***.*** Please keep in mind that our SpamGuard technology will continually monitor user feedback pertaining to emails coming from your mail server(s), and as such, the user feedback we receive will be one of the factors that influence where your emails are most appropriately delivered. Our studies have indicated that when users see messages miscategorized, they notify us within hours of delivery. Note: If you wish to ensure that your users get your emails in their Inbox, you may want to ask your subscribers to set up a filter in Yahoo! Mail specifically for your emails, or have them add your email address(es) to their Yahoo! Address Book. If you implement significant changes to your mailing practices, feel free to contact us again in 6 months and we will send you our most up-to-date application and reevaluate your mailing practices at that time. You may refer to the Help page below for some information and general guidelines that we have found to be effective in maintaining good mailing lists: http://help.yahoo.com/help/us/mail/bulk/bulk-01.html Please let us know if you still experience problems so we may assist you further to resolve your issue. Your patience during this process is greatly appreciated. Thank you again for contacting Yahoo! Mail. Regards, Thomas Immer Yahoo! Customer Care

1 0

Re: [nznog] Citylink problems?
by Tony Wicks 21 Oct '07

21 Oct '07

Ok, I'll run a pool for cause. Propose possible reasons and I'll come up with odds. All betting to be done in the currency of handles to be settled at the next meeting. Well Its been more than a couple of more hours now ! There had better be a good explanation and I really love the - Network Status - No known fault System Status Normal - No major problems

6 7

Re Yahoo and Spam...
by Mark Foster 19 Oct '07

19 Oct '07

Learned NZNOGrs, Some advice, please. Recently an email address that comes to me was sent some Unsolicited Commercial Email from (apparently) a UK based outfit that sells (print) magazine subscriptions. The headers contain this: Received: from smtp107.biz.mail.re2.yahoo.com (smtp107.biz.mail.re2.yahoo.com [206.190.52.176]) by mx.blakjak.net (Postfix) with SMTP id 8C508500D4 for <dest(a)address>; Tue, 16 Oct 2007 12:02:52 +1300 (NZDT) They contain additional Received: headers which would imply that Yahoo themselves received the message via SMTP from an AOL IP address that Traceroute implies is likely in the UK as well. So I took a full-headers copy of the message and forwarded the complaint to the relevant abuse contacts for both Yahoo and AOL. AOL, i've heard nothing (unsuprising). Yahoo, I had a response within 2-3 days which basically absolved them of responsibility, as follows: --8<-- Thank you for writing to Yahoo! Mail. I understand your frustration in receiving unsolicited email. While we investigate all reported violations against the Yahoo! Terms of Service (TOS), in this particular case the message you received was not sent through the Yahoo! Mail system. Yahoo! has no control over activities outside its service, and therefore we cannot take action. You may try contacting the sender's email provider, by identifying the sender's domain and contacting the administrator of that domain. The sender's provider should be in a better position to take appropriate action against the sender's account. The email message itself does contain some information relating to the sender's identity. Yahoo! includes the originating Internet Protocol (IP) address in the full Internet headers of all messages sent through Yahoo! Mail, so that we will have information regarding the origin of messages sent through our system. The originating IP address should be located in the very last "Received" line of the full Internet headers and corresponds to the sender's Internet Service Provider (ISP). Please see the following URL for more assistance: http://help.yahoo.com/help/us/mail/spam/spam-05.html Once you have identified the IP address, you can conduct an IP lookup to determine which ISP provides this person with Internet access. One such lookup tool you may want to try is: http://www.arin.net/whois/ You can then attempt to contact that ISP to report any abuse activities occurring within their service. Please let us know if you still need assistance so I may assist you further. Your patience during this process is greatly appreciated. Thank you again for contacting Yahoo! Mail. Regards, --8<-- I responded back indicating my understanding as being: - That my MTA received it from Yahoo, thus they relayed it... - That headers below the line where my MTA actually is involved, are often untrustworthy... I got a very-slightly-reworded version of exactly the same canned response back. So despite the fact that the sender is very clearly using Yahoo for SMTP (which, one would hope, would establish the sender as a Yahoo! Mail customer), they're pleading ignorance and/or innocence. Any other players had similar dealings with Yahoo (or other free mail providers) ? At what point can the provider realistically abdicate from responsibility when it comes to spam? And the obvious question: Is it fair to expect more from them? Or am I resigned to accept either periodic junk relayed by Yahoo because they can't be held responsible for what individual customers do? (And because in this example, the collateral damage of blackholing them is probably unacceptable? Cheers Mark.

1 0

JobSpam
by Richard Nelson 17 Oct '07

17 Oct '07

If you are tired of the attractions of the real world, burdened by responsibility and overpaid or just need to move to Hamilton before the V8s get here then you will be pleased to learn that WAND are looking for a Research Fellow. see http://www.waikato.ac.nz/hrm/vacancies/270292.shtml Richard.

1 0

Emails to xtra addresses not being delivered
by Vaughan Chetwynd 16 Oct '07

16 Oct '07

My server generates emails for about 150 members of a choir. 30 of these have xtra addresses, and since the change to yahoo, these are not being delivered. All other addresses work OK. The xtra addresses were OK before the yahoo bubble started up. I receive no notification of non delivery. Can anybody tell me what I need to do to get these emails accepted by the xtra servers? Vaughan Chetwynd 968c Tauwhare Road RD4 Hamilton phone 07 824 0983 mobile 0275 657 724

2 1

Re: [nznog] Citylink problems?
by Anton Smith 16 Oct '07

16 Oct '07

Simon wrote: > I'll do a more in depth explanation tomorrow. Essentially, this started > happening, on every interswitch trunk on most switches on the network: > > Oct 6 14:09:07: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back > detected on FastEthernet0/24. > Oct 6 14:09:07: %PM-4-ERR_DISABLE: loopback error detected on Fa0/24, > putting Fa0/24 in err-disable state Oct 6 14:09:08: %LINEPROTO-5-UPDOWN: > Line protocol on Interface FastEthernet0/24, changed state to down Oct 6 > 14:09:09: %LINK-3-UPDOWN: Interface FastEthernet0/24, changed state to down > Oct 6 14:09:50: %PM-4-ERR_RECOVER: Attempting to recover from loopback > err-disable state on Fa0/24 Oct 6 14:09:55: %LINK-3-UPDOWN: Interface > FastEthernet0/24, changed state to up Oct 6 14:09:57: %LINEPROTO-5-UPDOWN: > Line protocol on Interface FastEthernet0/24, changed state to up Oct 6 > 14:09:57: %ETHCNTR-3-LOOP_BACK_DETECTED: Keepalive packet loop-back detected > on FastEthernet0/24. Any further word on the more in depth explanation? Interested from both a customer perspective and a technical perspective - good to learn from these things. Regards, Anton

3 2

NZRR Route Registry Update
by NZRR Database Notifications 15 Oct '07

15 Oct '07

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: AS9560:RS-ROUTES:AS24005 descr: advertised to AS9560 by SafeNZ Networks - AS24005 members: 202.56.32.0/20^20-29, 202.56.48.0/21^21-29, 202.137.240.0/21^21-29, 202.170.160.0/21^21-29, 203.167.254.0/23^23-29, 202.50.252.0/24^24-29, 203.97.6.0/24^24-29, 203.98.6.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: tonyw(a)tonyw.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20061026 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS24005 descr: advertised to AS9560 by SafeNZ Networks Limited - AS24005 members: 124.155.224.0/20^20-29, 202.170.160.0/20^20-29, 203.167.254.0/23^23-29, 202.50.252.0/24^24-29, 203.97.6.0/24^24-29, 203.98.6.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: tonyw(a)tonyw.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20071016 source: NZRR ------------------------------------------------------------

1 0