June 2003 - NZNOG - lists.nznog.org

list.waikato.ac.nz Has Moved
by Donald Neal 11 Dec '24

11 Dec '24

NZNOG-People, I have just finished migrating all of the mailing lists held at The University of Waikato from one server to another. I don't have any reason to believe that anything's gone wrong, but please bear with me for today if it turns out that something has. - Donald Neal -- Donald Neal | Q: How many Aucklanders does it take to change Systems Programmer/Analyst | a light bulb? The University of Waikato | A: Pass me that candle and I'll tell you. Hamilton, New Zealand | --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

4 3

RE: Sort of OT: are there any "Internet enabled" temperature sens ors/servers for Auckland?
by Greg Clare 18 Aug '21

18 Aug '21

May not be exactly what you are after? However DSE have an Internet weather station at the Albany HQ. http://www.dse.gen.nz/public/webdata/weather.htm Regards Greg > -----Original Message----- > From: Juha Saarinen [mailto:juha(a)saarinen.org] > Sent: Wednesday, 2 January 2002 2:47 pm > To: NZNOG > Subject: Sort of OT: are there any "Internet enabled" temperature > sensors/servers for Auckland? > > > Measuring the outside temperature, with geographic location given. > > -- > Juha > Take off every sig! > > - > To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz > where the body of your message reads: > unsubscribe nznog > - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

2 1

problems with NTP on bigben?
by Simon Blake 03 Mar '05

03 Mar '05

Anybody else observed that bigben gained about 19 years at about 1:25pm this arvo? $ date Tue Jan 1 14:54:33 NZDT 2002 $ /usr/sbin/ntpdate -q truechimer.waikato.ac.nz server 130.217.76.32, stratum 2, offset -0.001089, delay 0.04276 1 Jan 14:49:38 ntpdate[17537]: adjust time server 130.217.76.32 offset -0.001089 sec $ /usr/sbin/ntpdate -q bigben.clix.net.nz server 203.167.224.60, stratum 1, offset 619315199.998172, delay 0.03613 1 Jan 14:49:55 ntpdate[17540]: step time server 203.167.224.60 offset 619315199.998172 sec - To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog

13 20

Sale of Domainz
by DPF 27 Nov '03

27 Nov '03

Notice of the sale of Domainz is being sent by post to ISPs, but a quick e-mail here may also prove effective in reaching any interested purchasers. The advert relating to the sale of Domainz is at http://www.internetnz.net.nz/sale-of-domainz-nbr-ad.pdf, as per the announcement below. All inquiries are best directed to Tim Russell of Deloitte Corporate Finance at the details below. DPF On Fri, 30 May 2003 13:35:44 +1200, Peter Macaulay <exedir(a)internetnz.net.nz> wrote: >Further to our earlier announcements, the public aspect of the sale of >Domainz is under way. An advertisement is in today's (Friday 29 May) >National Business Review. A copy will be posted on the web site at 1830 >tonight. >Feel free to pass on this information to any parties that may have a >genuine interest. The contact is >Tim Russell >+64 9 303 0857 >timrussell(a)deloitte.co.nz > >-- >Peter Macaulay >Executive Director >InternetNZ >Direct +64 4 495 2113 -- E-mail: david(a)farrar.com ICQ: 29964527 MSN: dpf666(a)hotmail.com

22 42

Re: [nznog] Multicast status in New Zealand
by Ewen McNeill 07 Jul '03

07 Jul '03

In message <5.2.0.9.0.20030627160856.02023200(a)pele.citylink.co.nz>, Richard Nayl or writes: >At 03:54 p.m. 27/06/2003 +1200, Ewen McNeill wrote: >>In message <5.2.0.9.0.20030627141054.038683c0(a)pele.citylink.co.nz>, >>Richard Naylor writes: >> >>[Multicast] >> >Well the biggest part of the business is video on demand and that can >> >really only be unicast as getting viewers to agree on what they watch is >> >like agreeing on a TV Channel in a huge flat - hopeless. >> >>[... "on demand" doesn't necessarily mean "instantly" ...] >>Which means that for popular stuff that is "on demand" it might not be >>enough to have one channel with it, where the wait time is, say, 15 >>minutes for it to cycle around -- but it might be fine to have 10-20 >>channels, suitably staggered, where the wait time was 1-2 minutes. > >ah - its that word "channel" that I don't see in the future. Such a dated >concept. Ah. Channels are double-plus-ungood. Call it a stream if it makes you feel happier. Or VDC or whatever. >Instead, you're interested in Alastair Cook. Why should you wait til Monday >at 8:45 every week and then miss it because you were on the phone. I don't recall suggesting that you should. >Hey you have 10 minutes now and would like to catch up with what he said last >Monday (when you were on the phone, remember). So why can't you click in >now and view it ? Your argument seems to be "viewers must be able to view it __NOW__(tm)" and hence we must use unicast for everything in order that everyone can have their whim satisifed at an instants notice (and provide all the bandwidth from source to (multiple) sink(s) to make this possible). My argument is that there's a fair chunk of evidence that says that people would be willing to wait 1, 2, 5, 10, 30, or even 60 seconds for something to start (maybe even longer if it's a sizeable time investment to watch it all and the waiting time can be used productively -- eg, getting that beer out of the fridge before settling down to watch the game), especially given a proper cost/benefit tradeoff ("would you pay 5 times as much to be able to have it start within half a second instead of within 5 seconds"?). And that by adding that relaxing condition it's both quite feasible, and quite benefical, to use multicast at least for the more popular things, especially where the multicast VDCs is set up "on demand" with just a short "setup time" to pull in other potential viewers. Think of it as the difference between everyone just crossing the road when they feel like it, and traffic lights (or at very least waiting for the same gap in the traffic). The big reason that it's beneficial in the popular-to-(re)view situation is that there're more people wanting to view something than there are 5-second, 10-second, 30-second, 60-second, whatever start periods. So you can achieve an N:M reduction in the number of VDC you need originating from the source, for only the price of a bit of management infrastructure (request-a-start-soon), and a slightly slip from the "I wanna watch it now! Now! Now! Mommy, make it go!" instant satisfaction. >Multicast is great for synchronous events like TRADITIONAL tv. I just don't >see that continuing. It's good for things other than traditional TV too. Especially where there's (significantly) more than one person wanting to watch something at the "same" time. Which is a surprisingly common case for "current" events. (Speech replays, sports replays, recent movie releases, etc.) Oh, and I quite agree with Joe's comment that caching at the edge can achieve quite remarkable things in turning "watch now or miss it" into "watch when you feel like it". (And even better, if those with suitable broadcast channels would actually get a clue and use the "down" time to spool out things people might want to watch during the week (eg, "this week's hot new movies"). But "video recorders are bad, we must do everything to defeat the use of video recorders". Furrfu.) Ewen

8 7

The New Zealand Network Operators' Group
by Donald Neal 01 Jul '03

01 Jul '03

The New Zealand Network Operators' Group The New Zealand Network Operators' Group (NZNOG) has no king, president or formal membership. At present it consists of the subscribers to this mailing list, which anyone is free to join. NZNOG held a face to face gathering as part of the UniForum NZ conference in 2002, and is to do the same again from 10-12 July this year. That's next week. See http://www.uniforum.org.nz/conference_2003/conference.html for details. If you're going - and you are, aren't you? - you need to register NOW. NZNOG doesn't hold other national face to face meetings, but see http://thursdaynightcurry.com/ if you live in or near Wellington or Auckland. Operators' Contact List See http://www.usenet.net.nz/noc/ for operational contact details for most New Zealand ISP's. These are intended for use by other network operators rather than by most customers. Auckland Peering Exchange See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. About This Mailing List This list has around 480 addresses subscribed. You may only post to the list from a subscribed address. A number of people subscribe addresses which do not receive email purely to allow posting from them. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by an employee of Alcatel NZ Ltd. Neither of these organisations, nor the administrator, is responsible for its content. NZNOG Mailing List Acceptable Use Policy The NZNOG mailing list exists to provide a forum for the exchange of technical information and the discussion of implementation issues that require cooperation among New Zealand network service providers. In order to continue to provide a useful forum for discussion of relevant technical issues, users of the list are asked to respect the following guidelines. 1. Discussion will focus on Internet operational and technical issues. 2. Discussion related to meetings of network service providers is appropriate. 3. Discussion unrelated to these topics is not appropriate. 4. Postings to multiple mailing lists are discouraged. 5. Postings that include foul language, character assassination, and lack of respect for other participants are unacceptable. 6. Blatant product or service marketing is unacceptable. 7. Postings of a political, philosophical or legal nature are discouraged. 8. Postings to the list should be in ASCII or MIME encoded as text/plain. Attachments should not be sent to the list. To present a document, a suitable URL may be referred to. For documents of general interest, the use of proprietary file formats is discouraged. 9. Breaches of list etiquette should be dealt with privately with the offending list user, and should not result in complaints being sent to the list. 10. A person repeatedly breaching list etiquette shall receive warnings from the list administrator. A further breach after the second such warning within thirty days shall result in the offender being unsubscribed from the list. Other action may also be taken to block postings to the list by the offender. Any such unsubscription is to be immediately announced to the list. Mailing List Archives A full archive is available at http://list.waikato.ac.nz/archives/nznog/ Any message sent to the list will be archived and made available on the web automatically. Changes are not made to the archive on request, though the administrator remains happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins ------------------------------------------------------------------------------ "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ------------------------------------------------------------------------------

2 1

RE: [nznog] Multicast status in New Zealand
by Frank March 30 Jun '03

30 Jun '03

Electric fences are a problem with POTS when they are poorly designed and maintained. The major problem with ADSL in rural areas is the distance from the nearest enabled exchange - only a relatively small number of rural people are within the 5-7 km distance that ADSL will reach. It is likely that wireless technologies will be necessary to reach anyone more than this distance for an exchange and for some satellite will be the only practical solution. According to Fonterra, there could be as many as 5,000 farms (probably not dairy farms) in this category. --- Frank March Senior Specialist Adviser, IT Policy Group (and member of the PROBE project team) Ministry of Economic Development, PO Box 1473, Wellington, New Zealand Phone (+64 4) 474 2908; Fax (+64 4) 474 2659; Mobile (+64) 21 042 9205 -----Original Message----- From: Cameron Kerr [mailto:cameron.kerr(a)paradise.net.nz] Sent: Tuesday, 1 July 2003 00:35 To: nznog(a)list.waikato.ac.nz Subject: Re: [nznog] Multicast status in New Zealand On Mon, Jun 30, 2003 at 11:20:32PM +1200, Lin Nah wrote: > Some of the target audience in the groups above tend to live in > rural areas and it is a challenge for them to get a 56k dialup > connection going (without worrying about line quality, electric > fences etc) let alone worry about high speed internet. Hence the > need for Project Probe. That raises an interesting question. If a primary problem with POTS is with electric fences creating a large amount of interference, how on earth is ADSL going to fare??? Surely its higher frequencies would be even more messed up. Or would they use wireless for people in that position? _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog http://www.govt.nz - connecting you to New Zealand central & local government services Any opinions expressed in this message are not necessarily those of the Ministry of Economic Development. This message and any files transmitted with it are confidential and solely for the use of the intended recipient. If you are not the intended recipient or the person responsible for delivery to the intended recipient, be advised that you have received this message in error and that any use is strictly prohibited. Please contact the sender and delete the message and any attachment from your computer.

1 0

RE: [nznog] Multicast status in New Zealand
by Michael Sutton 30 Jun '03

30 Jun '03

Over 500 clients of Xtra voluntarily registered and received Radio New Zealand and BBC World Live as Multicast on Telecoms dial up service for 3 years from 1998. I attended and observed when Telecom engineers enabled the same service via adsl in Wellington as multicast sourced from my servers in Akl in 2000. If i was in the Ministry of Health and needed to distribute 3,000 * 10m bytes PDF document from my source server to all distribution points within 60 minutes (3GigaBytes) no New Zealand network can do it. The distribution server and network would fail. If I used multicast and have a 256kbit multicast injection source the upload to all 3000 GPs will be complete in less than 10 minutes. The clients will still be billed for 3 gigabytes if they were being changed for local traffic and the rest of the national network would remain stable, especially for servers colocated with the originating server. If future spam blocking uses a signature system, multicast would enable this information to be distributed to all enterprise mail servers instantly and efficiently using multicast distribution... If I was implementing Maori Television and Youth Radio I would use multicast for distribution of the network transmission to reach 150 National distribution points where I would convert the multicast program for terrestrial transmission and in one step have positively changed the operational budget as well as reduced complexity of distribution. Yes I would still have to pay for each clients data charges... If I ran Correspondence School I would use multicast... If I was the TAB I would use it... I could give you 20 project scenarios that unicast can not implement in the real world. All unicast can do in every application is show the prototype concept - scale-up can not occur without multicast... This is really an Interconnect issue: customers should have network access to inject on a case by case situation... It is not up to the networks to be arbitrarily prohibiting this protocol... Please name another network protocol that could make such a difference and which is disabled ... Its like saying that the protocol extensions enabling mobile TXT messaging should have been blocked until each application was identified. I thought that Telecom, Telstra etc stopped "telling" customers what are permissible applications... Telecom and Telstra etc are supposed to implement enabling technologies which can be used by its customers who know there own current and future applications... In my professional opinion if the Boards of both these organisations understood the damage that this decision does to their clients network application capabilities, all of those executives involved would be gone. New Zealand has never had a real Internet as far as I am concerned due to this network management decision. Multicast is a broadcast service and without it the network remains unicast spaghetti, like pieces of string with empty cans of W* Baked Beans on each end... If Probe does not require multicast as a mandatory network service then the future of that service will be DOA... Due to public obfuscation of the process I don't know what they thought they required anyway. My final view on this is; turn it on and make the interconnect arrangements necessary for peering at wix and ape before one or more customers takes this to the Commissioner as an interconnect issue. Michael Sutton +64 4 4759235 www.awacs.co.nz -----Original Message----- From: Donald Neal [mailto:Donald.Neal(a)telecom.co.nz] Sent: Friday, June 27, 2003 12:41 To: nznog(a)list.waikato.ac.nz Subject: RE: [nznog] Multicast status in New Zealand My own opinion - and I must stress that it is just my opinion - is that this will be exactly Telecom's attitude. To change the answer you'd need to change the question. If you say "Look, to provide new service X which your customers will want, you need to enable IP multicasting", that's a different issue. But that would require the identification of service X. - Donald Neal ---------------------------------------------------------------------------- -- "This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you." ---------------------------------------------------------------------------- -- _______________________________________________ Nznog mailing list Nznog(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog

4 3

Test the Nation, Request (REPOST)
by Chris O'Donoghue 29 Jun '03

29 Jun '03

Sorry had to repost from home email Hi all, We (TVNZ) are running a programme tonight that _may_ attract considerable audience online. To try and make things run smoothly and lower calls to our and your call centres, can those of you that aggressively cache make sure you don't cache the following URL http://ttndata.nzoom.com/batches/data.xml This is the XML data that defines the current batch of questions. It will change in content frequently between 19:30 and midnight Ta Chris Chris ODonoghue Technology Manager Online & Digital TVNZ codonoghue(a)tvnz.co.nz

1 0

Test the Nation, request
by Chris O'Donoghue 29 Jun '03

29 Jun '03

Hi all, We (TVNZ) are running a programme tonight that _may_ attract considerable audience online. To try and make things run smoothly and lower calls to our and your call centres, can those of you that aggressively cache make sure you don't cache the following URL http://ttndata.nzoom.com/batches/data.xml This is the XML data that defines the current batch of questions. It will change in content frequently between 19:30 and midnight Ta Chris Chris O'Donoghue Technology Manager Online & Digital TVNZ ================================================================ CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on nzoom.com, visit us online at http://www.nzoom.com ================================================================

1 0