Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!bellcore!ulysses!ucbvax!USC-ISID.ARPA!MILLS
From: MILLS@USC-ISID.ARPA
Newsgroups: mod.protocols.tcp-ip
Subject: Re: more interesting features of 4.2
Message-ID: <8606050225.AA19266@ucbvax.Berkeley.EDU>
Date: Wed, 4-Jun-86 14:15:01 EDT
Article-I.D.: ucbvax.8606050225.AA19266
Posted: Wed Jun  4 14:15:01 1986
Date-Received: Thu, 5-Jun-86 09:23:25 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 36
Approved: tcp-ip@sri-nic.arpa

In response to the message sent  4 Jun 86 04:15:48 EDT from HEDRICK@RED.RUTGERS.EDU

Charles,

I'm not sure who you mean by the "gateway group." The old Gateway Algorithms
and Data Structures (GADS) Task Force, which I chaired, has been dissolved and
precipitated into the Internet Engineering (INENG) Task Force, Chaired by
Mike Corrigan, and the Internet Architecture (INARC) Task FOrce, which I
chair. THe INENG is concerned about relatively near-term (a couple of
years) issues, while the INARC is looking further out. Both of these task
forces are concerned about gateways, among many other issues.

The NSF Network Technical Advisory Group (NTAG), which serves as advisor to
NSF staff on network issues in general, including gateways for the explosively
growing NSF Internet community, created an ad-hoc subcommittee to establish
a first cut at Internet gateway requirements in general and the NSF community
in particular. That subcommittee, also chaired by me, produced in close
cooperation with the Internet Activities Board, chaired by Dave Clark,
a working document that was published as RFC-985. You can see there is no
single "gateway group," but a number of committees and task forces very
much concerned with the issues being discussed here. The chairs mentioned
above watch this list and others for developing issues and consider them
carefully when constructing agendae and moderating meeting discussion.
Nevertheless, the issues wandering around here on gateway routing, ARP,
redirects and cranky Unix systems are incredibly complicated, easily
misunderstood and highly flame-able.

Speaking for myself and the above committees, we would very much like to
harden the model proposed in RFC-985, especially in the technical details
involved with multi-net cables, host-gateway routing, address resolution,
redirects and so forth on Ethernets, TransLANs and similar technologies.
If you have specific questions or comments you think unsuitable for this list,
you are welcome to jiggle my chain or the others mentioned in RFC-985.

Dave
-------