February 2011 - 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

Re: [nznog] APE 6to4
by Matthew Moyle-Croft 24 Jun '11

24 Jun '11

On 09/03/2009, at 1:44 PM, Jasper Bryant-Greene wrote: > > How is that different from normal IP routing? The other end always > decides which way to send packets back to you, and in the event that > your customer is multihomed, the return path might not even transit > your AS. I control my outbound and inbound routing. People only send packets via routes I advertise and I can show a contractual relationship between me and my upstream or peer, my upstream and theirs or their peer and then to the far end etc. With using 6to4 the downside is that whilst I may have my own gateway, the FAR end could be using a 3rd party 6to4 gateway. This means that the return packets traverse links for which I have no contractual relationship. I guess in some way I'm agreeing with Joe that everyone SHOULD run their own, especially if they offer up content over IPv6. (I wonder if Google do with ipv6.google.com?). MMC -- Matthew Moyle-Croft Internode/Agile Peering and Core Networks Level 5, 162 Grenfell Street, Adelaide, SA 5000 Australia Email: mmc(a)internode.com.au Web: http://www.on.net Direct: +61-8-8228-2909 Mobile: +61-419-900-366 Reception: +61-8-8228-2999 Fax: +61-8-8235-6909

6 10

Vocus to build Aus-NZ Exchange
by Simon Lyall 19 May '11

19 May '11

via Ausnog: "Wholesale internet transit provider Vocus will create an internet peering exchange to greatly cut latency between Sydney and Auckland. The PacificIX exchange would go live "by the end of the year", Vocus (ASX: VOC) chief executive officer James Spenceley (pictured) told iTnews today. It would run out of the Equinix and Global Switch data centres in Sydney and from the Auckland Sky Tower and a "second [undisclosed] node" elsewhere in the NZ city." http://www.itnews.com.au/News/232330,vocus-to-cut-sydney-auckland-latency.a… -- Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/ "To stay awake all night adds a day to your life" - Stilgar | eMT.

4 4

[isoc-advisory-council] URGENT UPDATE- Statement relating to today’s ITU-T SG15 MPLS development decision
by jamie baddeley 01 Mar '11

01 Mar '11

what thoughts do folks have on this? > The Internet we know today could > not have come about without open, interoperable, global standards. wise words. jamie > > > ---------- Forwarded message ---------- > From: Drew Dvorshak <dvorshak(a)isoc.org> > Date: 26 February 2011 17:44 > Subject: [isoc-advisory-council] URGENT UPDATE- Statement relating to > today’s ITU-T SG15 MPLS development decision > To: isoc-advisory-council(a)elists.isoc.org > Cc: Russ Housley <housley(a)vigilsec.com> > > > Dear Colleagues, > > Many of you have followed with interest (and some anxiety) ITU Study > Group 15's work and the implications of it has been the subject of > several Advisory Council meeting dialogues for some time. Please read > below ISOCs' response to today's SG15 decision on transport MPLS also > reflecting the views of IETF Chair Russ Housley. This news is indeed > unfortunate and you will note copy to Russ to ensure he is included in > Council dialogue as I am confident your willingness and ability to > focus expertise on issues for problem solving and positive planning > will be useful and appreciated here. > Your communications and media people may link to this release at: > http://isoc.org/wp/newsletter/?p=3287. Please let me know should you > have any questions or comments. > Cheers, > Drew > IETF and Internet Society Statement relating to today’s ITU-T SG15 > decision that will lead to non-interoperability in MPLS development > > Today, the ITU-T Study Group 15 determined a Recommendation that > defines Y.1731 based operations, administration and management (OAM) > for MPLS transport networks. This decision sets the stage for a > divergence in MPLS development; it creates a situation where some > vendors will use the IETF standard for MPLS OAM while other vendors > implement the ITU-T Recommendation for OAM. This situation ensures > that the two product groups will not work together. While the impact > may not be immediate, ongoing evolution along this path will > jeopardize the globally interconnected Internet, which is an > interoperable network of networks. > > Russ Housley, IETF chair, commented; "The Internet we know today could > not have come about without open, interoperable, global standards. > After we have worked so long and so hard together to ensure that MPLS > OAM products from all vendors around the world would be compatible > with each other, I am surprised and disappointed by the action taken > by the ITU-T today, which takes us off the path of global > interoperability for this technology. The decision is all the more > regrettable because the IETF is just completing work on the first > major phase of extensions to MPLS OAM protocols for use in transport > networks.” > > Furthermore, this ITU-T SG15 action represents a serious breach of the > IETF/ ITU-T Joint Working Team (JWT) agreement. This JWT was > commissioned by the ITU-T and IETF to examine the feasibility of a > single, collaborative solution to MPLS transport requirements. The > team unanimously agreed that a single viable solution had been > identified; their report was completed in April 2008 and accepted in > December 2008. This JWT Report states not only that a single solution > was possible but also recommended an approach where protocol > development for MPLS-TP would be undertaken by the IETF. The IETF and > ITU-T independently accepted and endorsed the JWT report. The ITU-T > committed to the IETF that they would abide by the JWT recommendations > and recognized the IETF as the design authority for MPLS. Furthermore, > the JWT confirmed that it was technically feasible to extend the > existing MPLS architecture to meet the requirements of a transport > profile, now called MPLS-TP. Since the acceptance of the JWT Report, > both organizations have worked constructively until now. > > "Resolution 101 represented the clear wishes of the member states of > the ITU, and was agreed at the ITU's Plenipotentiary conference less > than six months ago. That Resolution was agreed at the highest level > of the Union, and yet SG15 has taken action that directly contradicts > it,” said Lynn St. Amour, president and CEO of the Internet Society. > > “The IETF will complete its work on a MPLS OAM specification, and the > IETF leadership is considering the best way to proceed in light of > this surprising development,” added Russ Housley. “At this point, our > goal is to minimize the negative consequences of this unfortunate > situation. The priority is to establish a measured and careful > approach that protects the stability of the Internet while enabling it > to grow to serve the entire world-wide population.” > > Although the ITU-T SG15 decision is disappointing, in an ongoing > pursuit of a globally interoperable solution, the IETF will continue > to gather transport requirements and work to extend IETF MPLS > forwarding, OAM, survivability, network management, and control plane > protocols to meet those requirements through the IETF Standards > Process. > > When two non-interoperable standards are developed, there are only two > possible outcomes: if both technologies are deployed, there will be > confusion, if only one is deployed, the existence of the alternative > is irrelevant. In this instance, there are believed to be commercial > products in development for both proposals, so confusion appears > inevitable. > > Russ Housley concluded, “The IETF leadership continues to believe that > a single OAM solution will better serve the continued growth of > Internet, and we hope that the ITU-T leadership will also come to > recognize the benefits of a single globally interoperable solution.” > > > > > > _______________________________________________ > Isoc-advisory-council mailing list > Isoc-advisory-council(a)elists.isoc.org > https://elists.isoc.org/mailman/listinfo/isoc-advisory-council >

2 1

NZRR Route Registry Update
by NZRR Database Notifications 28 Feb '11

28 Feb '11

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:AS17492 descr: advertised to AS9560 by Vector Communications Limited - AS17492 members: 101.100.0.0/16^16-29, 116.199.208.0/20^20-29, 202.126.192.0/20^20-29, 115.126.128.0/21^21-29, 123.108.144.0/21^21-29, 182.23.176.0/21^21-29, 202.162.176.0/21^21-29, 110.34.48.0/22^22-29, 180.210.208.0/22^22-29, 182.16.152.0/22^22-29, 202.36.68.0/23^23-29, 202.0.151.0/24^24-29, 202.27.160.0/24^24-29, 202.50.246.0/24^24-29, 202.62.245.0/24^24-29, 202.129.253.0/24^24-29, 203.30.174.0/24^24-29, 203.99.68.0/24^24-29, 210.54.58.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: Tim.Harman(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110222 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS17492 descr: advertised to AS9560 by Vector Communications Limited - AS17492 members: 101.100.0.0/16^16-29, 116.199.208.0/20^20-29, 202.126.192.0/20^20-29, 115.126.128.0/21^21-29, 123.108.144.0/21^21-29, 182.23.176.0/21^21-29, 202.162.176.0/21^21-29, 110.34.48.0/22^22-29, 180.210.208.0/22^22-29, 182.16.152.0/22^22-29, 202.36.68.0/23^23-29, 202.0.151.0/24^24-29, 202.27.160.0/24^24-29, 202.37.173.0/24^24-29, 202.50.246.0/24^24-29, 202.62.245.0/24^24-29, 202.129.253.0/24^24-29, 203.30.174.0/24^24-29, 203.99.68.0/24^24-29, 210.54.58.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: Tim.Harman(a)vector.co.nz mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110301 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 28 Feb '11

28 Feb '11

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:AS2687 descr: advertised to AS9560 by AT&T - AS2687 members: 124.248.128.0/20^20-29, 202.27.216.0/22^22-29, 202.36.192.0/22^22-29, 202.169.192.0/22^22-29, 32.114.24.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.27.136.0/23^23-29, 202.36.68.0/23^23-29, 202.37.70.0/23^23-29, 202.169.198.0/23^23-29, 202.169.202.0/23^23-29, 202.169.206.0/23^23-29, 202.169.212.0/23^23-29, 202.175.142.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 32.234.80.0/24^24-29, 192.88.190.0/24^24-29, 192.203.216.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.20.92.0/24^24-29, 202.27.77.0/24^24-29, 202.27.83.0/24^24-29, 202.27.160.0/24^24-29, 202.27.222.0/24^24-29, 202.27.236.0/24^24-29, 202.27.247.0/24^24-29, 202.27.251.0/24^24-29, 202.36.12.0/24^24-29, 202.36.29.0/24^24-29, 202.36.43.0/24^24-29, 202.36.75.0/24^24-29, 202.36.80.0/24^24-29, 202.36.154.0/24^24-29, 202.36.198.0/24^24-29, 202.37.68.0/24^24-29, 202.37.167.0/24^24-29, 202.37.168.0/24^24-29, 202.37.187.0/24^24-29, 202.37.254.0/24^24-29, 202.49.189.0/24^24-29, 202.49.216.0/24^24-29, 202.50.240.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.85.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 202.169.196.0/24^24-29, 202.169.201.0/24^24-29, 202.169.205.0/24^24-29, 202.169.223.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.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: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20101109 source: NZRR REPLACED BY: route-set: AS9560:RS-ROUTES:AS2687 descr: advertised to AS9560 by AT&T - AS2687 members: 124.248.128.0/20^20-29, 202.27.216.0/22^22-29, 202.36.192.0/22^22-29, 202.169.192.0/22^22-29, 32.114.24.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.27.136.0/23^23-29, 202.36.68.0/23^23-29, 202.37.70.0/23^23-29, 202.169.198.0/23^23-29, 202.169.202.0/23^23-29, 202.169.206.0/23^23-29, 202.169.212.0/23^23-29, 202.175.142.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 32.234.80.0/24^24-29, 192.88.190.0/24^24-29, 192.203.216.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.20.92.0/24^24-29, 202.27.77.0/24^24-29, 202.27.83.0/24^24-29, 202.27.160.0/24^24-29, 202.27.222.0/24^24-29, 202.27.236.0/24^24-29, 202.27.247.0/24^24-29, 202.27.251.0/24^24-29, 202.36.12.0/24^24-29, 202.36.29.0/24^24-29, 202.36.43.0/24^24-29, 202.36.75.0/24^24-29, 202.36.80.0/24^24-29, 202.36.154.0/24^24-29, 202.36.198.0/24^24-29, 202.37.68.0/24^24-29, 202.37.167.0/24^24-29, 202.37.168.0/24^24-29, 202.37.187.0/24^24-29, 202.37.254.0/24^24-29, 202.49.189.0/24^24-29, 202.49.216.0/24^24-29, 202.50.240.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.85.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 202.169.196.0/24^24-29, 202.169.201.0/24^24-29, 202.169.205.0/24^24-29, 202.169.209.0/24^24-29, 202.169.223.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.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: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110301 source: NZRR ------------------------------------------------------------

1 0

NZRR Route Registry Update
by NZRR Database Notifications 28 Feb '11

28 Feb '11

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:AS2687 descr: advertised to AS9439 by AT&T - AS2687 members: 124.248.128.0/20^20-29, 202.27.216.0/22^22-29, 202.36.192.0/22^22-29, 202.169.192.0/22^22-29, 32.114.24.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.27.136.0/23^23-29, 202.36.68.0/23^23-29, 202.37.70.0/23^23-29, 202.169.198.0/23^23-29, 202.169.202.0/23^23-29, 202.169.206.0/23^23-29, 202.169.212.0/23^23-29, 202.175.142.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 32.234.80.0/24^24-29, 192.88.190.0/24^24-29, 192.203.216.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.20.92.0/24^24-29, 202.27.77.0/24^24-29, 202.27.83.0/24^24-29, 202.27.160.0/24^24-29, 202.27.222.0/24^24-29, 202.27.236.0/24^24-29, 202.27.247.0/24^24-29, 202.27.251.0/24^24-29, 202.36.12.0/24^24-29, 202.36.29.0/24^24-29, 202.36.43.0/24^24-29, 202.36.75.0/24^24-29, 202.36.80.0/24^24-29, 202.36.154.0/24^24-29, 202.36.198.0/24^24-29, 202.37.68.0/24^24-29, 202.37.167.0/24^24-29, 202.37.168.0/24^24-29, 202.37.187.0/24^24-29, 202.37.254.0/24^24-29, 202.49.189.0/24^24-29, 202.49.216.0/24^24-29, 202.50.240.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.85.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 202.169.196.0/24^24-29, 202.169.201.0/24^24-29, 202.169.205.0/24^24-29, 202.169.223.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.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: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20101109 source: NZRR REPLACED BY: route-set: AS9439:RS-ROUTES:AS2687 descr: advertised to AS9439 by AT&T - AS2687 members: 124.248.128.0/20^20-29, 202.27.216.0/22^22-29, 202.36.192.0/22^22-29, 202.169.192.0/22^22-29, 32.114.24.0/23^23-29, 122.248.172.0/23^23-29, 202.14.252.0/23^23-29, 202.27.136.0/23^23-29, 202.36.68.0/23^23-29, 202.37.70.0/23^23-29, 202.169.198.0/23^23-29, 202.169.202.0/23^23-29, 202.169.206.0/23^23-29, 202.169.212.0/23^23-29, 202.175.142.0/23^23-29, 203.99.128.0/23^23-29, 203.163.70.0/23^23-29, 203.176.122.0/23^23-29, 32.234.80.0/24^24-29, 192.88.190.0/24^24-29, 192.203.216.0/24^24-29, 202.12.105.0/24^24-29, 202.14.254.0/24^24-29, 202.20.92.0/24^24-29, 202.27.77.0/24^24-29, 202.27.83.0/24^24-29, 202.27.160.0/24^24-29, 202.27.222.0/24^24-29, 202.27.236.0/24^24-29, 202.27.247.0/24^24-29, 202.27.251.0/24^24-29, 202.36.12.0/24^24-29, 202.36.29.0/24^24-29, 202.36.43.0/24^24-29, 202.36.75.0/24^24-29, 202.36.80.0/24^24-29, 202.36.154.0/24^24-29, 202.36.198.0/24^24-29, 202.37.68.0/24^24-29, 202.37.167.0/24^24-29, 202.37.168.0/24^24-29, 202.37.187.0/24^24-29, 202.37.254.0/24^24-29, 202.49.189.0/24^24-29, 202.49.216.0/24^24-29, 202.50.240.0/24^24-29, 202.135.38.0/24^24-29, 202.135.49.0/24^24-29, 202.135.64.0/24^24-29, 202.135.85.0/24^24-29, 202.135.111.0/24^24-29, 202.135.112.0/24^24-29, 202.135.116.0/24^24-29, 202.135.142.0/24^24-29, 202.135.146.0/24^24-29, 202.135.190.0/24^24-29, 202.135.192.0/24^24-29, 202.135.231.0/24^24-29, 202.169.196.0/24^24-29, 202.169.201.0/24^24-29, 202.169.205.0/24^24-29, 202.169.209.0/24^24-29, 202.169.223.0/24^24-29, 203.163.68.0/24^24-29, 203.163.94.0/24^24-29, 203.163.98.0/24^24-29, 203.196.101.0/24^24-29, 203.196.119.0/24^24-29, 203.196.121.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: dl-globalwork(a)att.com mnt-by: MAINT-NZRR-NZ changed: rpsl-admin(a)nzix.net 20110301 source: NZRR ------------------------------------------------------------

1 0

Telecom Business Hub MX
by Jodi Thomson 27 Feb '11

27 Feb '11

Hi Can someone from Telecom Business Hub contact me off list regarding IP blacklisting from mail.tbhub.co.nz? I've followed the required procedures with no joy Cheers JT -- Jodi Thomson Network & Systems Engineer Ph +64-6-8355800 Fax +64-6-8355811 Mob +64-21-903712 E-Mail jodi(a)team.waspnet.co.nz www.waspnet.co.nz

1 0

Re: [nznog] CHCH - Looking for iPad/tablet or similar device
by Forman, Lana 27 Feb '11

27 Feb '11

Thanks for all of the offers, Renaissance are going to get one to us. Thanks again, Lana. From: nznog-bounces(a)list.waikato.ac.nz [mailto:nznog-bounces(a)list.waikato.ac.nz] On Behalf Of Forman, Lana Sent: Monday, 28 February 2011 12:47 p.m. To: nznog(a)list.waikato.ac.nz Subject: [nznog] CHCH - Looking for iPad/tablet or similar device Hi, Bit of a random request, I have a workmate sitting at Burwood hospital caring for his wife who has a spinal injury resulting from the quake. She's not able to communicate well verbally, but has been able to slowly tap out messages on his HTC touch phone. If anyone could loan me an iPad or other such touchy tablet device there will be beer. I'm trying to find a device that I can purchase off one of our suppliers at the moment but a loaner for a couple of days while I get that sorted would be so helpful. Regards, Lana. Lana Forman Senior Services Engineer Fujitsu New Zealand Limited Unit 3, 1 Show Place, Addington, Christchurch, New Zealand 8024 T +64 3 963 7950 M +64 21 289 8829 F +64 3 963 7941 lana.forman(a)nz.fujitsu.com nz.fujitsu.com

1 0