- NZNOG - lists.nznog.org

Anti Spam Legislation vs Spam realities and ISP staffing
by Mark Foster 29 Jul '05

29 Jul '05

http://www.nzherald.co.nz/index.cfm?c_id=5&ObjectID=10338203 My review of this article noted this paragraph: --8<-- Internet users will complain in the first instance to their internet provider about spam email, and the Department of Internal Affairs will act as an internet watchdog if the matter is taken further. --8<-- Now did I get the wrong end of the stick here, or is this saying that the onus of the ISP that provides connectivity to the Spam Receiver to act on complaints - or the DIA will be hounding them? Shouldn't the source ISP, and not the destination, be the people responsible for dealing with their own spam sources? I wrote a bit of a commentary of my own: http://www.blakjak.net/node/view/261 However wonder if this has come to the attention of anyone else yet... The first thing that jumps into my head is that ISPs are going to wind up having to do all the investigative legwork on the complaints they receive - and not many ISPS I know of are staffed to support this. Antispam costs for all providers going up - and probably going up in relation to the size of their customer base. Hmmm.... Mark.

3 3

RE: [nznog] Multi-point VPN around NZ to a central location ( Wellington)
by Kerry Milestone 28 Jul '05

28 Jul '05

Mmmmm....... Chrome bits...... Yes. Realistically though... Nissan350z. ________________________________ From: Drew Broadley [mailto:drew(a)corrupt.co.nz] Sent: Friday, 29 July 2005 2:19 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] Multi-point VPN around NZ to a central location ( Wellington) Hi all, I'm representing a company where the requirements are going to need a large amount of nodes around the country where they will all require (at least) a dedicated 128kbps connection to a central "nerve" located on WIX and additional redundancy on the central system at another location, ultimately somewhere on the APE. We would ideally not approach Telecom directly at the moment through a buzz-word junkie sales person at the moment as I want a realistic perspective on this, not someone who will just say yes so they can afford to chrome more parts on their Audi. If you have any available options, could you please contact me off list. Cheers, Drew

2 1

Multi-point VPN around NZ to a central location (Wellington)
by Drew Broadley 28 Jul '05

28 Jul '05

Hi all, I'm representing a company where the requirements are going to need a large amount of nodes around the country where they will all require (at least) a dedicated 128kbps connection to a central "nerve" located on WIX and additional redundancy on the central system at another location, ultimately somewhere on the APE. We would ideally not approach Telecom directly at the moment through a buzz-word junkie sales person at the moment as I want a realistic perspective on this, not someone who will just say yes so they can afford to chrome more parts on their Audi. If you have any available options, could you please contact me off list. Cheers, Drew

1 0

Reminder Notice: ENUM Consultation extended until 19th August
by Michael Sutton 28 Jul '05

28 Jul '05

ENUM ANNOUNCEMENT: Those interested are reminded, that InternetNZ is receiving feed back & submissions on the "New Zealand ENUM Trial Framework - Consultation Report" by M-co for InternetNZ: The Report is available on the web site at http://www.internetnz.net.nz/public/enum/2005-07-ENUM-Trial-Report-complete. pdf (1.2MB) Originally we had advised 21 July, however there is now additional time available in our schedule. Best Regards Michael S. Sutton Councillor - InternetNZ 2003 - 2006 Chair - Enum Task Force InternetNZ Project Manager - UCI PUA Enum Prototype Member Audit & Technical Committee Telephone: +64 4 475 9235 Mobile: +64 21 305500 Facsimile: +64 21 305002 WWW: http://www.internetnz.net.nz/public/enum/ E-mail: mailto:michael.sutton(a)awacs.co.nz mailto:michael.sutton(a)internetnz.net.nz> ----------------------------------------------------------------------- CAUTION: This email and any attachments may contain information that is confidential and subject to legal privilege. If you are not the intended recipient, you must not read, use, disseminate,distribute or copy this email or any attachments. DISCLAIMER: To the maximum extent permitted by law, Michael Sutton is not liable (including in respect of negligence) for viruses or other defects or for the changes made to this email or to any attachments. Before opening or using attachments, check them for viruses and other defects. -----------------------------------------------------------------------

1 0

Notification of NZRR Database changes
by NZRR Database Notifications 28 Jul '05

28 Jul '05

Dear Colleague, This is to notify you that some object(s) in NZRR database which you either maintain or are listed as to-be-notified have been added, deleted or changed. 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. --- PREVIOUS OBJECT: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 203.109.128.0/17^17-29, 203.173.128.0/17^17-29, 203.118.128.0/18^18-29, 203.96.192.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.50.188.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.148.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 202.7.6.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.174.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.89.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.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)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050728 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS7657 descr: advertised to AS9560 by Ihug Ltd - AS7657 members: 203.109.128.0/17^17-29, 203.173.128.0/17^17-29, 203.118.128.0/18^18-29, 203.96.192.0/19^19-29, 202.36.16.0/20^20-29, 202.46.160.0/20^20-29, 202.49.64.0/21^21-29, 202.126.80.0/21^21-29, 198.48.0.0/22^22-29, 202.8.44.0/22^22-29, 202.50.188.0/22^22-29, 202.21.136.0/23^23-29, 202.36.94.0/23^23-29, 202.36.230.0/23^23-29, 202.49.46.0/23^23-29, 202.49.148.0/23^23-29, 202.49.180.0/23^23-29, 202.61.2.0/23^23-29, 192.107.113.0/24^24-29, 198.32.71.0/24^24-29, 202.7.6.0/24^24-29, 202.21.130.0/24^24-29, 202.36.44.0/24^24-29, 202.36.174.0/24^24-29, 202.49.33.0/24^24-29, 202.49.59.0/24^24-29, 202.49.63.0/24^24-29, 202.49.89.0/24^24-29, 202.49.140.0/24^24-29, 202.49.144.0/24^24-29, 202.49.178.0/24^24-29, 202.49.186.0/24^24-29, 202.49.249.0/24^24-29, 202.50.84.0/24^24-29, 202.50.103.0/24^24-29, 202.50.255.0/24^24-29, 210.55.110.0/24^24-29, 210.55.184.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)ihug.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20050729 source: NZRR

1 0

RE: [nznog] [FW] Re: Interesting articles from Beehive
by Jeremy Strachan 28 Jul '05

28 Jul '05

We'd like an increase from 128K to a whole 256K! Greedy I know ... But 128K is horribly limited for any remote users trying to access a site over a vpn, webmail, you name it. Things we do in the modern age. Jeremy -----Original Message----- From: Blair Harrison [mailto:nznog(a)jedi.school.nz] Sent: Thursday, 28 July 2005 9:09 p.m. To: Richard Dingwall Cc: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] [FW] Re: Interesting articles from Beehive Richard Dingwall wrote: > > I would imagine that the low upstream limit could (partly) have been > an effort to curb NZ P2P network traffic. > > National P2P networks (DC, particularly) became very popular a few > years ago, when unlimited 128KBit/128KBit DSL was available (i.e, > download as fast as your connection goes - woohoo!). > > More recently, as the downstream rate has significantly exceeded the > upstream, your slow upload becomes someone else's slow download. > Imagine the thrill of leeching at 16KByte/s on a 2MBit connection..! > > - Richard > Quite a possibility. I did have one of our high speed customers leave Kazaa on over a few days.. managed to eat up about 75GB of traffic in those couple of days. They were uploading at a rate of about 1.8 gig an hour. I can see the merits of limiting upstream speed in the interests of conserving network capacity, but I don't see why regular non-p2p-using customers should be held back from experiencing true broadband speeds because of the actions of the leechers out there. There are methods available to limit the impact of such P2P applications and I believe at least one large ISP in NZ has implemented a layer 7 filtering system that can limit speeds at the application level. So the technology to limit the impact of P2P users to the network is available, should Telecom choose to use it. Why slow down the rest of the users who want to do really cool things like full screen multi-user videoconferencing and sending media files across town for processing because of the actions of the pesky leechers? Maybe because that would start to eat into their other more traditional 'higher value' revenue streams such as Frame Relay, Metro Ethernet and ATM? (which, incidentally, I can't even find on their website today) P2P may be a big reason and the most obvious, but I doubt it's the only reason. Cheers, Blair _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

3 2

NZ General Election - On The Night Results
by Andrew McMillan 28 Jul '05

28 Jul '05

Hi, As you will know by now this years general election will be on the 17th of September. The Chief Electoral Office have contracted Catalyst IT Ltd to host a public website with the election-night results, as we have done for the previous two elections. Counting of votes will begin when the polls close at 7:00pm, and will continue through to the small hours of the morning of the 18th. Historically, peak interest has been from around 8:30pm through to 10:30pm. If any ISPs or other websites would like to mirror this information for your own customers I will be happy to arrange rsync access to the changing website. In addition to the HTML formatted web pages there are a series of data files which are intended for post-processing and a specification of these data formats is available. Updates to the website are applied approximately every minute during the counting process. Please contact me off list if you are interested in any of this. Thanks, Andrew McMillan. ------------------------------------------------------------------------- Andrew @ Catalyst .Net .NZ Ltd, PO Box 11-053, Manners St, Wellington WEB: http://catalyst.net.nz/ PHYS: Level 2, 150-154 Willis St DDI: +64(4)803-2201 MOB: +64(272)DEBIAN OFFICE: +64(4)499-2267 Planning an election? Call us! -------------------------------------------------------------------------

1 0

Webcasting Heads up
by Richard Naylor 27 Jul '05

27 Jul '05

Tomorrow Internet NZ is having their AGM and using 2 Access Grid nodes to link participants in AKL and WLG. Its at 6pm from memory. I think I've managed enough parts to make another Access Grid node and so am going to attempt to webcast a grid session in action, using multiple simultaneous webcast streams . It may fail horribly. I will drink beer whatever happens (got back on topic). The link to the webcast is http://www.r2.co.nz/20050523 There is TV playing on the streams now if you want to see what it may look like, if it all works. Operators may get calls from clients requesting help. May see a bit of traffic (its about a meg per client) or may just like to watch and laugh as it all crashes. Drink beer, it all looks better then. Feedback will be appreciated. Anyone still got dial-up and willing to try it ? Rich

1 0

[FW] Re: Interesting articles from Beehive
by Juha Saarinen 27 Jul '05

27 Jul '05

---------------------------------------------------------------------------- Paul Brislen wrote: > I'm sorry but has the Minister read his own Commissioner's rulings? > > snip: > I am aware of an very strong opinion in the industry that 128k upstream is > a constraint. Like the Commissioner I do not regard the proposed regulated > 128k service as an upper limit. On the contrary, it should be seen as a > baseline and I expect commercial offerings in the market above that level. > snip I'm sorry but the regulation has 128 as the MAXIMUM upload speed, not some kind of regulated minimum. He can expect all he likes, without some new regulation that says otherwise, 128 is all the incumbent has to deliver and 128 is all it will deliver. I must now drink a lot of beer a: to stay on topic and b: to drown my narrowband sorrows. I bid you good day. - Paul ---------------------------------------------------------------------------

11 15

<<<Amendment>>> InternetNZ releases ENUM Personal User Agent Prot otype software under Open Source BSD Licence.
by Michael Sutton 27 Jul '05

27 Jul '05

============ July 28th 2005. Greetings: I am resending a modified version of this information bulletin highlighting the contribution of the European Telecommunications Standards Institute (ETSI) to this work: This PUA software was designed and developed in New Zealand by CatalystIT and utilised ETSI Guides available at http://www.etsi.org/services_products/freestandard/home.htm [1] ETSI EG 202 067: "Universal Communications Identifier (UCI); System framework". [2] ETSI EG 202 249: "Universal Communications Identifier (UCI); Guidelines on the usability of UCI based systems". We thank Mike Pluke and others at ETSI. Best Regards Michael Sutton Chair ENUM Task Force. ============ InternetNZ releases ENUM Personal User Agent Prototype software under Open Source BSD Licence. http://www.internetnz.net.nz/public/enum/pua/2005-07-pua-media-release.html InternetNZ announced today the release of its ENUM "Personal User Agent" prototype source code under an Open Source BSD Licence. The release hopes to encourage developer support of an ENUM initiative in New Zealand. The code is available from http://www.internetnz.net.nz/public/enum, as well as Reports prepared by the Task Force and a limited quantity of CDs. The PUA release does not include the "Universal Communications Identifier" Registry modules. Subscribe to a public information list at http://farsight.internetnz.net.nz/mailman/listinfo/enum. ENUM is a set of Internet protocols, mapping telephone numbers onto the Internet naming system. Existing email addresses, web sites and alternate telephone contact addresses can be attached to this ENUM record. This record can be used by suitable handsets or (pabx type) computer programs to contact the number holder. ENUM is in government approved trial or production in approximately 30 countries. "Personal User Agents" (PUA) are software programs which act like firewalls; automatically filtering requests for ENUM contact information and deciding what information to release and how incoming calls will be directed based on rules that look at the inbound identity of the caller. This protects the consumer from address harvesting or privacy breaches. In theory every existing and future telephone number in the world could be ENUM provisioned. This provides a massive legacy base on which commercial PUA software can be built. The ENUM PUA is based on our research and Guides by Europe's Telecommunications Standards Institute, ETSI (EG 202 067 & EG 202 249). http://www.etsi.org/services_products/freestandard/home.htm. In a complimentary note ETSI also referred InternetNZ's work to the European Commission. InternetNZ looks forward to continuing close and contructive dialogue with ETSI. Following completion of an ENUM PUA UCI Feasibility Study at the beginning of 2005 the prototype was developed by Catalyst IT (http://www.catalyst.net.nz) of Wellington, for InternetNZ. The PUA prototype was linked to another module known as the "Universal Communications Identifier" (UCI) which can bind an individual's name and service requirements to ENUM records and then be accessed by other PUAs. Future ENUM PUA software will enable users to opt-in to security services that will restrict publication of contact (email etc) information to anonymous callers and will permit intelligent routing of calls based on the relationship of the receiver to the caller and possible cost optimization of call termination and also increasing the rate of successful call completion for the networks. There are significant international opportunities for software developers to incorporate ENUM with PUA features into their existing communications software and directory services. InternetNZ anticipate that a number of software companies will work co-operatively to develop compatible systems that will compliment each other on different niche markets such as PUAs in the Telco-network, ISP, corporate business, SoHo and individual markets. Co-operating with the Government, Telecommunication Carriers Forum and applications developers, InternetNZ will participate and facilitate a New Zealand ENUM Trial over the next year that will provide a platform to test, demonstrate, commercialize applications and integrate ENUM to deliver economic advantage to the New Zealand community. InternetNZ welcomes enquiry from anyone interested in undertaking ENUM development work and participating in the Trial. "One Number To Hold Them All" Michael Sutton Chairman - InternetNZ ENUM Task Force Councillor InternetNZ Member Technical and Audit Committee Phone: +64 4 4721600 Ext 730 mailto:michael.sutton(a)internetnz.net.nz

1 0