- NZNOG - lists.nznog.org

NZRR Route Registry Update
by NZRR Database Notifications 17 Jul '12

17 Jul '12

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-ROUTES6:AS45177 descr: Route set advertised to AS9560 by Vibe Communications LTD - AS45177 mp-members: 2401:7000:0:0:0:0:0:0/32^32-64, 2001:DF0:2C1:0:0:0:0:0/48^48-64, 2404:5700:0:0:0:0:0:0/32^32-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)vibecommunications.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120716 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES6:AS45177 descr: Route set advertised to AS9560 by Vibe Communications LTD - AS45177 mp-members: 2401:7000:0:0:0:0:0:0/32^32-64, 2001:DF0:2C1:0:0:0:0:0/48^48-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: operations(a)vibecommunications.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120718 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jul '12

17 Jul '12

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-ROUTES6:AS45179 descr: Route set advertised to AS9560 by SiteHost - AS45179 mp-members: 2403:7000:0:0:0:0:0:0/32^32-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: quintin(a)sitehost.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20090312 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES6:AS45179 descr: Route set advertised to AS9560 by SiteHost - AS45179 mp-members: 2403:7000:0:0:0:0:0:0/32^32-64, 2400:4800:4006:0:0:0:0:0/48^48-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: mike.jager(a)synack.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120718 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jul '12

17 Jul '12

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-ROUTES6:AS9503 descr: Route set advertised to AS9560 by FX Networks - AS9503 mp-members: 2402:6000:0:0:0:0:0:0/32^32-64, 2404:3800:0:0:0:0:0:0/32^32-64, 2001:DCE:0:0:0:0:0:0/32^32-64, 2001:DCE:E000:0:0:0:0:0/48^48-64, 2001:DF0:4A:0:0:0:0:0/48^48-64, 2404:1800:0:0:0:0:0:0/32^32-64, 2001:4530:0:0:0:0:0:0/32^32-64, 2400:B400:0:0:0:0:0:0/32^32-64, 2404:130:0:0:0:0:0:0/32^32-64, 2403:E00:0:0:0:0:0:0/32^32-64, 2400:1200:0:0:0:0:0:0/32^32-64, 2403:C200:0:0:0:0:0:0/32^32-64, 2404:1E00:0:0:0:0:0:0/32^32-64, 2401:F000:0:0:0:0:0:0/32^32-64, 2407:2400:0:0:0:0:0:0/32^32-64, 2403:7000:0:0:0:0:0:0/32^32-64, 2404:138:103:0:0:0:0:0/48^48-64, 2404:138:104:0:0:0:0:0/48^48-64, 2404:138:4000:0:0:0:0:0/48^48-64, 2404:D000:0:0:0:0:0:0/32^32-64, 2405:3A00:0:0:0:0:0:0/32^32-64, 2400:C000:0:0:0:0:0:0/32^32-64, 2001:DF0:D1:0:0:0:0:0/48^48-64, 2405:2600:0:0:0:0:0:0/32^32-64, 2001:DF0:DC:0:0:0:0:0/48^48-64, 2001:DD8:13:0:0:0:0:0/48^48-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2404:6600:0:0:0:0:0:0/32^32-64, 2406:5A00:0:0:0:0:0:0/32^32-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2400:6900:0:0:0:0:0:0/32^32-64, 2400:BD00:0:0:0:0:0:0/32^32-64, 2001:DF0:4:0:0:0:0:0/48^48-64, 2404:139:300:0:0:0:0:0/43^43-64, 2404:139:3FF:0:0:0:0:0/56^56-64, 2406:1A00:0:0:0:0:0:0/32^32-64, 2400:E700:0:0:0:0:0:0/32^32-64, 2402:CC00:0:0:0:0:0:0/32^32-64, 2403:A00:0:0:0:0:0:0/32^32-64, 2405:B400:0:0:0:0:0:0/32^32-64, 2001:500:3:0:0:0:0:0/48^48-64, 2403:B700:0:0:0:0:0:0/32^32-64, 2403:F700:0:0:0:0:0:0/32^32-64 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 20120529 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES6:AS9503 descr: Route set advertised to AS9560 by FX Networks - AS9503 mp-members: 2402:6000:0:0:0:0:0:0/32^32-64, 2404:3800:0:0:0:0:0:0/32^32-64, 2001:DCE:0:0:0:0:0:0/32^32-64, 2001:DCE:E000:0:0:0:0:0/48^48-64, 2001:DF0:4A:0:0:0:0:0/48^48-64, 2404:1800:0:0:0:0:0:0/32^32-64, 2001:4530:0:0:0:0:0:0/32^32-64, 2400:B400:0:0:0:0:0:0/32^32-64, 2404:130:0:0:0:0:0:0/32^32-64, 2403:E00:0:0:0:0:0:0/32^32-64, 2400:1200:0:0:0:0:0:0/32^32-64, 2403:C200:0:0:0:0:0:0/32^32-64, 2404:1E00:0:0:0:0:0:0/32^32-64, 2401:F000:0:0:0:0:0:0/32^32-64, 2407:2400:0:0:0:0:0:0/32^32-64, 2403:7000:0:0:0:0:0:0/32^32-64, 2404:138:103:0:0:0:0:0/48^48-64, 2404:138:104:0:0:0:0:0/48^48-64, 2404:138:4000:0:0:0:0:0/48^48-64, 2404:D000:0:0:0:0:0:0/32^32-64, 2405:3A00:0:0:0:0:0:0/32^32-64, 2400:C000:0:0:0:0:0:0/32^32-64, 2001:DF0:D1:0:0:0:0:0/48^48-64, 2405:2600:0:0:0:0:0:0/32^32-64, 2001:DF0:DC:0:0:0:0:0/48^48-64, 2001:DD8:13:0:0:0:0:0/48^48-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2404:6600:0:0:0:0:0:0/32^32-64, 2406:5A00:0:0:0:0:0:0/32^32-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2400:6900:0:0:0:0:0:0/32^32-64, 2400:BD00:0:0:0:0:0:0/32^32-64, 2001:DF0:4:0:0:0:0:0/48^48-64, 2404:139:300:0:0:0:0:0/43^43-64, 2404:139:3FF:0:0:0:0:0/56^56-64, 2406:1A00:0:0:0:0:0:0/32^32-64, 2400:E700:0:0:0:0:0:0/32^32-64, 2402:CC00:0:0:0:0:0:0/32^32-64, 2403:A00:0:0:0:0:0:0/32^32-64, 2405:B400:0:0:0:0:0:0/32^32-64, 2001:500:3:0:0:0:0:0/48^48-64, 2403:B700:0:0:0:0:0:0/32^32-64, 2403:F700:0:0:0:0:0:0/32^32-64, 2001:DF0:2BB:0:0:0:0:0/48^48-64 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 20120718 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 17 Jul '12

17 Jul '12

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-ROUTES6:AS9503 descr: Route set advertised to AS9439 by FX Networks - AS9503 mp-members: 2402:6000:0:0:0:0:0:0/32^32-64, 2404:3800:0:0:0:0:0:0/32^32-64, 2001:DCE:0:0:0:0:0:0/32^32-64, 2001:DCE:E000:0:0:0:0:0/48^48-64, 2001:DF0:4A:0:0:0:0:0/48^48-64, 2404:1800:0:0:0:0:0:0/32^32-64, 2001:4530:0:0:0:0:0:0/32^32-64, 2400:B400:0:0:0:0:0:0/32^32-64, 2404:130:0:0:0:0:0:0/32^32-64, 2403:E00:0:0:0:0:0:0/32^32-64, 2400:1200:0:0:0:0:0:0/32^32-64, 2403:C200:0:0:0:0:0:0/32^32-64, 2404:1E00:0:0:0:0:0:0/32^32-64, 2401:F000:0:0:0:0:0:0/32^32-64, 2407:2400:0:0:0:0:0:0/32^32-64, 2403:7000:0:0:0:0:0:0/32^32-64, 2404:138:103:0:0:0:0:0/48^48-64, 2404:138:104:0:0:0:0:0/48^48-64, 2404:138:4000:0:0:0:0:0/48^48-64, 2404:D000:0:0:0:0:0:0/32^32-64, 2405:3A00:0:0:0:0:0:0/32^32-64, 2400:C000:0:0:0:0:0:0/32^32-64, 2001:DF0:D1:0:0:0:0:0/48^48-64, 2405:2600:0:0:0:0:0:0/32^32-64, 2001:DF0:DC:0:0:0:0:0/48^48-64, 2001:DD8:13:0:0:0:0:0/48^48-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2404:6600:0:0:0:0:0:0/32^32-64, 2406:5A00:0:0:0:0:0:0/32^32-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2400:6900:0:0:0:0:0:0/32^32-64, 2400:BD00:0:0:0:0:0:0/32^32-64, 2001:DF0:4:0:0:0:0:0/48^48-64, 2404:139:300:0:0:0:0:0/43^43-64, 2404:139:3FF:0:0:0:0:0/56^56-64, 2406:1A00:0:0:0:0:0:0/32^32-64, 2400:E700:0:0:0:0:0:0/32^32-64, 2402:CC00:0:0:0:0:0:0/32^32-64, 2403:A00:0:0:0:0:0:0/32^32-64, 2405:B400:0:0:0:0:0:0/32^32-64, 2001:500:3:0:0:0:0:0/48^48-64, 2403:B700:0:0:0:0:0:0/32^32-64, 2403:F700:0:0:0:0:0:0/32^32-64 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 20120529 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES6:AS9503 descr: Route set advertised to AS9439 by FX Networks - AS9503 mp-members: 2402:6000:0:0:0:0:0:0/32^32-64, 2404:3800:0:0:0:0:0:0/32^32-64, 2001:DCE:0:0:0:0:0:0/32^32-64, 2001:DCE:E000:0:0:0:0:0/48^48-64, 2001:DF0:4A:0:0:0:0:0/48^48-64, 2404:1800:0:0:0:0:0:0/32^32-64, 2001:4530:0:0:0:0:0:0/32^32-64, 2400:B400:0:0:0:0:0:0/32^32-64, 2404:130:0:0:0:0:0:0/32^32-64, 2403:E00:0:0:0:0:0:0/32^32-64, 2400:1200:0:0:0:0:0:0/32^32-64, 2403:C200:0:0:0:0:0:0/32^32-64, 2404:1E00:0:0:0:0:0:0/32^32-64, 2401:F000:0:0:0:0:0:0/32^32-64, 2407:2400:0:0:0:0:0:0/32^32-64, 2403:7000:0:0:0:0:0:0/32^32-64, 2404:138:103:0:0:0:0:0/48^48-64, 2404:138:104:0:0:0:0:0/48^48-64, 2404:138:4000:0:0:0:0:0/48^48-64, 2404:D000:0:0:0:0:0:0/32^32-64, 2405:3A00:0:0:0:0:0:0/32^32-64, 2400:C000:0:0:0:0:0:0/32^32-64, 2001:DF0:D1:0:0:0:0:0/48^48-64, 2405:2600:0:0:0:0:0:0/32^32-64, 2001:DF0:DC:0:0:0:0:0/48^48-64, 2001:DD8:13:0:0:0:0:0/48^48-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2404:6600:0:0:0:0:0:0/32^32-64, 2406:5A00:0:0:0:0:0:0/32^32-64, 2406:1E00:6000:0:0:0:0:0/35^35-64, 2400:6900:0:0:0:0:0:0/32^32-64, 2400:BD00:0:0:0:0:0:0/32^32-64, 2001:DF0:4:0:0:0:0:0/48^48-64, 2404:139:300:0:0:0:0:0/43^43-64, 2404:139:3FF:0:0:0:0:0/56^56-64, 2406:1A00:0:0:0:0:0:0/32^32-64, 2400:E700:0:0:0:0:0:0/32^32-64, 2402:CC00:0:0:0:0:0:0/32^32-64, 2403:A00:0:0:0:0:0:0/32^32-64, 2405:B400:0:0:0:0:0:0/32^32-64, 2001:500:3:0:0:0:0:0/48^48-64, 2403:B700:0:0:0:0:0:0/32^32-64, 2403:F700:0:0:0:0:0:0/32^32-64, 2001:DF0:2BB:0:0:0:0:0/48^48-64 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 20120718 source: NZRR ------------------------------------------------------------

1 0

DNSSEC now enabled for net.nz and org.nz
by Sebastian Castro 16 Jul '12

16 Jul '12

To our community: NZRS has just completed the deployment of DNSSEC for net.nz and org.nz, enabling full validation for their sub-domains. They join ac.nz, gen.nz, geek.nz, maori.nz and school.nz as fully signed domains. The deployment process will continue with co.nz in the upcoming weeks. There are also yet-to-be-announced plans to sign the moderated second level domains. If you are keen to sign your domains, or they are already signed and need to submit DS records, a list of .nz Registrars who are either DNSSEC Friendly, or offer DNSSEC services can be found at http://dnc.org.nz/registrars Kind Regards, -- Sebastian Castro DNS Specialist .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 495 2337 mobile: +64 21 400535

2 2

NZRR Route Registry Update
by NZRR Database Notifications 15 Jul '12

15 Jul '12

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-ROUTES6:AS45177 descr: Route set advertised to AS9560 by Vibe Communications - AS45177 mp-members: 2401:7000:0:0:0:0:0:0/32^32-64, 2401:D400:0:0:0:0:0:0/32^32-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: barry(a)vibecommunications.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20100830 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES6:AS45177 descr: Route set advertised to AS9560 by Vibe Communications LTD - AS45177 mp-members: 2401:7000:0:0:0:0:0:0/32^32-64, 2001:DF0:2C1:0:0:0:0:0/48^48-64, 2404:5700:0:0:0:0:0:0/32^32-64 admin-c: RPA1-NZRR tech-c: RPA1-NZRR notify: rpsl-admin(a)nzix.net notify: nznog(a)list.waikato.ac.nz notify: noc(a)vibecommunications.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20120716 source: NZRR ------------------------------------------------------------

1 0

For he's a jolly good fellow...
by Andy Linton 14 Jul '12

14 Jul '12

Dean Pemberton, who some of you may know, was made a Fellow of InternetNZ last night at the AGM. Big ups to him. andy

4 3

Remote access to Data Loggers in Taharoa Mine and Rangiriri
by Bill Walker 11 Jul '12

11 Jul '12

Hey Guys, I'm looking for someone who would be interested in building a solution to give remote access to two data loggers in the North Island: Taharoa Mine 38° 9'52.40"S 174°42'48.84"E Rangiriri Interchange 37°25'41.29"S 175° 7'41.86"E Basically the solution would need to be self contained and probably solar powered. It would need to interface to both these data loggers via serial. If your interested or know someone who would be, send me your details and I'll forward them onto the engineer who has this requirement. This is something I could do but I'm on the wrong island and I doubt my wife would let me go..... Thanks, Bill

1 0

Re: [nznog] APNIC - The policy to end all policies prop-103-v001
by Dean Pemberton 10 Jul '12

10 Jul '12

That may be true for v4 (although I'm far from convinced). But I'm not at all buying it for v6 On Wednesday, July 11, 2012, wrote: > > > Actually, I think that this proposal is more than just to incite thinking, > it actually > has merit. The v4 space is functionally all assigned. Many/Most of the > existing policies > are focused on events that are no longer relevent. new policies, if any, > should ensure > accurate recording of stewardship. It would make an ISP's life -MUCH- > simpler. > > /bill > > > > > On Wed, Jul 11, 2012 at 03:53:19PM +1200, Dean Pemberton wrote: > > So let me ask a simple question. > > > > Do people think that there is a need to develop any more IP policies? Or > > are all the policies we have the moment sufficient for the future? > > > > Dean > > > > On Tuesday, July 10, 2012, Matthew Moyle-Croft wrote: > > > > > I think Randy's taking the wrong tactic with this. > > > > > > Policy needs to be a series of no-rules cage fights or, maybe, > something > > > along the line of gladiator traditions in Roman time. > > > > > > Then it could be televised, a profit made and APNIC run from that > profit > > > rather than charging for IP addresses and ASes. > > > > > > MMC > > > > > > On 09/07/2012, at 6:08 AM, Dean Pemberton wrote: > > > > > > > Morning all, > > > > > > > > Randy Bush (from IIJ in Japan) has just tabled a policy for > discussion > > > > at the August APNIC members meeting. > > > > Essentially if passed this would see the APNIC policy development > > > > process disolved. > > > > > > > > I'm interested in feedback that people on this list may have, and I'm > > > > happy to pass it along on the sig-policy list or in person at the > > > > meeting. > > > > As always, feel free to contribute to what I'm sure will be heated > > > > discussion on the APNIC sig-policy list. I'll try and summarise the > > > > happenings back here. > > > > > > > > Regards, > > > > Dean > > > > > > > > > > > > ---------- Forwarded message ---------- > > > > From: Andy Linton <asjl(a)lpnz.org> > > > > Date: Mon, Jul 9, 2012 at 5:32 AM > > > > Subject: [sig-policy] prop-103-v001: A Final IP Address Policy > Proposal > > > > To: SIG policy <sig-policy(a)apnic.net> > > > > > > > > > > > > Dear SIG members > > > > > > > > The proposal "prop-103-v001: A Final IP Address Policy Proposal" has > > > > been sent to the Policy SIG for review. > > > > > > > > It will be discussed at the Policy SIG at APNIC 34 in Phnom Penh, > > > > Cambodia, Thursday, 30 August 2012. > > > > > > > > We invite you to review and comment on the proposal on the mailing > list > > > > before the meeting. > > > > > > > > The comment period on the mailing list before an APNIC meeting is an > > > > important part of the policy development process. We encourage you to > > > > express your views on the proposal: > > > > > > > > - Do you support or oppose this proposal? > > > > - Does this proposal solve a problem you are experiencing? > If > > > > so, tell the community about your situation. > > > > - Do you see any disadvantages in this proposal? > > > > - Is there anything in the proposal that is not clear? > > > > - What changes could be made to this proposal to make it > more > > > > effective? > > > > > > > > Information about this and other policy proposals is available from: > > > > > > > > https://www.apnic.net/policy/proposals/prop-103 > > > > > > > > Andy, Skeeve, Masato > > > > > > > > > > > > ------------------------------------------------------------------- > > > > > > > > prop-103-v001: A Final IP Address Policy Proposal > > > > > > > > -------------------------------------------------------------------- > > > > > > > > Author: Randy Bush > > > > <randy(a)psg.com> > > > > > > > > > > > > 1. Introduction > > > > ------------------- > > > > > > > > IPv4 is history, with no need to add more pol> > > > NZNOG(a)list.waikato.ac.nz <javascript:;> <javascript:;> > > > > http://list.waikato.ac.nz/mailman/listinfo/nznog > > > > > > > > > _______________________________________________ > > NZNOG mailing list > > NZNOG(a)list.waikato.ac.nz <javascript:;> > > http://list.waikato.ac.nz/mailman/listinfo/nznog > >

3 2

APNIC - The policy to end all policies prop-103-v001
by Dean Pemberton 10 Jul '12

10 Jul '12

Morning all, Randy Bush (from IIJ in Japan) has just tabled a policy for discussion at the August APNIC members meeting. Essentially if passed this would see the APNIC policy development process disolved. I'm interested in feedback that people on this list may have, and I'm happy to pass it along on the sig-policy list or in person at the meeting. As always, feel free to contribute to what I'm sure will be heated discussion on the APNIC sig-policy list. I'll try and summarise the happenings back here. Regards, Dean ---------- Forwarded message ---------- From: Andy Linton <asjl(a)lpnz.org> Date: Mon, Jul 9, 2012 at 5:32 AM Subject: [sig-policy] prop-103-v001: A Final IP Address Policy Proposal To: SIG policy <sig-policy(a)apnic.net> Dear SIG members The proposal "prop-103-v001: A Final IP Address Policy Proposal" has been sent to the Policy SIG for review. It will be discussed at the Policy SIG at APNIC 34 in Phnom Penh, Cambodia, Thursday, 30 August 2012. We invite you to review and comment on the proposal on the mailing list before the meeting. The comment period on the mailing list before an APNIC meeting is an important part of the policy development process. We encourage you to express your views on the proposal: - Do you support or oppose this proposal? - Does this proposal solve a problem you are experiencing? If so, tell the community about your situation. - Do you see any disadvantages in this proposal? - Is there anything in the proposal that is not clear? - What changes could be made to this proposal to make it more effective? Information about this and other policy proposals is available from: https://www.apnic.net/policy/proposals/prop-103 Andy, Skeeve, Masato ------------------------------------------------------------------- prop-103-v001: A Final IP Address Policy Proposal -------------------------------------------------------------------- Author: Randy Bush <randy(a)psg.com> 1. Introduction ------------------- IPv4 is history, with no need to add more policy. IPv6 is sufficiently plentiful that further policies are not needed. So let us agree to make no more IP address policies or proposals. 2. Summary ---------------- The APNIC community spends time and resources proposing, discussing, arguing, ... about IP address policies out of habit. The process is no longer relevant to actually coordinating the prudent and high quality operation of the internet. 3. Situation in other RIRs --------------------------------- There is an industry of policy wannabes spending inordinate time and resources making endless policy proposals about miniscule issues and baroque corner cases. This is a waste of time and other resources. 4. Details ------------- The policy proposal and decision processes should be closed and stopped after the Phnom Penh meeting. Should an emergency arise, where community consensus is needed, the EC can organize fora for forming that consensus. 5. Pros/Cons ----------------- Advantages: - We would not have to spend time discussing things of small consequence and which do not help the customer/user in any real way. Disadvantages: - It would impact the amateur careers of policy wannabes. This is a feature, not a bug. 6. Effect on APNIC ------------------------- Saves money, time, and other resources such as administrative complexity created by more complex but useless policies. 7. Effect on NIRs ----------------------- Saves money, time, and other resources such as administrative complexity created by more complex but useless policies.. * sig-policy: APNIC SIG on resource management policy * _______________________________________________ sig-policy mailing list sig-policy(a)lists.apnic.net http://mailman.apnic.net/mailman/listinfo/sig-policy

7 10