RFC 1070
Use of the Internet as a subnetwork for experimentation with the OSI network layer
RFC 1070: Use of the Internet as a Subnetwork for Experimentation with the OSI Network Layer 🎀
okay so the title block is giving 📚 This is RFC 1070, filed under the Network Working Group and dated February 1989. The authors are:
- R. Hagens, U of Wiscsonsin - Madison
- N. Hall, U of Wiscsonsin - Madison
- M. Rose, The Wollongong Group
There's no category listed, and it doesn't obsolete or update anything. 🫶
Status of this Memo 📜
This RFC proposes a scenario for experimentation with the International Organization for Standardization (ISO) Open Systems Interconnection (OSI) network layer protocols over the Internet, and it asks for discussion and suggestions on how to improve the scenario. It also proposes creating an experimental OSI internet. To take part in that experimental OSI internet, a system has to abide by the agreements set out in this RFC. Distribution of this memo is unlimited. 💖
WARNING 🚨
The methods proposed in this RFC are suitable ONLY for experimental use on a limited scale. These methods are not suitable for use in an operational environment. 🙈
Introduction 🌸
okay so the OSI network layer protocols are literally still in their infancy 👶 but everyone is obsessed with them anyway. Interest in how they'll develop, and worry about what they could do to internetworking, is everywhere. It got even bigger once the US Government OSI Profile (GOSIP) showed up, which means US Government agencies will be required to use OSI products in the near future. 😭 The catch is that these protocols haven't had much experimentation or testing yet. Their status goes all the way from full ISO International Standard down to "contribution" (aka not even a Draft Proposal yet 💀). We think thorough testing of the protocols and their implementations should happen at the same time they move toward ISO standards, so making a place to experiment is honestly timely. ✨
Testing network and transport layer protocols for internetworking properly needs a big, varied, and complicated environment 🌍 An implementor can totally test their OSI implementation locally 🙄 but very few implementors have the resources to build a dynamic topology large enough to test the protocols and implementations properly.
One option would be putting the OSI network layer protocols into the routers that already exist in an existing internetwork. ngl that's giving disruptive 😬 The OSI stuff is still immature, and you'd need a whole bunch of routers running the OSI network layer just to do realistic testing.
This memo suggests a scenario that makes it easy for implementors to test with each other, using the Internet's existing connectivity without disturbing existing gateways. 🦋
The method suggested is to treat the Internet as a subnetwork, which the memo calls the "IP subnet." Here's the vibe: OSI connectionless network layer protocol (ISO 8473) packets get encapsulated in IP datagrams, where IP means the Internet network layer protocol from RFC 791. This encapsulation only happens for packets traveling over the IP subnet to sites that aren't reachable over a local area network. The plan is for implementations to use OSI network layer protocols directly over local links, and to use the IP subnet as a link only when it's necessary to reach a site separated from the source by an IP gateway. Almost any system at a participating site may be reachable with IP, but experimenters are expected to configure their systems so that a subset of them consider themselves directly connected to the IP subnet for testing the OSI network layer protocols or their implementations. 🧚 The scheme lets systems change their topological relationship to the IP subnet at any time, and also change their behavior as an end system (ES), intermediate system (IS), or both, at any time. That flexibility is needed to test the dynamic adaptive properties of the routing exchange protocols. 👑
A variant of this scheme is proposed for implementors who don't have direct access to the IP layer in their systems. This variation uses the User Datagram Protocol over IP (UDP/IP) as the subnetwork. 🌈
In this memo, the experiment based on the IP subnet is called EON, short for "Experimental OSI-based Network." The experiment based on the UDP/IP subnet is called EON-UDP. 💜
It's assumed that you already know the OSI connectionless network layer, and in particular the following documents:
RFC 768: User Datagram Protocol.RFC 791: Internet Protocol.ISO 8473: Protocol for Providing the Connectionless mode Network Service.ISO DP 9542: End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473).ISO TC 97/SC 6/N xxxx: Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol.PD TR 97/SC 6/N 9575: OSI Routing Framework.
Definitions 📖
- EON: An acronym for Experimental OSI Network, a name for the proposed experimental OSI-based internetwork that uses the IP over the Internet as a subnetwork.
- EON-UDP: A name for the proposed experimental OSI-based internetwork that uses the UDP/IP over the Internet as a subnetwork.
- ES: End system as defined by OSI: an OSI network layer entity that provides the OSI network layer service to a transport layer.
- IANA: The Internet Assigned Numbers Authority. Contact Joyce K. Reynolds (JKREY@ISI.EDU).
- IS: An OSI network layer entity that provides the routing and forwarding functions of the OSI connectionless network layer.
- OSI CLNL: OSI connectionless network layer.
- NSDU: Network Service Data Unit.
- PDU: Protocol Data Unit, or packet.
- NPDU: Network Protocol Data Unit.
- ISO-gram: An NPDU for any protocol in the OSI CLNL, including ISO 8473 (CLNP), ISO DP 9542 (ES-IS), and ISO TC 97/SC 6/N xxxx (IS-IS).
- Participating system: An ES or IS that is running a subset of the OSI CLNL protocols and is reachable through the application of these protocols and the agreements set forth in this memo.
- Core system: An ES or IS that considers itself directly connected to the IP subnet for the purpose of participating in EON.
- NSAP-address: Network Service Access Point address, or an address at which the OSI network services are available to a transport entity.
- SNPA-address: SubNetwork Point of Attachment address, or an address at which the subnetwork service is available to the network entity.
Issues to be Addressed by this Memo 🧩
To make the experimental OSI internet work, participating experimenters must agree on:
- how ISO-grams will be encapsulated in IP or UDP packets,
- the format of NSAP-addresses to be used,
- how NSAP-addresses will be mapped to SNPA-addresses on the IP subnet,
- how multicasting, which is assumed by some OSI CLNL protocols, will be satisfied, and
- how topology information and host names will be disseminated.
This memo contains proposals for each of these issues. 💅
Design Considerations 💅
The goals of this memo are:
- to facilitate the testing of the OSI network layer protocols among different implementations,
- to do this as soon as possible, exploiting existing connectivity,
- to do this without requiring any changes to existing IP gateways,
- to create a logical topology that can be changed easily, for the purpose of testing the dynamic adaptive properties of the protocols, and
- to minimize the administrative requirements of this experimental internetwork. 🌷
The following are not goals of this memo:
- to permit the use of arbitrary ISO-style NSAP-addresses,
- to require that participants have working implementations of all of the OSI routing protocols before they can participate in any capacity,
- to permit or encourage the use of existing IP routing methods and algorithms for the routing of ISO-grams among participating ESs and ISs,
- to create a production-like environment accommodating a very large number of systems (ESs, ISs or both), and
- to provide or to encourage IP-to-CLNP gatewaying. 🙅♀️
Encapsulating ISO-grams in IP datagrams 📦
The entire OSI network layer PDU, whether it's an ISO 8473 PDU, an ISO DP 9542 PDU, or an IS-IS PDU, gets placed in the data portion of an IP datagram at the source. The ISO 8473 entity may fragment an NSDU into several NPDUs, and if it does, each NPDU gets encapsulated in its own IP datagram. The point is for the OSI CLNL to do the fragmenting rather than IP, so the OSI CLNL can be tested. ✨ Of course, there's no guarantee that fragmentation won't happen within the IP subnet, so reassembly must be supported at the IP level in the destination participating system. 🫧
SNPA-addresses (Internet addresses) get algorithmically derived from the NSAP-addresses, as described below. The protocol field of the IP datagram takes the value 80 (decimal), which has been assigned for this purpose. 🍓
NSAP-Address Format ✨
okay so the OSI internetwork in this doc is gonna be ONE routing domain 🌸 and every level 1 router in it recognises the same single form of NSAP address. so clean, no cap. other address formats might get agreed on in later editions of this memo 🦋
the address format for this experiment is the one from RFC 1069. according to RFC 1069, the low-order part of the Domain Specific Part of the NSAP address can vary depending on the conventions of the particular routing domain 💅. for this experiment we're using this format:
Address Format for EON
Octet Value Meaning
-------- ------------- ----------------------------------------
1 47 Authority and Format Identifier
2,3 00, 06 International Code Designator
4 3 Version Number
5,6 0 Global Area Number, see RFC 1069
7,8 RDN Routing Domain Number, assigned by IANA
9-11 0 Pad
12,13 0 LOC-AREA, see below
14,15 0 unused
16-19 A.B.C.D Internet address
20 NSAP Selector, assigned IANANote: it's our desire that the address format used by EON stays consistent with RFC 1069 🫶 so the format proposed here may change as future editions of RFC 1069 come out.
the mapping between NSAP-addresses and SNPA-addresses (Internet addresses) on the proposed IP subnet is super straightforward 🍓 the SNPA-address is embedded right inside the NSAP-address.
there are a few ways the LOC-AREA field could be used:
(1) Assign local areas, administered by the Internet Assigned Numbers Authority (IANA). the upside is it allows experimenting with area routing 🧚 the downside is it'll need an additional directory service to map host names to NSAP-addresses. we'd like to use the existing domain name servers to derive Internet addresses from names, and we'd like NSAP-addresses to be derivable from the Internet addresses alone 🤞
(2) Have one local area in the EON, with LOC-AREA value 0. this would kill the problem of name-to-NSAP-address binding 🙌 but it wouldn't allow experimenting with area routing. it wouldn't, however, rule out using areas later, for example when OSI directory services are widely available.
(3) Make the local area a simple function of the Internet address. the upside is it would allow experimenting with area addressing without needing extra directory services 🌈 but the areas derived wouldn't be under the control of the experimenters, and they may not correspond to anything useful or meaningful for this experiment 😭
we believe that initially, the preferred option is to use only zero-valued local areas ⭐ later editions of this memo may propose ways to use the local area field, once the IS-IS proposal is more mature and maybe when OSI directory services are in use among experimenters.
the value of the high-order portion of the DSP will be set in accordance with RFC 1069 💜
Other NSAP-Address Formats
PDUs carrying NSAP-addresses of other formats can still be routed through this domain 🌸 that's the job of the level 2 routers, which are described in the IS-IS document.
Multicast Addresses on the IP Subnet
okay this part is lowkey a lot but it's so good 🔥 the ES-IS and IS-IS routing exchange protocols assume that broadcast subnetworks support two multicast addresses: one for all ESs and one for all ISs. you could dodge this by treating the IP subnet as a general topology subnetwork or as a set of point-to-point links, but it's also desirable to treat the IP subnet as a broadcast subnetwork 🦋 that way you can test the parts of an implementation that run over broadcast subnets. an implementor who doesn't have access to several local machines running the OSI CLNL can test the protocols over the IP subnet as if it were a broadcast subnet 🧚
the multicasting the OSI CLNL assumes can be simulated by a small sublayer sitting between the OSI CLNL and the IP subnet layer. for this discussion, let's call this sublayer an SNAcP, which stands for SubNetwork Access Protocol, in OSI argot 💅 in each system, the SNAcP caches a table of the Internet addresses of systems it considers reachable in one ISO 8473-hop over the IP subnet. these are called "core" systems ✨ so basically the cache pretends to be a set of links, and a system sends its ISO configuration messages (ES Hello, IS Hello, etc.) over those links when it comes up. as a local matter, the table of core systems may or may not grow during the system's lifetime, in response to configuration messages from other core systems 🌷
on the outgoing path, the SNAcP accepts an ISO-gram plus a parameter saying what it's for: send to a single system, to all ESs, to all ISs, or to all systems 🎀 if the intended destination is a single system, the ISO-gram goes only to that destination. otherwise, the SNAcP makes a copy of the ISO-gram for each of the SNPA-addresses in the cache, which is how you get a broadcast to all participating systems 📡 before handing the ISO-gram down to the IP subnet layer, the SNAcP prepends an SNAcP header to each outgoing ISO-gram.
this header takes the form:
SNAcP Header Format
Octet Value Meaning
--------------------------------------------------------
1 01 Version number
--------------------------------------------------------
2 Semantics of address:
00 Not a multicast address
01 All ESs
02 All ISs
03 Broadcast
--------------------------------------------------------
3,4 OSI checksum as defined in ISO 8473the SNAcP header has three fields: a version number field, a semantics field, and a checksum field 🧁 the version number is always 01. the checksum field holds the two octet ISO (Fletcher) checksum of the SNAcP header, and the checksum algorithm is described in ISO 8473.
the semantics field takes one of 4 values, meaning "all ESs", "all ISs", "broadcast", or "not a multicast address" 💖 which one you get is decided by a parameter the calling OSI network entity passes to the SNAcP. and if you're a participant testing the OSI network layer over a set of point-to-point links, you can just skip the multicast capabilities the SNAcP provides on the outgoing path 🌈
on the incoming path, the SNAcP looks at the SNAcP header and decides whether to accept the ISO-gram 👀 if it accepts, it strips off the SNAcP header and passes the ISO-gram up to the OSI CLNL. if not, it throws the ISO-gram away 🗑️ the SNAcP always accepts ISO-grams whose headers say "not a multicast address" (value zero in the semantics field) or "broadcast" (value 03). for the two multicast groups, "all ESs" (value 1) and "all ISs" (value 2), it depends on local configuration information. if the system is configured as an end system, it accepts ISO-grams destined for "all ESs", and if it's configured as an intermediate system, it accepts ISO-grams destined for "all ISs" 🙈
a participant testing the OSI network layer over point-to-point links accepts ISO-grams under these same rules, bestie 🫶
someone considered making the SNAcP extensible by turning the semantics and checksum fields into variable-length parameters, the way ISO 8473 does. but the team feels the version number already gives enough extensibility 🦋
Errors on the IP subnet
okay this bit is about ICMP messages 🙈 the IP subnet layer may receive ICMP messages and may pass error indications up to the SNAcP layer because of them. in this context, the IP subnet is assumed to handle ICMP messages the same way it does in any other context ✨ for example, when it gets an ICMP echo message, it responds with an ICMP echo reply, and the SNAcP doesn't need to be told about the echo message at all. certain ICMP messages, like source quench, are likely to produce an error indication for every layer using the IP subnet 😭 what the SNAcP does with these indications is purely a local matter, but the following actions are suggested 💅
Suggested SNAcP Actions in Response to
ICMP-related Error Indications
ICMP message type Action taken by the SNAcP
-----------------------------------------------------------
Destination unreachable, If the remote address is present
Parameter problem, in the cache of core systems'
Time exceeded addresses, mark it unusable.
Inform network management.
-----------------------------------------------------------
Source quench If the remote address is present
in the cache of core systems'
addresses, mark the remote
address as unusable and set a
timer for a time after which
the address becomes usable
again.
Inform network management.
-----------------------------------------------------------
All others Ignored by the SNAcP layer."inform network management" can mean a bunch of things 🎀 printing a message on the system console, telling a local process, incrementing a counter, writing a message in a log file, or literally doing nothing 🤷♀️
marking a cached address as unusable has these effects. when the SNAcP tries to broadcast or multicast an ISO-gram, any cached addresses marked unusable get skipped 🙅♀️ when the SNAcP tries to send a non-multicast ISO-gram to an unusable cached address, it returns an error indication to the OSI CLNL. so when the OSI CLNL is using the SNAcP to simulate point-to-point links, it gets told when a link fails 💔 but when it's using the SNAcP to simulate a multicast subnet, it does not get told when one system on the subnet goes down 🌙
Use of UDP/IP in Lieu of IP ✨
okay so, plot twist 🌸 for testing purposes it can be super useful to run the OSI CLNL over the User Datagram Protocol (UDP) too, not just straight IP 🦋. why? because some implementors don't have direct access to IP, but they DO have access to UDP. like, an implementor might have a binary license for an operating system that gives them TCP/IP and UDP/IP, but no direct IP access 😭. those folks can join a parallel experiment called EON-UDP by using UDP/IP as a subnetwork instead of the IP subnet 💜.
in this case the OSI NPDU (after fragmentation, if that applies) gets placed in the data portion of a UDP datagram. the UDP port is 147 (decimal) 🎀, which has been assigned for exactly this purpose. these participants put an SNAcP between UDP and ISO 8473 instead of between IP and ISO 8473. in every other respect, EON-UDP is identical to EON ✨
of course, network layer entities on the UDP/IP subnet won't interoperate directly with network layer entities on the IP subnet 🙈. the procedures in this memo don't stop an implementor from building an EON to EON-UDP gateway, but the issues around building and routing to such a gateway aren't addressed here. this memo simply proposes two distinct parallel experiments for two groups of experimenters with different resources 🫶.
the preferred way to experiment is the IP subnet, aka EON. EON-UDP is intended only for those who can't participate in EON 💅.
Dissemination of Topological Information and Host Names 🗺️
so the EON experiment simulates a logical topology that is not as connected as the underlying logical topology the Internet offers 🌈. the topology of the IP subnet is, in effect, simulated by the SNAcP layer in each of the core systems. each core system caches a list of the other core systems in the EON 💖. when a system boots, it needs some initial list of the participating core systems, which is why the IANA will maintain a list of core systems 👑.
the IANA will also maintain a list of all participating ESs. this list isn't needed for the EON network layer to function. it's a convenience for the experimenters, meant for application layer software or human users 🧚.
there are two pairs of lists, one pair for the EON and one for EON-UDP 🍓:
core.EON: this is a list of SNPA-addresses of those systems that will be (logically) reachable via the IP subnet in one ISO 8473-hop from any other core system. this does NOT mean the systems in this file are gateways or ISs. they may be ESs, ISs, or both. a site may participate as a core system before its address is included in this file and distributed to other core systems, but in that case other core systems won't know to send configuration messages (ESHs and ISHs) to the new site when it comes up or reboots 😬. the SNPA-addresses in this file are ASCII strings of the form A.B.C.D, no more than one per line. white space (tabs, blanks) is optional before A and after D. a pound-sign (#) marks the start of a comment, meaning it and everything after it on that line is ignored. for example:
128.105.2.153 # bounty.cs.wisc.educore.EON-UDP: this is the equivalent ofcore.EONfor use with the UDP/IP subnet. the format is the same ascore.EON.hosts.EON: this is a list of the ASCII host names of all end systems participating in the IP subnet experiment, one host name per line. it isn't used by the OSI CLNL.hosts.EON-UDP: this is a list of the ASCII host names of all end systems participating in the UDP/IP subnet experiment, one host name per line. it's meant for the use of applications. it isn't used by the OSI CLNL.
the files will be available from the IANA via anonymous ftp 📂. sites that want to join the experimental OSI internet have to get their host names and core system addresses added to the appropriate files. to do that, they send requests to Joyce K. Reynolds at the email address JKREY@ISI.EDU 💌.
Hypothetical EON Topology 🧩
okay picture this, it's giving hypothetical world-building 🌍. Figure 1 shows the logical links in a hypothetical topology where three university computer science departments are in the experiment: the University of Wisconsin (U of W), the University of Tudor (U of Tudor), and the University of Fordor (U of Fordor) 🎓.
the U of W has two local area networks (LANs), 128.105.4 and 128.105.2, plus four systems acting as ESs in the experiment. two systems are attached to both LANs, but only one of those two is forwarding ISO-grams (aka acting as an IS) 🔥. the U of Tudor has only one participating system, and it's acting as an ES 🦋. the U of Fordor has two systems in the experiment: one is an IS only, and the other is an ES only 💜.
the contents of the core.EON and hosts.EON files for this topology look like this:
#
# core.EON for hypothetical EON topology
#
128.105.2.153 # IS/ES in cs.wisc.edu
26.5.0.73 # ES in cs.tudor.edu
192.5.2.1 # IS in cs.fordor.edu
#
# hosts.EON hypothetical EON topology
#
128.105.4.150 # ES in cs.wisc.edu
128.105.2.150 # same as above : multihomed ES
128.105.4.154 # ES in cs.wisc.edu
128.105.4.151 # ES in cs.wisc.edu
128.105.2.153 # IS/ES in cs.wisc.edu
26.5.0.73 # ES in cs.tudor.edu
192.5.2.2 # ES in cs.fordor.eduand here's the vibe check, Figure 1 🎀:
______U of WI (128.105)______
( )
( 128.105.4 )
( | ) _U of Tudor__
( | 128.105.2.150 ) ( )
( | 128.105.4.150 ) ( )
( |------ES-----------| ) ( ES )
( | | ) ( 26.5.0.73 )
( | | ) ( | )
( | | ) (___|_________)
( | | ) |
( | | ) -------------
( |---ES | ) _|_
( | 128.105.4.154 | ) ( )
( | | ) ( )
( | | ) ( IP )
( | |----------( subnet )
( | | ) ( )
( | | ) ( )
( | | ) (___)
( |---ES | ) |
( | 128.105.4.151 | ) -------------
( | | ) |
( | | ) _U of Fordor_
( | | ) ( | )
( |---IS/ES-----------| ) ( | )
( 128.105.2.153 | ) ( IS )
( 128.105.4.153 | ) ( 192.5.2.1 )
( | ) ( | )
( | ) ( | )
( 128.105.2 ) ( ES )
( ) ( 192.5.2.2 )
(_____________________________) (_____________)Figure 1: Hypothetical EON Topology 🌸
the U of Fordor system 192.5.2.1 can, on top of acting as an IS, start acting as an ES at any time 🔁. it does that by joining the ES-IS protocol as an ES and by starting to serve a set of NSAPs. it can act as an ES, as an IS, or as both. in fact, the U of Fordor systems 192.5.2.1 and 192.5.2.2 could swap roles at any time, regardless of their physical connectivity to the Internet, just by changing how they use the ES-IS protocol and whether they serve NSAPs 🦋.
say these two systems do swap roles: 192.5.2.1 becomes an ES and not a core system, and 192.5.2.2 becomes a core system and an IS 👀. now say the experimenters at U of Fordor don't tell the IANA about the change right away, so core.EON is out-of-date for a while. other core systems will keep sending configuration messages to 192.5.2.1, which will respond as an ES and not as an IS. it'll look like 192.5.2.2 can't be reached from the rest of the topology, because the other core systems won't know to send configuration information to it 😭. but when 192.5.2.2 boots, it sends configuration messages to all core systems to tell them it exists, via the IS-IS protocol. the core systems acting as ISs respond with their configuration messages and update their core system caches, which sets up a set of logical links between 192.5.2.2 and the rest of the core systems ✨💅.
Relationship of this Memo to other RFCs 🔗
RFCs 1006 and 983
ISO Transport Services on top of the TCP 🚀. RFCs 1006 and 983 offer a way to run the OSI session layer protocol and higher OSI layers over TCP/IP. this memo, on the other hand, offers a way to run the OSI network and transport layers on an IP internetwork 💖.
RFC 1069
this one is about guidelines for using Internet-IP addresses in the ISO Connectionless-Mode Network Protocol 🧠. RFC 1069 suggests a method to use the existing Internet routing and addressing in a gateway that forwards ISO connectionless network layer protocol datagrams. this memo, in contrast, suggests a method to use the ISO routing and addressing in a gateway that forwards ISO connectionless network layer protocol datagrams 🌈.
RFC 982
ANSI Working Document X3S3.3/85-258 📄. it's a set of guidelines for specifying the structure of the DSP part of an ISO address. the addresses described in this memo meet the guidelines set forth in RFC 982 🎀.
References 📚
Plummer, D., "An Ethernet Address Resolution Protocol - or - Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", RFC 826, MIT, November 1982.
Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse Address Resolution Protocol", RFC 903, Stanford, June 1984.
Postel, J., "Internet Protocol - DARPA Internet Program Protocol Specification", RFC 791, DARPA, September 1981.
Postel, J., "Internet Control Message Protocol - DARPA Internet Program Protocol Specification", RFC 792, ISI, September 1981.
Postel, J., "User Datagram Protocol", RFC 768, ISI, August 1980.
ISO, "Protocol For Providing the Connectionless Mode Network Service", (ISO 8473), March 1986. (This is also published as RFC 994.)
ISO, "End System to Intermediate System Routing Exchange Protocol for Use in Conjunction with the Protocol for the Provision of the Connectionless-mode Network Service (ISO 8473)", (ISO DP 9542). (This is also published as RFC 995.)
ISO, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol", (ISO TC 97/SC 6/N xxxx).
OSI, "OSI Routing Framework", (PD TR 97/SC 6/N 9575).
Authors' Addresses 💌
okay bestie, here are the three authors and how to reach each of them 🎀 they literally wrote the thing, so these are your people 💅
Robert A. Hagens
Computer Sciences Department
University of Wisconsin - Madison
1210 West Dayton Street
Madison, WI 53706
608/ 262-1017
EMail: hagens@cs.wisc.edu Nancy E. Hall
Computer Sciences Department
University of Wisconsin - Madison
1210 West Dayton Street
Madison, WI 53706
608/ 262-5945
EMail: nhall@cs.wisc.edu Marshall T. Rose
The Wollongong Group
San Antonio Blvd.
Palo Alto, California
415/ 962-7100
Email: mrose@twg.comComments and Suggestions 🫶
bestie, if you have comments or suggestions ✨ or you're feeling that "I want in!" energy and wanna participate, please send it all straight to the authors 💖 they're the ones who want to hear from you 🦋
📦 where this page comes from
- ietf: rfc1070 1989-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms