HDTenEightyP/NetNews huggingface dataset:
From: jrd@cc.usu.edu (Joe Doupnik)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: time outs in FIN-WAIT2??
Date: 9 Jan 93 16:47:34 MDT
Organization: Utah State University

In article <1993Jan9.164215.20972@jupiter.sun.csd.unb.ca>, dedgar@mta.ca writes:
> Hello
> 
> I was wondering if anyone out there knows anything about a curious thing I've
> seen while ftping into various machines.
> 
> I am writing a pc based ftp client program, among other things this software
> has a hold screen function which is useful for pausing dirs to the screen &
> etc.  Anyway, if the screen is held the incoming directory listing backs up
> to the limit of my advertised window - just like it is supposed to. If the 
> window happens to be larger than the remaining data the other side will 
> send its fin and (i presume) move to fin-wait1. My side will go to close_wait
> 
> My side will remain in close-wait because it cannot get rid of the remaining
> data (the hold screen is on) but will ack the other sides fin which 
> (i presume) moves it to fin_wait2. The problem happens when I release the
> hold screen. When this happens my side finishes processing the data and sends
> its own fin, then moves to last ack. I have found that if the wait is long 
> enough (10 sec or so) the other side will ignore my fin and never return an
> ack - this leaves me in last_ack.  Eventually it seems my retransmitted fin
> will generate a reset from the other side. 
> 
> I interpret this problem to mean that the other side has timed out or retried
> out in fin-wait2. Is this a valid assumption. Does tcp-ip software do this?
> It sure isn't in the rfc. Is there another interpretation. I have experienced
> it with a number of types of machines on the internet (via anonymous ftp) maybe
> anonymous is a special case in unix boxes?
> 
> Can anyone definitly confirm (one way or the other) that this is in fact
> what is going on. I don't rule out bugs in my software, but I checked pretty
> thouroughly before asking here.
> 
> Thanks
> 						Dale Edgar
> 						Cybernetic Control Inc.
> 						DEDGAR@MTA.CA
-----------
	I did some similar thinking recently in my program. The answer depends
on how one interprets "delivers the data." I finally decided that delivery
meant placing in a socket buffer so I could send ACKs in the background as
the buffer filled. Given this position then the buffer belongs to the top
level application and not to the TCP session. Thus the session can close up
normally and so on, yet that buffer remains for later draining. This works
well with systems which insist upon sending reams of goodbye message material 
and my program is busy with other things for a while. For top level app, the
session is over when both the TCP part has finished completely and the buffer
is empty.
	Opinions do/will differ on this end to end delivery stuff. 
	Joe D.
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA
Newsgroups: comp.protocols.tcp-ip
Date: Mon, 11 Jan 1993 10:29:26 -0500 
From: "Alex R.N. Wetmore" <aw2t+@andrew.cmu.edu>
Subject: call routine when packet arrives?

I was wondering if there is any way to have standard bsd sockets
automatically call a routine when a packet arrives (sort of like what
signal() does for signals).  Basically, I have a program that isn't
event driven, but I would like for it to be able to get interrupted when
certain packets arrive (it is for a bbs, and I need to use it for system
messages, talk pages, etc).  I used to implement them using signals, but
since I am moving to a client/server model, and the client can be on a
different machine, I can't use signals anymore.

Otherwise, I could implement the packet waiting routine in where the
program waits for keystrokes, but I don't see a way of doing that
without polling (which means high cpu usage).

any ideas?

alex
From: barnett@grymoire.crd.ge.com (Bruce Barnett)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: reading what you're writing on Suns
Date: 11 Jan 93 15:53:49 GMT
	<1993Jan9.081320.415@spectrum.CMC.COM>
Reply-To: barnett@crdgw1.ge.com
Organization: GE Corp. R & D, Schenectady, NY

The Berkeley Packet Filter, if installed in the kernel, does allow
etherfind/tcpdump to "see" packets transmitted. There is source and
binary available for some systems, but I have not been able to get it
working on SunOS - ( I didn't try too hard). 

The sources of BPF are included in the sources of tcpdump found on 
ftp.ee.lbl.gov:tcpdump.tar.Z
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
From: chuck@npdiss1.StPaul.NCR.COM (Charles Rissmeyer)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: STARLAN 10 10BASE-T hub unit doesn't like adapters
Date: 8 Jan 93 17:07:48 GMT
Organization: StPaul

In article <1993Jan8.022641.27932@alf.cooper.edu> hak@alf.cooper.edu (Jeff Hakner) writes:

>I've had a similar problem.  When I used the Allied Telesis thick-10BASE-T
>adapter and plucked the twisted pair into an AT&T STARLAN 10 hub, the
>whole network starting dying with heavy collisions (and no traffic!).
>WHen I replaced the hub with an Allied hub (more modern), no problems.
>I thought STARLAN10 was supposed to be compatible with 10-BASE-T, but perhaps

I'm not very familiar with the details of STARLAN10 hubs. The newer ones
are 10BaseT compatible. It sounds like you might have a problem with the
link-beat , sometimes called link integrity, or
heartbeat.  Basically, if you have link-beat on at the hub, you need it on
at the workstation's transceiver.  If your hub doesn't support link-beat, then
you must turn it off at the terminal too.  

One more thing I just thought of, I believe some Allied Telesis transceivers
do not have the ablility to turn off link-beat.  This means you must have
it on at the hub.

Good luck,

Charles (Chuck) Rissmeyer    KE0VG
(612) 638-7669  (VP 652-7669) -  charles.rissmeyer@StPaul.NCR.COM
NCR - An AT&T Company             NCR  CCS-PM&S NPD St. Paul
Newsgroups: comp.protocols.tcp-ip
From: sobczyk@bcstec.ca.boeing.com (Andy Sobczyk)
Subject: DLPI/LLI Protocols
Organization: Boeing
Distribution: usa
Date: Fri, 8 Jan 1993 20:37:30 GMT

Newsgroup: comp.protocols.tcp-ip
Expires: 1 Feb 92

I am converting a SCO DLPI (Data Link Provider Interface) to a Interactive
/Venix LLI driver to work with WINTCP for STREAMS.  The problem I am
having is getting any information on the two protocols LLI/DLPI perferable
a detailed spec. Does anyone know where I can get this information?

If you have a copy on line.... could you mail one to me????

Andy Sobczyk
sobczyk@bcstec.ca.boeing.com
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Who used TNAMED (IEN-116) any more?  And why?
Date: 12 Jan 1993 06:21:14 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: na
NNTP-Posting-Host: gandalf.think.com

In article <jpc.726775541@avdms8.msfc.nasa.gov> jpc@avdms8.msfc.nasa.gov (J. Porter Clark) writes:
>Who would want to use trivial name service?

Our 6-year-old Bridge terminal concentrators use it.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: leino@rat.vtt.fi (Tapio Leino)
Newsgroups: comp.protocols.tcp-ip
Subject: WINTCP or DOS / IRIS Problem.
Date: 5 Jan 1993 13:51:23 GMT
Organization: VTT / Lab. of Structural Engineering
Distribution: world
NNTP-Posting-Host: rat.vtt.fi

Hi folks,
Last week I posted an explanation about a problem with the
Wollongong WINTCP for DOS TCP/IT connection to IRIS workstation.

I received two mail answers and one posting to this newgroup.
Shantanu Kothavale from the Wollongong Group answered that there
is something in the WINTCP which makes it do this. It had something to
do with the large window sizes.
Tom Mitchell from Silicon Graphics responded also and he said that
the large window size of 60k in the new release of IRIX is the cause and
that we should alter it as the parameter fortunately is external (the
value in earlier release is 24k). The same has happened with several
other products than WINTCP too.

We did it and now it seems to work again.  Thank you very much!

This just makes us wonder. Why has the window size been changed? What
do we lose changing it back to its original value, 24k?

-- 
Tapio Leino
Technical Research Centre of Finland / Laboratory of Structural Engineering
mail: VTT/Rakennetekniikan laboratorio, P.O. Box 26, SF-02151 ESPOO, Finland
tel: -358-0-456 6683, telefax: -358-0-456 7003    e-mail: Tapio.Leino@vtt.fi
Newsgroups: comp.protocols.tcp-ip.domains
From: barr@pop.psu.edu (David Barr)
Subject: Re: Negative caching
Organization: Penn State Population Research Institute
Distribution: inet
Date: Thu, 07 Jan 93 22:01:55 GMT

In article <1ii2nsINNnsj@daisy.ee.und.ac.za> barrett@daisy.ee.und.ac.za (Alan P Barrett) writes:
>In article <#gb1Hfjgyb@atlantis.psu.edu>,
>barr@pop.psu.edu (David Barr) writes:
>> Hmm.  Does this work?
>
>No.  You can make no assumptions about the validity of the domains
>between the one you asked about and the one reported in the SOA record in
>the NXDOMAIN error reply.  You know that the intermediate domains don't
>have SOA records but you don't know if they exist.  If you asked for the
>SOA record for one of these intermediate domains you might get either
>NOERROR or NXDOMAIN, and until you try it you don't know which it will be.

Right.  Which is why I don't do negative caching for intermediate
domains.  (did you not understand my wording or did I miss something?)

To summarize my summary, my suggestion is to cache invalid domains only if
there are no intermediate domains between the one I asked about and
the one reported in the SOA record in the NXDOMAIN error reply.

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
What does it profit a man if he gains the whole world, but still runs DOS?
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Hm.. lookee what creeped into my '.' cache
Date: 6 Jan 93 20:30:21 GMT
Distribution: inet
Organization: DEC Network Software Lab
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: barr@pop.psu.edu's message of 4 Jan 93 14:17:51 GMT

if it's any consolation to you, the current bind 4.9 alpha version
is immune to this kind of cache corruption.

public beta coming soon, maybe this week.
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: SOA and root server question
Date: 13 Jan 93 00:10:38 GMT
Distribution: inet
Organization: MIT Artificial Intelligence Lab
NNTP-Posting-Host: churchy.gnu.ai.mit.edu
In-reply-to: andy@homebase.vistachrome.com's message of 12 Jan 93 17:22:25 GMT

In article <1993Jan12.172225.11113@homebase.vistachrome.com> andy@homebase.vistachrome.com (Andy Finkenstadt) writes:

   We have some vendor-supplied equipment here which is hard-coded for
   an IP address that belongs to control data (the dreaded 192.9.200.x)
   since they had no understanding of how IP connectivity works and 
   used the Sun default range.  Unfortunately, this equipment can not 
   be changed to use our correct IP address.

   If we have reverse pointers for the wrong IP address and never need
   connectivity to the real 192.9.200.x, do we need to worry about this
   external to our company as we join the internet?  I would guess that
   the root servers would not acknolwedge that our domain owns that IP
   space in in-addr.arpa and therefore we'd never get external queries
   about this hardware.  (Also, those machines will never ever talk to 
   the internet.)

Incorrect resource records have an annoying way of propogating
themselves to other parts of the network.  Doing this would, in my
opinion, be a very bad idea.  DNS programs assume (and should) that
people don't do things like you suggest (because it is strongly
discouraged) and as a result, don't segregate records at all.  Also,
assuming that you never need to send mail to CDC is a bad decision.
Are you willing to make that guarantee for ten years?  If not, you
shouldn't set things up this way.

If you just purchased the equipment, I would return it for refund,
with a nastily worded letter explaining that you understood it could
support TCP/IP, as claimed, when in fact it cannot.

	-mib
--
Michael I. Bushnell      |     Watch, for you do not know when the master of 
+1 617 625 4518 (H)     -+-    the house will come, in the evening, or at
+1 617 253 8568 (W)      |     midnight, or at cockcrow, or in the morning, 
mib@gnu.ai.mit.edu       |     lest he come suddenly and find you asleep.
Newsgroups: comp.protocols.tcp-ip.domains
From: geoff@world.std.com (Geoff Collyer)
Subject: Re: Negative caching
Organization: The World @ Software Tool & Die
Distribution: inet
Date: Tue, 12 Jan 1993 01:34:19 GMT

Paul A Vixie:
>yikes.  negative cachine was in utbind, and yet nobody from ut answered
>my request for 4.9 alpha testers?

I think everybody at U of T who worked on BIND is too battle-fatigued to
even consider another round of BIND testing.
-- 
Geoff Collyer				world!geoff, world.std.com!geoff

``People don't need to read the standards'' - head of the ISO computer group
Newsgroups: comp.protocols.tcp-ip.domains
From: andy@homebase.vistachrome.com (Andy Finkenstadt)
Subject: SOA and root server question
Reply-To: andy@homebase.vistachrome.com
Organization: Vista-Chrome Incorporated
Date: Tue, 12 Jan 1993 17:22:25 GMT

We have some vendor-supplied equipment here which is hard-coded for
an IP address that belongs to control data (the dreaded 192.9.200.x)
since they had no understanding of how IP connectivity works and 
used the Sun default range.  Unfortunately, this equipment can not 
be changed to use our correct IP address.

If we have reverse pointers for the wrong IP address and never need
connectivity to the real 192.9.200.x, do we need to worry about this
external to our company as we join the internet?  I would guess that
the root servers would not acknolwedge that our domain owns that IP
space in in-addr.arpa and therefore we'd never get external queries
about this hardware.  (Also, those machines will never ever talk to 
the internet.)

If more info is needed, I'll try to reply to mail.

-Andy

-- 
Andrew Finkenstadt, Vista-Chrome, Inc., Homes & Land Publishing Corporation
GEnie Unix RoundTable Manager, andy@vistachrome.com, andy@genie.geis.com.

"[The author] neither accidentally nor intentionally omits or includes 
anything that could support a preconceived thesis." - C&EN 21-DEC-92 p.72
Newsgroups: comp.protocols.tcp-ip.domains
From: nau@struppi.medizin.uni-ulm.de (Thomas Nau)
Subject: Re: What's a TXT NS record mean?
Organization: University of Ulm, Departement of Anaesthesia
Distribution: inet
Date: Mon, 11 Jan 1993 08:18:53 GMT

from an ARPA manual:

...
TXT records are text strings, used for information associated with the host.
This type is currently (I far as I know) not used 'officialy' but
you may you it to store some information. The interpretation is
service-dependend.
...

Thomas

**********************************************************************
                 Thomas Nau (nau@medizin.uni-ulm.de)
       Departement of Anaesthesia, University of Ulm, Germany

                    think about 42 and DONT PANIC
**********************************************************************
Newsgroups: comp.protocols.tcp-ip.domains
From: root@exicom.OZ.AU (Ray Soo)
Subject: need info on DNS/NIS conflict
Originator: news@xig
Reply-To: ray@exicom.OZ.AU (ray)
Organization: Exicom (Aust) Pty Ltd
Date: Tue, 5 Jan 1993 07:45:56 GMT

Can anybody give me any pointers to information relating to
bugs/debugging SunOS BIND and NIS conflicts?

I am running SunOS 4.1.2 and _sometimes_ find that when the
system administrator has changed the NIS database, that,

1. sometimes i have to restart sendmail again since it deosn't
seem to know the names of any hosts outside our LAN
once sendmail starts up again, it runs fine.

2. more seriously, we have to use IP addresses and not names to ping/
ftp/telnet to outside hosts. nslookup (which uses a named on another
machine) works fine.


please email ray@exicom.OZ.AU

any replies will be received most gratefully

	ray
From: ercm20@festival.ed.ac.uk (Sam Wilson)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: CNAME records and MX/NS records
Date: 12 Jan 93 11:06:45 GMT

cliff@garnet.berkeley.edu (Cliff Frost) writes:
> It appears reasonable (to me) if you think of providing these services on
> multiple hosts, so that if one host goes down hard the other one is still
> providing the function.  Eg:
> 
> ; sam and mary are identically configured for processing email:
> 
> 	sam.foo.bar.	A	1.2.3.4
> 	mary.foo.bar.	A	1.2.4.4
> 	mail.foo.bar.	A	1.2.3.4
> 			A	1.2.4.4

Surely what you want here is

	sam.foo.bar.	A	1.2.3.4
	mary.foo.bar.	A	1.2.4.4
	mail.foo.bar.	MX	10	sam.foo.bar.
			MX	10	mary.foo.bar.

(yes, you're allowed the same MX preference for multiple entries).

> ; fred and betsy are running identical authoritative nameservers:
> 
> 	fred.foo.bar.	A	1.2.3.5
> 	betsy.foo.bar.	A	1.2.4.5
> 	ns.foo.bar.	A	1.2.3.5
> 			A	1.2.4.5

And here you want

	fred.foo.bar.	A	1.2.3.5
	betsy.foo.bar.	A	1.2.4.5
	sub.foo.bar.	NS	fred.foo.bar.
			NS	betsy.foo.bar.

> From experience we can say it works well for mail and less wonderfully (but
> still useful) for nameservice.  The reason it is less useful for nameservice
> is the slew of software out there which is configurable for one and only one
> nameserver IP address.

Exuse me if I'm being obtuse here but I don't see what this gains you
for NSs at all.  If the s/w can cope with only one NS address then
having multiple A records for the same name won't help in the least.  It
probably won't help for things which can use multiple addresses, because
you can just put the multiple addresses in.  The only time it would help
is if you have something that can take a name and then use multiple
addresses for that name...  but to do that it needs to be able to query
a nameserver to get the information!!!


Sam Wilson
Network Services Division
Computing Services, The University of Edinburgh
Edinburgh, Scotland, UK
From: vixie@pa.dec.com (Paul A Vixie)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: Re: Negative caching
Date: 10 Jan 93 20:35:47 GMT
	<#gb1Hfjgyb@atlantis.psu.edu> <1ii2nsINNnsj@daisy.ee.und.ac.za>
	<C0IB0C.B6u@uunet.ca>
Distribution: inet
Organization: DEC Network Software Lab
NNTP-Posting-Host: cognition.pa.dec.com
In-reply-to: smd@uunet.ca's message of Thu, 7 Jan 1993 23:09:47 GMT

[smd@uunet.ca wrote]
>Negative caching has been implemented and used in the real world for
>quite some time.  One implementation can be found at
>ftp.cs.toronto.edu in pub/utbind.tar.Z.  The CHANGES.UT file in the
>utbind package is a bit dated, but worth reading as it discusses the
>implementation details of various things like negative caching and
>error caching.

yikes.  negative cachine was in utbind, and yet nobody from ut answered
my request for 4.9 alpha testers?  let's hope that someone from ut (or
some other interested party) takes the time to integrate negative caching
into 4.9.1 after i get 4.9 out the door..
--
Paul Vixie, DEC Network Systems Lab	
Palo Alto, California, USA         	"Don't be a rebel, or a conformist;
<vixie@pa.dec.com> decwrl!vixie		they're the same thing, anyway.  Find
<paul@vix.com>     vixie!paul		your own path, and stay on it."  -me
Newsgroups: comp.protocols.tcp-ip.domains
From: barr@pop.psu.edu (David Barr)
Subject: Hm.. lookee what creeped into my '.' cache
Organization: Penn State Population Research Institute
Date: Mon, 04 Jan 93 14:17:51 GMT

	Anyone else out there see this?  Anyone know the story
with this before I send out mail?

darwin:~>dig ns .

; <<>> DiG 2.0 <<>> ns . 
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
;; flags: qr rd ra ; Ques: 1, Ans: 8, Auth: 8, Addit: 9
;; QUESTIONS: 
;;      ., type = NS, class = IN

;; ANSWERS:
.       517838  NS      NS.NIC.DDN.MIL.
.       517838  NS      AOS.BRL.MIL.
.       517838  NS      KAVA.NISC.SRI.COM.
.       517838  NS      C.NYSER.NET.
.       517838  NS      TERP.UMD.EDU.
.       517838  NS      NS.NASA.GOV.
.       517838  NS      NIC.NORDU.NET.
.       16841   NS      bxnms.u-bordeaux.fr.

;; AUTHORITY RECORDS:
.       517838  NS      NS.NIC.DDN.MIL.
.       517838  NS      AOS.BRL.MIL.
.       517838  NS      KAVA.NISC.SRI.COM.
.       517838  NS      C.NYSER.NET.
.       517838  NS      TERP.UMD.EDU.
.       517838  NS      NS.NASA.GOV.
.       517838  NS      NIC.NORDU.NET.
.       16841   NS      bxnms.u-bordeaux.fr.

;; ADDITIONAL RECORDS:
NS.NIC.DDN.MIL. 517838  A       192.112.36.4
AOS.BRL.MIL.    517838  A       128.63.4.82
AOS.BRL.MIL.    517838  A       192.5.25.82
AOS.BRL.MIL.    517838  A       26.3.0.29
KAVA.NISC.SRI.COM.      517838  A       192.33.33.24
C.NYSER.NET.    517838  A       192.33.4.12
TERP.UMD.EDU.   517838  A       128.8.10.90
NS.NASA.GOV.    517742  A       128.102.16.10
NS.NASA.GOV.    517742  A       192.52.195.10

;; Sent 1 pkts, answer found in time: 0 msec 
;; FROM: darwin to SERVER: default -- 127.0.0.1
;; WHEN: Mon Jan  4 09:11:51 1993
;; MSG SIZE  sent: 17  rcvd: 500

darwin:~>dig ns . @bxnms.u-bordeaux.fr

; <<>> DiG 2.0 <<>> ns . @bxnms.u-bordeaux.fr 
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 10
;; flags: qr aa rd ra ; Ques: 1, Ans: 1, Auth: 0, Addit: 2
;; QUESTIONS: 
;;      ., type = NS, class = IN

;; ANSWERS:
.       86400   NS      bxnms.u-bordeaux.fr.

;; ADDITIONAL RECORDS:
bxnms.u-bordeaux.fr.    86400   A       147.210.253.1
bxnms.u-bordeaux.fr.    86400   A       147.210.253.1

;; Sent 1 pkts, answer found in time: 1442 msec 
;; FROM: darwin to SERVER: bxnms.u-bordeaux.fr  147.210.253.1
;; WHEN: Mon Jan  4 09:13:34 1993
;; MSG SIZE  sent: 17  rcvd: 81

--Dave
-- 
System Administrator, Population Research Institute    barr@pop.psu.edu
	What if there was no such thing as a hypothetical question?
From: mbl900@anusf.anu.edu.au (Mathew BM LIM)
Newsgroups: comp.protocols.tcp-ip.domains
Subject: What's a TXT NS record mean?
Date: 11 Jan 1993 02:24:24 GMT
Organization: Australian National University
Distribution: inet
NNTP-Posting-Host: 150.203.5.2

I just came across the following entry while doing a dig on a
particular host and was curious what the TXT record means - anyone
care to enlighten me?

(note - hostname and IP address x'ed out)

; <<>> DiG <<>> xxxxxx.xxx.xx.xxx any 
;; ->>HEADER<<- opcode: QUERY , status: NOERROR, id: 6
;; flags: qr aa rd ra  Ques: 1, Ans: 6, Auth: 0, Addit: 4

;; QUESTIONS: 
;;      xxxxxx.xxx.xx.xxx, type = ANY, class = IN

;; ANSWERS:
xxxxxx.xxx.xx.xxx       IN      A       xx.xxx.x.x      ; 86400
xxxxxx.xxx.xx.xxx       IN      TXT     openmail/notes/lmx/netdist

-- 
Mathew Lim, Unix Systems Programmer, ANU Supercomputer Facility,	
Australian National University,	Canberra ACT, Australia 0200.
Telephone : +61 6 249 2750 	| 
Fax       : +61 6 247 3425	| E-Mail  : M.Lim@anu.edu.au