November 2004 - NZNOG - lists.nznog.org

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

12 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

The New Zealand Network Operators' Group
by Donald Neal 01 Jan '08

01 Jan '08

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. Meetings Our next annual conference is to be hosted by the WAND group in Hamilton on February 2nd to 4th, 2005. See http://www.nznog.org/ for more information, including the Call For Presentations. Offers to present are due in by 22nd October, and all presenters should have had their acceptance confirmed by 31st October. Also see http://auckland.thursdaynightcurry.com/ if you live in or near Auckland or Wellington. 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, not by most customers. Internet Exchanges See http://www.ape.net.nz/ for details of the Auckland Peering Exchange and those connected there. See http://www.wix.net.nz/ for the Wellington Internet Exchange. About This Mailing List This list has slightly over 700 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. You may choose to receive postings as they come in, or just to receive daily "digests". See the bottom of the page http://list.waikato.ac.nz/mailman/listinfo/nznog/ to change the form in which you receive postings. The NZNOG mailing list is provided through a server at The University of Waikato, and is administered by employees of Alcatel NZ Ltd, Citylink and Telecom. None of these organisations, nor any 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/pipermail/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 administrators remain happy to assist the Office of the Privacy Commissioner should any complaint be laid with that office. One way to search the archive is to use google and prefix your search with site:list.waikato.ac.nz . Subscribing to the List See http://list.waikato.ac.nz/mailman/listinfo/nznog to subscribe. Donald Neal NZNOG Mailing List Owner/Administrator/Muggins Donald Neal |Palmersdale: Are you in charge here? Technical Specialist |The Doctor: No, but I'm full of Operations Engineering | ideas. Integration & Services Division +----------------------- Alcatel NZ Ltd - Telecom's network operations manager ------------------------------------------------------------------------------ "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. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002." ------------------------------------------------------------------------------

3 16

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

04 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

Re: [nznog] [Inetnum object]
by Andy Linton 25 Dec '04

25 Dec '04

About a month ago Sid Jones and I had a conversation about one of his customers who has a /23 in this space. We raised the issue with APNIC and I attach the thread. There's a clear implication in the mail below that APNIC expect Telecom NZ to cooperate on this issue which seems to be at odds with their behaviour over 202.49.252.0 - 202.49.255.255 as David Robb has noted. I suggest a number of things here: 1) each ISP who routes portions of this block should encourage their customers to write to APNIC requesting that as this block was allocated via the University of Waikato which was operating as a proto NZNIC at the time then this address space should be deemed to be provider independent space which should be administered as other 'swamp' space. For example, here's a record that's recently been obscured as part of this exercise: inetnum: 202.36.137.0 - 202.36.137.255 > netname: NZMFE > descr: Ministry for the Environment > descr: P.O. Box 10-362 > descr: The Terrace > descr: Wellington > country: NZ > admin-c: MB22-AP > tech-c: MB22-AP > notify: dbmon(a)apnic.net > mnt-by: APNIC-HM > changed: hostmaster(a)apnic.net 19931217 > status: ALLOCATED PORTABLE > changed: hm-changed(a)apnic.net 20031020 > source: APNIC This is clearly PORTABLE space and makes no reference to Telecom NZ and the admin-c and tech-c details were updated just over a year ago. Note that this address was allocated in 1993 long before Netway (a Telecom NZ subsidiary) entered the picture at all. Why are APNIC changing the goal posts? 2) the customers should also write to Telecom NZ making clear that their portion of address space was not issued to Telecom NZ but to them by the University of Waikato (acting as a proto NZNIC) and that they want Telecom to relinquish control of this space back to APNIC. 3) I'd encourage APNIC to look again at this. 4) user groups such as InternetNZ, TUANZ etc need to get across this issue and raise it with Telecom NZ 5) I'd suggest the press get their teeth into this but that's probably not necessary as there's no story here. (:-) andy -------- Original Message -------- Subject: Re: [Fwd: [APNIC #624302] 202.27.0.0/16 and http://www.apnic.net/info/faq/privacy-faq.html (fwd)] (fwd) Date: Thu, 4 Nov 2004 09:20:59 +1000 (EST) From: John Tran <john(a)apnic.net> To: asjl(a)citylink.co.nz CC: Anne Lord <anne(a)apnic.net>, Elly Tawhai <elly(a)apnic.net>, Tim Jones <tim(a)apnic.net> Hi Andy, We have searched all our historical emails and records regarding NZNIC as well as all information relating to 202.27.0.0/16. Here is the summary of what we found. Before 1995, the following address ranges had been allocated by APNIC to the University of Waikato, which operated as a gateway for New Zealand, under the name NZGATE: 202.27/16 202.37/16 202.36/16 202.49/16 202.50/16 These ranges were allocated on the basis that NZGATE would make further allocations to their customers. In 1995, Netway Commnication Ltd took over the international gateway function from the University of Waikato and the IP addresses were transfered with APNIC's approval. Netway continued contracting University of Waikato staff to allocate IP addresses on Netway's behalf to its customers. NZNIC was then established by the University of Waikato to obtain provider independent addresses for other organisations like Clear Communication and Netlink. Netway was then transfered to NZtelecom in late 1997, along with the corresponding address space. In November 1998, because of the confusion in the Internet community in New Zealand about whether the address space that they obtained from the University of Waikato was portable or not, APNIC and Brett Telfer (Netgate) re-confirmed that the above ranges would be best managed by NZTelecom. Since then, these address ranges are used by APNIC to determine the membership tier paid by NZtelecom as outlined in: http://www.apnic.net/member/feesinfo.html NZTelcom is able to assist any organisation holding address space with reverse DNS and is able to change the status of DB object to public, if so requested. I hope the above information is useful for you. If you need additional information please contact us. If you would prefer to discuss this further, we can arrange a telephone conference. Regards Son ---------- Forwarded message ---------- Date: Mon, 25 Oct 2004 12:39:44 +1000 (EST) From: Anne Lord <anne(a)apnic.net> To: Andy Linton <asjl(a)citylink.co.nz> Cc: son(a)apnic.net Subject: Re: [Fwd: [APNIC #624302] 202.27.0.0/16 and http://www.apnic.net/info/faq/privacy-faq.html (fwd)] hi Andy, Thanks for your email. I'm no longer involved in handling resource requests, but I have copied Son Tran, the manager of the Member Services department, on this email, who is and who will be able to help you. It certainly looks like this warrants a much closer examination of the records and history and I am sure Son would be happy to talk to you. Best wishes, Anne cc: Son On Fri, 22 Oct 2004, Andy Linton wrote: > Anne, > > I've had a conversation today with Sid Jones about this mail. These blocks > were allocated to the University of Waikato which operated as the proto NZNIC > in the early nineties prior to APNIC handling this work. > > Aaron Scott who is listed in the changed record below went to work for Telecom > NZ when they took over handling the exchange point at Waikato. There are a > significant number of NZ government departments and other "blue chip" > identities listed in the records who don't use Telecom NZ as their ISP and who > believe that they have portable space. Some of them have /21 allocations and > perhaps even /20 allocations. > > This whole set of blocks really should be considered as swamp space. > > I will be raising this issue on the NZNOG mailing list suggesting that those > entities who have had these blocks allocated to then for periods in the order > of 10 years or more should contact you asking for clarification of their position. > > I think it would be good if APNIC took a good look at the allocations within > these ranges and considered what's going on here. > > Happy to discuss - +64 4 910 5654 > > andy > > ---------- Forwarded message ---------- > Date: Thu, 21 Oct 2004 13:44:30 +1000 > From: gpan via RT <helpdesk(a)apnic.net> > To: sid(a)tsnz.net > Subject: [APNIC #624302] 202.27.0.0/16 and > http://www.apnic.net/info/faq/privacy-faq.html > > > Dear Sid, > > Thank you for your enquiry. It was proposed at the APNIC 16 > meeting in 2003 that customer assignments (and sub-allocation > records) need no longer be publicly accessible via normal > 'whois' queries to the APNIC Whois Database. > > Customer registration records must still be registered within > the APNIC Whois Database, in order to document address > utilisation, however a new 'public' database attribute has been > created to allow these records to be excluded from public whois > query results. This is why you are unable to receive any > result when querying the APNIC Whois Database about this > particular /23. You will get the result as: > > inetnum: 202.27.0.0 - 202.27.255.255 > netname: NZGATE-NZ > descr: NZ Gate National Service Provider > descr: Component of University Of Waikato > descr: New Zeland > country: NZ > admin-c: DBK1-AP > tech-c: KS61-AP > remarks: service provider > notify: dbmon(a)apnic.net > mnt-by: APNIC-HM > mnt-lower: NZTELECOM > changed: ARRON(a)WAIKATO.AC.NZ 19950612 > changed: hostmaster(a)apnic.net 20020208 > changed: hm-change(a)apnic.net 20020621 > status: ALLOCATED PORTABLE > source: APNIC > > Information contained within the historical records outlines that > NZTelecom has full authority over the following blocks: > > 202.27.0.0/16 > 202.36.0.0/16 > 202.37.0.0/16 > 202.49.0.0/16 > 202.50.0.0/16 > 203.96.0.0/17 > > Information from those records also outline that the assignments from > these ranges are non portable. > > 202.27.xx.0/23 > > This address space is from a block allocated, by APNIC to NZTelecom. > This means that all assignments made from this block are non portable. > > If your customer would like to see or change their records in APNIC > whois database, please advise them to contact NZ Telecom. > > Best Regards, > Guangliang > > ____________________________________________________________________ > Guangliang Pan, Internet Resource Analyst <gpan(a)apnic.net> > Asia Pacific Network Information Centre phone: +61 7 3858 3100 > http://www.apnic.net fax: +61 7 3858 3199 > Helpdesk phone: +61 7 3858 3188 > email: helpdesk(a)apnic.net > > Please send Internet Resource Requests to <hostmaster(a)apnic.net> > _____________________________________________________________________ > > > [sid(a)tsnz.net - Wed Oct 20 12:27:02 2004]: > > > Hi > > > > I'm writing to you on behalf of one of my customers XXXXXXX > > as we have something of a dilemma. > > > > I believe the XXXXXX applied for some PI address space from the > > university of waikato sometime in the mid-1990s and were allocated > > 203.27.xx.0/23. > > > > I also believe this space was "swamp" space and not allocated to any > > of the various service providers in New Zealand. > > > > > > They have had this space routed to them via effectively the same > > provider since then. The provider for the past 3 years has been > > TelstraClear NZ Ltd, prior to that it was Telstra NZ Ltd and > > previously Netlink > > > > Can you please clarify who the /23 is allocated to. > > > > Can you please clarify if the customer can still use this space while > > connected to the provider they have had for the past decade. > > > > Further if this is the case how do we get the current records updated > > to reflect this sub-delegation. I'm also curious as to what effect > if > > any this has on other customers I have in 202.27/16 > > > > >

9 8

Re: SPF and mail forwarding (was Re: [nznog] Sendmail Question)
by Ewen McNeill 01 Dec '04

01 Dec '04

In message <20041128083138.GB27487(a)walnut.gen.nz>, Richard Hector writes: >On Sat, Nov 27, 2004 at 12:20:03PM +1300, Ewen McNeill wrote: >> usera(a)ispa was one address so subscribed. Unfortunately usera(a)ispa >> actually forwards mail to userb(a)ispb, without rewriting the envelope >> from address -- [bounces because SPF check failed at ispb MX] > >Perhaps I'm a little confused, but if usera is rejecting mail from >servers that he has arranged to forward him mail, that's his own silly >fault? usera doesn't run the mail servers at ispb (or ispa for that matter). It is ispb's mail servers that are doing the SPF check, and rejecting the message, because it's been forwarded in a way that is not compliant with SPF. Other than complaining to ispb -- and they probably wouldn't even know to do so -- usera/userb can do little to influence the message being accepted or rejected at ispb. Viz: 1. spfprotecteddomain MX -> ispa MX: mail from: user(a)spfprotecteddomain rcpt to: usera(a)ispa Result: message accepted (passes SPF check if one is done) 2. ispa configuration for usera says "forward to userb(a)ispb" 3. ispa MX -> ispb MX: mail from: user(a)spfprotecteddomain rcpt to: userb(a)ispb Result: SPF check fails because ispa MX is not in the SPF from list, and message is rejected (and bounced by ispa MX back to user(a)spfprotecteddomain). SPF's answer to this is that mail servers should rewrite the from address -- complete with lots of magic about how it should be done (still being debated). Rewriting it to be "mail from: usera(a)isap" would work just about as well in practice in most situations (bounces go to the "wrong" place, but bounces are largely broken by all the abuse of them going on anyway). This is what procmail and some other things do. FWIW, this is not a theoritical situation. This is really happening right now. And I ended up relaxing some of my SPF statements as a "work around". As I said in the beginning I'd like to see more ISPs that offer "mail forwarding" services to their customers forward that mail in a way that won't cause SPF rejections further down the track. Like it or not SPF is being implemented, and trying to ignore it will not stop your customers mail being bounced. Ewen

3 2

Rescue from alligators in the swamp - note from APNIC
by John Tran 01 Dec '04

01 Dec '04

Hello all, First, as a general note, it is worth mentioning that there are several staff at the APNIC Secretariat who keenly follow the discussions on NZNOG. Currently, we have been closely following the discussion on the effects of implementing the 'whois privacy' policy on address ranges in use in New Zealand. This email is intended to clarify some of the issues raised, to provide explanations, and to try to identify a path forward. As there have been quite a lot of issues raised, I apologise in advance for the length of this reply. 1) Creating and changing policies --------------------------------- It is not necessary to be a member of APNIC to be involved in the policy making process. Anyone can propose policy changes and take part in the policy discussions. Also, you dont have to attend the meetings to take part. APNIC provides facilities for people not present to take part in discussions while the meetings are actually taking place. In addition, everyone is welcome to join the APNIC mailing lists where policies are proposed and discussed. The main list used to discuss the management of Internet resources is the Policy Special Interest Group (SIG) mailing list. A description of the Policy SIG is available at: http://www.apnic.net/meetings/archive/sigs/policy.html Details of how to subscribe to this and other APNIC mailing lists is available at: http://www.apnic.net/community/lists/ It is highly recommended that anyone holding resources does subscribe to this list (and others) so that they can voice their opinions and give feedback when policies are circulated for comment. You can also find a list of active policies under discussion at: http://www.apnic.net/docs/policy/proposals/ Feedback and participation in developing policies from the NZ community is very much appreciated. 2) Membership fees and criteria for portable allocations and assignments ------------------------------------------------------------------------ The fees for membership can be found here: http://www.apnic.net/member/feesinfo.html The criteria for a minium allocation (/21*) of portable address space are as follows: - the applicant must have used a /23 from their upstream provider or demonstrate an immediate need for a /23; - the applicant must have complied with applicable policies in managing all address space previously allocated to it; - the applicant must demonstrate a detailed plan for use of a /22 within a year; and commit to renumber from previously deployed space into the new address space within one year. [* it is worth noting that the size of the minimum allocation and the criteria for obtaining an allocation were recently lowered from a /20 to a /21 as a result of input and consensus from the community] More information is here: http://www.apnic.net/docs/policy/add-manage-policy.html#9.3 If you wish to obtain a portable assignment of address space as a multihomed organisation you can apply under the small multi-homing assignment policy. The criteria are: - the requestor must be currently multihomed with provider-based addresses, or demonstrates a plan to multihome within one month; and - agree to renumber out of previously assigned address space. The small multi-homing assignments are available to both members and non-members. 3) National Internet Registries (NIRs) -------------------------------------- APNIC recognises NIRs which operate within certain economies. Prospective NIRs must meet specific criteria and adopt the operational policies detailed in: http://www.apnic.net/docs/policy/nir-criteria.html and http://www.apnic.net/docs/policy/operational-policies-nirs.html 4) Whois database privacy policy -------------------------------------- Details of and the motivations for this policy are documented at: http://www.apnic.net/docs/policy/proposals/prop-007-v001.html In summary, the policy means that all non-portable assignments and non-portable sub-allocations will be private by default. Details of these resources remain registered in the whois database but are just not visible to the public. They can be made visible by the custodian of the allocation object through MyAPNIC, to which all APNIC members have access. 5) Next steps ------------- Under the database privacy policy, all non-portable assignments and non-portable sub-allocations that have not been specifically marked as public have now been made private. However, because some allocations and assignments within certain ranges appear to have been considered 'portable' by default from earlier practices in New Zealand, APNIC will restore the affected ranges from private to public. The ranges in question are: - 202.27.0./16 - 202.36.0.0/16 - 202.37.0.0/16 - 202.49.0.0/16, and - 202.50.0.0/16 Anyone holding addresses from these ranges that they wish to be made private, should contact APNIC helpdesk. The update will be done this week. 6) NZTelecom custodianship -------------------------- In regard to the wider issue of NZTelecom as a custodian of the ranges listed above, APNIC operated in good faith, trying to promote aggregation and provide a clearer framework for the custodianship of address space in New Zealand. That said, clearly there are now major concerns being expressed on this mailing list concerning portability of blocks within these ranges. The APNIC Secretariat will examine the records within these ranges and will work with NZTelecom, affected parties, and the community to find an appropriate solution. The solution will not happen overnight but the process is beginning immediately. Of course, APNIC will keep the New Zealand community fully up to date on the progress of the discussions. The APNIC Secretariat would be happy to assist anyone with concerns. If you want to discuss your concerns with us, please call the helpdesk on +61-7-3858-3188 or send email to <helpdesk(a)apnic.net>. 7) The past and the future -------------------------- Clearly, much of this stems back to a time when the framework for allocating and assigning resources was much less defined than it is today. The RIRs, with the community, are trying to provide a responsible framework for managing resources, both historical and existing resources. Some of you may be aware of the ERX transfer project in which resources in use in this region were previously registered in the ARIN database and are now being transferred to the APNIC database and are now managed by APNIC. More information about this project is available at: http://www.apnic.net/db/erx/ Many other steps are being taken. One such example is the policy recently implemented to support transfers of historical address space: http://www.apnic.net/docs/policy/proposals/prop-006-v001.html Others recently approved by the community, but yet to be implemented are: * Recovery of unused address space: http://www.apnic.net/docs/policy/proposals/prop-017-v001.html * Protecting historical records in the whois database: http://www.apnic.net/docs/policy/proposals/prop-018-v001.html I would strongly urge anyone who is a custodian of Internet resources to read these policies and to contact APNIC if they have any queries. Finally it is worth mentioning that four APNIC staff members will be at the forthcoming NZNOG meeting, and will be happy to meet with people and to provide a forum for discussing these issues. Regards Son ____________________________________________________________________ Resources Services Manager <Son(a)apnic.net> Asia Pacific Network Information Centre phone: +61 7 3858 3100 http://www.apnic.net fax: +61 7 3858 3199 Helpdesk phone: +61 7 3858 3188 email: helpdesk(a)apnic.net Please send Internet Resource Requests to <hostmaster(a)apnic.net> _____________________________________________________________________

3 3

Citynet, TelstraClear, Telecom, Orcon
by Joshua Brady 30 Nov '04

30 Nov '04

Could someone from Citynet, TelstraClear, Telecom, Orcon please contact me off-list please. Regards, Joshua Brady

1 0

IPv6 transit in .nz
by Lincoln Reid 30 Nov '04

30 Nov '04

Hi, Is anyone here able to offer international IPv6 transit in New Zealand currently? Ultimately I would like to start publishing AAAA records for some of our infrastructure, which means there is a little more pressure on to provide connectivity more compelling than through a tunnel broker eg. ~500ms, sometimes lossy, sometimes entirely broken. My experience as an end user through a tunnel broker accessing sites with AAAA records like www.apnic.net or www.isc.org is that the performance is often bad enough for me to kill my IPv6 connectivity to maintain sanity. Our requirements are very modest, even a shared 512 kbit is probably fine as long as it works most of the time. If anyone has any pointers get in touch. Cheers, -- Lincoln Reid Systems Engineer LinuxNet - AS18119 lincoln(a)linuxnet.co.nz Phone: +64 4 939 2200 Fax: +64 4 939 2201

1 0

Outage Notifications in a standardised format
by Jamie Baddeley 30 Nov '04

30 Nov '04

Hi people, I'm looking the various ways and means I get notified of early warnings/network outages, and I'm thinking that there's got to be a better way. This better way would probably involve an agreed information format (e.g XML, RSS etc) between all parties. Even just a standard email template. I'd be keen to herd a working group to come up with a standard mechanism for telling each other that the smoke has leaked out (or is about to), and that the rubber band fell off. Add some funkiness, and letting customers know would be so much easier. As usual, however, the usefulness of this is proportional to the number of network operators who agree to the standard...This is an open request to TelstraClear and Telecom - are you interested in working together on this? Can I have a show of hands from those in the NOG who'd be keen to work together to draft a standardised way of Outage Reporting. If we can get enough people together, and do some planning between now and February, then doing a BOF at the conference in February would be the way to go. And by all means, if such a standard already exists, then please point me in the direction of it.. Hands up? jamie --

1 0