From owner-Big-Internet@munnari.OZ.AU Sat Oct 8 03:25:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29316; Sat, 8 Oct 1994 03:25:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA29179; Sat, 8 Oct 1994 03:22:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29174; Sat, 8 Oct 1994 03:16:36 +1000 Precedence: list Received: from ecua.net.ec by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28964; Sat, 8 Oct 1994 03:16:21 +1000 (from rhuerta@ecua.net.ec) Received: by ecua.net.ec (AIX 3.2/UCB 5.64/4.04) id AA13427; Fri, 7 Oct 1994 12:16:30 -0500 X-Nupop-Charset: English Date: Fri, 7 Oct 1994 12:17:23 -0500 (EST) From: "Dr. Ricardo Huerta" Sender: rhuerta@ECUA.NET.EC Reply-To: rhuerta@ECUA.NET.EC Message-Id: <44254.rhuerta@intersea.com.ec> To: mpvecchi@twcable.com Cc: big-internet@munnari.OZ.AU Subject: Fw: HELP: NEED INFORMATION ABOUT " NETWORKING OVER CATV " ------------------------------ Subject: HELP: NEED INFORMATION ABOUT " NETWORKING OVER CATV " I'm from Guayaquil, Ecuador. My name is Fernando Sanchez Pulley, I'm a Computer Science student in my senior year, and my term paper prior to my graduation is about " NETWORKING OVER CATV " . I need help to obtain information about it, and I'd like you tell me where to look for it or if you can provide me some information about how to implement a Network over our CABLE TELEVISION SYSTEM (RG-59). My Internet address is rhuerta@ecua.net.ec Thanks and Regards, FERNANDO SANCHEZ PULLEY. From owner-Big-Internet@munnari.OZ.AU Sat Oct 8 07:48:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03505; Sat, 8 Oct 1994 05:22:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA29317; Sat, 8 Oct 1994 05:22:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29300; Sat, 8 Oct 1994 05:09:36 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03163; Sat, 8 Oct 1994 05:09:13 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA13038; Fri, 7 Oct 1994 12:07:59 -0700 Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="========================_10246246==_" Date: Fri, 7 Oct 1994 12:08:02 -0700 To: kre@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU --========================_10246246==_ Content-Type: text/plain; charset="us-ascii" I had a homework assignment from the EID BOF. The attached represents an initial proposal for accomplishing most of the required mobility and robustness using a transport-level mechanism, with no changes to IP (v4 or v6). I'll note that a truly complete mobility mechanism needs what is described in the attached AND: 1. Link-level mobility when the change is extremeley frequent and local 2. An ICMP "call forwarding" response, when the host's home network knows to send callers (and, yes, this is a change to IP, but along the lines of an ICMP Redirect, sortof.) 3. Dynamic update of data in the DNS (already in the works) Comments eagerly sought, of course. I'm aware of at least one other proposal that is related in spirit to the attached, but claiming to be lighter weight. It will emerge as the other author's schedule permits. Dave --========================_10246246==_ Content-Type: text/plain; name="TCN.spec.txt"; charset="us-ascii" Content-Disposition: attachment; filename="TCN.spec.txt" Internet Draft Transport Context Names August, 1994 D. Crocker [Page ] Network Working Group D. Crocker Internet Draft: Brandenburg Consulting DRAFT-CROCKER-TCN-00.{txt,ps} Expiration <2/75> Transport Context Names (TCN): Concepts and Facilities STATUS OF THIS MEMO This is a preliminary draft document, intended for eventual submission to the IETF working group process. At this stage, the document should be viewed strictly as a think-piece, with comments, corrections, etc. eagerly sought. This document is an Internet Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its Working Groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet- Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress." IETF Information is available by anonymous FTP from several Internet sites. Please check the 1id-abstracts.txt listing to learn the current status of any Internet Draft. SUMMARY When using the Internet protocol suite, processes communicate via transport associations, such as TCP connections; these define end- to-end communication relationships, or contexts, between the processes. Enhanced services, such as for host and service mobility and failure recovery, can be facilitated by distinguishing a transport association from the underlying network service(s) it uses. This distinction will allow re- locating one or both ends of the context, while maintaining a consistent and unique reference to that context, independent of its network connectivity. This proposal suggests using a combination of domain names, port numbers and protocol identifiers to define transport associations, and then using control channels between hosts for adding and removing network "channel" specifications to the associations. This document is a description of the proposed facility, rather than a complete specification. It is intended to convey the concepts and style of the proposed mechanism, saving the joy of formats for later. TABLE OF CONTENTS 1. Introduction 2. Transport context names 3. Transport context channel list management 4. Use of tcns by transport services 5. Example 6. Discussion 7. References 8. Security considerations 9. Acknowledgments 10. Contact 1. INTRODUCTION When using the Internet protocol suite processes communicate via transport associations, such as TCP connections; these define end- to-end communication relationships, or contexts, between the processes. For TCP, the context name is called a "connection identifier" and is defined by the source and destination IP addresses and the source and destination port numbers. [TCP] Implicit is the IP protocol value identifying TCP, itself. Identifying a connection in this fashion ties it to a particular IP address pair for the life of the connection. Since IP addresses identify particular host interfaces, this means that all datagrams for the connection must go through the same interfaces. Generally they also will go through the same intermediate routers, since routes tend to be quite stable. When a route becomes unavailable, routing protocols usually require significant time before establishing an alternate. While TCP is persistent and will succeed at sending its data after a network delay, some applications have performance requirements which need quicker recovery from failures. An IP (interface) address specifies the network and subnetwork to which the host is attached. Many forms of host mobility cause the host to be attached to different parts of the communication fabric at different times. For management and scaling, it can be quite helpful for hosts to have different IP addresses according the particular part of the fabric to which they are attached. Because a TCP connection id is tied to particular IP addresses, this means that the connection cannot survive such IP address transitions. This proposal suggests that enhanced services, such as for host and service mobility and failure recovery, can be facilitated by distinguishing a transport association from the underlying network service(s) it uses. This distinction will allow re- locating one or both ends of the context, while maintaining a consistent and unique reference to that context, independent of its network connectivity. Further, it allows using multiple network interfaces as part of the same association, so that a problem through one interface can lead to quick retransmission through one of the alternates. This proposal suggests using a combination of domain name, port number and protocol identifier to define transport associations, and then using control channels between hosts for adding and removing network "channel" specifications to the associations. This scheme supports enhanced functionality as incremental upgrades to end-system nodes, rather than as changes to the internetwork infrastructure. 2. TRANSPORT CONTEXT NAMES A Transport Context Name (TCN) is a globally unique reference to the communication context and is labeled by the tuple: where: Transport service specifies the transport protocol, such as UDP or TCP; Source host domain name specifies a globally unique reference to the machine or service hosting the one end of the transport context, and Destination host domain name specifies the other end. Source transport id specifies the transport association identifier used by the source, such as the TCP source port number Destination transport id specifies the identifier used by the destination. It is important to realize that a surprising opportunity with this naming scheme is to permit a transport service to operate a single interprocess transport association, such as a single TCP connection, over a range of different network protocols, as well as over a range of network "channels". Associated with a transport context name is a list of one or more network-dependent "channel" references, such as IP address pairs. A Transport Context Channel (TCC) defines a specific means of conveying transport data between hosts and may then be used by the transport service for alternate transmission choices, to improve recovery from delivery interruptions. It is labeled by the tuple: where Network protocol specifies the network-level protocol to be used for this channel, Source network host identifier specifies a network access identifier, such as IP address, for one host using the network protocol, Destination network host identifier specifies the other network access identifier. A Transport Context Channel List (TCCL) comprises a TCN and a set of one or more TCCs. It defines the choices that a transport association has when deciding how to send a segment of data. The list may be modified over the course of the context, to permit changing attachment to the Internet, such as for host mobility. (It may well also be useful to permit processes to migrate from one host to another -- assuming that the hosts cooperate among themselves to coordinate the local transfer of the process context.) When an TCCL contains more than one network channel specification, the transport may choose to send portions of traffic over different channels. While this may result in increased throughput, its primary benefit is to maintain knowledge about the utility of each channel. When one ceases to provide adequate performance, the transport may simply mark it as disabled and then send traffic over the remaining network channels. 3. TRANSPORT CONTEXT CHANNEL LIST MANAGEMENT A TCCL may be defined before or during a particular transport context. Using public domain names, such as from the domain name service, and the set of network addresses publicly listed, a host may build a TCCL prior to initiating a specific transport context. Alternatively, a host may choose to build a TCCL from an existing context. In this case of derived use, one of the hosts participating in an existing transport context initials a control channel exchange starting with the existing transport context channel, adding a transport context name and, possibly, other TCCs. A control channel operates between hosts, rather than processes. It needs to have a means of authenticating both participants, particularly since this service permits moving contexts to different addresses. Generally, the protocol is likely to be relatively simple, requiring commands roughly to do simple manipulations of TCC entries on a transport context channel list. For example: create (TCN, TCC) add (TCN, TCC) delete (TCN, TCC) list (TCN) It's periodic nature suggests that a simple transaction protocol will suffice, such as over UDP. 4. USE OF TCNS BY TRANSPORT SERVICES While actual implementations may behave in a far more integrated fashion, the model for transport/network interactions has a transport service build a transport segment and then pass it to the network service for additional handling. Use of a transport context channel model requires inserting an extra decision process prior to passing the segment down to the network service, since the transport must decide which of listed network channels should be used. In order to keep information about channel behavior, a transport service might do round-robin use of the available set. When a segment needs to be retransmitted, the transport service might choose to send it over a different channel that was initially used. Given the complexity and sensitivity of retransmission algorithms, this will require research. For transport services, like TCP's use of the pseudo-header, that integrate information about the network layer into the transport protocol, re-definition of the calculations need to account for the variability in network-layer headers. 5. EXAMPLE HOST: STABLE.ORG HOST: MOBILE.ORG (IP address: 192.254.254.1) (IP address: 192.253.253.1) TCP SYN (192.254.254.1, -> 192.253.253.1, 2345,25) ...Normal TCP session activity ... <- CONTROL CHANNEL: CREATE (TCP, mobile.org, stable.org, 192.253.253.1, 192.254.254.1, 25, 2345) CONTROL CHANNEL: -> CREATE (TCP, stable.org, mobile.org, 192.254.254.1, 192.253.253.1, 25, 2345) ...More TCP session activity... (Host mobile.org moves to location with overlapping service) <- CONTROL CHANNEL: ADD (TCP, mobile.org, stable.org, 192.253.253.2, 192.254.254.1, 25, 2345) CONTROL CHANNEL: -> ADD (TCP, mobile.org, stable.org, 192.254.254.1, 192.253.253.2, 2345, 25) ... Sending TCP data now requires choice of ... channel, either (192.253.253.1, 192.254.254.1) or (192.253.253.2, 192.254.254.1) (Host mobile.org moves fully into second service area) <- CONTROL CHANNEL: DELETE (TCP, mobile.org, stable.org, 192.253.253.1, 192.254.254.1, 25, 2345) ... Sending TCP data now requires use only of ... channel (192.253.253.2, 192.254.254.1) 6. DISCUSSION This proposal seeks to provide a layered facility for enhancing certain characteristics of Internet service. It proposes a mechanism which involves no changes in existing packet formats and which permits unmodified systems to continue to function as they do today if they do not need the new services. Further, it explicitly seeks to avoid changing the Internet infrastructure, preferring instead to allow incremental adoption by participating hosts. The facility will support a high degree of host mobility and will permit connections with high degrees of robustness to isolated network outages, when an alternate path is already available. The Internet Protocol is the foundation for Internet services. It is generally regarded as satisfying the competing pressures of being as simple as possible and as robust as necessary. Operation of the Internet is extremely efficient and difficult. This proposal seeks to retain the simplicity and robustness of that service in the hope that its operation is not perturbed unnecessarily, seeking instead to layer important -- but new and specialized -- services outside of the core Internet Protocol operation. Mobility requires a number of changes to Internet service components. For highly localized mobility, underlying media services need to make the changes transparent. For longer-term, longer-distance mobility, the domain name service needs to support dynamic registration of address changes. IP addresses pertain to host location within the topology of the Internet. Mobility is, by its definition, the process of changing that location. This should naturally cause a host's IP address to change. The proposal described here supports these changes naturally during the lifetime of a transport context. 7. REFERENCES [TCP] 8. SECURITY CONSIDERATIONS This proposal describes a control channel between host-pairs, used to assign channels for data transfer. Unauthorized use of this channel could cause a transport association, such as a TCP connection, to be redirected to an inappropriate host. For most current host exchanges, careful attention to the chain of channel directives should give the recipient as much basis for 9. ACKNOWLEDGMENTS 10. CONTACT David H. Crocker Brandendburg Consulting 675 Spruce Dr. Sunnyvale, CA 94086 Phone: +1 408 246 8253 Fax: +1 408 249 6205 --========================_10246246==_ Content-Type: application/PostScript; name="TCN.spec.ps" ; x-mac-type="54455854" ; x-mac-creator="4D505320" Content-Disposition: attachment; filename="TCN.spec.ps" Content-Transfer-Encoding: base64 JSFQUy1BZG9iZS0yLjANJSVUaXRsZTogVENOLnNwZWMNJSVDcmVhdG9yOiBNaWNyb3Nv ZnQgV29yZA0lJUNyZWF0aW9uRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDcsIDE5OTQNJSVQ YWdlczogKGF0ZW5kKQ0lJUJvdW5kaW5nQm94OiA/ID8gPyA/DSUlUGFnZUJvdW5kaW5n Qm94OiAzMCAzMSA1ODIgNzYxDSUlRm9yOiBkY3JvY2tlcg0lJURvY3VtZW50UHJvY1Nl dHM6ICIoQXBwbGVEaWN0IG1kKSIgNzEgMA0lJSCpIENvcHlyaWdodCBBcHBsZSBDb21w dXRlciwgSW5jLiAxOTg5LTkyIEFsbCBSaWdodHMgUmVzZXJ2ZWQuDSUlRW5kQ29tbWVu dHMNJSVCZWdpblByb2NTZXQ6ICIoQXBwbGVEaWN0IG1kKSIgNzEgMA11c2VyZGljdC9E Y2hlY2tsb2FkIDIgY29weSBrbm93bntwb3AgcG9wfQ0ge3t7cG9wIGV4ZWN9e3NhdmUg MyBkaWN0IGJlZ2luL3JiIDYwNTAgc3RyaW5nIGRlZiBleGNoIC9lcyBleGNoIGRlZg0g ZXJyb3JkaWN0L3JhbmdlY2hlY2t7cG9wIGV4Y2ggcG9wIHRydWV9cHV0DSB7Y3VycmVu dGZpbGUgcmIgcmVhZGxpbmUgbm90e3N0b3B9aWYgZXMgZXF7ZXhpdH1pZn1sb29wIGVu ZCByZXN0b3JlIHBvcH0NIGlmZWxzZX1iaW5kIHB1dH1pZmVsc2UNe30gKCAlZW5kYXBw bGVkaWN0KSAlRE1NDS9kbWQ3MTAgd2hlcmUgZHVwe2V4Y2ggcG9wfWlmIG5vdCAlRE1N DURjaGVja2xvYWQNL3N0YXR1c2RpY3Qgd2hlcmV7cG9wfXt1c2VyZGljdCAvc3RhdHVz ZGljdCAxMCBkaWN0IHB1dH1pZmVsc2UgJURNTQ1zdGF0dXNkaWN0IGJlZ2luICVETU0N L3Byb2R1Y3Qgd2hlcmV7cG9wfXsvcHJvZHVjdCAoKSBkZWZ9aWZlbHNlICVETU0NL3Jl dmlzaW9uIHdoZXJle3BvcH17L3JldmlzaW9uIDAgZGVmfWlmZWxzZSAlRE1NDS92ZXJz aW9uIHdoZXJle3BvcH17L3ZlcnNpb24gKDApIGRlZn1pZmVsc2UgJURNTQ1lbmQgJURN TQ17ICVETU0NdXNlcmRpY3QvTFd7c2F2ZSBzdGF0dXNkaWN0L3Byb2R1Y3QgZ2V0KExh c2VyV3JpdGVyKWFuY2hvcnNlYXJjaA1leGNoIHBvcHtkdXAgbGVuZ3RoIDAgZXF7cG9w IDF9eyggUGx1cyllcXsyfXszfWlmZWxzZX1pZmVsc2V9ezB9aWZlbHNlIGV4Y2ggcmVz dG9yZX0NJURNTSBiaW5kDSBwdXQNdXNlcmRpY3QvcGF0Y2hPSyBrbm93biBub3R7DXN5 c3RlbWRpY3QgZHVwL2VleGVjIGtub3duIGV4Y2gvY2V4ZWMga25vd24gYW5kIGR1cHtw b3AgJURNTQ1zYXZlIExXIGR1cCAxIG5lIGV4Y2ggMiBuZSBhbmQgZmFsc2U8MTg2MUFF REFFMTE4QTlGOTVGMTYyOUMwMTM3RjhGRTY1NjgxMUREOTNERkJFQTY1RTk0NzUwMkU3 OEJBMTIyODRCOEE1OEVGMEEzDTJFMjcyNzc4REFBMkFCRUM3MkE4NDEwMkQ1OTFFMTFE OTZCQTYxRjU3ODc3Qjg5NUE3NTJEOUJFQUFDM0RGRDdEMzIyMEUyQkRFN0MwMzY0Njc0 NjRFMEU4MzY3NDhGMURFN0FCNjIxNjg2NkYxMzBDRTdDRkNFQzhDRTA1MEI4NzBDMTE4 ODFFRTNFOUQ3MDkxOT57ZWV4ZWN9c3RvcHBlZHtkdXAgdHlwZS9zdHJpbmd0eXBlIGVx e3BvcH1pZn1pZiBhbmQgZXhjaCByZXN0b3JlDX1pZiVETU0NdXNlcmRpY3QvcGF0Y2hP SyAzIC0xIHJvbGwgcHV0fSBpZg0lRE1NIHVzZXJkaWN0L2Rvd25sb2FkT0sga25vd24g bm90ew11c2VyZGljdC9kb3dubG9hZE9Le3Ztc3RhdHVzIGV4Y2ggc3ViIGV4Y2ggcG9w IDEyMDAwMCBndCBwYXRjaE9LIGFuZH0NJURNTSBiaW5kDSBwdXQNJURNTSB9aWYNJURN TSB1c2VyZGljdC90eXBlNDJrbm93biBrbm93biBub3R7DXVzZXJkaWN0L3R5cGU0Mmtu b3duIHN5c3RlbWRpY3QvcmVzb3VyY2VzdGF0dXMga25vd257NDIvRm9udFR5cGUgcmVz b3VyY2VzdGF0dXN7cG9wIHBvcCB0cnVlfXtmYWxzZX1pZmVsc2UgfXtmYWxzZX1pZmVs c2UgcHV0DSVETU0gfWlmDXR5cGU0Mmtub3duIG5vdCBkb3dubG9hZE9LIGFuZA0gdXNl cmRpY3QvKmNoYXJwYXRoIGtub3duIG5vdCBhbmQgJURNTQ0ge3VzZXJkaWN0IGJlZ2lu IC8qY2hhcnBhdGggL2NoYXJwYXRoIGxvYWQgZGVmL2NoYXJwYXRoZmxhZyBmYWxzZSBk ZWYvY2hhcnBhdGh7dXNlcmRpY3QvY2hhcnBhdGhmbGFnIHRydWUgcHV0IHVzZXJkaWN0 LypjaGFycGF0aCBnZXQgZXhlYyB1c2VyZGljdC9jaGFycGF0aGZsYWcgZmFsc2UgcHV0 fQ0lRE1NIGJpbmQNIGRlZiBlbmR9aWYNJURNTSB1c2VyZGljdC9jaGVja2xvYWQga25v d24gbm90ew11c2VyZGljdC9jaGVja2xvYWR7e3BvcCBleGVjfSB7c2F2ZSAzIGRpY3Qg YmVnaW4vbXlzdHJpbmcgNjA1MCBzdHJpbmcgZGVmDWVycm9yZGljdC9yYW5nZWNoZWNr e3BvcCBleGNoIHBvcCB0cnVlfXB1dCAlRE1NDWV4Y2gvZW5kc3RyaW5nIGV4Y2ggZGVm e2N1cnJlbnRmaWxlIG15c3RyaW5nIHJlYWRsaW5lIG5vdHtzdG9wfWlmIGVuZHN0cmlu ZyBlcXtleGl0fWlmfWxvb3AgZW5kIHJlc3RvcmUgcG9wfWlmZWxzZX0NJURNTSBiaW5k DSBwdXQNJURNTSB9aWYNdXNlcmRpY3QvTFcre0xXIDIgZXF9DSVETU0gYmluZA0gcHV0 DSVETU0gdXNlcmRpY3Qvb2sga25vd24gbm90ew11c2VyZGljdC9va3tzeXN0ZW1kaWN0 L3N0YXR1c2RpY3Qga25vd24gZHVwe0xXIDAgZ3QgYW5kfWlmfQ0lRE1NIGJpbmQNIHB1 dA0lRE1NIH1pZg1zeXN0ZW1kaWN0L3NldG9iamVjdGZvcm1hdCBrbm93bnswIHNldG9i amVjdGZvcm1hdH1pZg19IGJpbmQgJURNTQ1zeXN0ZW1kaWN0L2N1cnJlbnRwYWNraW5n IGtub3due2N1cnJlbnRwYWNraW5nDSBleGNoICVETU0NIHRydWUgc2V0cGFja2luZ31p Zg0vZG1kNzEwIDI3MiAlRE1NDSVETU0gL21kIDI3MA0gZGljdCBkZWYNIGRtZDcxMCAl RE1NDSVETU0gbWQNIGJlZ2luDWR1cCAvaW5pdHVkIGV4Y2ggZGVmIGV4ZWMgJURNTQ0v YXYgNzEgZGVmDS9UIHRydWUgZGVmL0YgZmFsc2UgZGVmL210eCBtYXRyaXggZGVmL3M3 NSA3NSBzdHJpbmcgZGVmL3NhOCA4IHN0cmluZyBkZWYvc2I4IDggc3RyaW5nIGRlZg0v c2NsIDEgZGVmICVETU0NL3NjOCA4IHN0cmluZyBkZWYvc2Q4IDggc3RyaW5nIGRlZi9z MSAoICkgZGVmL3B4cyAxIGRlZi9weXMgMSBkZWYNL25zIGZhbHNlIGRlZg0xIDAgbXR4 IGRlZmF1bHRtYXRyaXggZHRyYW5zZm9ybSBleGNoIGF0YW4vcGEgZXhjaCBkZWYvbmx3 IC4yNCBkZWYvcHByIFstMzIgLTI5LjUyIDc2MiA1ODIuNDhdIGRlZg0vcGdyIFswIDAg MCAwXSBkZWYNL3BncyAxIGRlZi9wb3IgdHJ1ZSBkZWYveGIgNTAwIGFycmF5IGRlZi9z byB0cnVlIGRlZi90c28gdHJ1ZSBkZWYvZmlsbGZsYWcgZmFsc2UgZGVmL3BubSAxIGRl Zi9mbXYgdHJ1ZSBkZWYNL3NmbCBmYWxzZSBkZWYvbWEgMCBkZWYvaW52ZXJ0ZmxhZyBm YWxzZSBkZWYvZGJpbnZlcnRmbGFnIGZhbHNlIGRlZi94ZmxpcCBmYWxzZSBkZWYveWZs aXAgZmFsc2UgZGVmL25vZmxpcHMgdHJ1ZSBkZWYvc2NhbGVieTk2IGZhbHNlIGRlZi9m Tm90ZSB0cnVlIGRlZi9mQml0U3RyZXRjaCB0cnVlIGRlZg0vNGNvbG9ycyBmYWxzZSBk ZWYvZmcgKFJ2ZFwwMDFcMDAxXDAwMFwwMDBcMTc3KSBkZWYNL2JkZntiaW5kIGRlZn1i aW5kIGRlZg0veGRme2V4Y2ggZGVmfWJkZg0veGx7bmVnIGV4Y2ggbmVnIHRyYW5zbGF0 ZX1iZGYNL2Zwe3Buc2ggMCBuZSBwbnN2IDAgbmUgYW5kfWJkZg0vbm9we31iZGYvbG5v cFsvbm9wIGxvYWRdY3Z4IGJkZg0vdnJiWw17ZnB7ZmcgNiBnZXQgMCBuZXtnc2F2ZSBz dHJva2UgZ3Jlc3RvcmV9e2dzYXZlIDEgc2V0bGluZXdpZHRoIHBuc2ggcG5zdiBzY2Fs ZSBzdHJva2UgZ3Jlc3RvcmV9aWZlbHNlfWlmIG5ld3BhdGh9YmluZA0vZW9maWxsIGxv YWQNZHVwDS9uZXdwYXRoIGxvYWQNMiBpbmRleA1kdXANe2NsaXAgbmV3cGF0aH1iaW5k DXt9YmluZA1kdXANMiBjb3B5DV1kZWYNL3NnZCBzeXN0ZW1kaWN0L3NldHBhZ2VkZXZp Y2Uga25vd257ezIgZGljdCBiZWdpbi9QcmVSZW5kZXJpbmdFbmhhbmNlIGV4Y2ggZGVm L1BvbGljaWVzIDEgZGljdCBkdXAvUHJlUmVuZGVyaW5nRW5oYW5jZSAxIHB1dCBkZWYg Y3VycmVudGRpY3QgZW5kIHNldHBhZ2VkZXZpY2V9fXt7cG9wfX1pZmVsc2UgYmRmDS9z dnNjIHN5c3RlbWRpY3QvY3VycmVudGNvbG9yc2NyZWVuIGtub3due3tjdXJyZW50Y29s b3JzY3JlZW4vZGtzcGYgeGRmL2Rrcm90IHhkZi9ka2ZyZXEgeGRmL2R5c3BmIHhkZi9k eXJvdCB4ZGYvZHlmcmVxIHhkZi9kbXNwZiB4ZGYvZG1yb3QgeGRmL2RtZnJlcSB4ZGYN L2Rjc3BmIHhkZi9kY3JvdCB4ZGYvZGNmcmVxIHhkZn19e3tjdXJyZW50c2NyZWVuL3Nw ZiB4ZGYvcm90IHhkZi9mcmVxIHhkZn19aWZlbHNlIGJkZg0vZG9vcHt2cmIgZXhjaCBn ZXQgZXhlY31iZGYNL3BzdXsvdWRmIHhkZi90c28geGRmIC9mTm90ZSB4ZGYvZkJpdFN0 cmV0Y2ggeGRmL3NjYWxlYnk5NiB4ZGYveWZsaXAgeGRmL3hmbGlwIHhkZg0vaW52ZXJ0 ZmxhZyB4ZGYvZGJpbnZlcnRmbGFnIGludmVydGZsYWcgc3RhdHVzZGljdCBiZWdpbiB2 ZXJzaW9uIGN2ciA0Ny4wIGdlIHByb2R1Y3QgKExhc2VyV3JpdGVyKSBlcSBub3QgYW5k IGVuZCBpbnZlcnRmbGFnIGFuZCB7bm90fWlmIGRlZg14ZmxpcCB5ZmxpcCBvcnsvbm9m bGlwcyBmYWxzZSBkZWZ9aWYNL3BncyB4ZGYgMiBpbmRleA0gZHVwIDEwMCBkaXYgL3Nj bCB4ZGYgJURNTQ0gLjcyIG11bCBleGNoIGRpdi9weXMgeGRmIGRpdiAuNzIgbXVsL3B4 cyB4ZGYgcHByIGFzdG9yZSBwb3AgcGdyIGFzdG9yZSBwb3AvcG9yIHhkZiBzbiBhbmQv c28geGRmfWJkZg0vdGFie3VzZXJkaWN0IC8xMXgxNyBrbm93bnt1c2VyZGljdCBiZWdp biAvMTF4MTcgbG9hZCBleGVjIGVuZH17c3RhdHVzZGljdCAvc2V0cGFnZSBrbm93bntz dGF0dXNkaWN0IGJlZ2luIDc5MiAxMjI0IDEgc2V0cGFnZSBlbmR9e3N0YXR1c2RpY3Qg L3NldHBhZ2VwYXJhbXMga25vd257c3RhdHVzZGljdCBiZWdpbiA3OTIgMTIyNCAwIDEg c2V0cGFnZXBhcmFtcyBlbmR9aWZ9aWZlbHNlfWlmZWxzZX1iZGYNL2EzU2l6ZXt1c2Vy ZGljdCAvYTMga25vd257dXNlcmRpY3QgYmVnaW4gL2EzIGxvYWQgZXhlYyBlbmR9e3N0 YXR1c2RpY3QgL3NldHBhZ2VwYXJhbXMga25vd257c3RhdHVzZGljdCBiZWdpbiA4NDIg MTE5MSAwIDEgc2V0cGFnZXBhcmFtcyBlbmR9aWZ9aWZlbHNlfWJkZg0vdHhwb3Nle2ZO b3Rle3NtYWxsc317Ymlnc31pZmVsc2UgcGdzIGdldCBleGVjIHB4cyBweXMgc2NhbGUg cHByIGFsb2FkIHBvcCBwb3J7bm9mbGlwc3twb3AgZXhjaCBuZWcgZXhjaCB0cmFuc2xh dGUgcG9wIDEgLTEgc2NhbGV9aWYNeGZsaXAgeWZsaXAgYW5ke3BvcCBleGNoIG5lZyBl eGNoIHRyYW5zbGF0ZSAxODAgcm90YXRlIDEgLTEgc2NhbGUgcHByIDMgZ2V0IHBwciAx IGdldCBuZWcgc3ViIG5lZyBwcHIgMiBnZXQgcHByIDAgZ2V0IG5lZyBzdWIgbmVnIHRy YW5zbGF0ZX1pZiANeGZsaXAgeWZsaXAgbm90IGFuZHtwb3AgZXhjaCBuZWcgZXhjaCB0 cmFuc2xhdGUgcG9wIDE4MCByb3RhdGUgcHByIDMgZ2V0IHBwciAxIGdldCBuZWcgc3Vi IG5lZyAwIHRyYW5zbGF0ZX1pZiB5ZmxpcCB4ZmxpcCBub3QgYW5ke3BwciAxIGdldCBu ZWcgcHByIDAgZ2V0IG5lZyB0cmFuc2xhdGV9aWZ9DXtub2ZsaXBze3RyYW5zbGF0ZSBw b3AgcG9wIDI3MCByb3RhdGUgMSAtMSBzY2FsZX1pZiB4ZmxpcCB5ZmxpcCBhbmR7dHJh bnNsYXRlIHBvcCBwb3AgOTAgcm90YXRlIDEgLTEgc2NhbGUgcHByIDMgZ2V0IHBwciAx IGdldCBuZWcgc3ViIG5lZyBwcHIgMiBnZXQgcHByIDAgZ2V0IG5lZyBzdWIgbmVnIHRy YW5zbGF0ZX1pZg14ZmxpcCB5ZmxpcCBub3QgYW5ke3RyYW5zbGF0ZSBwb3AgcG9wIDkw IHJvdGF0ZSBwcHIgMyBnZXQgcHByIDEgZ2V0IG5lZyBzdWIgbmVnIDAgdHJhbnNsYXRl fWlmIHlmbGlwIHhmbGlwIG5vdCBhbmR7dHJhbnNsYXRlIHBvcCBwb3AgMjcwIHJvdGF0 ZSBwcHIgMiBnZXQgcHByIDAgZ2V0IG5lZyBzdWIgbmVnIDAgZXhjaCB0cmFuc2xhdGV9 aWZ9aWZlbHNlDXN0YXR1c2RpY3QgYmVnaW4vd2FpdHRpbWVvdXQgd2hlcmV7cG9wIHdh aXR0aW1lb3V0IDMwMCBsdHtzdGF0dXNkaWN0L3dhaXR0aW1lb3V0IDMwMCBwdXR9aWZ9 aWYgZW5kIA1zY2FsZWJ5OTZ7cHByIGFsb2FkIHBvcCA0IC0xIHJvbGwgYWRkIDIgZGl2 IDMgMSByb2xsIGFkZCAyIGRpdiAyIGNvcHkgdHJhbnNsYXRlIC45NiBkdXAgc2NhbGUg bmVnIGV4Y2ggbmVnIGV4Y2ggdHJhbnNsYXRlfWlmfWJkZg0vZnJ7NCBjb3B5IHBnciBh bG9hZCBwb3AgMyAtMSByb2xsIGFkZCAzIDEgcm9sbCBleGNoIGFkZCA2IDIgcm9sbCAz IC0xIHJvbGwNc3ViIDMgMSByb2xsIGV4Y2ggc3ViIDMgLTEgcm9sbCBleGNoIGRpdiAz IDEgcm9sbCBkaXYgZXhjaCBzY2FsZSBwb3AgcG9wIHhsfWJkZg0vb2Jse3swLjIxMjU1 NyBtdWx9e3BvcCAwfWlmZWxzZX1iZGYNL3NmZHtwcyBmZyA1IC0xIHJvbGwgZ2V0IG11 bCAxMDAgZGl2IDAgcHMgNSAtMSByb2xsIG9ibCBwcyBuZWcgMCAwIDZhIGFzdG9yZSBt YWtlZm9udCBzZXRmb250fWJkZg0vZm50e2ZpbmRmb250IHNmZH1iZGYNL2J0e3NhIDMg MSByb2xsIDMgaW5kZXggYW5kIHB1dH1iZGYNL3NhKFwwMDBcMDAwXDAwMFwwMDBcMDAw XDAwMFwwMDBcMDAwXDAwMFwwMDApZGVmDS9mc3swIDEgYnQgMSAyIGJ0IDIgNCBidCAz IDggYnQgNCAxNiBidCA1IDMyIGJ0IDYgNjQgYnQgNyAxMjggYnQgc2EgZXhjaCA4IGV4 Y2ggcHV0fWJkZg0vbXgxIG1hdHJpeCBkZWYNL214MiBtYXRyaXggZGVmDS9teDMgbWF0 cml4IGRlZg0vYnV7Y3VycmVudHBvaW50IDRjb2xvcnN7Y3VycmVudGNteWtjb2xvcn17 Y3VycmVudHJnYmNvbG9yfWlmZWxzZSBjdXJyZW50bGluZXdpZHRoIGN1cnJlbnRsaW5l Y2FwIGN1cnJlbnRsaW5lam9pbiANY3VycmVudGRhc2ggZXhjaCBhbG9hZCBsZW5ndGgg ZmcgNSBzZmx7MX17MH1pZmVsc2UgcHV0IHBuc3YgcG5zaCANMnQgYWxvYWQgcG9wIDNh IGFsb2FkIHBvcCBteDIgYWxvYWQgcG9wIG14MSBhbG9hZCBwb3AgbXR4IGN1cnJlbnRt YXRyaXggYWxvYWQgcG9wDW14MyBhbG9hZCBwb3AgcHMgcG0gcmVzdG9yZS9wcyB4ZGYg bXgzIGFzdG9yZSBwb3B9YmRmDS9ibnsvcG0gc2F2ZSBkZWYgbXgzIHNldG1hdHJpeCBu ZXdwYXRoIDAgMCBtb3ZldG8gY3QgZHVwIDM5IGdldCAwIGV4Y2ggZ2V0aW50ZXJ2YWwg Y3Z4IGV4ZWMgbXR4IGFzdG9yZSBzZXRtYXRyaXggbXgxIGFzdG9yZSBwb3AgbXgyIGFz dG9yZSBwb3AgM2EgDWFzdG9yZSBwb3AgMnQgYXN0b3JlIHBvcC9wbnNoIHhkZi9wbnN2 IHhkZiBndw0vc2ZsIGZnIDUgZ2V0IDAgbmUgZGVmIGFycmF5IGFzdG9yZSBleGNoIHNl dGRhc2ggc2V0bGluZWpvaW4gc2V0bGluZWNhcCANc2V0bGluZXdpZHRoIDRjb2xvcnN7 bXlzZXRjbXlrY29sb3J9e3NldHJnYmNvbG9yfWlmZWxzZSBtb3ZldG99YmRmDS9mY3tz YXZlIHZtc3RhdHVzIGV4Y2ggc3ViIDUwMDAwIGx0DXsoJSVbfDB8XSUlKT1wcmludCBm bHVzaH1pZiBwb3AgcmVzdG9yZX1iZGYNL3RjezMyNzY4IGRpdiBhZGQgMyAxIHJvbGwg MzI3NjggZGl2IGFkZCAydCBhc3RvcmUgcG9wfWJkZg0vM2EgWzAgMCAwXSBkZWYNLzJ0 IDIgYXJyYXkgZGVmDS90cHszYSBhc3RvcmUgcG9wfWJkZg0vdHR7bXgyIGN1cnJlbnRt YXRyaXggcG9wIGN1cnJlbnRwb2ludCAyIGNvcHkgMnQgYWxvYWQgcG9wIHFhIDIgY29w eSB0cmFuc2xhdGUgM2EgYWxvYWQgcG9wIGV4Y2ggZHVwIDAgZXENe3BvcH17MSBlcXst MSAxfXsxIC0xfWlmZWxzZSBzY2FsZX1pZmVsc2Ugcm90YXRlIHBvcCBuZWcgZXhjaCBu ZWcgZXhjaCB0cmFuc2xhdGUgbW92ZXRvfWJkZg0vdGV7bXgyIHNldG1hdHJpeH1iZGYN L3RoezMgLTEgcm9sbCBkaXYgMyAxIHJvbGwgZXhjaCBkaXYgMiBjb3B5IG14MSBzY2Fs ZSBwb3Agc2NhbGUvc2ZsIHRydWUgZGVmfWJkZg0vdHV7MSAxIG14MSBpdHJhbnNmb3Jt IHNjYWxlL3NmbCBmYWxzZSBkZWZ9YmRmDS90c3sxIDEgbXgxIHRyYW5zZm9ybSBzY2Fs ZS9zZmwgdHJ1ZSBkZWZ9YmRmDS9mensvcHMgeGRmfWJkZg0vZHZ7ZHVwIDAgbmV7ZGl2 fXtwb3B9aWZlbHNlfWJkZg0vcG9wNHtwb3AgcG9wIHBvcCBwb3B9YmRmDS9pdHtzZmx7 bXgxIGl0cmFuc2Zvcm19aWZ9YmRmDS9nbXtleGNoIGl0IG1vdmV0b31iZGYvcm17aXQg cm1vdmV0b31iZGYNL2xte2N1cnJlbnRwb2ludCBzZmx7bXgxIHRyYW5zZm9ybX1pZiBl eGNoIHBvcCBzdWIgMCBleGNoIGl0IHJtb3ZldG99YmRmDS9mbXtzdGF0dXNkaWN0L21h bnVhbGZlZWQga25vd259YmRmDS9zZXtzdGF0dXNkaWN0IGV4Y2gvbWFudWFsZmVlZCBl eGNoIHB1dH1iZGYNL21me2R1cC9tYSBleGNoIGRlZiAwIGd0e2ZtIHNlL3QxIDUgc3Qg b2sgbWEgMSBndCBhbmR7L3QyIDAgc3QvdDMgMCBzdA1zdGF0dXNkaWN0L21hbnVhbGZl ZWR0aW1lb3V0IDM2MDAgcHV0DX1pZn1pZn1iZGYNL2puey9zdGF0dXNkaWN0IHdoZXJl IGV4Y2ggcG9we3N0YXR1c2RpY3QgZXhjaCAvam9ibmFtZSBleGNoIHB1dH1pZn1iZGYN L3Blbntwbm0gbXVsL3Buc2ggeGRmIHBubSBtdWwvcG5zdiB4ZGYgcG5zaCBzZXRsaW5l d2lkdGh9YmRmDS9taW57MiBjb3B5IGd0e2V4Y2h9aWYgcG9wfWJkZg0vbWF4ezIgY29w eSBsdHtleGNofWlmIHBvcH1iZGYNL2Roe2ZnIDYgMSBwdXQgYXJyYXkgYXN0b3JlIGR1 cCB7MSBweHMgZGl2IG11bA0gc2NsIG11bCAlRE1NDSBleGNofWZvcmFsbCBhc3RvcmUg ZXhjaCBwb3AgZXhjaCBwb3AgZXhjaCBzZXRkYXNofWJkZg0vaWhbY3VycmVudGRhc2hd ZGVmDS9yaHtmZyA2IDAgcHV0IGloIGFsb2FkIHBvcCBzZXRkYXNofWJkZg0vZGx7Z3Nh dmUgbmx3IHB5cyBkaXYgc2V0bGluZXdpZHRoIDAgc2V0Z3JheX1iZGYNL2RsaW57ZXhj aCBjdXJyZW50cG9pbnQgY3VycmVudGxpbmV3aWR0aCAyIGRpdiBkdXANdHJhbnNsYXRl IG5ld3BhdGggbW92ZXRvIGxpbmV0byBjdXJyZW50cG9pbnQgc3Ryb2tlIGdyZXN0b3Jl IG1vdmV0b31iZGYNL2xpbntmZyA2IGdldCAwIG5le2V4Y2ggbGluZXRvIGN1cnJlbnRw b2ludCAwIGRvb3AgbW92ZXRvfQ17ZXhjaCBjdXJyZW50cG9pbnQvcG5sdiB4ZGYvcG5s aCB4ZGYgZ3NhdmUgbmV3cGF0aC9AMSB4ZGYvQDIgeGRmIGZwe3BubGggQDIgbHR7cG5s diBAMSBnZQ17cG5saCBwbmx2IG1vdmV0byBAMiBAMSBsaW5ldG8gcG5zaCAwIHJsaW5l dG8NMCBwbnN2IHJsaW5ldG8gcG5saCBwbnNoIGFkZCBwbmx2IHBuc3YgYWRkIGxpbmV0 byBwbnNoIG5lZyAwIHJsaW5ldG99DXtwbmxoIHBubHYgbW92ZXRvIHBuc2ggMCBybGlu ZXRvIEAyIHBuc2ggYWRkIEAxIGxpbmV0byAwIHBuc3YgcmxpbmV0bw1wbnNoIG5lZyAw IHJsaW5ldG8gcG5saCBwbmx2IHBuc3YgYWRkIGxpbmV0b31pZmVsc2V9e3BubHYgQDEg Z3QNe0AyIEAxIG1vdmV0byBwbnNoIDAgcmxpbmV0byBwbmxoIHBuc2ggYWRkIHBubHYg bGluZXRvIDAgcG5zdiBybGluZXRvDXBuc2ggbmVnIDAgcmxpbmV0byBAMiBAMSBwbnN2 IGFkZCBsaW5ldG99e3BubGggcG5sdiBtb3ZldG8gcG5zaCAwIHJsaW5ldG8NMCBwbnN2 IHJsaW5ldG8gQDIgcG5zaCBhZGQgQDEgcG5zdiBhZGQgbGluZXRvIHBuc2ggbmVnIDAg cmxpbmV0bw0wIHBuc3YgbmVnIHJsaW5ldG99aWZlbHNlfWlmZWxzZQ1jbG9zZXBhdGgg ZmlsbH1pZiBAMiBAMSBncmVzdG9yZSBtb3ZldG99aWZlbHNlfWJkZg0vZ3d7L3BubSBm ZyAzIGdldCBmZyA0IGdldCBkaXYgZGVmfWJkZg0vbHd7ZmcgZXhjaCA0IGV4Y2ggcHV0 IGZnIGV4Y2ggMyBleGNoIHB1dCBndyBwbnN2IHBuc2ggcGVufWJkZg0vYmFyY3svQDEg eGRmL0AyIHhkZi9AMyB4ZGYvQDQgeGRmL0A1IHhkZg0vQDYgeGRmL0A3IHhkZi9AOCB4 ZGYgZ3NhdmUNQDUgQDcgYWRkIDIgZGl2IEA2IEA4IGFkZCAyIGRpdiB0cmFuc2xhdGUg bmV3cGF0aCAwIDAgbW92ZXRvDUA1IEA3IHN1YiBANiBAOCBzdWIgbXR4IGN1cnJlbnRt YXRyaXggcG9wIHNjYWxlIEAxe25ld3BhdGh9aWYNMCAwIDAuNSBANCBAMyBhcmMgQDQg QDMgc3ViIGFicyAzNjAgZ2V7Y2xvc2VwYXRofWlmDW10eCBzZXRtYXRyaXggQDIgZG9v cCBncmVzdG9yZX1iZGYNL2Fye2R1cCAwIGVxIGJhcmN9YmRmDS9vdnswIGV4Y2ggMzYw IGV4Y2ggdHJ1ZSBiYXJjfWJkZg0vcmN7ZHVwL0B0IHhkZiAwIGVxezQgY29weSAzIC0x IHJvbGwgZXEgMyAxIHJvbGwgZXEgYW5ke3Buc3YgMiBkaXYgc3ViIGV4Y2ggcG5zaCAy IGRpdiBzdWIgZXhjaCA0IDIgcm9sbCBwbnN2IDIgZGl2IGFkZCBleGNoIHBuc2ggMiBk aXYgYWRkIGV4Y2gNL0B0IDEgZGVmfWlmfWlmIGN1cnJlbnRwb2ludCA2IDIgcm9sbCBu ZXdwYXRoIDQgY29weSA0IDIgcm9sbCBleGNoIG1vdmV0byA2IC0xIHJvbGwgbGluZXRv IGxpbmV0byBsaW5ldG8gY2xvc2VwYXRoIEB0IGRvb3AgbW92ZXRvfWJkZg0vbXVwe2R1 cCBwbnNoIDIgZGl2IGxlIGV4Y2ggcG5zdiAyIGRpdiBsZSBvcn1iZGYNL3Jyey9AMSB4 ZGYgMi4gZGl2L0AyIHhkZiAyLiBkaXYvQDMgeGRmDS9ANCB4ZGYvQDUgeGRmL0A2IHhk Zi9ANyB4ZGYNQDcgQDUgZXEgQDYgQDQgZXEgQDIgbXVwIG9yIG9ye0A3IEA2IEA1IEA0 IEAxIHJjfQ17QDQgQDYgc3ViIDIuIGRpdiBkdXAgQDIgbHR7L0AyIHhkZn17cG9wfWlm ZWxzZQ1ANSBANyBzdWIgMi4gZGl2IGR1cCBAMiBsdHsvQDIgeGRmfXtwb3B9aWZlbHNl DUAxIDAgZXF7L0AyIEAyIHBuc2ggMiBkaXYgMiBjb3B5IGd0e3N1YiBkZWZ9ezAgcG9w NH1pZmVsc2V9aWYNY3VycmVudHBvaW50IG5ld3BhdGgNQDQgQDYgYWRkIDIuIGRpdiBA NyBtb3ZldG8NQDQgQDcgQDQgQDUgQDIgYXJjdG8gcG9wNA1ANCBANSBANiBANSBAMiBh cmN0byBwb3A0DUA2IEA1IEA2IEA3IEAyIGFyY3RvIHBvcDQNQDYgQDcgQDQgQDcgQDIg YXJjdG8gcG9wNA1jbG9zZXBhdGggQDEgZG9vcCBtb3ZldG99aWZlbHNlfWJkZg0vcHJ7 Z3NhdmUgbmV3cGF0aC9wbHtleGNoIG1vdmV0by9wbHtleGNoIGxpbmV0b31kZWZ9ZGVm fWJkZg0vcGx7ZXhjaCBsaW5ldG99YmRmDS9lcHtkdXAgMCBlcXt7bW92ZXRvfXtleGNo IGxpbn17fXsoJSVbfDF8XSUlKT0gZmx1c2h9cGF0aGZvcmFsbA1wb3AgZ3Jlc3RvcmV9 e2Rvb3AgZ3Jlc3RvcmV9aWZlbHNlIGN1cnJlbnRwb2ludCBuZXdwYXRoIG1vdmV0b31i ZGYNL2dyezY0LiBkaXYgc2V0Z3JheX1iZGYNL3NhdmVzY3JlZW57bnMgbm90ey9ucyB0 cnVlIGRlZiBzeXN0ZW1kaWN0L2N1cnJlbnRjb2xvcnNjcmVlbiBrbm93bntjdXJyZW50 Y29sb3JzY3JlZW4vcGtzcGYgeGRmL3Brcm90IHhkZi9wa2ZyZXEgeGRmL3B5c3BmIHhk Zi9weXJvdCB4ZGYvcHlmcmVxIHhkZi9wbXNwZiB4ZGYvcG1yb3QgeGRmL3BtZnJlcSB4 ZGYNL3Bjc3BmIHhkZi9wY3JvdCB4ZGYvcGNmcmVxIHhkZn17Y3VycmVudHNjcmVlbi9z c3BmIHhkZi9zcm90IHhkZi9zZnJlcSB4ZGZ9aWZlbHNlfWlmfWJkZg0vcmVzdG9yZXNj cmVlbnsvbnMgZmFsc2UgZGVmIHN5c3RlbWRpY3Qvc2V0Y29sb3JzY3JlZW4ga25vd257 cGNmcmVxIHBjcm90L3Bjc3BmIGxvYWQgcG1mcmVxIHBtcm90L3Btc3BmIGxvYWQgcHlm cmVxIHB5cm90L3B5c3BmIGxvYWQNcGtmcmVxIHBrcm90L3Brc3BmIGxvYWQgc2V0Y29s b3JzY3JlZW59e3NmcmVxIHNyb3Qvc3NwZiBsb2FkIHNldHNjcmVlbn1pZmVsc2V9YmRm DS9wYXR7c2F2ZXNjcmVlbiBzYTggDWNvcHkgcG9wIDkuMzc1IHBhIHBvciBub3R7OTAg YWRkfWlmezEgYWRkIDQgbXVsIGN2aSBzYTggZXhjaCBnZXQgZXhjaCAxIGFkZCA0IG11 bCBjdmkgNyBzdWIgYml0c2hpZnQgMSBhbmR9c2V0c2NyZWVuIGV4Y2ggbm90e2dyfXtw b3B9aWZlbHNlfWJkZg0vc2d7cmVzdG9yZXNjcmVlbiBncn1iZGYNL2NwYXR7c2F2ZXNj cmVlbiAxMCAyIHJvbGwgNyAtMSByb2xsIHNhOCBjb3B5IHBvcCA5LjM3NSBwYSBwb3Ig bm90ezkwIGFkZH1pZnsxIGFkZCA0IG11bCBjdmkgc2E4IGV4Y2ggZ2V0IGV4Y2ggMSBh ZGQgNCBtdWwgY3ZpIDcgc3ViIGJpdHNoaWZ0IDEgYW5kfTggLTEgcm9sbCBzYjggY29w eSBwb3AgOS4zNzUgcGEgcG9yIG5vdHs5MCBhZGR9aWZ7MSBhZGQgNCBtdWwgY3ZpIHNi OA1leGNoIGdldCBleGNoIDEgYWRkIDQgbXVsIGN2aSA3IHN1YiBiaXRzaGlmdCAxIGFu ZH05IC0xIHJvbGwgc2M4IGNvcHkgcG9wIDkuMzc1IHBhIHBvciBub3R7OTAgYWRkfWlm ezEgYWRkIDQgbXVsIGN2aSBzYzggZXhjaCBnZXQgZXhjaCAxIGFkZCA0IG11bCBjdmkg NyBzdWIgYml0c2hpZnQgMSBhbmR9MTAgLTEgcm9sbCBzZDggY29weSBwb3AgOS4zNzUg cGEgcG9yIG5vdHs5MCBhZGR9aWZ7MSBhZGQgNCBtdWwgY3ZpIHNkOA1leGNoIGdldCBl eGNoIDEgYWRkIDQgbXVsIGN2aSA3IHN1YiBiaXRzaGlmdCAxIGFuZH1wc3VlZG8xIGRz YyA0ezQgLTEgcm9sbCAxIGV4Y2ggNjQgZGl2IHN1Yn1yZXBlYXQgbXlzZXRjbXlrY29s b3IgcG9wIHBvcH1iZGYNc3lzdGVtZGljdC9zZXRjb2xvcnNjcmVlbiBrbm93biBzdGF0 dXNkaWN0L3Byb2Nlc3Njb2xvcnMga25vd24gYW5key9wc3VlZG8xIGxub3AgYmRmL2Rz Yy9zZXRjb2xvcnNjcmVlbiBsb2FkIGRlZn17L3BzdWVkbzF7MTZ7cG9wfXJlcGVhdCBz YTggY29weSBwb3AgOS4zNzUgcGEgcG9yIG5vdHs5MCBhZGR9aWZ7MSBhZGQgNCBtdWwg Y3ZpIHNhOCBleGNoIGdldCBleGNoIDEgYWRkIDQgbXVsIGN2aSA3IHN1YiBiaXRzaGlm dCAxIGFuZH19YmRmDS9id3Nje3NldHNjcmVlbiBkdXAgZ3IgMCBleGNoIDAgZXhjaCA2 NCBleGNoIDY0IGV4Y2ggNjQgZXhjaH1iZGYvZHNjL2J3c2MgbG9hZCBkZWYNfWlmZWxz ZQ1zeXN0ZW1kaWN0L3NldGNteWtjb2xvciBrbm93bnsvbXlzZXRjbXlrY29sb3IgL3Nl dGNteWtjb2xvciBsb2FkIGRlZn17L215c2V0Y215a2NvbG9yezEgc3ViIDQgMSByb2xs IDN7MyBpbmRleCBhZGQgbmVnIGR1cCAwIGx0e3BvcCAwfWlmIDMgMSByb2xsfXJlcGVh dCBzZXRyZ2Jjb2xvciBwb3B9YmRmfWlmZWxzZQ0vZGN7dHJhbnNmb3JtIHJvdW5kIC41 IHN1YiBleGNoIHJvdW5kIC41IHN1YiBleGNoIGl0cmFuc2Zvcm19YmRmDS9zbnt1c2Vy ZGljdC9zbW9vdGg0IGtub3dufWJkZg0veDh7MyBiaXRzaGlmdH1iZGYNL3g0ezIgYml0 c2hpZnR9YmRmDS9kNHstMiBiaXRzaGlmdH1iZGYNL2Q4ey0zIGJpdHNoaWZ0fWJkZg0v cmJ7MTUgYWRkIC00IGJpdHNoaWZ0IDEgYml0c2hpZnR9YmRmDS9kYnsvQDcgc2F2ZSBk ZWYvQDEgeGRmL0AyIHhkZi9AMyB4ZGYvQDQgeGRmL0A1IHhkZi9ANiBANSBAMyA0IGFk ZCBtdWwgZGVmDWRjIHRyYW5zbGF0ZSBzY2FsZS94ZGJpdCAxIDEgaWR0cmFuc2Zvcm0g YWJzL3lkYml0IGV4Y2ggZGVmIGFicyBkZWZ7MCAwIDEgeWRiaXQgYWRkIDEgMTAgcmMg Y2xpcH1pZg1AMSAwIGVxIEAxIDQgZXEgb3J7Y3VycmVudHJnYmNvbG9yIDEgc2V0Z3Jh eSB5ZGJpdCAwIDEgeWRiaXQgYWRkIDEgMiByYyBzZXRyZ2Jjb2xvcn1pZg1AMSAzIGVx IEAxIDcgZXEgb3J7MSBzZXRncmF5fXtjdXJyZW50cmdiY29sb3IgMiBpbmRleCBlcSBl eGNoIDIgaW5kZXggZXEgYW5kIGV4Y2ggcG9wezAgc2V0Z3JheX1pZn1pZmVsc2UvQDkg QDEgMCBlcSBAMSAxIGVxIEAxIDMgZXEgb3Igb3IgZGJpbnZlcnRmbGFnIHhvciBkZWYv QDEzIEA2IGRlZg1AMiBmQml0U3RyZXRjaCBvcnsvQDEwIEA0IHg0IGRlZi9AMTEgQDMg eDQgZGVmL0AxMiBAMTAgcmIgZGVmL0AxMyBAMTIgQDExIG11bCBkZWYvQDE1IDEgMSBk dHJhbnNmb3JtIGFicy9jYWxjWSAxIGluZGV4IGRlZiByb3VuZCBjdmkvQDE0IGV4Y2gg ZGVmDWFicy9jYWxjWCAxIGluZGV4IGRlZiByb3VuZCBjdmkgc2NhbGVieTk2IG5vdHsx IGFkZH1pZiBkZWYvQDE2IEAxNSByYiBkZWYvQDE3IEAxNiBAMTQgbXVsIGRlZn1pZg1z biBAMTMgNjAwMDAgbHQgYW5kIEAyIGZCaXRTdHJldGNoIG9yIGFuZHttdHggY3VycmVu dG1hdHJpeCBkdXAgMSBnZXQgZXhjaCAyIGdldCAwLiBlcSBleGNoIDAuIGVxIGFuZCBA MTcgNjAwMDAgbHQgYW5kIGZCaXRTdHJldGNoIGFuZHtAMTYgMyBiaXRzaGlmdCBAMTQg QDkgW2NhbGNYIDAgMCBjYWxjWSAwIDBde0AxNyBzdHJpbmcgQDEzIHN0cmluZw1jdXJy ZW50ZmlsZSBANiBzdHJpbmcgcmVhZGhleHN0cmluZyBwb3AgMSBpbmRleCBANCBAMyBA NSBAMTIgQDIgc21vb3RoNA1AMTAgQDExIEAxMiBkdXAgc3RyaW5nIDUgaW5kZXggQDE1 IEAxNCBAMTYgZHVwIHN0cmluZyBzdHJldGNofWltYWdlbWFza317QDEyIHg4IEAxMSBA OSBbQDEwIDAgMCBAMTEgMCAwXXtAMTMgc3RyaW5nDWN1cnJlbnRmaWxlIEA2IHN0cmlu ZyByZWFkaGV4c3RyaW5nIHBvcCAxIGluZGV4IEA0IEAzIEA1IEAxMiBAMiBzbW9vdGg0 fWltYWdlbWFza31pZmVsc2V9e0A1IDMgYml0c2hpZnQgQDMgNCBhZGQgQDkgW0A0IDAg MCBAMyAwIDJde2N1cnJlbnRmaWxlIEA2IHN0cmluZyByZWFkaGV4c3RyaW5nIHBvcH1p bWFnZW1hc2t9aWZlbHNlDUA3IHJlc3RvcmV9YmRmDXN5c3RlbWRpY3Qvc2V0Y215a2Nv bG9yIGtub3duey9wc3VlZG8gbG5vcCBiZGYvZGkvY29sb3JpbWFnZSBsb2FkIGRlZn17 L3JvdXRpbmVzW3suMyBtdWwgYWRkIDF9YmluZHsuNTkgbXVsIGFkZCAyfWJpbmR7LjEx IG11bCBhZGQgcm91bmQgY3ZpIHN0ciBleGNoIGkgZXhjaCBwdXQvaSBpIDEgYWRkIGRl ZiAwIDB9YmluZF1kZWYNL3BzdWVkb3svaSAwIGRlZiAwIGV4Y2ggMCBleGNoe2V4Y2gg cm91dGluZXMgZXhjaCBnZXQgZXhlY31mb3JhbGwgcG9wIHBvcCBzdHJ9YmRmL2J3aXtw b3AgcG9wIGltYWdlfWJkZi9kaS9id2kgbG9hZCBkZWZ9aWZlbHNlDS9jZGJ7L0A3IHNh dmUgZGVmL0AxIHhkZi9AMiB4ZGYvQDMgeGRmL0A0IHhkZi9ANSB4ZGYNc3lzdGVtZGlj dC9zZXRjbXlrY29sb3Iga25vd24gbm90e2RjfWlmIHRyYW5zbGF0ZSBzY2FsZSAvQDYg eGRmDS9AMTggQDUgZHVwIDYwMDAwIGdle3BvcCA2MDAwMH1pZiBzdHJpbmcgZGVmIEA2 IG5vdHsvc3RyIEAxOCAwIEAxOCBsZW5ndGggMyBpZGl2IGdldGludGVydmFsIGRlZn1p ZiBANCBAMyA4IFtANCAwIDAgQDMgMCAwXUA2e3tjdXJyZW50ZmlsZSBAMTggcmVhZGhl eHN0cmluZyBwb3B9aW1hZ2V9e3tjdXJyZW50ZmlsZSBAMTggcmVhZGhleHN0cmluZyBw b3AgcHN1ZWRvfWZhbHNlIDMgZGl9aWZlbHNlIEA3IHJlc3RvcmV9YmRmDS93ZCAxNiBk aWN0IGRlZg0vbWZvbnQgMTQgZGljdCBkZWYNL21kZnttZm9udCB3Y2hlY2sgbm90ey9t Zm9udCAxNCBkaWN0IGRlZn1pZiBtZm9udCBiZWdpbiB4ZGYgZW5kfWJkZg0vY2Z7ezEg aW5kZXgvRklEIG5le2RlZn17cG9wIHBvcH1pZmVsc2V9Zm9yYWxsfWJkZi9yZnsvQDEg ZXhjaCBkZWYvQDIgZXhjaCBkZWYNRm9udERpcmVjdG9yeSBAMiBrbm93bntjbGVhcnRv bWFyayBwb3B9e2ZpbmRmb250IGR1cCBiZWdpbiBkdXAgbGVuZ3RoIEAxIGFkZCBkaWN0 IGJlZ2luDWNmey9FbmNvZGluZyBtYWN2ZWMgZGVmfXtFbmNvZGluZyBkdXAgbGVuZ3Ro IGFycmF5IGNvcHkvRW5jb2RpbmcgZXhjaCBkZWYNY291bnR0b21hcmsgMiBpZGl2e0Vu Y29kaW5nIDMgMSByb2xsIHB1dH1yZXBlYXR9aWZlbHNlDXBvcA1leGVjIGN1cnJlbnRk aWN0IGVuZCBlbmQgQDIgZXhjaCBkZWZpbmVmb250IHBvcH1pZmVsc2V9YmRmDS9ibWJj e2V4Y2ggYmVnaW4gd2QgYmVnaW4NL2NyIHhkZg1zYXZlDUNoYXJUYWJsZSBjciA2IG11 bCA2IGdldGludGVydmFse31mb3JhbGwNL2JpdGhlaWdodCB4ZGYvYml0d2lkdGggeGRm DS45NiBkaXYvd2lkdGggeGRmDUdrZXJubWF4IGFkZC9YT2Zmc2V0IHhkZiBHZGVzY2Vu dCBhZGQvWU9mZnNldCB4ZGYvcm93Ynl0ZXMgeGRmDXJvd2J5dGVzIDI1NSBlcXswIDAg MCAwIDAgMCBzZXRjYWNoZWRldmljZX0Ne0dub3Jtc2l6ZSBkdXAgc2NhbGUNd2lkdGgg MCBYT2Zmc2V0IFlPZmZzZXQgYml0d2lkdGggWE9mZnNldCBhZGQgYml0aGVpZ2h0IFlP ZmZzZXQgYWRkDXNldGNhY2hlZGV2aWNlDXJvd2J5dGVzIDAgbmV7DVhPZmZzZXQgWU9m ZnNldCB0cmFuc2xhdGUgbmV3cGF0aCAwIDAgbW92ZXRvDWJpdHdpZHRoIGJpdGhlaWdo dCBzY2FsZQ1zbnsNL3hTbXQgYml0d2lkdGggeDQgZGVmDS95U210IGJpdGhlaWdodCB4 NCBkZWYNL3JTbXQgeFNtdCByYiBkZWYNclNtdCB4OCB5U210IHRydWUNW3hTbXQgMCAw IHlTbXQgbmVnIDAgeVNtdF0Ne3JTbXQgeVNtdCBtdWwgc3RyaW5nIENoYXJEYXRhIGNy IGdldA0xIGluZGV4IGJpdHdpZHRoIGJpdGhlaWdodCByb3dieXRlcyByU210IHRzbyBz bW9vdGg0fQ19e3Jvd2J5dGVzIDMgYml0c2hpZnQgYml0aGVpZ2h0IDQgYWRkIHRydWUN W2JpdHdpZHRoIDAgMCBiaXRoZWlnaHQgbmVnIDAgYml0aGVpZ2h0IDIgYWRkXQ17Q2hh ckRhdGEgY3IgZ2V0fQ19aWZlbHNlDWltYWdlbWFzaw19aWYNfWlmZWxzZQ1yZXN0b3Jl DWVuZCBlbmQNfWJkZg0vYmJ7Ljk2IGV4Y2ggZGl2L0dub3Jtc2l6ZSBtZGYgMiBpbmRl eA0vR2tlcm5tYXggbWRmIDEgaW5kZXgvR2Rlc2NlbnQgbWRmDTMgaW5kZXggZGl2IDQg MSByb2xsDTIgaW5kZXggZGl2IDEuIDUgMiByb2xsDWV4Y2ggZGl2IDQgMSByb2xsDTQg YXJyYXkgYXN0b3JlL0ZvbnRCQm94IG1kZg19YmRmDS9jZGZ7bWZvbnQvQ2hhckRhdGEg Z2V0IDMgMSByb2xsIHB1dH1iZGYNL2Jmew1tZm9udCBiZWdpbg0vRm9udFR5cGUgMyBk ZWYNL0ZvbnRNYXRyaXggWzEgMCAwIDEgMCAwXSBkZWYNL0VuY29kaW5nIG1hY3ZlYyBk ZWYNL01Gb250VHlwZSAwIGRlZg0vQnVpbGRDaGFyL2JtYmMgbG9hZCBkZWYNZW5kDW1m b250IGRlZmluZWZvbnQgcG9wDX1iZGYNL3dpIExXIDEgZXF7e2dzYXZlIDAgMCAwIDAg MCAwIDAgMCBtb3ZldG8gbGluZXRvIGxpbmV0byBsaW5ldG8gY2xvc2VwYXRoIGNsaXAg c3RyaW5nd2lkdGggZ3Jlc3RvcmV9YmluZH17L3N0cmluZ3dpZHRoIGxvYWR9aWZlbHNl IGRlZg0vYXBzezAgZ2V0IDEyNCBlcX1iZGYNL3hje3M3NSBjdnMgZHVwfWJkZg0veHB7 cHV0IGN2bn1iZGYNL3Njc3t4YyAzIDY3IHB1dCBkdXAgMCA5NSB4cH1iZGYNL3Nvc3t4 YyAzIDc5IHhwfWJkZg0vc2Jze3hjIDEgNjYgeHB9YmRmDS9zaXN7eGMgMiA3MyB4cH1i ZGYNL3NvYnt4YyAyIDc5IHhwfWJkZg0vc3Nze3hjIDQgODMgeHB9YmRmDS9kZHtleGNo IDEgaW5kZXggYWRkIDMgMSByb2xsIGFkZCBleGNofWJkZg0vc21je21vdmV0byBkdXAg c2hvd31iZGYNL25kZjJ7dWRme2R1cCAvRm9udFR5cGUgZ2V0IDAgZXF7L0ZEZXBWZWN0 b3IgZ2V0e2R1cCAvRm9udFR5cGUgZ2V0IDAgZXF7bmRmMn17ZHVwIC9kZjIga25vd257 YmVnaW4gZGYyIDAgbnVsbCBwdXQgZW5kDX17cG9wfWlmZWxzZX1pZmVsc2V9Zm9yYWxs fXsvZGYyIGtub3due2R1cCBiZWdpbiBkZjIgMCBudWxsIHB1dCBlbmR9aWZ9aWZlbHNl fXtwb3B9aWZlbHNlfWJkZg0va3due0ZvbnREaXJlY3RvcnkgMSBpbmRleCBrbm93bntm aW5kZm9udCBkdXAgbmRmMiBleGNoIHBvcH19YmRmDS9nbHsxIGN1cnJlbnRncmF5IHN1 YiBzZXRncmF5fWJkZg0vbmV3bW17ZHVwIC9Gb250VHlwZSBnZXQgMCBlcXtkdXAgbWF4 bGVuZ3RoIGRpY3QgYmVnaW57MSBpbmRleC9GSUQgbmUgMiBpbmRleC9VbmlxdWVJRCBu ZSBhbmR7ZGVmfXtwb3AgcG9wfWlmZWxzZX1mb3JhbGwgY3VycmVudGRpY3QgZW5kDWR1 cCAvRkRlcFZlY3RvciAyIGNvcHkgZ2V0W2V4Y2ggNiBpbmRleCBleGNoIDYgaW5kZXgg ZXhjaHtuZXdtbSAzIDEgcm9sbH1mb3JhbGwgcG9wIHBvcF0gcHV0IGR1cA19ey9tZm9u dCAxMCBkaWN0IGRlZiBtZm9udCBiZWdpbi9Gb250TWF0cml4IFsxIDAgMCAxIDAgMF0g ZGVmDS9Gb250VHlwZSAzIGRlZi9FbmNvZGluZyBtYWN2ZWMgZGVmL2RmIDEgaW5kZXgg ZGVmL2RmMiAxIGFycmF5IGRlZi9Gb250QkJveCBbMCAwIDEgMV0gZGVmL1N0eWxlQ29k ZSAyIGluZGV4IGRlZg0vbWJje2JjYXJyYXkgU3R5bGVDb2RlIGdldH1kZWYvQnVpbGRD aGFye2V4Y2ggYmVnaW4Jd2QgYmVnaW4vY3IgZXhjaCBkZWYvY3MgczEgZHVwIDAgY3Ig cHV0IGRlZiBkZiAvTUZvbnRUeXBlIGtub3duIG5vdHsNZGYyIDAgZ2V0IG51bGwgZXF7 ZGYgZHVwIGxlbmd0aCAyIGFkZCBkaWN0IGJlZ2luezEgaW5kZXgvRklEIG5lIDIgaW5k ZXgvVW5pcXVlSUQgbmUgYW5ke2RlZn17cG9wIHBvcH1pZmVsc2V9Zm9yYWxsDS9TdHJv a2VXaWR0aCAxIDAgRm9udE1hdHJpeCBpZHRyYW5zZm9ybSBwb3AgZHVwIG5sdyBtdWwg cHlzIGRpdiBwcyBkaXYgZXhjaCAwLjAxMiBtdWwgMiBjb3B5IGxle2V4Y2h9aWYgcG9w IGRlZi9QYWludFR5cGUgMiBkZWYgY3VycmVudGRpY3QgZW5kDS9xIGV4Y2ggZGVmaW5l Zm9udCBkZjIgZXhjaCAwIGV4Y2ggcHV0fWlmfWlmIG1iYyBleGVjIGVuZCBlbmR9ZGVm IGVuZCBtZm9udH1pZmVsc2UNMyBpbmRleCBleGNoIGRlZmluZWZvbnQgZXhjaCBwb3B9 YmRmDS9tYntkdXAgc2JzIGt3bnswIDIgaW5kZXggZmluZGZvbnQgbmV3bW0gZXhjaCBw b3AgZXhjaCBwb3AgZXhjaCBwb3B9aWZlbHNlIHNmZH1iZGYNL21ve2R1cCBzb3Mga3du ezIgMiBpbmRleCBmaW5kZm9udCBuZXdtbSBleGNoIHBvcCBleGNoIHBvcCBleGNoIHBv cH1pZmVsc2Ugc2ZkfWJkZg0vbXN7ZHVwIHNzcyBrd257NCAyIGluZGV4IGZpbmRmb250 IG5ld21tIGV4Y2ggcG9wIGV4Y2ggcG9wIGV4Y2ggcG9wfWlmZWxzZSBzZmR9YmRmDS9v dXtkdXAgc29zIGt3bnttZm9udC9kZjIga25vd257bWZvbnQgYmVnaW4gZGYyIDAgbnVs bCBwdXQgZW5kfWlmIDMgMiBpbmRleCBmaW5kZm9udCBuZXdtbSBleGNoIHBvcCBleGNo IHBvcCBleGNoIHBvcH1pZmVsc2Ugc2ZkfWJkZg0vc3V7ZHVwIHNzcyBrd257bWZvbnQv ZGYyIGtub3due21mb250IGJlZ2luIGRmMiAwIG51bGwgcHV0IGVuZH1pZiA1IDIgaW5k ZXggZmluZGZvbnQgbmV3bW0gZXhjaCBwb3AgZXhjaCBwb3AgZXhjaCBwb3B9aWZlbHNl IHNmZH1iZGYNL2Fvey9mbXYgdHJ1ZSBkZWYgb3V9YmRmL2Fzey9mbXYgdHJ1ZSBkZWYg c3V9YmRmDS92b3svZm12IGZhbHNlIGRlZiBvdX1iZGYvdnN7L2ZtdiBmYWxzZSBkZWYg c3V9YmRmDS9je2N1cnJlbnRyZ2Jjb2xvciBkdXAgNCAxIHJvbGwgZXEgMyAxIHJvbGwg ZXEgYW5kL2dyYXkgeGRmfWJkZg0vYmNhcnJheVt7L2RhIC4wMyBkZWYgZGYgc2V0Zm9u dCBnc2F2ZSBjcyB3aSAxIGluZGV4IDAgbmV7ZXhjaCBkYSBhZGQgZXhjaH1pZiBncmVz dG9yZSBzZXRjaGFyd2lkdGgNY3MgMCAwIHNtYyBkYSAwIHNtYyBkYSBkYSBzbWMgMCBk YSBtb3ZldG8gc2hvd31iaW5kIGR1cHsvZGEgMSBwcyBkaXYgZGVmIGRmIHNldGZvbnQg Z3NhdmUgY3Mgd2kgMSBpbmRleCAwIG5le2V4Y2ggZGEgYWRkIGV4Y2h9aWYgZ3Jlc3Rv cmUgc2V0Y2hhcndpZHRoDWNzIDAgMCBzbWMgZGEgMCBzbWMgZGEgZGEgc21jIDAgZGEg c21jIGMgZ3JheXtnbH17MSBzZXRncmF5fWlmZWxzZSBkYSAyLiBkaXYgZHVwIG1vdmV0 byBzaG93fWJpbmQNe2RmIHNldGZvbnQgZ3NhdmUgY3Mgd2kgZ3Jlc3RvcmUgc2V0Y2hh cndpZHRoIGMgZ3JheXtnbH17Y3VycmVudHJnYmNvbG9yIDEgc2V0Z3JheX1pZmVsc2Ug Y3MgMCAwIHNtYyBkZjIgMCBnZXQgc2V0Zm9udA1ncmF5e2dsfXs0IDEgcm9sbCBzZXRy Z2Jjb2xvcn1pZmVsc2UgMCAwIG1vdmV0byBzaG93fWJpbmQNey9kYSAxIHBzIGRpdiBk ZWYvZHMgLjA1IGRlZi9kYTIgZGEgMi4gZGl2IGRlZiBkZiBzZXRmb250IGdzYXZlIGNz IHdpIDEgaW5kZXggMCBuZXtleGNoIGRzIGFkZCBkYTIgYWRkIGV4Y2h9aWYgZ3Jlc3Rv cmUgc2V0Y2hhcndpZHRoDWNzIGRzIGRhMiBhZGQgLjAxIGFkZCAwIHNtYyAwIGRzIGRh MiBzdWIgdHJhbnNsYXRlIDAgMCBzbWMgZGEgMCBzbWMgZGEgZGEgc21jIDAgZGEgc21j IGMgZ3JheXtnbH17MSBzZXRncmF5fWlmZWxzZSBkYSAyLiBkaXYgZHVwIG1vdmV0byBz aG93fWJpbmQNey9kYSAuMDUgZGVmIGRmIHNldGZvbnQgZ3NhdmUgY3Mgd2kgMSBpbmRl eCAwIG5le2V4Y2ggZGEgYWRkIGV4Y2h9aWYgZ3Jlc3RvcmUgc2V0Y2hhcndpZHRoIGMg Y3MgZGEgLjAxIGFkZCAwIHNtYyAwIGRhIHRyYW5zbGF0ZQ1ncmF5e2dsfXtjdXJyZW50 cmdiY29sb3IgMSBzZXRncmF5IDQgLTEgcm9sbH1pZmVsc2UgMCAwIHNtYyBncmF5e2ds fXs0IDEgcm9sbCBzZXRyZ2Jjb2xvcn1pZmVsc2UgZGYyIDAgZ2V0IHNldGZvbnQgMCAw IG1vdmV0byBzaG93fWJpbmRdZGVmDS9zdHsxMDAwIG11bCB1c2VydGltZSBhZGQgZHVw IDIxNDc0ODM2NDcgZ3R7MjE0NzQ4MzY0NyBzdWJ9aWYgZGVmfWJkZg0vdGhle3VzZXJ0 aW1lIHN1YiBkdXAgMCBsdCBleGNoIC0yMTQ3NDgzNjQ4IGd0IGFuZH1iZGYNLzZhIDYg YXJyYXkgZGVmDS8yYSAyIGFycmF5IGRlZg0vM3EgMyBhcnJheSBkZWYNL3FzezMgLTEg cm9sbCBzdWIgZXhjaCAzIC0xIHJvbGwgc3ViIGV4Y2h9YmRmDS9xYXszIC0xIHJvbGwg YWRkIGV4Y2ggMyAtMSByb2xsIGFkZCBleGNofWJkZg0vcW17MyAtMSByb2xsIDEgaW5k ZXggbXVsIDMgMSByb2xsIG11bH1iZGYNL3FuezZhIGV4Y2ggZ2V0IG11bH1iZGYNL3FB IC4xNjY2NjcgZGVmL3FCIC44MzMzMzMgZGVmL3FDIC41IGRlZg0vcXh7NmEgYXN0b3Jl IHBvcA1xQSAwIHFuIHFCIDIgcW4gYWRkICAgcUEgMSBxbiBxQiAzIHFuIGFkZA1xQiAy IHFuIHFBIDQgcW4gYWRkICAgcUIgMyBxbiBxQSA1IHFuIGFkZA1xQyAyIHFuIHFDIDQg cW4gYWRkICAgcUMgMyBxbiBxQyA1IHFuIGFkZH1iZGYNL3FwezYgY29weSAxMiAtMiBy b2xsIHBvcCBwb3B9YmRmDS9xY3tleGNoIHFwIHF4IGN1cnZldG99YmRmDS9xaXt7ZXhj aCA0IGNvcHkgMmEgYXN0b3JlIGFsb2FkIHBvcCBxYSAuNSBxbSBuZXdwYXRoIG1vdmV0 b317ZXhjaCAyIGNvcHkgNiAtMiByb2xsIDIgcW0gcXMgNCAyIHJvbGx9aWZlbHNlfWJk Zg0vcXF7e3FjIDJhIGFsb2FkIHBvcCBxeCBjdXJ2ZXRvfXtleGNoIDQgY29weSBxcyBx YSBxeCBjdXJ2ZXRvfWlmZWxzZX1iZGYNL3B0e2N1cnJlbnRwb2ludCBuZXdwYXRoIG1v dmV0b31iZGYNL3Fmey9maWxsZmxhZyB0cnVlIGRlZn1iZGYNL2Vje2R1cCA0IGFuZCAw IG5le2Nsb3NlcGF0aH1pZiAxIGFuZCAwIG5lezAgZG9vcH1pZiBncmVzdG9yZSBjdXJy ZW50cG9pbnQgbmV3cGF0aCBtb3ZldG8vZmlsbGZsYWcgZmFsc2UgZGVmfWJkZg0vZXV7 Y3VycmVudHBvaW50IGZwezAgZXB9e2dyZXN0b3JlIG5ld3BhdGh9aWZlbHNlIG1vdmV0 by9maWxsZmxhZyBmYWxzZSBkZWZ9YmRmDS9icHtjdXJyZW50cG9pbnQgbmV3cGF0aCAy IGNvcHkgbW92ZXRvfWJkZg0vZWZ7Z3NhdmUgZmlsbGZsYWd7Z3NhdmUgZW9maWxsIGdy ZXN0b3JlfWlmfWJkZg0vc217MCBleGNoe0AxIGVxezEgYWRkfWlmfWZvcmFsbH1iZGYN L2xzaG93ezQgMSByb2xsIGV4Y2gvQDEgZXhjaCBkZWZ7MSBpbmRleCB3aSBwb3Agc3Vi IDEgaW5kZXggc20gZHYgMCBAMSA0IC0xIHJvbGwgd2lkdGhzaG93fXsxIGluZGV4IHdp IHBvcCBzdWINMSBpbmRleCBkdXAgc20gMTAgbXVsIGV4Y2ggbGVuZ3RoIDEgc3ViIGFk ZCBkdiBkdXAgMTAuIG11bCAwIEAxIDQgLTEgcm9sbCAwIDYgLTEgcm9sbCBhd2lkdGhz aG93fWlmZWxzZX1iZGYNL3NldFR4TW9kZXtzYSA5IDIgaW5kZXggcHV0IGV4Y2ggbm90 ezMgZXF7MX17MH1pZmVsc2Ugc2V0Z3JheX17cG9wfWlmZWxzZX1iZGYNL1N3VG9TeW17 e31tYXJrIGZhbHNlL1N5bWJvbC98X19fX19fU3ltYm9sIDAgcmYgMCBzYSA2IGdldCAw IG5le3BvcCAxfXtzYSA3IGdldCAwIGVxe3BvcCAyfWlmfWlmZWxzZQ1zYSAxIGdldCAw IG5lL3xfX19fX19TeW1ib2wNc2EgNCBnZXQgMCBuZXt2c317c2EgMyBnZXQgMCBuZXt2 b317Zm50fWlmZWxzZX1pZmVsc2V9YmRmDS9tY3swIDMgMSByb2xsIHRyYW5zZm9ybSBu ZWcgZXhjaCBwb3B9YmRmDS91bHtkdXAgMCBuZSBzYSAyIGdldCAwIG5lIGFuZHtnc2F2 ZSAwIDANL1VuZGVybGluZVBvc2l0aW9uIGtpZnttY317cHMgLTEwIGRpdn1pZmVsc2Uv VW5kZXJsaW5lVGhpY2tuZXNzIGtpZnttY317cHMgMTUgZGl2fWlmZWxzZQ1hYnMgc2V0 bGluZXdpZHRoIG5lZyBybW92ZXRvDXNhIDQgZ2V0IDAgbmV7Z3NhdmUgY3VycmVudGxp bmV3aWR0aCAyLiBkaXYgZHVwIHJtb3ZldG8gY3VycmVudHBvaW50IG5ld3BhdGggbW92 ZXRvDTIgY29weSBybGluZXRvIHN0cm9rZSBncmVzdG9yZX1pZg1zYSAzIGdldCBzYSA0 IGdldCBvciAwIG5le2dzYXZlIGN1cnJlbnRyZ2Jjb2xvciBkdXAgNCAxIHJvbGwgZXEg MyAxIHJvbGwgZXEgYW5ke2dsfXsxIHNldGdyYXl9aWZlbHNlIDIgY29weSBybGluZXRv IHN0cm9rZSBncmVzdG9yZSBybGluZXRvIHN0cm9rZXBhdGggbmx3IHB5cyBkaXYgc2V0 bGluZXdpZHRofXtybGluZXRvfWlmZWxzZQ1zdHJva2UgZ3Jlc3RvcmV9e3BvcH1pZmVs c2V9YmRmDS9zZ3R7MiBjb3B5IGtub3due2dldCB0cnVlfXtwb3AgcG9wIGZhbHNlfWlm ZWxzZX1iZGYNL2tpZntjdXJyZW50Zm9udCBkdXAvRm9udE1hdHJpeCBnZXQgZXhjaC9G b250SW5mbyBzZ3R7dHJ1ZX17Y3VycmVudGZvbnQvZGYgc2d0DXtkdXAvRm9udEluZm8g c2d0ezMgMSByb2xsL0ZvbnRNYXRyaXggZ2V0IG10eCBjb25jYXRtYXRyaXggZXhjaCB0 cnVlfXtwb3AgcG9wIHBvcCBmYWxzZX0NaWZlbHNlfXtwb3AgcG9wIGZhbHNlfWlmZWxz ZX1pZmVsc2V7MyAtMSByb2xsIHNndHtleGNoIHRydWV9e3BvcCBmYWxzZX1pZmVsc2V9 e2ZhbHNlfWlmZWxzZX1iZGYNL2JsYW5rL1RpbWVzLVJvbWFuIGZpbmRmb250L0NoYXJT dHJpbmdzIGdldC9zcGFjZSBnZXQgZGVmDS9tYWN2ZWMgMjU2IGFycmF5IGRlZg0vTlVM L1NPSC9TVFgvRVRYL0VPVC9FTlEvQUNLL0JFTC9CUy9IVC9MRi9WVC9GRi9DUi9TTy9T SQ0vRExFL0RDMS9EQzIvREMzL0RDNC9OQUsvU1lOL0VUQi9DQU4vRU0vU1VCL0VTQy9G Uy9HUy9SUy9VUw1tYWN2ZWMgMCAzMiBnZXRpbnRlcnZhbCBhc3RvcmUgcG9wDW1hY3Zl YyAzMi9UaW1lcy1Sb21hbiBmaW5kZm9udC9FbmNvZGluZyBnZXQNMzIgOTYgZ2V0aW50 ZXJ2YWwgcHV0aW50ZXJ2YWwgbWFjdmVjIGR1cCAzOS9xdW90ZXNpbmdsZSBwdXQgOTYv Z3JhdmUgcHV0DS9BZGllcmVzaXMvQXJpbmcvQ2NlZGlsbGEvRWFjdXRlL050aWxkZS9P ZGllcmVzaXMvVWRpZXJlc2lzL2FhY3V0ZQ0vYWdyYXZlL2FjaXJjdW1mbGV4L2FkaWVy ZXNpcy9hdGlsZGUvYXJpbmcvY2NlZGlsbGEvZWFjdXRlL2VncmF2ZQ0vZWNpcmN1bWZs ZXgvZWRpZXJlc2lzL2lhY3V0ZS9pZ3JhdmUvaWNpcmN1bWZsZXgvaWRpZXJlc2lzL250 aWxkZS9vYWN1dGUNL29ncmF2ZS9vY2lyY3VtZmxleC9vZGllcmVzaXMvb3RpbGRlL3Vh Y3V0ZS91Z3JhdmUvdWNpcmN1bWZsZXgvdWRpZXJlc2lzDS9kYWdnZXIvZGVncmVlL2Nl bnQvc3Rlcmxpbmcvc2VjdGlvbi9idWxsZXQvcGFyYWdyYXBoL2dlcm1hbmRibHMNL3Jl Z2lzdGVyZWQvY29weXJpZ2h0L3RyYWRlbWFyay9hY3V0ZS9kaWVyZXNpcy9ub3RlcXVh bC9BRS9Pc2xhc2gNL2luZmluaXR5L3BsdXNtaW51cy9sZXNzZXF1YWwvZ3JlYXRlcmVx dWFsL3llbi9tdS9wYXJ0aWFsZGlmZi9zdW1tYXRpb24NL3Byb2R1Y3QvcGkvaW50ZWdy YWwvb3JkZmVtaW5pbmUvb3JkbWFzY3VsaW5lL09tZWdhL2FlL29zbGFzaA0vcXVlc3Rp b25kb3duL2V4Y2xhbWRvd24vbG9naWNhbG5vdC9yYWRpY2FsL2Zsb3Jpbi9hcHByb3hl cXVhbC9EZWx0YS9ndWlsbGVtb3RsZWZ0DS9ndWlsbGVtb3RyaWdodC9lbGxpcHNpcy9i bGFuay9BZ3JhdmUvQXRpbGRlL090aWxkZS9PRS9vZQ0vZW5kYXNoL2VtZGFzaC9xdW90 ZWRibGxlZnQvcXVvdGVkYmxyaWdodC9xdW90ZWxlZnQvcXVvdGVyaWdodC9kaXZpZGUv bG96ZW5nZQ0veWRpZXJlc2lzL1lkaWVyZXNpcy9mcmFjdGlvbi9jdXJyZW5jeS9ndWls c2luZ2xsZWZ0L2d1aWxzaW5nbHJpZ2h0L2ZpL2ZsDS9kYWdnZXJkYmwvcGVyaW9kY2Vu dGVyZWQvcXVvdGVzaW5nbGJhc2UvcXVvdGVkYmxiYXNlL3BlcnRob3VzYW5kL0FjaXJj dW1mbGV4L0VjaXJjdW1mbGV4L0FhY3V0ZQ0vRWRpZXJlc2lzL0VncmF2ZS9JYWN1dGUv SWNpcmN1bWZsZXgvSWRpZXJlc2lzL0lncmF2ZS9PYWN1dGUvT2NpcmN1bWZsZXgNL2Fw cGxlL09ncmF2ZS9VYWN1dGUvVWNpcmN1bWZsZXgvVWdyYXZlL2RvdGxlc3NpL2NpcmN1 bWZsZXgvdGlsZGUNL21hY3Jvbi9icmV2ZS9kb3RhY2NlbnQvcmluZy9jZWRpbGxhL2h1 bmdhcnVtbGF1dC9vZ29uZWsvY2Fyb24NbWFjdmVjIDEyOCAxMjggZ2V0aW50ZXJ2YWwg YXN0b3JlIHBvcA17fW1hcmsgdHJ1ZS9Db3VyaWVyL3xfX19fX19Db3VyaWVyIDAgcmYN ey9NZXRyaWNzIDIxIGRpY3QgYmVnaW4vemVybyA2MDAgZGVmL29uZSA2MDAgZGVmL3R3 byA2MDAgZGVmL3RocmVlIDYwMCBkZWYvZm91ciA2MDAgZGVmL2ZpdmUgNjAwIGRlZi9z aXggNjAwIGRlZi9zZXZlbiA2MDAgZGVmL2VpZ2h0IDYwMCBkZWYNL25pbmUgNjAwIGRl Zi9jb21tYSA2MDAgZGVmL3BlcmlvZCA2MDAgZGVmL2RvbGxhciA2MDAgZGVmL251bWJl cnNpZ24gNjAwIGRlZi9wZXJjZW50IDYwMCBkZWYvcGx1cyA2MDAgZGVmL2h5cGhlbiA2 MDAgZGVmL0UgNjAwIGRlZi9wYXJlbmxlZnQgNjAwIGRlZi9wYXJlbnJpZ2h0IDYwMCBk ZWYvc3BhY2UgNjAwIGRlZg1jdXJyZW50ZGljdCBlbmQgZGVmIGN1cnJlbnRkaWN0L1Vu aXF1ZUlEIGtub3duey9VbmlxdWVJRCAxNiM4MDAwMDAgZGVmfWlmL0ZvbnRCQm94IEZv bnRCQm94IDQgYXJyYXkgYXN0b3JlIGRlZn1tYXJrIHRydWUvSGVsdmV0aWNhL3xfX19f X19TZWF0dGxlIDEgcmYNL29sZHNldHRyYW5zZmVyL3NldHRyYW5zZmVyIGxvYWQgZGVm DS9jb25jYXRwcm9jc3svcHJvYzIgZXhjaCBjdmxpdCBkZWYvcHJvYzEgZXhjaCBjdmxp dCBkZWYvbmV3cHJvYyBwcm9jMSBsZW5ndGggcHJvYzIgbGVuZ3RoIGFkZCBhcnJheSBk ZWYNbmV3cHJvYyAwIHByb2MxIHB1dGludGVydmFsIG5ld3Byb2MgcHJvYzEgbGVuZ3Ro IHByb2MyIHB1dGludGVydmFsIG5ld3Byb2MgY3Z4fWRlZg0vc2V0dHJhbnNmZXJ7Y3Vy cmVudHRyYW5zZmVyIGNvbmNhdHByb2NzIG9sZHNldHRyYW5zZmVyfWRlZg0vUGFpbnRC bGFja3sNJURNTSB7MSBleGNoIHN1Yn1zZXR0cmFuc2Zlcg1nc2F2ZSBuZXdwYXRoIGNs aXBwYXRoIDEgc2V0Z3JheSBmaWxsIGdyZXN0b3JlfWRlZg0vb2R7KFJ2ZFwwMDFcMDAx XDAwMFwwMDBcMTc3KSBmZyBjb3B5IHBvcCB0eHBvc2UNMSAwIG10eCBkZWZhdWx0bWF0 cml4IGR0cmFuc2Zvcm0gZXhjaCBhdGFuL3BhIGV4Y2ggZGVmDW5ld3BhdGggY2xpcHBh dGggbWFyaw17dHJhbnNmb3Jte2l0cmFuc2Zvcm0gbW92ZXRvfX17dHJhbnNmb3Jte2l0 cmFuc2Zvcm0gbGluZXRvfX0NezYgLTIgcm9sbCB0cmFuc2Zvcm0gNiAtMiByb2xsIHRy YW5zZm9ybSA2IC0yIHJvbGwgdHJhbnNmb3JtDXtpdHJhbnNmb3JtIDYgMiByb2xsIGl0 cmFuc2Zvcm0gNiAyIHJvbGwgaXRyYW5zZm9ybSA2IDIgcm9sbCBjdXJ2ZXRvfX0Ne3tj bG9zZXBhdGh9fXBhdGhmb3JhbGwgbmV3cGF0aCBjb3VudHRvbWFyayBhcnJheSBhc3Rv cmUvZ2MgeGRmIHBvcCBjdCAzOSAwIHB1dA0xMCBmeiAwIGZzIDIgRi98X19fX19fQ291 cmllciBmbnQgaW52ZXJ0ZmxhZ3sNJURNTSBQYWludEJsYWNrDSB7MSBleGNoIHN1Yn1z ZXR0cmFuc2ZlciAlRE1NDSB9aWYNc3RhdHVzZGljdC9wcm9jZXNzY29sb3JzIGtub3du e3N0YXR1c2RpY3QgYmVnaW4gcHJvY2Vzc2NvbG9ycyBlbmQgNCBlcXsvNGNvbG9ycyB0 cnVlIGRlZn1pZn1pZn1iZGYNL2Nke31iZGYNL29wew0gaW52ZXJ0ZmxhZ3tQYWludEJs YWNrfWlmICVETU0NIC9zZmwgZmFsc2UgZGVmIHN5c3RlbWRpY3QvY3VycmVudGNvbG9y c2NyZWVuIGtub3due2RjZnJlcSBkY3JvdC9kY3NwZiBsb2FkIGRtZnJlcSBkbXJvdC9k bXNwZiBsb2FkIGR5ZnJlcSBkeXJvdC9keXNwZiBsb2FkDWRrZnJlcSBka3JvdC9ka3Nw ZiBsb2FkIHNldGNvbG9yc2NyZWVufXtmcmVxIHJvdC9zcGYgbG9hZCBzZXRzY3JlZW59 aWZlbHNlIHNhdmVzY3JlZW4NL25zIGZhbHNlIGRlZi9wbSBzYXZlIGRlZn1iZGYNL2Nw e25vdHt1c2VyZGljdC8jY29waWVzIDAgcHV0fWlmIG1hIDAgZ3R7e3QxIHRoZXtleGl0 fWlmfWxvb3B9aWZ7L2NvcHlwYWdlIGxvYWQgZXhlY317L3Nob3dwYWdlIGxvYWQgZXhl Y31pZmVsc2UgcG0gcmVzdG9yZX1iZGYNL3B4ezAgMyAxIHJvbGwgdHAgdHR9YmRmDS9w c2J7L3VzIHNhdmUgZGVmfWJkZg0vcHNle3VzIHJlc3RvcmV9YmRmDS9jdCA0MCBzdHJp bmcgZGVmDS9uY3tjdXJyZW50cG9pbnQgaW5pdGNsaXAgbmV3cGF0aCBnY3tkdXAgdHlw ZSBkdXAvYXJyYXl0eXBlIGVxIGV4Y2gvcGFja2VkYXJyYXl0eXBlIGVxIG9ye2V4ZWN9 aWZ9DWZvcmFsbCBjbGlwIG5ld3BhdGggbW92ZXRvfWRlZg0va3B7Y3QgMCAyIGluZGV4 IGxlbmd0aCAyIGluZGV4IDM5IDIgaW5kZXggcHV0IGdldGludGVydmFsIGNvcHkgY3Z4 IGV4ZWMgbXgzIGN1cnJlbnRtYXRyaXggcG9wfWJkZg1lbmQNTFcgMSBlcSB1c2VyZGlj dC9hNHNtYWxsIGtub3duIG5vdCBhbmR7L2E0c21hbGwNW1szMDAgNzIgZGl2IDAgMCAt MzAwIDcyIGRpdiAtMTIwIDMzODFdDTI4MCAzMjU1DXtzdGF0dXNkaWN0L2pvYnN0YXRl IChwcmludGluZykgcHV0IDAgc2V0YmxpbmsNbWFyZ2lucw1leGNoIDE5NiBhZGQgZXhj aCAzMDQgYWRkIDggZGl2IHJvdW5kIGN2aSBmcmFtZXRvcm9rZXQNc3RhdHVzZGljdC9q b2JzdGF0ZSAoYnVzeSkgcHV0DTEgc2V0Ymxpbmt9DS9mcmFtZWRldmljZSBsb2FkDTYw IDQ1e2R1cCBtdWwgZXhjaCBkdXAgbXVsIGFkZCAxLjAgZXhjaCBzdWJ9L3NldHNjcmVl biBsb2FkDXt9L3NldHRyYW5zZmVyIGxvYWQvaW5pdGdyYXBoaWNzIGxvYWQvZXJhc2Vw YWdlIGxvYWRdY3Z4DXN0YXR1c2RpY3QgYmVnaW4gYmluZCBlbmQgcmVhZG9ubHkgZGVm fWlmDWRtZDcxMCAlRE1NDSVETU0gbWQNIGJlZ2luL2JpZ3NbbG5vcCB1c2VyZGljdC9s ZXR0ZXIga25vd257L2xldHRlciBsb2FkfXtsbm9wfWlmZWxzZSB1c2VyZGljdC9sZWdh bCBrbm93bnsvbGVnYWwgbG9hZH17bG5vcH1pZmVsc2UgdXNlcmRpY3QvYTQga25vd257 L2E0IGxvYWR9e2xub3B9aWZlbHNlIHVzZXJkaWN0L2I1IGtub3duey9iNSBsb2FkfXts bm9wfWlmZWxzZSANbG5vcCBsbm9wIGxub3AgL3RhYiBsb2FkL2EzU2l6ZSBsb2FkXWRl Zg0vc21hbGxzW2xub3AgdXNlcmRpY3QvbGV0dGVyc21hbGwga25vd257L2xldHRlcnNt YWxsIGxvYWR9e3VzZXJkaWN0L25vdGUga25vd257L25vdGUgbG9hZH17bG5vcH1pZmVs c2V9aWZlbHNlDXVzZXJkaWN0L2xlZ2FsIGtub3duey9sZWdhbCBsb2FkfXtsbm9wfWlm ZWxzZSB1c2VyZGljdC9hNHNtYWxsIGtub3duey9hNHNtYWxsIGxvYWR9e2xub3B9aWZl bHNlIA11c2VyZGljdC9iNSBrbm93bnsvYjUgbG9hZH17dXNlcmRpY3Qvbm90ZSBrbm93 bnsvbm90ZSBsb2FkfXtsbm9wfWlmZWxzZX1pZmVsc2UgbG5vcCBsbm9wIGxub3AgL3Rh YiBsb2FkL2EzU2l6ZSBsb2FkXWRlZiBlbmQNc3lzdGVtZGljdC9jdXJyZW50cGFja2lu ZyBrbm93bntzZXRwYWNraW5nfWlmDXtjdXJyZW50ZmlsZSBlZXhlY30gKCAlZW5kZWV4 ZWMpIG9rIHVzZXJkaWN0L3N0cmV0Y2gga25vd24gbm90IGFuZCBjaGVja2xvYWQNMzcz QTc2N0Q0QjdGRDk0RkU1OTAzQjcwMTRCMUI4RDNCRUQwMjYzMkM4NTVENTZGNDU4QjEx OEFDRjNBRjczRkM0RUY1RTgxRjU3NDkwNDJCNUY5Q0YxMDE2RDA5M0I3NUYyNTBCN0Q4 MjgwQjJFQUNFMDVBMzcwMzdGN0JERjZFMTIyMjZEN0Q0RTJERjJDNTJGQUZENUZENDBG RTcyQTBEM0FDNEJENDg1RDgzNjlENEM4NzYzNkU5MjBEMURBRjIyMkQ5MjE1NUE5Q0Ix NjY3RTcxNUYwQjgyNzk5QjM3Q0M4RjVCMzJCNzRCMzlDRjQ5NDUzNkRDMzlDN0VGMDRB N0JDQjI5RTJDRUM3OTA3M0NBRENDRkIyM0I0QUExMzYzRjg3NkY1MTIxQjYxODA3MUI3 QjRFQjFFNURFNzVGQUEyMzY4QTNFNURCMkIxOTg2MjNBRkU5MkFFOTQ4NDI3MEZFN0Y1 N0E4NTBFODhDMEQzRUVBMTU2NjExQzkxRDhFNDgwRDQzNzBCMDI1Q0NBNjkyOUEyQkY0 MEFEM0QwMUIyQ0I3RUU2REZCNDZFMTJBODMwNTQyMzM3Rjc4MTlCNjdGOTc2NTIxMEY3 NkRCMDZGMzREQTVCMTNBMTE3NTkzMDVDNTgyRTE2RDJCODU0OTM5RjZEOTEyMUYyQTRG Mjg1MjgyRjVEQ0QzRDE1ODk2RDEyMUUzRDZGNUJFNzlFMDg3NDUxQkIwRUQyMzNDREJF RjA5MEQzQjRBQzJEQzM0Qjk3RTcwQzYxRDk1RkIwNzJCOEMxMkQyQUJEODQzNTIwOTQ5 QTM5RENGOTlFMkMxQUE4RkJDRDAyNUU0N0UwQTgyQThEOTZFNzVCQUY0MEY1MkFENDAy NDk1QkJENERFMEYzNTZDOEIxNEU3NjQ4NzRFNjM5QzlGMDQ1QTBEMTkwOEVDNjQ1NkVC NkM1QjhBNkY4MjYxOTJGNzY3RUYyQzU1QTIxQzU4RjVGOUNDMUY1OTI0N0I1NUYyMzg3 ODI4QzdGRTg5RDVFN0Q4NDg0RDFCQzg2Q0I2NjczQkRCRTRGRTE3REQ5QkRFOTUyMjRG RTY0NTEzNkY0MTMzMEJGMTU1QTREREUxQjBBMzIyMzNCRjQ3MUNFNThGQkM2NjBEQzdF NjQxQjBBMEQzMDAxODQ1NEUyMTkxQzQxNEEzMDExRkYzRkVEMUMwRDg4RkUxRkY5Rjc1 RENDNDU2RDA5Nzk0NzIyNkZCRUM5MjUwOTE0NkQzQTRDRkZDMDQ3MUIzMUM1MzIyMkVE OUREODg1NjZGNjBGNkMwRDcwNUFENzlEQUNGNTNCMDcwMDI2RjA4M0VEMjhCNUNGNzU3 QUFBMEExNjlGNkYzMjBBNzVFOUQyRUQ1MEFCRDkzOUFGODVCNjM0NkMyQURCMjVEMTY4 RjEwNTA4RTE1MTZEMTk0QzYzNUU2QjE4N0ZBREVBMDgyOURCRjAzOTBDMEYwMDNGMDI2 NUUyMTVCQzk2Q0EzQ0MxM0Q0QThFMDE1NzBCRTE5M0NBNzVBNjIwNzI4Q0QyNzVBQ0Yx OTg2RUZGQjNBMTM0MTlGRTU1RUE3QzQ0NjdCN0U3RUVEQzFGQzI5QzlGOEM0NkE1NTdE MkNDREI5MTRFRjdCOTNFNzUzMEQ1NTVERkMyMzk4QUZDNjhDQUQ5OTFGMDYyRUY4NUJB QTE4ODRFQzE2NkM3QzVERjg1NDM2NjZEOEM0MUJFMjY3RDcwNkJEMTU4OEYxRjY2MkY3 MDVDQUU0RDI5REMzOEVGNjZCRkFBODk0NzBEOEEwOTlCNkYxQjQ1ODdGN0IwMjQ0MTIy NzYxMDZGQ0QzRUI1QUUxN0E1RDFERjE3ODE5OTJEQzQwRUEwQTk5MkY3MDZGNzAxMzA0 Q0VBOUQ5MDczRTdBNzRGMUU2ODdEODFDM0U1ODQxRDMxQ0Y4Njg1NUJBQUFEOUI1RDMw MzE3Qzc1MTUwQTg1N0M2QjExNDczNTMxNUNERDFBRUYzNkMyNkJCQjA2NDU0OTk0MDZE RUUyRjI0QjNCMUM3MkZFQzk3QzdCQTMxQUEyQ0RBQjI1NDE4QkIxREM0QzdFNDc1N0Yx RDYyNTA4N0IwRkQwMzAwQzAzQTY1RjJBNzJDRTczNDkyNTczNTI3N0UwMzRDRENGNTk5 MTI5Njc5RjcwQ0M4QjY2RTAzODc4ODUxREI3NTA0MUYyNzVFMUU1NzYxRjNFQzc1M0JF MTM1OUNBMzY0QTIyMDQ3QUU0ODg2MjE3RjkyNTlGRTE5RkY1QjExNkU4MDE5Qjk4QjE0 MzExNEIzMTNFOEJFRjg3RUM5NDlEODVDODJFMDgxMkU2RjUwNTI1RTczODkwQUYzNjJD QzhFRThBODVGNDE5N0U2QUMxODYzOEVGMTJFNTZBODA4RDQzOUFGMUJGRDM2M0YxNDAz MTRCRjRFNTM0NDg1QzQyRjE4NTY2ODhDQzM1Mjg4RThENzcwMTIwQTQyMEZCOUYxRkNG OEFFOEJENkQ2MTU2Q0MyM0U2QzUxMTE5RkU0REUxQjY4QzlERjM0ODdFOTk3NEJGOUVE MzFGOEQzQ0U5M0ZGMTAxODY3MzE5RjJGRjQ5MkQ1RDM5OEI0RjA5QTY2RjJGNTVCQ0FC MzRCOTkxNzNCN0VFODkwMzlEMDBERDIxQTdCM0E1MkU5RjAyOEY4MzAxQjVGQzEyRDQw OTQxMkUwNjQ1MTNCQzU3OUFBQzQ5OEY1NzdFQThFQ0QxRkUzRTQyREMzQ0MzMjA3ODZD N0IwMDE5NEZFREYzNDQ0MDJDMzNGQzQ5MkQ0QkE4Njk5MkIwMTY4M0Y0NDAyMjBGRkU3 NTZCQzg4QTk0MjIzRDMxNjA3OEQ2OUQzMzU2MEU4RUFCNzZCMjRDQjdBQTQzMjBDRjQz NTU5M0Q3NkY2MjQzMjRBQkUwMEI1NTg3QTRGMjgzQzcyNUVBMjQ1NjcxMzNGMjVGNDcy QjVFMkU0NDc0RERCNUExNkFDNUYyREYzMjM1MDM5NUQzRTM4OTJGRTM2MUY0RDVDOUE2 MTBDNjU0QzkyMjc2MTRGQkJBRkYzMzU2QTkwQTIyNjZFMDBGNjYyMzQwNjEwNzU0OTE1 NzFBNjU2MTYyMTEyNTdGMTYwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwDTAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMA0wMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwDTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0w MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwDTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANY2xlYXJ0b21hcmsKICVlbmRlZXhlYwoN e2N1cnJlbnRmaWxlIGVleGVjfSAoICVlbmRlZXhlYykgb2sgdXNlcmRpY3Qvc21vb3Ro NCBrbm93biBub3QgYW5kIGNoZWNrbG9hZA1GOTRFMDBFRTQxQTcxQzU5RTVDQUVFRDFF REJDRjIzRDFEQkExRUU5OUI5QkIzNTY0OTI5MjNCRDhCMUJBODNBODdDRUIwRTA3Mzc3 QTMxRkQ2MjQxRTgxNDY4MTExOEUxN0RDN0NBQ0U1NzAzOTk1MDZFNkU0NDFCODcxQjYw NDM4MzFCRDAzRUZDMTFEQkJEODAwMUVFMkZGOENGQkQ0ODUwNjVENDU1QTJFMTVBQzM2 RjFBODRBRDg3ODlGQTY0NjExOTlDN0NEMTRDQjlGRDY0RDRCMDY0NTJCN0ZDMEE4RkMy NjNGNzBGMUNDQjg5MzI5NUQ0REU3MEFEQUI3NzFDMEY4NDM5NkZBOThDNjBCMTFEQTAy QUJBMTU3Mjk4REYwQTIzNjIxODUzQkVGMTY3NDQzQTk4NUFEQzA5QkVGRkQ1MUNCNEQy OTE3OUUyQjM0NjA5RUYzOEE0OURBNjFGNEJGQzI1NkEzREUwNzMyRDdEMjk3NTRBMTk0 ODU3QjlDOUU5OTcxMjI3QUExREQwNjExRkJCMTBFNDRFNUZGNjZDMDYyRDlDMjRFRDMy OTA1MjkzMzBCQzMxNzgyNUU4NzY5Mjk1ODJEQjBFMzlCOUZDNUVGRDIwQ0MxRDRGOTQ5 MjBFQjlDNTM0RDBEQTkwREU3MEQyNUJDNzI4NzMxOUNGMjg2MDJCM0Y0NjYzM0MyNDJD QUZDODkwNUU5NjAzMTdFM0MyRkEyMEFCOERCMDZBREJBRjI5MkZDN0JBMkNBMTRFRTY1 REYyOEI5OUNDMTE2NjZCNzBBRDMzRThFMUQ1N0Q2M0Q0Qjg5RUNDNjE1QUU1NzQ3QzFD QTc1MkM4MzNEOEQ2REU1NENENEEwMzUwQjQ0MzEwNTU1Q0UzQkQyQzYxNUFERDI3QjYz NENEQjM1MEFGM0E0MzJDRTc4QUFDRDI5MDlBNUI1ODZGNjY2Q0Q4NzkxOUEzNkRCMUNC RTg2QjNDRTI4MURGRDAxQ0Q3RTFCOEExOEE0QjQxNUNFQ0JGRjc5QTVDNDM5MEExNUVB NzdEMTRENkJFMTJCQUI1QTgyNjhDM0YyODZEMDU5MDA2MDY0N0NBQkVENjc0NDQzQ0Qy NThGMTE0MTVFODY2QUIzMzBBMjUxNjkxQjYxRjI0MjJBNjFBRkU1OUI2QjRGQkRDRjg1 RUQ5QkEwRjhFNDgzQzAzNDA4OUU2ODc3RkY1OTIzNjk4RDNBMERDMEVFRDZCOUNGRDMy REYwODM5QkM0RUE1RjZEMUZDQjZERDA5MjAzOTFFNTdFODQ3NDUxMzFEMDJEMTAwMTc5 RjRFMEE2OEVDMEE1RkY2NjgwQTZGNDYzRDAzOEIwNEFGNjNGRkExM0Q3NDNCOTk1QTI2 QTc0M0MyNkQzODcyMDkwMjNDOTFERTQzREYwNDdBMTZGMzI4QUM5RERDMDg1NzNCMzhC RTlFQTM0MUVBMTZDNzhFQzMyRjNBMUIzNkI5MEQ5NUE1MDYxMEY0RDA1MEVDMUMzMzQ5 N0YzRjNBODFBMUI0QzhCRUYwQkE4NEVFMkZBQTMyREMxMTJEQUM0OTBBRjUzRTE3NDlD NEEwRDg2NkNBRjdCODkzRTUyMzgzQjBEMzgwNjVDMzMzRkIxMjJCNzAwRDcyNDZGN0VF ODdEOTQyQUUzREI1QzFERDc3RTlFNzZDODBDQzVBRDYzRDI4REZFRDBFMjI5Q0U2MDQ2 NzNGNzhDRDQ3RjI1OEZERjVCRjNBM0VBRUM1QzlCQzhFNDgyRDhEQkE5RDI2OEEzNURB OEMwOTVBNjkwNjc5RUQyMTIzRThCOEY1RTQ4MjZGQTNCMTk5RUFBNUQ0ODJENEI2QUE4 NjU3MkUzODdDRUNFQjcxNDlDODk0N0Y0MUQ2MzM5MzI4QTc0OEExN0Y4QzRBRDNCMDU1 NUYxRTQwOTQ1MEJBMEM1NjRGMUY0ODhCQjUwOTZFQjAwMzU2OEQ0RDVFRjY0ODk4OTdF Mjc0MDk1NDdEMEVFNDQ4N0QzMDE4NDc5M0IwRjI3QkQyNjVBNjRCREIzRUE2NzYxNTY5 REE5NTU2MjBDNjEyRTcxODY3N0I3N0Q2RDgxQjk5OUM2Mjk4ODc3QUZFMEQxRDZGNkYz NTgzNzdBOEJEMjQwMkY2NjlDNjRCOTcyQjNBMDY1RUY3REQ0QkRFRkZGRTE3RTYzREI4 ODk4RkE2RTY5MTY2QjcxMEFBRDZCQTJFQTlBRjYxRTRCOEM4NzAxNjM4RDRENkU0REZG RkMxOTJBRUY2QkMwMjcwOTVDNEM3MkQ3NDg5Nzk2NzVCQTI5RkFGNjFFNzUzNDNFMTRF NjEwMzQ2MDJFNUE3OUNEMjUxOTc5NkVENkE5Q0M0RURFQTQ2QTlCNTlENEE4MDdFNzg2 QjVFRTQ2RjI1QjAzNjBCQzhFN0MxMkQ3MjMxMjJDREVFRjI0N0M5Nzc2RjRDOTlDOEVC RUQ2ODI4QUExOTc0NEI1QURGMEQwN0Q5NUQ5OEIzMDcyMzcyMzg4RDQxQjBGQUIxQ0NF Mjc3NTE3MDY3OTU3NUVDRENBMTNCMjJBMTdGRTlDNjYwNUMzNDQ1RjU4RjFBODI5NTEy REFCNkM1MjhGODM1ODBDOEFBNTNDMzVENjA1RjYyNkY1QUQwQjdGQzFFQTg3RDY5QTgz NUUzRjUzQTFGNDUwRkIwQUY0MkE1NzcyRjg5RDkyQTUwRDEwRjE1QkRCREE0MDlGNTBD MEI4QUI5M0ZFOEExNkQwMjlERDhCQjVDNDgwRDE0NjY3MzVFRDREOUNBRjYzN0U1RUNE NkMyRUNCNkJGM0IzRUZCRUU3QUI5MzZEMkM1NjhFMzAwOUQxNTZCODdDQUNCMUZCM0E0 OEE3MEJDOTFCMkVDMzVDQzkxNDdGRkIxQTUyNEUyQjJGMkU0RTJDMUIxMkYxQzFDNjM3 NjhCQjk1Q0Q2MkZFQzAxQ0JBNzlCOUZBMjgyREQ0REY0OTk5MEYyN0ZGOEVFNEUyRERF MkYwQUNEODNCQzlENEJFMDA5MDE5MkM3QTc5OTk2N0VDNERDMkQ2M0MwODM1RTIyRDRD NEIzNjZEN0ZEQ0YzQTA1QTRCNTNERjc4MEY5ODZFRjI1Qzc5QjY2NUQ1QzAwRUZGN0Yx N0MwQkI2RDU0NEY5RDgzQTdGREFDNDdEOUM1NjgzQTY1NjAxMTM3NDI1M0M5MThGRjZF QTY0NzQ5REQ5NzFCMjMwMERENTMyMDAzM0UwMUVDNTkxRjYzMThDQ0U5NENFMkI4MUMw NDMyMkVDNTJCNjI0RTUwNjQzQjUyMzkxQ0NEMkFCNTYzOTZBMkFEOEUyRDNDQTYxQjgw RDlENENDMzYzQjJERjc4NjM1MjY5NThDREYzNDk3RTM2NjQ4NDA2QzMxN0U1OEVDNTYz RTdDMjYxNDlBMkEzQzY0M0FERkIzOUE4REQ5Mjk3NEM2RDJBMkE5RDdCNzFDREYzRkVC QkYzMkJCMDJFN0I0NUNGNTNBQUVBRDVFOTYzQTRBQTRBRjlBMTQ5QTA4QTRFQzMwM0Q1 RjIzNjk5NzdFOTNGNTQ4OTdFRUFEMzFCMDZDNTg0NUQ2M0Y0OUQ2NUY4RTU1NzM5NjIy NDFBNTdDQ0Q3MTdDRTZDQThDNzg0QTExMTkyOTQzNjE2RUEwNTlCNTFCQzM4NDI5RTE4 RDAxMjFGQ0JCNkZCRDVEOTA5QjBEODlFNjE2QzY2REVGNkEwRjE2NUE3MDMwQkQ5MTFB MUIxMjA0NjgzMjlDQkIwMDZDOEQzNzcyMEU1MzFDRjMxRTg3OENCNEFBQUMxMzc2MzM2 NzVDM0Q1NDZGNTE2MjQ4N0FCMzVGNDcwQzA0MkJERUI5NDVFMEYyNTMyQkY5MkFBNkZE NTM0MzQ0NDAyMjFFQ0QzNTMzQTdBQTg5OTAwQ0IxOUVGRTJDRDg3MkRGOEI3OTY5QUYw RDNCNzJCRjMxREM1REQ2OUNBNjQ2MDk2NkY2MUFCMTdDQjUwNzk2NDA5OERCQTNBRjEy MkVFQzMxMjhBOUJBRkUxMDM0NDkzRjM3MkIzNkJEMTM1MTIwNUU5MDQzQTY3QzU0NDQw MkQ4QkNFMjQzNThDOEE1Q0UzMzg2N0EwMDc5NENGNzA5N0Q1OUM4ODI3OUExMUVFOUM4 NTRFN0U3QUFFODgxRjk4MjhDNTY5RDIwOEY1RjMzMzc1RjU5RTlBMzgxOENGQTM4QUFE MENCRkJBMzJGOUY0NEE4QkI3OURFNEM0MEUzODg2NDU3QzE2REE0QTI3OTUzQUExRTk5 NDcyRTM1RjIzMjNGMEJBQTVFMzdEQzI4Q0JBNDZGRUZCNzNCMTkwMDE2MDU1QURENEQy NzYxNUQ3NDg0OTlBMEUxQzRCOEM3RUMzMzlDMUM0RDk1QTgxM0E4NTkxOEE4RDAxRUVC NDg1RERDRENFQTZFQTNGMkMyQTlEODVDMTM5Q0Q5MENDQjM1MjYzNEY5QUZFODM2QkNB QzBDMjc0RTM1MkJBMjA3MUI1MjY5RDVERTRDQ0RFM0ZGOTkwQ0JBOTc0OTgwQzczMzJB RTE1NDVBOUM2MEQ1RDE0NTlEM0FFOTVDMUFDMDY1NzMzQUYxNEZBREI0NDBBMTEwREQ1 Mzk1NjNCOEQ4NTBDRDA3MDRDNTJGM0Y3Q0NDQjUzNjMwRDc3NjU2MENCRDIyRDhGRjA4 RjVCMzU0NDg3QTE3MUFFQzE1RjVGNTRERTlDQUI2NjhCQ0FDNTczRTc4OEQ5Mjc2MkVG NjNFNzYwODcwMDVGNEFDMkQwMkUwQ0FDMTczQzExQkU2MkFDRTVEQzREMzM3NEYyRjk3 NDZDOTk4MUUxMjVGRjlBQjhDQUU3NkQxMzAzOUUyQzU0REZENzA4RTAyOEE2MTlFQTFF RDc4RTZCNDZGMDZERjBEMEI3NEJCRUREOEMxOTBDN0MwQ0VCREU4RjdBNDg4OENDMzY1 NzUzMTM0NzhERDJDRkUzOTJFOUJCN0IyNDE2OTU1RDQ0QjcwMjRBM0JBNDNGQkYzNzI5 M0IzODZENjQ3NDZENzc0ODg5NTQxMUQyNDNGQUVDNTA2MzhGMkFBMzMzMzdEN0ZBMDE4 QUREQUM1ODM1QTBEREZBRTk5QUQ2Mjk5REZCNENBNjg3MkM1OTg1M0UzQUMxMkZDOUUz RDI2NjI5QzVCNDlDRjg0NEM4N0IzQzRCRkJFMzA3NEUzQTFDRTY5ODQ3NThDMjBDNjYx MDg0MzgxQ0Q2QjQ1ODJEODRGMTlDMDAwMEI1RkMwRENCNDJCNTY3RTM5NjAzMTYwMUMw OTVENzAxNjI4M0VCRTVGMTNDRDhBM0EzNzRBNzREREJCQUJEMzYwODExNDlGOEJDMjQy MDg1RjJGNzI5N0NDOTdGRDNCOEJBRDIwNkQ4QUM5NzA3QTM5RUNDQzc5NjNCNTIyRTA4 REEzOTFBMUVGMTJERDRENzQ2REJERERDQzA4MzRGODgxNjBDRjE4OUE5NjQ1NTY3Q0VD MkYwMjNBNTcxQUYwREZEMTVEQjg1Qjc0NEMyOEMwMDBERjUzQjA1RjhGMjEwODQxRjZF ODdBMDRGMjBDNzc3QjdDMEJFNjE4MkJFMkU5MDIyNkU1MzAxQTEyNTMyQTc0NUYyRkFB QTgxNjM3Q0YxMUI3OENEMkI5OUE0RDE4Qjg2MkQ2QzVEQkQzMTc5M0ZCMTZBMkQ5QUFE Mzc2RDQ0ODRENzVBQTgzM0QwMDY4QjFEMzREQjc0RTMzMDI0ODA4NTRFM0I1NDg0RDhB NDdFMzlBODlBMkZBOTI3QkMzNjQxRUE3RjhFMDA0RkRFNEMyRjA4RDQwRDk5RjFBQ0I0 N0NBRjY4ODc2MjlCRjZERkUxMjk2OEQyOTc1OTZEMjhDRTBDRjE0OEIxMkU3RENCNDlG Qjk0RjVBREJEMjE0QzNBNkNFMUUyNDk4MzFCQTlFQjhBMTg5RjJDRTFBQkUzOUE3QjUz NzI1M0UzNjlBNTA4QTJBRjJBREI5NDYzRjlCNTZCQkJGRjMxRDUzNUZGOTk3RjUzN0M2 Njc1QzE5NkU3RUNCRDQ5M0Y2NTJGQTdDQzZEOUMxQ0EzMzc5QkZEQjVBRjc1MTNDNkU4 MzQwNTQ0OTQyOTZCOTFBNkVFODAwMTE0MzYzRDVENUQwNzU5RjQxQjRERUNCNjUzQjlE RTNFOTQ1ODM1NzlFRjU0OUVENUYzRkFGQjEyNjYxQUJDMEM1N0EzMzI0MDY1MTdFRDM0 NTRFREVEMzRCMzg2QzYwRjc4REM5NzYyNjZFMEVBRjU0RkMyNDVGQjBFM0VGQzgwMTYy MzY0MzZCNTk5QzFDOTdBOEM1RTBBQzhGNzgzNjE2MTg3M0M3MUYwMUVEOUNDMjVDMjM2 NDIwRjQxRkQ4Mjc3OTkzRDM5NTkyMDU5MTJGQTA5MjdCNTlFM0RBRTczNzdEODIwNzk0 NDdENkU0MUVFNUFFQzBERkZGNzlBRjhGNEVENDdGMTdFRTcwOEZFQTQ1ODc3ODYwRDU2 RjhDQkNFNjVBMDYxRThFMUNBNEE1RkJBRjBFMTM0MjlBN0YwQURCNkYxNzhGQTQ0OUY0 NkNDNTM5QkJDMDEwN0UzQTUzQjFDMzYyQTA0QjIwRTZENzIxRTdFNkUxRTQ5NzZBMTFE REM5OEM3NjE0RDIyQjUzREZCQjZEQUU1MzNBQzlCRTg4MjAyMUE3MzVDMzBEQUE0QTQ0 QUVEMDlGNDlBMzkwRThDRkY1OUJEOUMzMDY2N0FGMjFCMDNFQzVDRUJENUMyQzNBQTI3 NjlFOEQ3MTQxOTFBNDhFN0RERjUwQjEzRDE1NjBFODJFRkI2NUZDRTYwMUFFOUU4QzM1 MUZCQTFERUQ4MEI3MzUxMzE0RTdGOUY5QTc4NEJGRTM3NTlCN0UzMjJBODRFN0I1MUY5 REM1RjVEOUM4MDUwQ0Q3OUIyN0MwQTRCMERENjhBM0MyN0E5NDhBRDY4NThFMzVCOTYw RDJERUE4MzhDNDc5Q0FFQTgzQjFBOTEyMTc0QUNCMjEwMEU1NUU3QTE0ODkyRDdBOUIz NzExRkYwQjIwMDY1QzE5OTVCNDlFMUYyMzQ2NEE5MkREMTQwNjQyRTNBN0IxOTczODQ5 RTY0RDFBM0NGNjAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDANMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0wMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw DTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDANMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMA0wMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwDTAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDANMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMA1jbGVhcnRvbWFyawogJWVuZGVleGVjCg0KICVlbmRh cHBsZWRpY3QKDSUlRW5kUHJvY1NldA0NJSVJbmNsdWRlUHJvY1NldDogIihBcHBsZURp Y3QgbWQpIiA3MSAwDS9kbWQ3MTAgd2hlcmV7L21kL2RtZDcxMCBsb2FkIHB1dCBtZCAv aW5pdHVkIGdldCBleGVjfSBpZiAlRE1NDSUlQmVnaW5Qcm9jU2V0OiAiKERNTUFwcGxl Rml4IG1kKSIgMiAzDS9zaG93cGFnZSBsb2FkIHR5cGUgL29wZXJhdG9ydHlwZSBuZXsN L3Nob3dwYWdlIGxvYWQgZHVwIHR5cGUvYXJyYXl0eXBlIGVxe2R1cCB3Y2hlY2sgZXhj aCBsZW5ndGggNiBuZSBvcn17cG9wIHRydWV9aWZlbHNlew0vbWQgd2hlcmV7DS9tZCBn ZXQgdHlwZS9kaWN0dHlwZSBlcXsNbWQgYmVnaW4NL2Nwe25vdHt1c2VyZGljdC8jY29w aWVzIDAgcHV0fWlme2NvcHlwYWdlfXtzaG93cGFnZX1pZmVsc2UgcG0gcmVzdG9yZX1k ZWYNL25je2N1cnJlbnRwb2ludCBpbml0Y2xpcCBuZXdwYXRoIG1vdmV0b31iaW5kIGRl Zg1bdXNlcmRpY3QvRE1NLW51cC1kaWN0IGtub3duew1sbm9wL2xldHRlciBsb2FkL2xl Z2FsIGxvYWQvYTQgbG9hZC9iNSBsb2FkIGxub3AgbG5vcCBsbm9wLzExeDE3IGxvYWQv YTMgbG9hZA19aWYgY291bnR0b21hcmsgYmlncyBsZW5ndGggc3ViIG5lZyBkdXAgMCBn dHt7bG5vcH1yZXBlYXR9e3BvcH1pZmVsc2UNXWR1cC9iaWdzIGV4Y2ggZGVmL3NtYWxs cyBleGNoIGRlZg0vam57L3N0YXR1c2RpY3Qgd2hlcmUgZXhjaCBwb3B7c3RhdHVzZGlj dC9qb2JuYW1lIDIgY29weSBrbm93biBkdXB7DW5vdCAzIGNvcHkgcG9wIGdldCBkdXAg dHlwZS9zdHJpbmd0eXBlIGVxe2xlbmd0aCAwIGd0e25vdH1pZn17cG9wfWlmZWxzZX1p Zg17cG9wIHBvcCBwb3B9ezMgLTEgcm9sbCBwdXR9aWZlbHNlfWlmfWJpbmQgZGVmDWVu ZA19aWZ9aWZ9aWZ9aWYNJSVFbmRQcm9jU2V0DSUlRW5kUHJvbG9nDSUlQmVnaW5Eb2N1 bWVudFNldHVwDW1kIGJlZ2luDVQgc2dkDXN2c2MNDUYgVCAwIDAgNzMwIDU1MiAtMzEg LTMwIDc2MSA1ODIgMTAwIDcyIDcyIDEgRiBGIEYgRiBUIFQgRiBGIHBzdQ0oZGNyb2Nr ZXI7IGRvY3VtZW50OiBUQ04uc3BlYylqbg0wIG1mDW9kDSUlRW5kRG9jdW1lbnRTZXR1 cA0lJVBhZ2U6ID8gMQ1vcA0zMSAzMCB4bA0xIDEgcGVuDTAgMCBnbQ0obmMgMzEgMzAg NzYxIDU4MiA2IHJjKWtwDTgxIDcyIGdtDTAgZ3INVCAxIHNldFR4TW9kZQ0wIGZzDWJ1 IGZjDQ0lJUJlZ2luRm9udDogVGltZXMtUm9tYW4NYm4NJSVFbmRGb250DWJ1IGZjDXt9 bWFyayBUIC9UaW1lcy1Sb21hbiAvfF9fX19fX1RpbWVzLVJvbWFuIDAgcmYNYm4NMTIg ZnoNYnUgZmMNMiBGIC98X19fX19fVGltZXMtUm9tYW4gZm50DWJuDShOZXR3b3JrIFdv cmtpbmcgR3JvdXAgKXNob3cNODEgNDg3IGdtDShELlwzMTJDcm9ja2VyKXNob3cNOTMg NzIgZ20NKEludGVybmV0IERyYWZ0OilzaG93DTkzIDQyMiBnbQ0oQnJhbmRlbmJ1cmdc MzEyQ29uc3VsdGluZylzaG93DTEwNSA3MiBnbQ0oICAgICBEUkFGVC1DUk9DS0VSLVRD Ti0wMC57dHh0LHBzfSlzaG93DTEwNSA0NjIgZ20NKE9jdG9iZXIgNywgMTk5NClzaG93 DTExNyA3MiBnbQ0oRXhwaXJhdGlvbiA8Mi83NT4pc2hvdw0xNTggMTY2IGdtDTEgZnMN YnUgZmMNDSUlQmVnaW5Gb250OiBIZWx2ZXRpY2EtQm9sZA1ibg0lJUVuZEZvbnQNYnUg ZmMNe31tYXJrIFQgL0hlbHZldGljYS1Cb2xkIC98X19fX19fSGVsdmV0aWNhLUJvbGQg MCByZg1ibg0xOCBmeg1idSBmYw0yIEYgL3xfX19fX19IZWx2ZXRpY2EtQm9sZCBmbnQN Ym4NKFRyYW5zcG9ydCBDb250ZXh0IE5hbWVzIFwoVENOXCk6KXNob3cNMTc2IDIwNSBn bQ0oQ29uY2VwdHMgYW5kIEZhY2lsaXRpZXMpc2hvdw0yMTQgNzIgZ20NMTIgZnoNYnUg ZmMNMiBGIC98X19fX19fSGVsdmV0aWNhLUJvbGQgZm50DWJuDShTVEFUVVMgT0YgVEhJ UyBNRU1PKXNob3cNMjM4IDcyIGdtDTAgZnMNYnUgZmMNMiBGIC98X19fX19fVGltZXMt Um9tYW4gZm50DWJuDShUaGlzIGlzIGEgcHJlbGltaW5hcnkgZHJhZnQgZG9jdW1lbnQs IGludGVuZGVkIGZvciBldmVudHVhbCBzdWJtaXNzaW9uIHRvIHRoZSBJRVRGIHdvcmtp bmcpc2hvdw0yNTAgNzIgZ20NKGdyb3VwIHByb2Nlc3MuICBBdCB0aGlzIHN0YWdlLCB0 aGUgZG9jdW1lbnQgc2hvdWxkIGJlIHZpZXdlZCBzdHJpY3RseSBhcyBhIHRoaW5rLXBp ZWNlLCB3aXRoKXNob3cNMjYyIDcyIGdtDShjb21tZW50cywgY29ycmVjdGlvbnMsIGV0 Yy4gZWFnZXJseSBzb3VnaHQuKXNob3cNMjg2IDcyIGdtDShUaGlzIGRvY3VtZW50IGlz IGFuIEludGVybmV0IERyYWZ0LiBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldClzaG93DTI5OCA3MiBnbQ0oRW5naW5lZXJpbmcg VGFzayBGb3JjZSBcKElFVEZcKSwgaXRzIGFyZWFzLCBhbmQgaXRzIFdvcmtpbmcgR3Jv dXBzLiBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSlzaG93DTMxMCA3MiBnbQ0oYWxz byBkaXN0cmlidXRlIHdvcmtpbmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4g IEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkKXNob3cNMzIy IDcyIGdtDShmb3IgYSBtYXhpbXVtIG9mIHNpeCBtb250aHMuIEludGVybmV0LURyYWZ0 cyBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlcilz aG93DTMzNCA3MiBnbQ0oZG9jdW1lbnRzIGF0IGFueSB0aW1lLiBJdCBpcyBub3QgYXBw cm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJp YWwgb3IgdG8gY2l0ZSlzaG93DTM0NiA3MiBnbQ0odGhlbSBvdGhlciB0aGFuIGFzIGEg XDMyMndvcmtpbmcgZHJhZnRcMzIzIG9yIFwzMjJ3b3JrIGluIHByb2dyZXNzLlwzMjMg IElFVEYgSW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIGJ5KXNob3cNMzU5IDcyIGdtDShh bm9ueW1vdXMgRlRQIGZyb20gc2V2ZXJhbCBJbnRlcm5ldCBzaXRlcy4gIFBsZWFzZSBj aGVjayB0aGUgKXNob3cNYnUgZmMNDSUlQmVnaW5Gb250OiBDb3VyaWVyDWJuDSUlRW5k Rm9udA1idSBmYw17fW1hcmsgVCAvQ291cmllciAvfF9fX19fX0NvdXJpZXIgMCByZg1i bg1idSBmYw0yIEYgL3xfX19fX19Db3VyaWVyIGZudA1ibg0oMWlkLWFic3RyYWN0cy50 eHQpc2hvdw1idSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKCBsaXN0 aW5nIHRvKXNob3cNMzcxIDcyIGdtDShsZWFybiB0aGUgY3VycmVudCBzdGF0dXMgb2Yg YW55IEludGVybmV0IERyYWZ0LilzaG93DTQwOCA3MiBnbQ0xIGZzDWJ1IGZjDTIgRiAv fF9fX19fX0hlbHZldGljYS1Cb2xkIGZudA1ibg0oU1VNTUFSWSlzaG93DTQzMiA3MiBn bQ0wIGZzDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZudA1ibg0oV2hlbiB1 c2luZyB0aGUgSW50ZXJuZXQgcHJvdG9jb2wgc3VpdGUsIHByb2Nlc3NlcyBjb21tdW5p Y2F0ZSB2aWEgdHJhbnNwb3J0IGFzc29jaWF0aW9ucywgc3VjaClzaG93DTQ0NCA3MiBn bQ0oYXMgVENQIGNvbm5lY3Rpb25zOyB0aGVzZSBkZWZpbmUgZW5kLXRvLWVuZCBjb21t dW5pY2F0aW9uIHJlbGF0aW9uc2hpcHMsIG9yIGNvbnRleHRzLCBiZXR3ZWVuKXNob3cN NDU2IDcyIGdtDSh0aGUgcHJvY2Vzc2VzLiAgRW5oYW5jZWQgc2VydmljZXMsIHN1Y2gg YXMgZm9yIGhvc3QgYW5kIHNlcnZpY2UgbW9iaWxpdHkgYW5kIGZhaWx1cmUgcmVjb3Zl cnksIGNhbilzaG93DTQ2OCA3MiBnbQ0oYmUgZmFjaWxpdGF0ZWQgYnkgZGlzdGluZ3Vp c2hpbmcgYSB0cmFuc3BvcnQgYXNzb2NpYXRpb24gZnJvbSB0aGUgdW5kZXJseWluZyBu ZXR3b3JrIHNlcnZpY2VcKHNcKSBpdClzaG93DTQ4MCA3MiBnbQ0odXNlcy4gIFRoaXMg ZGlzdGluY3Rpb24gd2lsbCBhbGxvdyByZS1sb2NhdGluZyBvbmUgb3IgYm90aCBlbmRz IG9mIHRoZSBjb250ZXh0LCB3aGlsZSBtYWludGFpbmluZyBhKXNob3cNNDkyIDcyIGdt DShjb25zaXN0ZW50IGFuZCB1bmlxdWUgcmVmZXJlbmNlIHRvIHRoYXQgY29udGV4dCwg aW5kZXBlbmRlbnQgb2YgaXRzIG5ldHdvcmsgY29ubmVjdGl2aXR5LiAgVGhpcylzaG93 DTUwNCA3MiBnbQ0ocHJvcG9zYWwgc3VnZ2VzdHMgdXNpbmcgYSBjb21iaW5hdGlvbiBv ZiBkb21haW4gbmFtZXMsIHBvcnQgbnVtYmVycyBhbmQgcHJvdG9jb2wgaWRlbnRpZmll cnMgdG8pc2hvdw01MTYgNzIgZ20NKGRlZmluZSB0cmFuc3BvcnQgYXNzb2NpYXRpb25z LCBhbmQgdGhlbiB1c2luZyBjb250cm9sIGNoYW5uZWxzIGJldHdlZW4gaG9zdHMgZm9y IGFkZGluZyBhbmQpc2hvdw01MjggNzIgZ20NKHJlbW92aW5nIG5ldHdvcmsgXDMyMmNo YW5uZWxcMzIzIHNwZWNpZmljYXRpb25zIHRvIHRoZSBhc3NvY2lhdGlvbnMuICAgVGhp cyBkb2N1bWVudCBpcyBhIGRlc2NyaXB0aW9uKXNob3cNNTQwIDcyIGdtDShvZiB0aGUg cHJvcG9zZWQgZmFjaWxpdHksIHJhdGhlciB0aGFuIGEgY29tcGxldGUgc3BlY2lmaWNh dGlvbi4gIEl0IGlzIGludGVuZGVkIHRvIGNvbnZleSB0aGUpc2hvdw01NTIgNzIgZ20N KGNvbmNlcHRzIGFuZCBzdHlsZSBvZiB0aGUgcHJvcG9zZWQgbWVjaGFuaXNtLCBzYXZp bmcgdGhlIGpveSBvZiBmb3JtYXRzIGZvciBsYXRlci4pc2hvdw01ODkgNzIgZ20NMSBm cw1idSBmYw0yIEYgL3xfX19fX19IZWx2ZXRpY2EtQm9sZCBmbnQNYm4NKFRBQkxFIE9G IENPTlRFTlRTKXNob3cNNjAxIDcyIGdtDTAgZnMNYnUgZmMNMiBGIC98X19fX19fVGlt ZXMtUm9tYW4gZm50DWJuDSgxLilzaG93DTYwMSAxMDggZ20NKEludHJvZHVjdGlvbilz aG93DTYxMyA3MiBnbQ0oMi4pc2hvdw02MTMgMTA4IGdtDShUcmFuc3BvcnQgY29udGV4 dCBuYW1lcylzaG93DTYyNSA3MiBnbQ0oMy4pc2hvdw02MjUgMTA4IGdtDShUcmFuc3Bv cnQgY29udGV4dCBjaGFubmVsIGxpc3QgbWFuYWdlbWVudClzaG93DTYzNyA3MiBnbQ0o NC4pc2hvdw02MzcgMTA4IGdtDShVc2Ugb2YgdGNucyBieSB0cmFuc3BvcnQgc2Vydmlj ZXMpc2hvdw02NDkgNzIgZ20NKDUuKXNob3cNNjQ5IDEwOCBnbQ0oRXhhbXBsZSlzaG93 DTY2MSA3MiBnbQ0oNi4pc2hvdw02NjEgMTA4IGdtDShEaXNjdXNzaW9uKXNob3cNNjcz IDcyIGdtDSg3LilzaG93DTY3MyAxMDggZ20NKFJlZmVyZW5jZXMpc2hvdw02ODUgNzIg Z20NKDguKXNob3cNNjg1IDEwOCBnbQ0oU2VjdXJpdHkgY29uc2lkZXJhdGlvbnMpc2hv dw02OTcgNzIgZ20NKDkuKXNob3cNNjk3IDEwOCBnbQ0oQWNrbm93bGVkZ21lbnRzKXNo b3cNNzA5IDcyIGdtDSgxMC4pc2hvdw03MDkgMTA4IGdtDShDb250YWN0KXNob3cNRiBU IGNwDSUlUGFnZTogPyAyDW9wDTMxIDMwIHhsDTEgMSBwZW4NNzA5IDE0NSBnbQ0obmMg MzEgMzAgNzYxIDU4MiA2IHJjKWtwDTgxIDcyIGdtDTAgZ3INVCAxIHNldFR4TW9kZQ0w IGZzDTEwIGZ6DWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZudA1ibg0oSW50 ZXJuZXQgRHJhZnQpc2hvdw04MSAyNTQgZ20NKFRyYW5zcG9ydCBDb250ZXh0IE5hbWVz KXNob3cNODEgNDg2IGdtDShBdWd1c3QsIDE5OTQpc2hvdw03MTggNzIgZ20NKEQuIENy b2NrZXIpc2hvdw03MTggNTA2IGdtDShbUGFnZSAyXSlzaG93DTEwNSA3MiBnbQ0xIGZz DTEyIGZ6DWJ1IGZjDTIgRiAvfF9fX19fX0hlbHZldGljYS1Cb2xkIGZudA1ibg0oMS4p c2hvdw0xMDUgMTA4IGdtDShJTlRST0RVQ1RJT04pc2hvdw0xMjkgNzIgZ20NMCBmcw1i dSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKFdoZW4gdXNpbmcgdGhl IEludGVybmV0IHByb3RvY29sIHN1aXRlIHByb2Nlc3NlcyBjb21tdW5pY2F0ZSB2aWEg dHJhbnNwb3J0IGFzc29jaWF0aW9ucywgc3VjaCBhcylzaG93DTE0MSA3MiBnbQ0oVENQ IGNvbm5lY3Rpb25zOyB0aGVzZSBkZWZpbmUgZW5kLXRvLWVuZCBjb21tdW5pY2F0aW9u IHJlbGF0aW9uc2hpcHMsIG9yIGNvbnRleHRzLCBiZXR3ZWVuIHRoZSlzaG93DTE1MyA3 MiBnbQ0ocHJvY2Vzc2VzLiAgRm9yIFRDUCwgdGhlIGNvbnRleHQgbmFtZSBpcyBjYWxs ZWQgYSBcMzIyY29ubmVjdGlvbiBpZGVudGlmaWVyXDMyMyBhbmQgaXMgZGVmaW5lZCBi eSB0aGUpc2hvdw0xNjUgNzIgZ20NKHNvdXJjZSBhbmQgZGVzdGluYXRpb24gSVAgYWRk cmVzc2VzIGFuZCB0aGUgc291cmNlIGFuZCBkZXN0aW5hdGlvbiBwb3J0IG51bWJlcnMu IFtUQ1BdICBJbXBsaWNpdClzaG93DTE3NyA3MiBnbQ0oaXMgdGhlIElQIHByb3RvY29s IHZhbHVlIGlkZW50aWZ5aW5nIFRDUCwgaXRzZWxmLiAgSWRlbnRpZnlpbmcgYSBjb25u ZWN0aW9uIGluIHRoaXMgZmFzaGlvbiB0aWVzIGl0IHRvKXNob3cNMTg5IDcyIGdtDShh IHBhcnRpY3VsYXIgSVAgYWRkcmVzcyBwYWlyIGZvciB0aGUgbGlmZSBvZiB0aGUgY29u bmVjdGlvbi4gIFNpbmNlIElQIGFkZHJlc3NlcyBpZGVudGlmeSBwYXJ0aWN1bGFyKXNo b3cNMjAxIDcyIGdtDShob3N0IGludGVyZmFjZXMsIHRoaXMgbWVhbnMgdGhhdCBhbGwg ZGF0YWdyYW1zIGZvciB0aGUgY29ubmVjdGlvbiBtdXN0IGdvIHRocm91Z2ggdGhlIHNh bWUpc2hvdw0yMTMgNzIgZ20NKGludGVyZmFjZXMuICBHZW5lcmFsbHkgdGhleSBhbHNv IHdpbGwgZ28gdGhyb3VnaCB0aGUgc2FtZSBpbnRlcm1lZGlhdGUgcm91dGVycywgc2lu Y2Ugcm91dGVzIHRlbmQpc2hvdw0yMjUgNzIgZ20NKHRvIGJlIHF1aXRlIHN0YWJsZS4g IFdoZW4gYSByb3V0ZSBiZWNvbWVzIHVuYXZhaWxhYmxlLCByb3V0aW5nIHByb3RvY29s cyB1c3VhbGx5IHJlcXVpcmUpc2hvdw0yMzcgNzIgZ20NKHNpZ25pZmljYW50IHRpbWUg YmVmb3JlIGVzdGFibGlzaGluZyBhbiBhbHRlcm5hdGUuICBXaGlsZSBUQ1AgaXMgcGVy c2lzdGVudCBhbmQgd2lsbCBzdWNjZWVkIGF0KXNob3cNMjQ5IDcyIGdtDShzZW5kaW5n IGl0cyBkYXRhIGFmdGVyIGEgbmV0d29yayBkZWxheSwgc29tZSBhcHBsaWNhdGlvbnMg aGF2ZSBwZXJmb3JtYW5jZSByZXF1aXJlbWVudHMgd2hpY2gpc2hvdw0yNjEgNzIgZ20N KG5lZWQgcXVpY2tlciByZWNvdmVyeSBmcm9tIGZhaWx1cmVzLilzaG93DTI4NSA3MiBn bQ0oQW4gSVAgXChpbnRlcmZhY2VcKSBhZGRyZXNzIHNwZWNpZmllcyB0aGUgbmV0d29y ayBhbmQgc3VibmV0d29yayB0byB3aGljaCB0aGUgaG9zdCBpcyBhdHRhY2hlZC4pc2hv dw0yOTcgNzIgZ20NKE1hbnkgZm9ybXMgb2YgaG9zdCBtb2JpbGl0eSBjYXVzZSB0aGUg aG9zdCB0byBiZSBhdHRhY2hlZCB0byBkaWZmZXJlbnQgcGFydHMgb2YgdGhlKXNob3cN MzA5IDcyIGdtDShjb21tdW5pY2F0aW9uIGZhYnJpYyBhdCBkaWZmZXJlbnQgdGltZXMu ICBGb3IgbWFuYWdlbWVudCBhbmQgc2NhbGluZywgaXQgY2FuIGJlIHF1aXRlIGhlbHBm dWwgZm9yKXNob3cNMzIxIDcyIGdtDShob3N0cyB0byBoYXZlIGRpZmZlcmVudCBJUCBh ZGRyZXNzZXMgYWNjb3JkaW5nIHRoZSBwYXJ0aWN1bGFyIHBhcnQgb2YgdGhlIGZhYnJp YyB0byB3aGljaCB0aGV5IGFyZSlzaG93DTMzMyA3MiBnbQ0oYXR0YWNoZWQuICBCZWNh dXNlIGEgVENQIGNvbm5lY3Rpb24gaWQgaXMgdGllZCB0byBwYXJ0aWN1bGFyIElQIGFk ZHJlc3NlcywgdGhpcyBtZWFucyB0aGF0IHRoZSlzaG93DTM0NSA3MiBnbQ0oY29ubmVj dGlvbiBjYW5ub3Qgc3Vydml2ZSBzdWNoIElQIGFkZHJlc3MgdHJhbnNpdGlvbnMuKXNo b3cNMzY5IDcyIGdtDShUaGlzIHByb3Bvc2FsIHN1Z2dlc3RzIHRoYXQgZW5oYW5jZWQg c2VydmljZXMsIHN1Y2ggYXMgZm9yIGhvc3QgYW5kIHNlcnZpY2UgbW9iaWxpdHkgYW5k IGZhaWx1cmUpc2hvdw0zODEgNzIgZ20NKHJlY292ZXJ5LCBjYW4gYmUgZmFjaWxpdGF0 ZWQgYnkgZGlzdGluZ3Vpc2hpbmcgYSB0cmFuc3BvcnQgYXNzb2NpYXRpb24gZnJvbSB0 aGUgdW5kZXJseWluZyBuZXR3b3JrKXNob3cNMzkzIDcyIGdtDShzZXJ2aWNlXChzXCkg aXQgdXNlcy4gIFRoaXMgZGlzdGluY3Rpb24gd2lsbCBhbGxvdyByZS1sb2NhdGluZyBv bmUgb3IgYm90aCBlbmRzIG9mIHRoZSBjb250ZXh0LCB3aGlsZSlzaG93DTQwNSA3MiBn bQ0obWFpbnRhaW5pbmcgYSBjb25zaXN0ZW50IGFuZCB1bmlxdWUgcmVmZXJlbmNlIHRv IHRoYXQgY29udGV4dCwgaW5kZXBlbmRlbnQgb2YgaXRzIG5ldHdvcmspc2hvdw00MTcg NzIgZ20NKGNvbm5lY3Rpdml0eS4gIEZ1cnRoZXIsIGl0IGFsbG93cyB1c2luZyBtdWx0 aXBsZSBuZXR3b3JrIGludGVyZmFjZXMgYXMgcGFydCBvZiB0aGUgc2FtZSBhc3NvY2lh dGlvbiwpc2hvdw00MjkgNzIgZ20NKHNvIHRoYXQgYSBwcm9ibGVtIHRocm91Z2ggb25l IGludGVyZmFjZSBjYW4gbGVhZCB0byBxdWljayByZXRyYW5zbWlzc2lvbiB0aHJvdWdo IG9uZSBvZiB0aGUpc2hvdw00NDEgNzIgZ20NKGFsdGVybmF0ZXMuKXNob3cNNDY1IDcy IGdtDShUaGlzIHByb3Bvc2FsIHN1Z2dlc3RzIHVzaW5nIGEgY29tYmluYXRpb24gb2Yg ZG9tYWluIG5hbWUsIHBvcnQgbnVtYmVyIGFuZCBwcm90b2NvbCBpZGVudGlmaWVyKXNo b3cNNDc3IDcyIGdtDSh0byBkZWZpbmUgdHJhbnNwb3J0IGFzc29jaWF0aW9ucywgYW5k IHRoZW4gdXNpbmcgY29udHJvbCBjaGFubmVscyBiZXR3ZWVuIGhvc3RzIGZvciBhZGRp bmcgYW5kKXNob3cNNDg5IDcyIGdtDShyZW1vdmluZyBuZXR3b3JrIFwzMjJjaGFubmVs XDMyMyBzcGVjaWZpY2F0aW9ucyB0byB0aGUgYXNzb2NpYXRpb25zLiAgVGhpcyBzY2hl bWUgc3VwcG9ydHMgZW5oYW5jZWQpc2hvdw01MDEgNzIgZ20NKGZ1bmN0aW9uYWxpdHkg YXMgaW5jcmVtZW50YWwgdXBncmFkZXMgdG8gZW5kLXN5c3RlbSBub2RlcywgcmF0aGVy IHRoYW4gYXMgY2hhbmdlcyB0byB0aGUpc2hvdw01MTMgNzIgZ20NKGludGVybmV0d29y ayBpbmZyYXN0cnVjdHVyZS4pc2hvdw01NTAgNzIgZ20NMSBmcw1idSBmYw0yIEYgL3xf X19fX19IZWx2ZXRpY2EtQm9sZCBmbnQNYm4NKDIuKXNob3cNNTUwIDEwOCBnbQ0oVFJB TlNQT1JUIENPTlRFWFQgTkFNRVMpc2hvdw01NzQgNzIgZ20NMCBmcw1idSBmYw0yIEYg L3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKEEgVHJhbnNwb3J0IENvbnRleHQgTmFt ZSBcKFRDTlwpICBpcyBhIGdsb2JhbGx5IHVuaXF1ZSByZWZlcmVuY2UgdG8gdGhlIGNv bW11bmljYXRpb24gY29udGV4dClzaG93DTU4NiA3MiBnbQ0oYW5kIGlzIGxhYmVsZWQg YnkgdGhlIHR1cGxlOilzaG93DTYxMSAxMDggZ20NYnUgZmMNMiBGIC98X19fX19fQ291 cmllciBmbnQNYm4NKDxUcmFuc3BvcnQgc2VydmljZSwpc2hvdw02MjMgMTA4IGdtDShT b3VyY2UgaG9zdCBkb21haW4gbmFtZSwgRGVzdGluYXRpb24gaG9zdCBkb21haW4gbmFt ZSlzaG93DTYzNSAxMDggZ20NKFNvdXJjZSB0cmFuc3BvcnQgaWQsIERlc3RpbmF0aW9u IHRyYW5zcG9ydCBpZD4pc2hvdw02NTggNzIgZ20NYnUgZmMNMiBGIC98X19fX19fVGlt ZXMtUm9tYW4gZm50DWJuDSh3aGVyZTopc2hvdw02ODMgMTA4IGdtDWJ1IGZjDTIgRiAv fF9fX19fX0NvdXJpZXIgZm50DWJuDShUcmFuc3BvcnQgc2VydmljZSlzaG93DTY5NCAy NTIgZ20NYnUgZmMNMiBGIC98X19fX19fVGltZXMtUm9tYW4gZm50DWJuDShzcGVjaWZp ZXMgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCwgc3VjaCBhcyBVRFAgb3IgVENQOylzaG93 DUYgVCBjcA0lJVBhZ2U6ID8gMw1vcA0zMSAzMCB4bA0xIDEgcGVuDTY5NCA1MDkgZ20N KG5jIDMxIDMwIDc2MSA1ODIgNiByYylrcA04MSA3MiBnbQ0wIGdyDVQgMSBzZXRUeE1v ZGUNMCBmcw0xMCBmeg1idSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4N KEludGVybmV0IERyYWZ0KXNob3cNODEgMjU0IGdtDShUcmFuc3BvcnQgQ29udGV4dCBO YW1lcylzaG93DTgxIDQ4NiBnbQ0oQXVndXN0LCAxOTk0KXNob3cNNzE4IDcyIGdtDShE LiBDcm9ja2VyKXNob3cNNzE4IDUwNiBnbQ0oW1BhZ2UgM10pc2hvdw0xMDUgMTA4IGdt DTEyIGZ6DWJ1IGZjDTIgRiAvfF9fX19fX0NvdXJpZXIgZm50DWJuDShTb3VyY2UgaG9z dCBkb21haW4gbmFtZSlzaG93DTExNiAyNTIgZ20NYnUgZmMNMiBGIC98X19fX19fVGlt ZXMtUm9tYW4gZm50DWJuDShzcGVjaWZpZXMgYSBnbG9iYWxseSB1bmlxdWUgcmVmZXJl bmNlIHRvIHRoZSBtYWNoaW5lIG9yKXNob3cNMTI4IDI1MiBnbQ0oc2VydmljZSBob3N0 aW5nIHRoZSBvbmUgZW5kIG9mIHRoZSB0cmFuc3BvcnQgY29udGV4dCwgYW5kKXNob3cN MTUzIDEwOCBnbQ1idSBmYw0yIEYgL3xfX19fX19Db3VyaWVyIGZudA1ibg0oRGVzdGlu YXRpb24gaG9zdCBkb21haW4gbmFtZSlzaG93DTE2NCAyNTIgZ20NYnUgZmMNMiBGIC98 X19fX19fVGltZXMtUm9tYW4gZm50DWJuDShzcGVjaWZpZXMgdGhlIG90aGVyIGVuZC4p c2hvdw0xODkgMTA4IGdtDWJ1IGZjDTIgRiAvfF9fX19fX0NvdXJpZXIgZm50DWJuDShT b3VyY2UgdHJhbnNwb3J0IGlkKXNob3cNMjAwIDI1MiBnbQ1idSBmYw0yIEYgL3xfX19f X19UaW1lcy1Sb21hbiBmbnQNYm4NKHNwZWNpZmllcyB0aGUgdHJhbnNwb3J0IGFzc29j aWF0aW9uIGlkZW50aWZpZXIgdXNlZCBieSB0aGUpc2hvdw0yMTIgMjUyIGdtDShzb3Vy Y2UsIHN1Y2ggYXMgdGhlIFRDUCBzb3VyY2UgcG9ydCBudW1iZXIpc2hvdw0yMzcgMTA4 IGdtDWJ1IGZjDTIgRiAvfF9fX19fX0NvdXJpZXIgZm50DWJuDShEZXN0aW5hdGlvbiB0 cmFuc3BvcnQgaWQpc2hvdw0yNDggMjUyIGdtDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVz LVJvbWFuIGZudA1ibg0oc3BlY2lmaWVzIHRoZSBpZGVudGlmaWVyIHVzZWQgYnkgdGhl IGRlc3RpbmF0aW9uLilzaG93DTI3MiA3MiBnbQ0oSXQgaXMgaW1wb3J0YW50IHRvIHJl YWxpemUgdGhhdCBhIHN1cnByaXNpbmcgb3Bwb3J0dW5pdHkgd2l0aCB0aGlzIG5hbWlu ZyBzY2hlbWUgaXMgdG8gcGVybWl0IGEpc2hvdw0yODQgNzIgZ20NKHRyYW5zcG9ydCBz ZXJ2aWNlIHRvIG9wZXJhdGUgYSBzaW5nbGUgaW50ZXJwcm9jZXNzIHRyYW5zcG9ydCBh c3NvY2lhdGlvbiwgc3VjaCBhcyBhIHNpbmdsZSBUQ1Apc2hvdw0yOTYgNzIgZ20NKGNv bm5lY3Rpb24sIG92ZXIgYSByYW5nZSBvZiBkaWZmZXJlbnQgbmV0d29yayBwcm90b2Nv bHMsIGFzIHdlbGwgYXMgb3ZlciBhIHJhbmdlIG9mIG5ldHdvcmspc2hvdw0zMDggNzIg Z20NKFwzMjJjaGFubmVsc1wzMjMuKXNob3cNMzMyIDcyIGdtDShBc3NvY2lhdGVkIHdp dGggYSB0cmFuc3BvcnQgY29udGV4dCBuYW1lIGlzIGEgbGlzdCBvZiBvbmUgb3IgbW9y ZSBuZXR3b3JrLWRlcGVuZGVudCBcMzIyY2hhbm5lbFwzMjMpc2hvdw0zNDQgNzIgZ20N KHJlZmVyZW5jZXMsIHN1Y2ggYXMgSVAgYWRkcmVzcyBwYWlycy4gIEEgVHJhbnNwb3J0 IENvbnRleHQgQ2hhbm5lbCBcKFRDQ1wpIGRlZmluZXMgYSBzcGVjaWZpYylzaG93DTM1 NiA3MiBnbQ0obWVhbnMgb2YgY29udmV5aW5nIHRyYW5zcG9ydCBkYXRhIGJldHdlZW4g aG9zdHMgYW5kIG1heSB0aGVuIGJlIHVzZWQgYnkgdGhlIHRyYW5zcG9ydCBzZXJ2aWNl KXNob3cNMzY4IDcyIGdtDShmb3IgYWx0ZXJuYXRlIHRyYW5zbWlzc2lvbiBjaG9pY2Vz LCB0byBpbXByb3ZlIHJlY292ZXJ5IGZyb20gZGVsaXZlcnkgaW50ZXJydXB0aW9ucy4g IEl0IGlzIGxhYmVsZWQpc2hvdw0zODAgNzIgZ20NKGJ5IHRoZSB0dXBsZTopc2hvdw00 MDUgMTA4IGdtDWJ1IGZjDTIgRiAvfF9fX19fX0NvdXJpZXIgZm50DWJuDSg8TmV0d29y ayBwcm90b2NvbCwpc2hvdw00MTcgMTA4IGdtDShTb3VyY2UgbmV0d29yayBob3N0IGlk ZW50aWZpZXIsKXNob3cNNDI5IDEwOCBnbQ0oRGVzdGluYXRpb24gbmV0d29yayBob3N0 IGlkZW50aWZpZXI+KXNob3cNNDUyIDcyIGdtDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVz LVJvbWFuIGZudA1ibg0od2hlcmUpc2hvdw00NzcgMTA4IGdtDWJ1IGZjDTIgRiAvfF9f X19fX0NvdXJpZXIgZm50DWJuDShOZXR3b3JrIHByb3RvY29sKXNob3cNNDg4IDI1MiBn bQ1idSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKHNwZWNpZmllcyB0 aGUgbmV0d29yay1sZXZlbCBwcm90b2NvbCB0byBiZSB1c2VkIGZvciB0aGlzKXNob3cN NTAwIDI1MiBnbQ0oY2hhbm5lbCwpc2hvdw01MjUgMTA4IGdtDWJ1IGZjDTIgRiAvfF9f X19fX0NvdXJpZXIgZm50DWJuDShTb3VyY2UgbmV0d29yayBob3N0IGlkZW50aWZpZXIp c2hvdw01MzYgMjUyIGdtDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZudA1i bg0oc3BlY2lmaWVzIGEgbmV0d29yayBhY2Nlc3MgaWRlbnRpZmllciwgc3VjaCBhcyBJ UCBhZGRyZXNzLCBmb3Ipc2hvdw01NDggMjUyIGdtDShvbmUgaG9zdCB1c2luZyB0aGUg bmV0d29yayBwcm90b2NvbCwpc2hvdw01NzMgMTA4IGdtDWJ1IGZjDTIgRiAvfF9fX19f X0NvdXJpZXIgZm50DWJuDShEZXN0aW5hdGlvbiBuZXR3b3JrIGhvc3QgaWRlbnRpZmll cilzaG93DTU4NCAyNTIgZ20NYnUgZmMNMiBGIC98X19fX19fVGltZXMtUm9tYW4gZm50 DWJuDShzcGVjaWZpZXMgdGhlIG90aGVyIG5ldHdvcmsgYWNjZXNzIGlkZW50aWZpZXIu KXNob3cNNjIwIDcyIGdtDShBIFRyYW5zcG9ydCBDb250ZXh0IENoYW5uZWwgTGlzdCBc KFRDQ0xcKSBjb21wcmlzZXMgYSBUQ04gYW5kIGEgc2V0IG9mIG9uZSBvciBtb3JlIFRD Q3MuICBJdClzaG93DTYzMiA3MiBnbQ0oZGVmaW5lcyB0aGUgY2hvaWNlcyB0aGF0IGEg dHJhbnNwb3J0IGFzc29jaWF0aW9uIGhhcyB3aGVuIGRlY2lkaW5nIGhvdyB0byBzZW5k IGEgc2VnbWVudCBvZiBkYXRhLilzaG93DTY1NiA3MiBnbQ0oVGhlIGxpc3QgbWF5IGJl IG1vZGlmaWVkIG92ZXIgdGhlIGNvdXJzZSBvZiB0aGUgY29udGV4dCwgdG8gcGVybWl0 IGNoYW5naW5nIGF0dGFjaG1lbnQgdG8gdGhlKXNob3cNNjY4IDcyIGdtDShJbnRlcm5l dCwgc3VjaCBhcyBmb3IgaG9zdCBtb2JpbGl0eS4gIFwoSXQgbWF5IHdlbGwgYWxzbyBi ZSB1c2VmdWwgdG8gcGVybWl0IHByb2Nlc3NlcyB0byBtaWdyYXRlKXNob3cNNjgwIDcy IGdtDShmcm9tIG9uZSBob3N0IHRvIGFub3RoZXIgLS0gYXNzdW1pbmcgdGhhdCB0aGUg aG9zdHMgY29vcGVyYXRlIGFtb25nIHRoZW1zZWx2ZXMgdG8gY29vcmRpbmF0ZSlzaG93 DTY5MiA3MiBnbQ0odGhlIGxvY2FsIHRyYW5zZmVyIG9mIHRoZSBwcm9jZXNzIGNvbnRl eHQuXCkpc2hvdw1GIFQgY3ANJSVQYWdlOiA/IDQNb3ANMzEgMzAgeGwNMSAxIHBlbg02 OTIgMjY3IGdtDShuYyAzMSAzMCA3NjEgNTgyIDYgcmMpa3ANODEgNzIgZ20NMCBncg1U IDEgc2V0VHhNb2RlDTAgZnMNMTAgZnoNYnUgZmMNMiBGIC98X19fX19fVGltZXMtUm9t YW4gZm50DWJuDShJbnRlcm5ldCBEcmFmdClzaG93DTgxIDI1NCBnbQ0oVHJhbnNwb3J0 IENvbnRleHQgTmFtZXMpc2hvdw04MSA0ODYgZ20NKEF1Z3VzdCwgMTk5NClzaG93DTcx OCA3MiBnbQ0oRC4gQ3JvY2tlcilzaG93DTcxOCA1MDYgZ20NKFtQYWdlIDRdKXNob3cN MTA0IDcyIGdtDTEyIGZ6DWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZudA1i bg0oV2hlbiBhbiBUQ0NMIGNvbnRhaW5zIG1vcmUgdGhhbiBvbmUgbmV0d29yayBjaGFu bmVsIHNwZWNpZmljYXRpb24sIHRoZSB0cmFuc3BvcnQgbWF5IGNob29zZSlzaG93DTEx NiA3MiBnbQ0odG8gc2VuZCBwb3J0aW9ucyBvZiB0cmFmZmljIG92ZXIgZGlmZmVyZW50 IGNoYW5uZWxzLiAgV2hpbGUgdGhpcyBtYXkgcmVzdWx0IGluIGluY3JlYXNlZCB0aHJv dWdocHV0LClzaG93DTEyOCA3MiBnbQ0oaXRzIHByaW1hcnkgYmVuZWZpdCBpcyB0byBt YWludGFpbiBrbm93bGVkZ2UgYWJvdXQgdGhlIHV0aWxpdHkgb2YgZWFjaCBjaGFubmVs LiAgV2hlbiBvbmUgY2Vhc2VzKXNob3cNMTQwIDcyIGdtDSh0byBwcm92aWRlIGFkZXF1 YXRlIHBlcmZvcm1hbmNlLCB0aGUgdHJhbnNwb3J0IG1heSBzaW1wbHkgbWFyayBpdCBh cyBkaXNhYmxlZCBhbmQgdGhlbiBzZW5kKXNob3cNMTUyIDcyIGdtDSh0cmFmZmljIG92 ZXIgdGhlIHJlbWFpbmluZyBuZXR3b3JrIGNoYW5uZWxzLilzaG93DTE4OSA3MiBnbQ0x IGZzDWJ1IGZjDTIgRiAvfF9fX19fX0hlbHZldGljYS1Cb2xkIGZudA1ibg0oMy4pc2hv dw0xODkgMTA4IGdtDShUUkFOU1BPUlQgQ09OVEVYVCBDSEFOTkVMIExJU1QgTUFOQUdF TUVOVClzaG93DTIxMyA3MiBnbQ0wIGZzDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJv bWFuIGZudA1ibg0oQSBUQ0NMIG1heSBiZSBkZWZpbmVkIGJlZm9yZSBvciBkdXJpbmcg YSBwYXJ0aWN1bGFyIHRyYW5zcG9ydCBjb250ZXh0LiAgVXNpbmcgcHVibGljIGRvbWFp bilzaG93DTIyNSA3MiBnbQ0obmFtZXMsIHN1Y2ggYXMgZnJvbSB0aGUgZG9tYWluIG5h bWUgc2VydmljZSwgYW5kIHRoZSBzZXQgb2YgbmV0d29yayBhZGRyZXNzZXMgcHVibGlj bHkgbGlzdGVkLCBhKXNob3cNMjM3IDcyIGdtDShob3N0IG1heSBidWlsZCBhIFRDQ0wg cHJpb3IgdG8gaW5pdGlhdGluZyBhIHNwZWNpZmljIHRyYW5zcG9ydCBjb250ZXh0Lilz aG93DTI2MSA3MiBnbQ0oQWx0ZXJuYXRpdmVseSwgYSBob3N0IG1heSBjaG9vc2UgdG8g YnVpbGQgYSBUQ0NMIGZyb20gYW4gZXhpc3RpbmcgY29udGV4dC4gIEluIHRoaXMgY2Fz ZSBvZilzaG93DTI3MyA3MiBnbQ0oZGVyaXZlZCB1c2UsIG9uZSBvZiB0aGUgaG9zdHMg cGFydGljaXBhdGluZyBpbiBhbiBleGlzdGluZyB0cmFuc3BvcnQgY29udGV4dCBpbml0 aWFscyBhIGNvbnRyb2wpc2hvdw0yODUgNzIgZ20NKGNoYW5uZWwgZXhjaGFuZ2Ugc3Rh cnRpbmcgd2l0aCB0aGUgZXhpc3RpbmcgdHJhbnNwb3J0IGNvbnRleHQgY2hhbm5lbCwg YWRkaW5nIGEgdHJhbnNwb3J0IGNvbnRleHQpc2hvdw0yOTcgNzIgZ20NKG5hbWUgYW5k LCBwb3NzaWJseSwgb3RoZXIgVENDcy4pc2hvdw0zMjEgNzIgZ20NKEEgY29udHJvbCBj aGFubmVsIG9wZXJhdGVzIGJldHdlZW4gaG9zdHMsIHJhdGhlciB0aGFuIHByb2Nlc3Nl cy4gIEl0IG5lZWRzIHRvIGhhdmUgYSBtZWFucyBvZilzaG93DTMzMyA3MiBnbQ0oYXV0 aGVudGljYXRpbmcgYm90aCBwYXJ0aWNpcGFudHMsIHBhcnRpY3VsYXJseSBzaW5jZSB0 aGlzIHNlcnZpY2UgcGVybWl0cyBtb3ZpbmcgY29udGV4dHMgdG8pc2hvdw0zNDUgNzIg Z20NKGRpZmZlcmVudCBhZGRyZXNzZXMuKXNob3cNMzY5IDcyIGdtDShHZW5lcmFsbHks IHRoZSBwcm90b2NvbCBpcyBsaWtlbHkgdG8gYmUgcmVsYXRpdmVseSBzaW1wbGUsIHJl cXVpcmluZyBjb21tYW5kcyByb3VnaGx5IHRvIGRvKXNob3cNMzgxIDcyIGdtDShzaW1w bGUgbWFuaXB1bGF0aW9ucyBvZiBUQ0MgZW50cmllcyBvbiBhIHRyYW5zcG9ydCBjb250 ZXh0IGNoYW5uZWwgbGlzdC4gIEZvciBleGFtcGxlOilzaG93DTQwNiAxMDggZ20NYnUg ZmMNMiBGIC98X19fX19fQ291cmllciBmbnQNYm4NKGNyZWF0ZSApc2hvdw00MDYgMTk4 IGdtDShcKFRDTiwgVENDXCkpc2hvdw00MTggMTA4IGdtDShhZGQgKXNob3cNNDE4IDE5 OCBnbQ0oXChUQ04sIFRDQ1wpKXNob3cNNDMwIDEwOCBnbQ0oZGVsZXRlIClzaG93DTQz MCAxOTggZ20NKFwoVENOLCBUQ0NcKSlzaG93DTQ0MiAxMDggZ20NKGxpc3QgKXNob3cN NDQyIDE5OCBnbQ0oXChUQ05cKSlzaG93DTQ2NSA3MiBnbQ1idSBmYw0yIEYgL3xfX19f X19UaW1lcy1Sb21hbiBmbnQNYm4NKEl0XDMyNXMgcGVyaW9kaWMgbmF0dXJlIHN1Z2dl c3RzIHRoYXQgYSBzaW1wbGUgdHJhbnNhY3Rpb24gcHJvdG9jb2wgd2lsbCBzdWZmaWNl LCBzdWNoIGFzIG92ZXIgVURQLilzaG93DTUwMiA3MiBnbQ0xIGZzDWJ1IGZjDTIgRiAv fF9fX19fX0hlbHZldGljYS1Cb2xkIGZudA1ibg0oNC4pc2hvdw01MDIgMTA4IGdtDShV U0UgT0YgVENOUyBCWSBUUkFOU1BPUlQgU0VSVklDRVMpc2hvdw01MjYgNzIgZ20NMCBm cw1idSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKFdoaWxlIGFjdHVh bCBpbXBsZW1lbnRhdGlvbnMgbWF5IGJlaGF2ZSBpbiBhIGZhciBtb3JlIGludGVncmF0 ZWQgZmFzaGlvbiwgdGhlIG1vZGVsIGZvcilzaG93DTUzOCA3MiBnbQ0odHJhbnNwb3J0 L25ldHdvcmsgaW50ZXJhY3Rpb25zIGhhcyBhIHRyYW5zcG9ydCBzZXJ2aWNlIGJ1aWxk IGEgdHJhbnNwb3J0IHNlZ21lbnQgYW5kIHRoZW4gcGFzcyBpdCB0bylzaG93DTU1MCA3 MiBnbQ0odGhlIG5ldHdvcmsgc2VydmljZSBmb3IgYWRkaXRpb25hbCBoYW5kbGluZy4g IFVzZSBvZiBhIHRyYW5zcG9ydCBjb250ZXh0IGNoYW5uZWwgbW9kZWwgcmVxdWlyZXMp c2hvdw01NjIgNzIgZ20NKGluc2VydGluZyBhbiBleHRyYSBkZWNpc2lvbiBwcm9jZXNz IHByaW9yIHRvIHBhc3NpbmcgdGhlIHNlZ21lbnQgZG93biB0byB0aGUgbmV0d29yayBz ZXJ2aWNlLClzaG93DTU3NCA3MiBnbQ0oc2luY2UgdGhlIHRyYW5zcG9ydCBtdXN0IGRl Y2lkZSB3aGljaCBvZiBsaXN0ZWQgbmV0d29yayBjaGFubmVscyBzaG91bGQgYmUgdXNl ZC4gIEluIG9yZGVyIHRvKXNob3cNNTg2IDcyIGdtDShrZWVwIGluZm9ybWF0aW9uIGFi b3V0IGNoYW5uZWwgYmVoYXZpb3IsIGEgdHJhbnNwb3J0IHNlcnZpY2UgbWlnaHQgZG8g cm91bmQtcm9iaW4gdXNlIG9mIHRoZSlzaG93DTU5OCA3MiBnbQ0oYXZhaWxhYmxlIHNl dC4gIFdoZW4gYSBzZWdtZW50IG5lZWRzIHRvIGJlIHJldHJhbnNtaXR0ZWQsIHRoZSB0 cmFuc3BvcnQgc2VydmljZSBtaWdodCBjaG9vc2UgdG8pc2hvdw02MTAgNzIgZ20NKHNl bmQgaXQgb3ZlciBhIGRpZmZlcmVudCBjaGFubmVsIHRoYXQgd2FzIGluaXRpYWxseSB1 c2VkLiAgR2l2ZW4gdGhlIGNvbXBsZXhpdHkgYW5kIHNlbnNpdGl2aXR5IG9mKXNob3cN NjIyIDcyIGdtDShyZXRyYW5zbWlzc2lvbiBhbGdvcml0aG1zLCB0aGlzIHdpbGwgcmVx dWlyZSByZXNlYXJjaC4pc2hvdw02NDYgNzIgZ20NKEZvciB0cmFuc3BvcnQgc2Vydmlj ZXMsIGxpa2UgVENQXDMyNXMgdXNlIG9mIHRoZSBwc2V1ZG8taGVhZGVyLCB0aGF0IGlu dGVncmF0ZSBpbmZvcm1hdGlvbiBhYm91dCB0aGUpc2hvdw02NTggNzIgZ20NKG5ldHdv cmsgbGF5ZXIgaW50byB0aGUgdHJhbnNwb3J0IHByb3RvY29sLCByZS1kZWZpbml0aW9u IG9mIHRoZSBjYWxjdWxhdGlvbnMgbmVlZCB0byBhY2NvdW50IGZvciB0aGUpc2hvdw02 NzAgNzIgZ20NKHZhcmlhYmlsaXR5IGluIG5ldHdvcmstbGF5ZXIgaGVhZGVycy4pc2hv dw1GIFQgY3ANJSVQYWdlOiA/IDUNb3ANMzEgMzAgeGwNMSAxIHBlbg02NzAgMjQ2IGdt DShuYyAzMSAzMCA3NjEgNTgyIDYgcmMpa3ANODEgNzIgZ20NMCBncg1UIDEgc2V0VHhN b2RlDTAgZnMNMTAgZnoNYnUgZmMNMiBGIC98X19fX19fVGltZXMtUm9tYW4gZm50DWJu DShJbnRlcm5ldCBEcmFmdClzaG93DTgxIDI1NCBnbQ0oVHJhbnNwb3J0IENvbnRleHQg TmFtZXMpc2hvdw04MSA0ODYgZ20NKEF1Z3VzdCwgMTk5NClzaG93DTcxOCA3MiBnbQ0o RC4gQ3JvY2tlcilzaG93DTcxOCA1MDYgZ20NKFtQYWdlIDVdKXNob3cNMTA1IDcyIGdt DTEgZnMNMTIgZnoNYnUgZmMNMiBGIC98X19fX19fSGVsdmV0aWNhLUJvbGQgZm50DWJu DSg1LilzaG93DTEwNSAxMDggZ20NKEVYQU1QTEUpc2hvdw0xMzAgMTE4IGdtDTAgZnMN YnUgZmMNMiBGIC98X19fX19fQ291cmllciBmbnQNYm4NKEhPU1Q6ICBTVEFCTEUuT1JH KXNob3cNMTMwIDM3MiBnbQ0oSE9TVDogIE1PQklMRS5PUkcpc2hvdw0xNDIgODAgZ20N KFwoSVAgYWRkcmVzczogIDE5Mi4yNTQuMjU0LjFcKSlzaG93DTE0MiAzMzQgZ20NKFwo SVAgYWRkcmVzczogIDE5Mi4yNTMuMjUzLjFcKSlzaG93DTE2NiA3MiBnbQ0oVENQIFNZ TiBcKDE5Mi4yNTQuMjU0LjEsKXNob3cNMTc4IDcyIGdtDSgxOTIuMjUzLjI1My4xLCAy MzQ1LDI1XCkpc2hvdw0xNjYgMjkyIGdtDSgtPilzaG93DTIwMiAxODUgZ20NKC4uLk5v cm1hbCBUQ1Agc2Vzc2lvbiBhY3Rpdml0eSAuLi4pc2hvdw0yMjYgMjkyIGdtDSg8LSlz aG93DTIyNiAzMjggZ20NKENPTlRST0wgQ0hBTk5FTDopc2hvdw0yMzggMzI4IGdtDShD UkVBVEUgXChUQ1AsIG1vYmlsZS5vcmcsKXNob3cNMjUwIDMyOCBnbQ0oc3RhYmxlLm9y ZywgMTkyLjI1My4yNTMuMSwpc2hvdw0yNjIgMzI4IGdtDSgxOTIuMjU0LjI1NC4xLCAy NSwgMjM0NVwpKXNob3cNMjg2IDcyIGdtDShDT05UUk9MIENIQU5ORUw6KXNob3cNMjk4 IDcyIGdtDShDUkVBVEUgXChUQ1AsIHN0YWJsZS5vcmcsKXNob3cNMzEwIDcyIGdtDSht b2JpbGUub3JnLCAxOTIuMjU0LjI1NC4xLClzaG93DTMyMiA3MiBnbQ0oMTkyLjI1My4y NTMuMSwgMjUsIDIzNDVcKSlzaG93DTI4NiAyOTIgZ20NKC0+KXNob3cNMzQ2IDE5NSBn bQ0oLi4uTW9yZSBUQ1Agc2Vzc2lvbiBhY3Rpdml0eS4uLilzaG93DTM3MCAzMjggZ20N KFwoSG9zdCBtb2JpbGUub3JnIG1vdmVzIHRvKXNob3cNMzgyIDMyOCBnbQ0obG9jYXRp b24gd2l0aCBvdmVybGFwcGluZylzaG93DTM5NCAzMjggZ20NKHNlcnZpY2VcKSlzaG93 DTQxOCAyOTIgZ20NKDwtKXNob3cNNDE4IDMyOCBnbQ0oQ09OVFJPTCBDSEFOTkVMOilz aG93DTQzMCAzMjggZ20NKEFERCBcKFRDUCwgbW9iaWxlLm9yZywpc2hvdw00NDIgMzI4 IGdtDShzdGFibGUub3JnLCAxOTIuMjUzLjI1My4yLClzaG93DTQ1NCAzMjggZ20NKDE5 Mi4yNTQuMjU0LjEsIDI1LCAyMzQ1XCkpc2hvdw00NzggNzIgZ20NKENPTlRST0wgQ0hB Tk5FTDopc2hvdw00OTAgNzIgZ20NKEFERCBcKFRDUCwgbW9iaWxlLm9yZywpc2hvdw01 MDIgNzIgZ20NKHN0YWJsZS5vcmcsIDE5Mi4yNTQuMjU0LjEsKXNob3cNNTE0IDcyIGdt DSgxOTIuMjUzLjI1My4yLCAyMzQ1LCAyNVwpKXNob3cNNDc4IDI5MiBnbQ0oLT4pc2hv dw01MzggMTA4IGdtDSguLi4pc2hvdw01MzggMTM5IGdtDShTZW5kaW5nIFRDUCBkYXRh IG5vdyByZXF1aXJlcyBjaG9pY2Ugb2Ypc2hvdw01NTAgMTM5IGdtDShjaGFubmVsLCBl aXRoZXIgXCgxOTIuMjUzLjI1My4xLCAxOTIuMjU0LjI1NC4xXCkpc2hvdw01NjIgMTM5 IGdtDShvciBcKDE5Mi4yNTMuMjUzLjIsIDE5Mi4yNTQuMjU0LjFcKSlzaG93DTUzOCA0 NzIgZ20NKC4uLilzaG93DTU4NiAzMjggZ20NKFwoSG9zdCBtb2JpbGUub3JnIG1vdmVz IGZ1bGx5KXNob3cNNTk4IDMyOCBnbQ0oaW50byBzZWNvbmQgc2VydmljZSBhcmVhXCkp c2hvdw02MjIgMjkyIGdtDSg8LSlzaG93DTYyMiAzMjggZ20NKENPTlRST0wgQ0hBTk5F TDopc2hvdw02MzQgMzI4IGdtDShERUxFVEUgXChUQ1AsIG1vYmlsZS5vcmcsKXNob3cN NjQ2IDMyOCBnbQ0oc3RhYmxlLm9yZywgMTkyLjI1My4yNTMuMSwpc2hvdw02NTggMzI4 IGdtDSgxOTIuMjU0LjI1NC4xLCAyNSwgMjM0NVwpKXNob3cNNjgyIDEwOCBnbQ0oLi4u KXNob3cNNjgyIDE0OCBnbQ0oU2VuZGluZyBUQ1AgZGF0YSBub3cgcmVxdWlyZXMgdXNl IG9ubHkgb2Ypc2hvdw02OTQgMTQ4IGdtDShjaGFubmVsIFwoMTkyLjI1My4yNTMuMiwg MTkyLjI1NC4yNTQuMVwpKXNob3cNNjgyIDQ3MiBnbQ0oLi4uKXNob3cNRiBUIGNwDSUl UGFnZTogPyA2DW9wDTMxIDMwIHhsDTEgMSBwZW4NNjgyIDQ5MyBnbQ0obmMgMzEgMzAg NzYxIDU4MiA2IHJjKWtwDTgxIDcyIGdtDTAgZ3INVCAxIHNldFR4TW9kZQ0wIGZzDTEw IGZ6DWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZudA1ibg0oSW50ZXJuZXQg RHJhZnQpc2hvdw04MSAyNTQgZ20NKFRyYW5zcG9ydCBDb250ZXh0IE5hbWVzKXNob3cN ODEgNDg2IGdtDShBdWd1c3QsIDE5OTQpc2hvdw03MTggNzIgZ20NKEQuIENyb2NrZXIp c2hvdw03MTggNTA2IGdtDShbUGFnZSA2XSlzaG93DTE0MSA3MiBnbQ0xIGZzDTEyIGZ6 DWJ1IGZjDTIgRiAvfF9fX19fX0hlbHZldGljYS1Cb2xkIGZudA1ibg0oNi4pc2hvdw0x NDEgMTA4IGdtDShESVNDVVNTSU9OKXNob3cNMTY1IDcyIGdtDTAgZnMNYnUgZmMNMiBG IC98X19fX19fVGltZXMtUm9tYW4gZm50DWJuDShUaGlzIHByb3Bvc2FsIHNlZWtzIHRv IHByb3ZpZGUgYSBsYXllcmVkIGZhY2lsaXR5IGZvciBlbmhhbmNpbmcgY2VydGFpbiBj aGFyYWN0ZXJpc3RpY3Mgb2YgSW50ZXJuZXQpc2hvdw0xNzcgNzIgZ20NKHNlcnZpY2Uu ICBJdCBwcm9wb3NlcyBhIG1lY2hhbmlzbSB3aGljaCBpbnZvbHZlcyBubyBjaGFuZ2Vz IGluIGV4aXN0aW5nIHBhY2tldCBmb3JtYXRzIGFuZClzaG93DTE4OSA3MiBnbQ0od2hp Y2ggcGVybWl0cyB1bm1vZGlmaWVkIHN5c3RlbXMgdG8gY29udGludWUgdG8gZnVuY3Rp b24gYXMgdGhleSBkbyB0b2RheSBpZiB0aGV5IGRvIG5vdCBuZWVkKXNob3cNMjAxIDcy IGdtDSh0aGUgbmV3IHNlcnZpY2VzLiAgRnVydGhlciwgaXQgZXhwbGljaXRseSBzZWVr cyB0byBhdm9pZCBjaGFuZ2luZyB0aGUgSW50ZXJuZXQgaW5mcmFzdHJ1Y3R1cmUsKXNo b3cNMjEzIDcyIGdtDShwcmVmZXJyaW5nIGluc3RlYWQgdG8gYWxsb3cgaW5jcmVtZW50 YWwgYWRvcHRpb24gYnkgcGFydGljaXBhdGluZyBob3N0cy4gIFRoZSBmYWNpbGl0eSB3 aWxsIHN1cHBvcnQpc2hvdw0yMjUgNzIgZ20NKGEgaGlnaCBkZWdyZWUgb2YgaG9zdCBt b2JpbGl0eSBhbmQgd2lsbCBwZXJtaXQgY29ubmVjdGlvbnMgd2l0aCBoaWdoIGRlZ3Jl ZXMgb2Ygcm9idXN0bmVzcyB0bylzaG93DTIzNyA3MiBnbQ0oaXNvbGF0ZWQgbmV0d29y ayBvdXRhZ2VzLCB3aGVuIGFuIGFsdGVybmF0ZSBwYXRoIGlzIGFscmVhZHkgYXZhaWxh YmxlLilzaG93DTI2MSA3MiBnbQ0oVGhlIEludGVybmV0IFByb3RvY29sIGlzIHRoZSBm b3VuZGF0aW9uIGZvciBJbnRlcm5ldCBzZXJ2aWNlcy4gIEl0IGlzIGdlbmVyYWxseSBy ZWdhcmRlZCBhcyBzYXRpc2Z5aW5nKXNob3cNMjczIDcyIGdtDSh0aGUgY29tcGV0aW5n IHByZXNzdXJlcyBvZiBiZWluZyBhcyBzaW1wbGUgYXMgcG9zc2libGUgYW5kIGFzIHJv YnVzdCBhcyBuZWNlc3NhcnkuICBPcGVyYXRpb24gb2Ypc2hvdw0yODUgNzIgZ20NKHRo ZSBJbnRlcm5ldCBpcyBleHRyZW1lbHkgZWZmaWNpZW50IGFuZCBkaWZmaWN1bHQuICBU aGlzIHByb3Bvc2FsIHNlZWtzIHRvIHJldGFpbiB0aGUgc2ltcGxpY2l0eSBhbmQpc2hv dw0yOTcgNzIgZ20NKHJvYnVzdG5lc3Mgb2YgdGhhdCBzZXJ2aWNlIGluIHRoZSBob3Bl IHRoYXQgaXRzIG9wZXJhdGlvbiBpcyBub3QgcGVydHVyYmVkIHVubmVjZXNzYXJpbHks IHNlZWtpbmcpc2hvdw0zMDkgNzIgZ20NKGluc3RlYWQgdG8gbGF5ZXIgaW1wb3J0YW50 IC0tIGJ1dCBuZXcgYW5kIHNwZWNpYWxpemVkIC0tIHNlcnZpY2VzIG91dHNpZGUgb2Yg dGhlIGNvcmUgSW50ZXJuZXQpc2hvdw0zMjEgNzIgZ20NKFByb3RvY29sIG9wZXJhdGlv bi4pc2hvdw0zNDUgNzIgZ20NKE1vYmlsaXR5IHJlcXVpcmVzIGEgbnVtYmVyIG9mIGNo YW5nZXMgdG8gSW50ZXJuZXQgc2VydmljZSBjb21wb25lbnRzLiAgRm9yIGhpZ2hseSBs b2NhbGl6ZWQpc2hvdw0zNTcgNzIgZ20NKG1vYmlsaXR5LCB1bmRlcmx5aW5nIG1lZGlh IHNlcnZpY2VzIG5lZWQgdG8gbWFrZSB0aGUgY2hhbmdlcyB0cmFuc3BhcmVudC4gIEZv ciBsb25nZXItdGVybSwpc2hvdw0zNjkgNzIgZ20NKGxvbmdlci1kaXN0YW5jZSBtb2Jp bGl0eSwgdGhlIGRvbWFpbiBuYW1lIHNlcnZpY2UgbmVlZHMgdG8gc3VwcG9ydCBkeW5h bWljIHJlZ2lzdHJhdGlvbiBvZilzaG93DTM4MSA3MiBnbQ0oYWRkcmVzcyBjaGFuZ2Vz LiAgSVAgYWRkcmVzc2VzIHBlcnRhaW4gdG8gaG9zdCBsb2NhdGlvbiB3aXRoaW4gdGhl IHRvcG9sb2d5IG9mIHRoZSBJbnRlcm5ldC4pc2hvdw0zOTMgNzIgZ20NKE1vYmlsaXR5 IGlzLCBieSBpdHMgZGVmaW5pdGlvbiwgdGhlIHByb2Nlc3Mgb2YgY2hhbmdpbmcgdGhh dCBsb2NhdGlvbi4gIFRoaXMgc2hvdWxkIG5hdHVyYWxseSBjYXVzZSBhKXNob3cNNDA1 IDcyIGdtDShob3N0XDMyNXMgSVAgYWRkcmVzcyB0byBjaGFuZ2UuICBUaGUgcHJvcG9z YWwgZGVzY3JpYmVkIGhlcmUgc3VwcG9ydHMgdGhlc2UgY2hhbmdlcyBuYXR1cmFsbHkg ZHVyaW5nKXNob3cNNDE3IDcyIGdtDSh0aGUgbGlmZXRpbWUgb2YgYSB0cmFuc3BvcnQg Y29udGV4dC4pc2hvdw00NTQgNzIgZ20NMSBmcw1idSBmYw0yIEYgL3xfX19fX19IZWx2 ZXRpY2EtQm9sZCBmbnQNYm4NKDcuKXNob3cNNDU0IDEwOCBnbQ0oUkVGRVJFTkNFUylz aG93DTQ3OCA3MiBnbQ0wIGZzDWJ1IGZjDTIgRiAvfF9fX19fX1RpbWVzLVJvbWFuIGZu dA1ibg0oW1RDUF0pc2hvdw01MTUgNzIgZ20NMSBmcw1idSBmYw0yIEYgL3xfX19fX19I ZWx2ZXRpY2EtQm9sZCBmbnQNYm4NKDguKXNob3cNNTE1IDEwOCBnbQ0oU0VDVVJJVFkg Q09OU0lERVJBVElPTlMpc2hvdw01MzkgNzIgZ20NMCBmcw1idSBmYw0yIEYgL3xfX19f X19UaW1lcy1Sb21hbiBmbnQNYm4NKFRoaXMgcHJvcG9zYWwgZGVzY3JpYmVzIGEgY29u dHJvbCBjaGFubmVsIGJldHdlZW4gaG9zdC1wYWlycywgdXNlZCB0byBhc3NpZ24gY2hh bm5lbHMgZm9yIGRhdGEpc2hvdw01NTEgNzIgZ20NKHRyYW5zZmVyLiAgVW5hdXRob3Jp emVkIHVzZSBvZiB0aGlzIGNoYW5uZWwgY291bGQgY2F1c2UgYSB0cmFuc3BvcnQgYXNz b2NpYXRpb24sIHN1Y2ggYXMgYSBUQ1Apc2hvdw01NjMgNzIgZ20NKGNvbm5lY3Rpb24s IHRvIGJlIHJlZGlyZWN0ZWQgdG8gYW4gaW5hcHByb3ByaWF0ZSBob3N0LiAgRm9yIG1v c3QgY3VycmVudCBob3N0IGV4Y2hhbmdlcywgY2FyZWZ1bClzaG93DTU3NSA3MiBnbQ0o YXR0ZW50aW9uIHRvIHRoZSBjaGFpbiBvZiBjaGFubmVsIGRpcmVjdGl2ZXMgc2hvdWxk IGdpdmUgdGhlIHJlY2lwaWVudCBhcyBtdWNoIGJhc2lzIGZvcilzaG93DUYgVCBjcA0l JVBhZ2U6ID8gNw1vcA0zMSAzMCB4bA0xIDEgcGVuDTU3NSA0ODMgZ20NKG5jIDMxIDMw IDc2MSA1ODIgNiByYylrcA04MSA3MiBnbQ0wIGdyDVQgMSBzZXRUeE1vZGUNMCBmcw0x MCBmeg1idSBmYw0yIEYgL3xfX19fX19UaW1lcy1Sb21hbiBmbnQNYm4NKEludGVybmV0 IERyYWZ0KXNob3cNODEgMjU0IGdtDShUcmFuc3BvcnQgQ29udGV4dCBOYW1lcylzaG93 DTgxIDQ4NiBnbQ0oQXVndXN0LCAxOTk0KXNob3cNNzE4IDcyIGdtDShELiBDcm9ja2Vy KXNob3cNNzE4IDUwNiBnbQ0oW1BhZ2UgN10pc2hvdw0xMDUgNzIgZ20NMSBmcw0xMiBm eg1idSBmYw0yIEYgL3xfX19fX19IZWx2ZXRpY2EtQm9sZCBmbnQNYm4NKDkuKXNob3cN MTA1IDEwOCBnbQ0oQUNLTk9XTEVER01FTlRTKXNob3cNMTQyIDcyIGdtDSgxMC4pc2hv dw0xNDIgMTA4IGdtDShDT05UQUNUKXNob3cNMTY3IDcyIGdtDTAgZnMNYnUgZmMNMiBG IC98X19fX19fQ291cmllciBmbnQNYm4NKERhdmlkIEguIENyb2NrZXIgIDxkY3JvY2tl ckBtb3Jkb3Iuc3RhbmZvcmQuZWR1PilzaG93DTE3OSA3MiBnbQ0oQnJhbmRlbmRidXJn IENvbnN1bHRpbmcpc2hvdw0xOTEgNzIgZ20NKDY3NSBTcHJ1Y2UgRHIuKXNob3cNMjAz IDcyIGdtDShTdW5ueXZhbGUsIENBICA5NDA4NilzaG93DTIyNyA3MiBnbQ0oUGhvbmU6 KXNob3cNMjI3IDE0NCBnbQ0oKzEgNDA4IDI0NiA4MjUzKXNob3cNMjM5IDcyIGdtDShG YXg6IClzaG93DTIzOSAxNDQgZ20NKCsxIDQwOCAyNDkgNjIwNSlzaG93DUYgVCBjcA0l JVRyYWlsZXINY2QNZW5kDSUlUGFnZXM6IDcgMA0lJUVPRg0= --========================_10246246==_ Content-Type: text/plain; charset="us-ascii" -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu --========================_10246246==_-- From owner-Big-Internet@munnari.OZ.AU Wed Oct 12 05:10:11 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06186; Tue, 11 Oct 1994 22:13:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14287 Tue, 11 Oct 1994 22:13:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA03878; Tue, 11 Oct 1994 22:03:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA03873; Tue, 11 Oct 1994 22:02:23 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01370; Tue, 11 Oct 1994 19:41:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 11 Oct 94 18:31:12 +0900 From: Masataka Ohta Message-Id: <9410110931.AA15505@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Tue, 11 Oct 94 18:31:10 JST Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 7, 94 12:08 pm X-Mailer: ELM [version 2.3 PL11] Dave; > The attached represents an initial proposal for accomplishing most of the > required mobility and robustness using a transport-level mechanism, with no > changes to IP (v4 or v6). Who required the mobility and roustness for EID? Or, in general, are there any requirement list for EID? > I'll note that a truly complete mobility mechanism needs what is described > in the attached AND: > > 1. Link-level mobility when the change is extremeley frequent and local > > 2. An ICMP "call forwarding" response, when the host's home network knows > to send callers (and, yes, this is a change to IP, but along the lines of > an ICMP Redirect, sortof.) > > 3. Dynamic update of data in the DNS (already in the works) "a truly complete mobility mechanism"? Mobile WG is working on mobility with fixed IP address(es), and I think that is practically enough (combined with above three, of course). You might be thinking that the true mobility should work even if IP address changes but host's domain name unchanged. But, I think, for "a truly complete mobility mechanism", mobility scheme should work even if host's domain name changes, as long as host's IDENTITY, represented by some identification scheme like public key even which may gradually change, unchanged. Too theoretical? But, host's domain name is not so meaningful to mobile end users who use locally-assigned temporal domain names through DHCP. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 01:21:38 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28404; Thu, 13 Oct 1994 01:21:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA18219 Thu, 13 Oct 1994 00:49:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA05379; Thu, 13 Oct 1994 00:49:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA05346; Thu, 13 Oct 1994 00:36:51 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25207; Thu, 13 Oct 1994 00:05:22 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: from necom830.cc.titech.ac.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02769 Wed, 12 Oct 1994 14:16:22 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 12 Oct 94 13:08:27 +0900 From: Masataka Ohta Message-Id: <9410120408.AA21629@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Wed, 12 Oct 94 13:08:25 JST Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 11, 94 8:28 am X-Mailer: ELM [version 2.3 PL11] > >Or, in general, are there any requirement list for EID? > > well, that IS a useful question. But we don't seem to be very good as > agreeing on requirements statements these days. True. But, then, isn't it better to say "objective" than "requirement". > >Mobile WG is working on mobility with fixed IP address(es), and I think > >that is practically enough (combined with above three, of course). > > Yes, well... I believe that mobility can and should be achieved without > making any changes to IP. I believe the mobility WG's approach is the best among all the approaches including those which changes IP. > >You might be thinking that the true mobility should work even if > >IP address changes but host's domain name unchanged. > > Not might. That is exactly what I am proposing. IP address pertains to > LOCATION on the net. That has been the motivation for locator/EID separation. > Mobility changes location. Hence it should change IP > address. That's not the view of the current mobile WG. Mobility does not change identity. Hence it should not change IP address. According to the view, mobility has nothing to do with EID/locator separation. Thus, to me, the only reason for EID/locator separation is for provider independence. Provider change does not change identity. Hence it does (with IPv4) and should not change IP address, which is why EID is useful. > Domain names are far more stable. One problem of domain names is that it is of variable length. > Domain name is exactly used for purposes of establishing identity. With DHCP assigned host name, I don't think it so true. > We don't need yet-another string to administer. It depends on the usefulness of EID. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 03:53:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05166; Thu, 13 Oct 1994 03:04:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA05515; Thu, 13 Oct 1994 03:03:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05499; Thu, 13 Oct 1994 02:44:39 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01778; Thu, 13 Oct 1994 02:10:46 +1000 (from dcrocker@mordor.stanford.edu) Received: from Mordor.Stanford.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA17527 Wed, 12 Oct 1994 01:32:23 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA27406; Tue, 11 Oct 1994 08:28:49 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 11 Oct 1994 08:28:52 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU At 2:31 AM 10/11/94, Masataka Ohta wrote: >Who required the mobility and roustness for EID? mobility is often cited, by many, as one of the functions for an EID. The robustness function is one that I added, since it happens to be easy to provide and is very, very useful for some applications. >Or, in general, are there any requirement list for EID? well, that IS a useful question. But we don't seem to be very good as agreeing on requirements statements these days. >Mobile WG is working on mobility with fixed IP address(es), and I think >that is practically enough (combined with above three, of course). Yes, well... I believe that mobility can and should be achieved without making any changes to IP. IP is a critical, well-understood function and one of its charms is how simple it was made. Originally, TCP and IP were one protocol. It was split into 2 so that services not needing the TCP functionality would not be burdened with it. While mobility is (going to be) wonderful, we should not burden the entire infrastructure with it. We need to keep IP as simple as possible. If a function can be provided adequately by layering on top of IP rather than changing IP, then that's what we should do. >You might be thinking that the true mobility should work even if >IP address changes but host's domain name unchanged. Not might. That is exactly what I am proposing. IP address pertains to LOCATION on the net. Mobility changes location. Hence it should change IP address. Domain names are far more stable. >But, I think, for "a truly complete mobility mechanism", mobility scheme >should work even if host's domain name changes, as long as host's >IDENTITY, represented by some identification scheme like public key >even which may gradually change, unchanged. Domain name is exactly used for purposes of establishing identity. We don't need yet-another string to administer. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 04:04:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07468; Thu, 13 Oct 1994 04:04:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05600; Thu, 13 Oct 1994 04:03:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA05568; Thu, 13 Oct 1994 03:48:49 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05140; Thu, 13 Oct 1994 03:03:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20836; Wed, 12 Oct 94 13:03:22 -0400 Date: Wed, 12 Oct 94 13:03:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410121703.AA20836@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU From: Masataka Ohta > IP address pertains to LOCATION on the net. That has been the motivation for locator/EID separation. > Mobility changes location. Hence it should change IP address. Mobility does not change identity. Hence it should not change IP address. I think I'm going to go bang my head on the wall. It will feel *sooooo* good when I stop. Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 04:05:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07484; Thu, 13 Oct 1994 04:05:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA05617; Thu, 13 Oct 1994 04:04:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA05571; Thu, 13 Oct 1994 03:52:20 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05446; Thu, 13 Oct 1994 03:13:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: from [18.26.0.82] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20087 Thu, 13 Oct 1994 03:12:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20883; Wed, 12 Oct 94 13:09:44 -0400 Date: Wed, 12 Oct 94 13:09:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410121709.AA20883@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Excuse me. "Address" pertains to location, not identity. You better check with the SIPP architect on that. Last time I looked, he wanted the term "address" to do both (and of course his design has only one namespace to do both). Please refer to Schoch's seminal paper distinguishing names, addresses, and routes. Also check out Saltzer, RFC-1498. I don't like his use of the term "address" to mean any binding process (preferring to go with your (and Schoch's) definition of an address as "where" something is) but other than that I think it is a much better paper than Shoch's (which it was written as a follow-on to). Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 12:58:30 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24046; Thu, 13 Oct 1994 12:19:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02471 Thu, 13 Oct 1994 12:08:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA06033; Thu, 13 Oct 1994 12:04:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA06017; Thu, 13 Oct 1994 11:54:32 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22960; Thu, 13 Oct 1994 11:54:18 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 13 Oct 94 10:46:36 +0900 From: Masataka Ohta Message-Id: <9410130146.AA27322@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Thu, 13 Oct 94 10:46:34 JST Cc: kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 12, 94 7:17 am X-Mailer: ELM [version 2.3 PL11] > >That has been the motivation for locator/EID separation. > > There have been many and varied motivations for EIDs. It often has been > quite difficult to find out what specific problems they are intended to > solve. It seems to me that EID discussion became complete chaos only because some thought it at the transport layer. > >> Mobility changes location. Hence it should change IP > >> address. > >Mobility does not change identity. Hence it should not change IP > >address. > > Excuse me. "Address" pertains to location, not identity. Say it to mobile WG. "Address" pertains to the location of the home network, that is, identity. > Please refer to > Schoch's seminal paper distinguishing names, addresses, and routes. > Addresses refer to the "where" of a thing. When you say identity, you > presumably are meaning it's "name". Don't also forget that, with IPv4, address is NOT hierarchical that, IPv4 address is provider independent and it is much more for identification than locating. > >One problem of domain names is that it is of variable length. > > that is not a "problem" for the proposal I've made. Yes, you can handle variable length NSAP address, as well. > Whether it is a > problem in other circumstances is for a separate discussion. Sure. > >> Domain name is exactly used for purposes of establishing identity. > > > >With DHCP assigned host name, I don't think it so true. > > Use of DHCP isn't the issue. How the names are assigned is the issue. If > DHCP keeps assigning the same name, then there's no problem. Don't forget that you said "a truly complete mobility mechanism". If a host moves to a different place under different DHCP administration, what happens? > If it keeps > assigning different names, then I'm not sure there's much of a way to > maintain the "identity" of the host. EID may be made to be a more stable identification than host name. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 19:45:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09537; Thu, 13 Oct 1994 19:45:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA06423; Thu, 13 Oct 1994 19:44:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA06418; Thu, 13 Oct 1994 19:42:19 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07492; Thu, 13 Oct 1994 18:47:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25886; Thu, 13 Oct 94 04:47:23 -0400 Date: Thu, 13 Oct 94 04:47:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410130847.AA25886@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU From: Masataka Ohta It seems to me that EID discussion became complete chaos only because some thought it at the transport layer. I guess I'm to blame for that (even though I've always proposed that endpoint names are not at the transport layer, but below it, so that all transport layers can share a single mechanisms to change the locator<->endpoint_name binding, etc, etc). In part, this happened because people seemed to be having difficulty with the concept of endpoint, and exactly what it was that EID's named. When people were told that they named transport entities, they seemed to get it approximately, which was better than "not at all". Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 13 20:42:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10082; Thu, 13 Oct 1994 20:04:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA06453; Thu, 13 Oct 1994 20:04:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA06428; Thu, 13 Oct 1994 19:45:18 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09430; Thu, 13 Oct 1994 19:45:02 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 13 Oct 94 18:34:02 +0900 From: Masataka Ohta Message-Id: <9410130934.AA29846@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 13 Oct 94 18:34:00 JST Cc: dcrocker@mordor.stanford.edu, Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU In-Reply-To: <9410130847.AA25886@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 13, 94 4:47 am X-Mailer: ELM [version 2.3 PL11] > It seems to me that EID discussion became complete chaos only because > some thought it at the transport layer. > > I guess I'm to blame for that (even though I've always proposed that endpoint > names are not at the transport layer, but below it, so that all transport > layers can share a single mechanisms to change the locator<->endpoint_name > binding, etc, etc). It's OK to try to say "network layer EID is useful to be combined with port# to identify transport layer entity", which is totally different from claiming EID is at the transport layer. > In part, this happened because people seemed to be having difficulty with the > concept of endpoint, and exactly what it was that EID's named. When people > were told that they named transport entities, they seemed to get it > approximately, which was better than "not at all". Considering that EID is derived from IP address, it is surprising that so many people want to relate it to the transport layer. It is also surprising that those who want to relate EID and mobility ignore that a host, a network layer entity, moves as a whole. Masataka Ohta PS Layering is for specification. Wrong layering is fatal for the discussion of specification. From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 03:19:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23927; Fri, 14 Oct 1994 03:19:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06959; Fri, 14 Oct 1994 03:19:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06912; Fri, 14 Oct 1994 02:44:55 +1000 Precedence: list Received: from uu6.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21863; Fri, 14 Oct 1994 02:16:51 +1000 (from eric@isci.com) Received: from isci.com by uu6.psi.com (5.65b/4.0.071791-PSI/PSINet) via SMTP; id AA22337 for kre@munnari.oz.au; Thu, 13 Oct 94 12:18:56 -0400 Message-Id: <9410131618.AA22337@uu6.psi.com> Date: Thu, 13 Oct 1994 12:12:33 +0000 From: Eric "D." Williams Subject: Re: Draft minutes - Toronto EID BOF To: Masataka Ohta Cc: jnc@ginger.lcs.mit.edu, dcrocker@mordor.stanford.edu, Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Organization: Open Systems Technology, Inc. Ufn: Eric Williams, OST, District of Columbia, US Dn: @c=US@o=OST%st=District of Columbia@cn=Eric Williams From: Masataka Ohta Date: Thu, 13 Oct 94 18:34:00 JST >> It seems to me that EID discussion became complete chaos only because >> some thought it at the transport layer. >> >> I guess I'm to blame for that (even though I've always proposed that endpoint >> names are not at the transport layer, but below it, so that all transport >> layers can share a single mechanisms to change the locator<->endpoint_name >> binding, etc, etc). > >It's OK to try to say "network layer EID is useful to be combined with >port# to identify transport layer entity", which is totally different >from claiming EID is at the transport layer. > >> In part, this happened because people seemed to be having difficulty with the >> concept of endpoint, and exactly what it was that EID's named. When people >> were told that they named transport entities, they seemed to get it >> approximately, which was better than "not at all". Noel, is it appropos to get an approximate understanding of what an EID "names" as opposed to it's function for the support of networked entities? My read is that the "naming derivation" will fall out of this functionality and then we can establish appropriate interfaces to network and transport entities to utilize this name-space in the internetwork. AM I MISSING SOMETHING? >Considering that EID is derived from IP address, it is surprising >that so many people want to relate it to the transport layer. Has the derivation of an EID been finalized? Should the EID really be 'derived from' the IP address? Has the issue been conceded since only one(?) name-space (in IPv6) for indicating 'identitity' to IP is available(?). If an EID is derived from the IP address is addressing mobile and distributed 'processes' scalable? >It is also surprising that those who want to relate EID and mobility >ignore that a host, a network layer entity, moves as a whole. Masataka, what about subnets that, may, move as a whole (as in a ship or plane) do these entities derive an EID based on IP subnet or individual host IP addresses? Peace, Eric Eric D. Williams Open Systems Technology Inc. OST ewilliams@isci.com or guru@isci.com - Fax +1(202)331-4049 or +1(202)872-0896 1899 L Street NW. Suite 500 - Washington, DC 20036-3804 - Voice +1(202)331-1262 From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 03:39:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23502; Fri, 14 Oct 1994 03:06:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06931; Fri, 14 Oct 1994 03:04:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06926; Fri, 14 Oct 1994 02:55:16 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23108; Fri, 14 Oct 1994 02:55:10 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA01099; Thu, 13 Oct 94 11:55:07 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:Big-Internet@munnari.oz.au id AA07871; Thu, 13 Oct 94 11:55:05 -0500 Date: Thu, 13 Oct 94 11:55:05 -0500 Message-Id: <9410131655.AA07871@benedick.ctd.anl.gov> To: Big-Internet@munnari.OZ.AU Subject: Re: Draft minutes - Toronto EID BOF From: "Richard Carlson" > Masataka Ohta Writes: >Considering that EID is derived from IP address, it is surprising >that so many people want to relate it to the transport layer. Well I for one don't agree with this statement at all. An EID is mapped to an IP address the same way that an IP address is mapped to an IEEE 802.3 MAC address. The EID provides another layer of abstraction hiding the details of the network from the user apps. Let me say this again. EID's and IP addresses are two separate, indepentent "things". Each "thing" is a collection of octets (0x00 - 0xFF). The octets are grouped together to form a fixed length string. The length of one string is indepentent of the length of any other string. My design calles for the EID to be included in the TCP header field of every packet sent between two communicating nodes (for unicast connections). The communicating TCP nodes use EID+port strings of the Src and Dest nodes to uniquely identify a socket. User applications use sockets when sending data between two separate Internet nodes. Others may (and have .-) disagreed with this model. However there are some who agree, and these are the people that want EID's in the transport layer, NOT the networking layer. ++Rich ---------------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory Phone: (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 03:44:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24880; Fri, 14 Oct 1994 03:44:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07003; Fri, 14 Oct 1994 03:44:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06987; Fri, 14 Oct 1994 03:38:36 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23728; Fri, 14 Oct 1994 03:12:27 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA12190; Thu, 13 Oct 1994 10:12:15 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Oct 1994 10:12:24 -0700 To: Big-Internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Just a quick sanity check: The current round of discussion seems to have gone off into the nether regions. I submitted a proposal describing a way to achieve some new functionality, in response to requirements that are often mentioned: mobility and outage-recovery. I don't much care whether it includes a thing called an EID or not. The issue here isn't termonology or modeling, but enhancing functionality. What would be helpful is for the proposal to be evaluated in terms of its likely effectiveness, compared against alternatives. What is NOT overly helpful is for us to conduct a debate about terminology and abstractions. Honest, folks. Let's try to focus on the utility or problems with the proposal for accomplishing real work. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 04:05:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25481; Fri, 14 Oct 1994 04:05:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07034; Fri, 14 Oct 1994 04:04:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07019; Fri, 14 Oct 1994 03:46:21 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24902; Fri, 14 Oct 1994 03:46:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27848; Thu, 13 Oct 94 13:08:35 -0400 Date: Thu, 13 Oct 94 13:08:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410131708.AA27848@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu, kre@munnari.OZ.AU From: Masataka Ohta It's OK to try to say "network layer EID is useful to be combined with port# to identify transport layer entity", which is totally different from claiming EID is at the transport layer. RIght, that's basically what I was trying to do (tieit to something they did understand), except I must have said it wrong or something, because everyone jumped from "identifying transport layer entites" to "it's a transport layer name". Sigh. Layering is for specification. Wrong layering is fatal for the discussion of specification. Layering is also useful when thinking about architecture. In some sense, specification and architecture are the same thing, just at different degrees of details; the architecture is the picture of how all the pieces fit together, and the specification is the fully detailed description of each piece. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 05:34:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27320; Fri, 14 Oct 1994 04:44:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07100; Fri, 14 Oct 1994 04:44:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07095; Fri, 14 Oct 1994 04:43:19 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27269; Fri, 14 Oct 1994 04:43:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28544; Thu, 13 Oct 94 14:43:05 -0400 Date: Thu, 13 Oct 94 14:43:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410131843.AA28544@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu The current round of discussion seems to have gone off into the nether regions. I submitted a proposal describing a way to achieve some new functionality, in response to requirements that are often mentioned ... What is NOT overly helpful is for us to conduct a debate about terminology and abstractions. .. Let's try to focus on the utility or problems with the proposal for accomplishing real work. Big-I is probably the wrong place to take it up. Start a WG. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 05:50:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28838; Fri, 14 Oct 1994 05:24:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07149; Fri, 14 Oct 1994 05:24:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07144; Fri, 14 Oct 1994 05:20:57 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26851; Fri, 14 Oct 1994 04:33:51 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA12828; Thu, 13 Oct 1994 11:30:48 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 13 Oct 1994 11:30:50 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU At 10:08 AM 10/13/94, Noel Chiappa wrote: >understand), except I must have said it wrong or something, because everyone >jumped from "identifying transport layer entites" to "it's a transport layer >name". Sigh. just so there is no confusion, my proposal is for "transport context names" (TCN) which means that it very much DOES specify a name at the transport layer. The name is specifically independent of the internet/net layer. The rest of the proposal is for creating and modifying a list which maps a TCN to a list of network layer addresses, presumably IP addresses, but not inherently restricted to it. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 06:47:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29513; Fri, 14 Oct 1994 05:44:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07194; Fri, 14 Oct 1994 05:44:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07189; Fri, 14 Oct 1994 05:42:25 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25787; Fri, 14 Oct 1994 04:13:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28244; Thu, 13 Oct 94 14:13:27 -0400 Date: Thu, 13 Oct 94 14:13:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410131813.AA28244@ginger.lcs.mit.edu> To: eric@isci.com, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Eric "D." Williams Noel, is it appropos to get an approximate understanding of what an EID "names" as opposed to it's function for the support of networked entities? My read is that the "naming derivation" will fall out of this functionality and then we can establish appropriate interfaces to network and transport entities to utilize this name-space in the internetwork. AM I MISSING SOMETHING? Not really, it's just that some of us have had a clear idea all along what an EID "names". I guess it would be helpful to have the definition written down some place other than a mailing list archive, sigh. Using the terminology of RFF-1498 (which everyone *has* to read), an EID is one form of "name" for a thing called an "endpoint" (hence the E in EID). An endpoint is more or less what RFC-1498 calls a "node"; i.e. a host. I was originally (circa '87 or so) just going to use just that concept/term, but Dave Oran pointed out (at the San Diego IETF, wheneever that was) that it would be more useful to generalize it to handle mobile objects, etc. This caused the development of the endpoint concept, which is tightly connected to the "fate-sharing" principle behind TCP-IP (see "Design Philosophy of the DARPA Internet Protocols", by Dave Clark, for more about "fatesharing"), and the end-end design principle (see "End-End Arguments in System Design", by Saltzer, Reed and Clark). Some day I may get these made into RFC's too.. An endpoint is a "fate-sharing region", or the "entity at one end of an end-end communication". When you understand both of these deeply enough, you see it's like the wave/particle duality in physics; they are two sides of one thing. I'm actually no longer sure I like the "EID" kind of name for endpoints, although I still firmly believe we i) need to recognize the existence of endpoints, as separate entities from what RFC-1498 calls "network attachment points" (which I call "interfaces"), and ii) we need a separate, non-topological, namespace for endpoints. These two points allow separation of the concept of identity and location, which people are now sometimes thinking is a good thing. I have been persuaded by arguments on Big-I that the management of such another namespace, above and beyond the existing ones, would be sufficiently painful that it might not be worth it. I'm thus currently leaning to DNS names as alternatives for naming endpoints. Since DNS names can be arbitrary strings, provision of locally-created globally-unique names (for things like mobile entities) is now trivial; you append a process id, date-time-stamp, whatever, to your DNS name. We also don't have to worry about getting the size right, or running out of them! The exact mechanics of when these endpoint names get carried in packets, etc, is all up in the air. Of course, first you have to figure out whether the endpoint name is an internetwork layer name, or a transport layer name. I assume the former, but there is not agreement. If the former, you could use ESEL's in packets, or associate endpoints with flows, in which case the flow-id alone would identify the destination endpoint. Of course, for datagram applications you'd still have to send the whole endpoint name, at least if the endpoint identification is needed. (It would be nice if we had a term which meant "endpoint namespace"; both EID's and DNS names are different kinds of potential endpoint namespaces.) Historical sidenote: EID's came from two places. One was IPv4 compatability; reinterpreting the 32-bit field as an EID maximized the lifetime of IPv4. The second was for globally-unique (GU) flow identifiers. My thinking was that you needed them (to prevent hassles with collisions), and the best way was to tack a local flow-id onto a GU EID, which you had in the packet anyway (see point one). That way, you got twice the bang for bits in the header used to hold the EID; once as an EID, and again as part of the flow-id. However, for a variety of reasons, it doesn't seem like it will be possible to overload the EID, as the whole flow-id may need to be bashable. If you have to have a whole separate field for flow-id's, I currently think making them "path-unique" (i.e. not local, like X.25, or global, but something in between) is good, then you can get away with a nice short length like 16 or 32 bits. So, if that use for EID's is gone, EID's as a whole look less attractive. Has the issue been conceded since only one(?) name-space (in IPv6) for indicating 'identitity' to IP is available(?). The whole issue of how endpoints, and endpoints names, relate to IPv6 is completely outside the scope of anything I think about these days. Someone else will have to figure that out. If asked for clarification of theoretical design ideas, I can provide that, but in terms of IPng, I've given up on trying to convince anyone of anything along that front. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 13:26:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18353; Fri, 14 Oct 1994 13:26:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA07651; Fri, 14 Oct 1994 13:24:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA07635; Fri, 14 Oct 1994 13:09:37 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13274; Fri, 14 Oct 1994 11:19:37 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 14 Oct 94 10:07:44 +0900 From: Masataka Ohta Message-Id: <9410140107.AA03884@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: RACarlson@anl.gov (Richard Carlson) Date: Fri, 14 Oct 94 10:07:42 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9410131655.AA07871@benedick.ctd.anl.gov>; from "Richard Carlson" at Oct 13, 94 11:55 am X-Mailer: ELM [version 2.3 PL11] > Well I for one don't agree with this statement at all. An EID is > mapped to an IP address the same way that an IP address is mapped > to an IEEE 802.3 MAC address. All the ID's are mappable each other, of course, which means nothing. > The communicating TCP nodes use EID+port > strings of the Src and Dest nodes to uniquely identify a socket. That's exactly what is being done by IPv4 address. It's OK to try to say "network layer EID is useful to be combined with port# to identify transport layer entity", which is totally different from claiming EID is at the transport layer. So, > Let me say this again. EID's and IP addresses are two separate, > indepentent "things". Never say it again, please. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 13:31:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13696; Fri, 14 Oct 1994 11:26:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA07509; Fri, 14 Oct 1994 11:24:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA07504; Fri, 14 Oct 1994 11:21:52 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11610; Fri, 14 Oct 1994 10:43:37 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 14 Oct 94 09:35:34 +0900 From: Masataka Ohta Message-Id: <9410140035.AA03615@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Fri, 14 Oct 94 9:35:32 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 13, 94 10:12 am X-Mailer: ELM [version 2.3 PL11] > Just a quick sanity check: The current round of discussion seems to have > gone off into the nether regions. > > I submitted a proposal describing a way to achieve some new functionality, > in response to requirements that are often mentioned: mobility and > outage-recovery. My opinion is, as already stated, that it is wrong to relate mobility and the transport layer and that the mobility issue is solved by mobile WG perfectly well. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 14:05:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15120; Fri, 14 Oct 1994 12:04:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA07564; Fri, 14 Oct 1994 12:04:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA07548; Fri, 14 Oct 1994 11:54:45 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11485; Fri, 14 Oct 1994 10:41:48 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 14 Oct 94 09:28:20 +0900 From: Masataka Ohta Message-Id: <9410140028.AA03580@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: eric@isci.com (Eric "D." Williams) Date: Fri, 14 Oct 94 9:28:19 JST Cc: jnc@ginger.lcs.mit.edu, dcrocker@mordor.stanford.edu, Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU In-Reply-To: <9410131607.AA01760@necom830.cc.titech.ac.jp>; from "Eric "D." Williams" at Oct 13, 94 12:12 pm X-Mailer: ELM [version 2.3 PL11] > >It is also surprising that those who want to relate EID and mobility > >ignore that a host, a network layer entity, moves as a whole. > > Masataka, what about subnets that, may, move as a whole (as in a ship > or plane) do these entities derive an EID based on IP subnet or individual > host IP addresses? My point is that mobility is at the network layer. You may solve the subnet mobility as a collection of individual mobility, as a pure routing issue or you may be able to use link layer mobility. Anyway, there is no room for transport layer. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 14 14:54:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19181; Fri, 14 Oct 1994 13:45:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA07694; Fri, 14 Oct 1994 13:44:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA07689; Fri, 14 Oct 1994 13:42:52 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14638; Fri, 14 Oct 1994 11:50:43 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 14 Oct 94 10:39:47 +0859 From: Masataka Ohta Message-Id: <9410140140.AA04067@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 14 Oct 94 10:39:45 JST Cc: eric@isci.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9410131813.AA28244@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 13, 94 2:13 pm X-Mailer: ELM [version 2.3 PL11] > This caused the development of the endpoint concept, which is tightly connected > to the "fate-sharing" principle behind TCP-IP (see "Design Philosophy of the > DARPA Internet Protocols", by Dave Clark, for more about "fatesharing"), and > the end-end design principle (see "End-End Arguments in System Design", by > Saltzer, Reed and Clark). Some day I may get these made into RFC's too.. Your terminology is confusing, usually, end-end or endpoint is the word for the transport layer, while "end system" is at the network layer. > I have been persuaded by arguments on Big-I that the management of such > another namespace, above and beyond the existing ones, would be sufficiently > painful that it might not be worth it. I'm thus currently leaning to DNS names > as alternatives for naming endpoints. Though, to me, the use of DNS has been obvious solution for uniqueness management from the beginning, you can continue to use topology- independent fixed length binary EID with DNS. IPv4 addresses under "in-addr.arpa." are such examples. Don't confuse that DNS is hierarchically structured and that the hierarchy must correspond network topology. > Since DNS names can be arbitrary > strings, provision of locally-created globally-unique names (for things like > mobile entities) is now trivial; you append a process id, date-time-stamp, > whatever, to your DNS name. We also don't have to worry about getting the size > right, or running out of them! That's unnecessary complication. 8 byte fixed length is enough. > If the former, you could use ESEL's in packets, or associate endpoints > with flows, in which case the flow-id alone would identify the destination > endpoint. That is not true, if flow is to be used for policy routing shared by several transport connections. > However, for a variety > of reasons, it doesn't seem like it will be possible to overload the EID, as > the whole flow-id may need to be bashable. I can't understand what you want to say here. Global uniqueness is so easy, isn't it? > If you have to have a whole > separate field for flow-id's, I currently think making them "path-unique" > (i.e. not local, like X.25, or global, but something in between) is good, I think it no good for any purpose. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 04:23:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15666; Sat, 15 Oct 1994 03:04:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA08474; Sat, 15 Oct 1994 03:04:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08469; Sat, 15 Oct 1994 02:58:08 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13259; Sat, 15 Oct 1994 02:13:40 +1000 (from dcrocker@mordor.stanford.edu) Received: from Mordor.Stanford.EDU by shark.mel.dit.csiro.au with SMTP id AA22876 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 15 Oct 1994 00:14:43 +1000 Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA00614; Fri, 14 Oct 1994 07:09:25 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Oct 1994 07:09:28 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU At 5:28 PM 10/13/94, Masataka Ohta wrote: >My point is that mobility is at the network layer. On this, we simply disagree. My proposal is in direct response to the various efforts that are trying to impose the mobility requirement on the network layer. I say "impose" because we have a nice, efficient, stable network layer and I don't think we should burden it with specialized functions that are not needed by all participants and can be provided outside of the core infrastructure. My proposal attempts to demonstrate the viability of that view. To claim that mobility MUST be at the network layer, you need to make a very strong case indeed. For example, please explain why adequate functionality cannot be obtained with the scheme I am proposing. Note that that scheme requires modifications only in the leaves and not in the core of the net. >You may solve the subnet mobility as a collection of individual mobility, >as a pure routing issue or you may be able to use link layer mobility. I agree that we need link-layer, for highly local and variable mobility. It then is invisible to the upper layers. >Anyway, there is no room for transport layer. Rather than make such an assertion, please offer a substantive critique of my proposal. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 04:27:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18731; Sat, 15 Oct 1994 04:27:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA08573; Sat, 15 Oct 1994 04:24:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08563; Sat, 15 Oct 1994 04:12:59 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18192; Sat, 15 Oct 1994 04:12:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06111; Fri, 14 Oct 94 14:12:46 -0400 Date: Fri, 14 Oct 94 14:12:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410141812.AA06111@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > My point is that mobility is at the network layer. On this, we simply disagree. ... we have a nice, efficient, stable network layer and I don't think we should burden it with specialized functions that are not needed by all participants ... [my] scheme requires modifications only in the leaves and not in the core of the net ... To claim that mobility MUST be at the network layer, you need to make a very strong case indeed. I'm not sure there is any way to come to agreement here. I suspect that those who think mobility ought to be at the internetwork layer, or at least below the transport layer, feel that the case is adequately made by observing that any mechanism at the transport layer to provide mobility is going to have to be replicated for each additional type of tranport layer. That alone, absent a good reason why it should *not* be at the internetwork layer, seems good enough to me, and perhaps others. Your assertion that we have a "nice, efficient, stable [internetwork] layer" isn't good enough. We have a nice transport layer. Why put the burden of the mobility mechanism at that layer? Are there some functional reasons to do so? I cannot think of any. The point about "[not] burden it with specialized functions that are not needed by all participants" also contains no weight. Any mobility functionality, no matter which layer it is put at, is going to be mechanism which is not needed by all the clients of that layer. Likewise, saying your "scheme requires modifications only in the leaves" doesn't mean much. Every node has to contain at least part of the mechanism, lest we have a class of non-mobile clients which cannot communicate with mobile clients. In more detail technically, any mobility scheme implemented purely at the transport layer is going to have certain functionality which is the same in all transport layers, such as notification that a partner has moved to a new address, etc. If placed at a lower layer, this functionality can be shared between all clients, instead of being replicated. I can't think of any reason why you'd want to have differences in the basic functionality, such as the notification, between different transport layers. Sure, some transport layers may react differently than others, but that simply means the lower layer has to notify all transport clients when a change happens. However, as the RSVP group is discovering, this applies to more than just mobile hosts, it also applies when the *path* to a destination changes. These two events have exactly the same effects, as far as the transport layer can tell (i.e. attributes of the channel to the destination such as delay, etc, may change, and there will usually be some lost packets as a result). There is no way to move the path change to the transport layer, so the transport layer is going to have to deal with this kind of event from the lower layers anyway. In sum, short a better argument than "let's not disturb the existing internetwork layer" (a truly worthless argument from a design or long-term perspective) I suspect that those who think the proper place for mobility is below the transport layer will continue to think that. Do you have any *design* arguments as to why transport is the way to go? Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 06:45:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20702; Sat, 15 Oct 1994 05:27:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA08644; Sat, 15 Oct 1994 05:24:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA08638; Sat, 15 Oct 1994 05:19:07 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19137; Sat, 15 Oct 1994 04:36:12 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA01871; Fri, 14 Oct 1994 11:35:55 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Oct 1994 11:35:59 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: mohta@necom830.cc.titech.ac.jp, Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 11:12 AM 10/14/94, Noel Chiappa wrote: >isn't good enough. We have a nice transport layer. Why put the burden of fair question. The answer is a core-versus-leaves argument. In effect, my proposal wedges some mechanism above the internet layer and below those transports wishing to use it. Those that don't don't have to. It views mobility as a nice, but specialized, facility, rather than one which must go into the guts of the entire internet. THAT is the key point of the choice. The Internet layer is for everwhere. The transport layer is only for the leaves and only the leaves that want it. >The point about "[not] burden it with specialized functions that are not >needed by all participants" also contains no weight. Any mobility no weight? Noel, it was at the core of the original decision to create the TCP and IP split. Not burdening everyone with a facility needed only by some is a fundamental architectural choice. >However, as the RSVP group is discovering, this applies to more than just >mobile hosts, it also applies when the *path* to a destination changes. These yes, well, that's what the 'robustness' use for my proposal covers, and for the same reason. >In sum, short a better argument than "let's not disturb the existing >internetwork layer" (a truly worthless argument from a design or long-term what a clever reductio ad absurdem summary of my statement. Let's try again, Noel: I said: It works well and only barely. We should not place functionality into it that we don't have to. While you may not think it important to keep ones hands off of something that is fragile, I do. I hope others do, too. And while you may not think it important to keep the core internet technology as simple as we can get away with, I do. I hope others do, too. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 07:48:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23722; Sat, 15 Oct 1994 07:04:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA08748; Sat, 15 Oct 1994 07:04:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08732; Sat, 15 Oct 1994 06:50:28 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21874; Sat, 15 Oct 1994 06:03:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07165; Fri, 14 Oct 94 16:03:25 -0400 Date: Fri, 14 Oct 94 16:03:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410142003.AA07165@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp From: dcrocker@mordor.stanford.edu (Dave Crocker) my proposal wedges some mechanism above the internet layer and below those transports wishing to use it. On carefully reading your spec, you're basically correct, so I have to apologise for getting somewhat confused there by statements implying that your mechanism was at the transport layer. You're right, your mechanism *is* basically below the transport layer. However, your statement above is not completely accurate, from my reading of your proposal. First, there's a change to the application/transport interface, since connections are now identified by source and destination (DNS_name, protocol, port) tuples. (Incidentially, this introduces a problem, which is that this mobility mechanism cannot reliably be used for mobile computations, at least without more extensive changes than you currently contemplate, which I'll explain later.) Second, since some transports (e.g. TCP) identify connections using the source and destination address, which can now change, it requires changes to the transport layer internals of all such transport layers. Mind you, I think your approach *is* basically right, and these changes *are* needed in any reasonable solution. It views mobility as a nice, but specialized, facility, rather than one which must go into the guts of the entire internet.... The Internet layer is for everwhere. The transport layer is only for the leaves and only the leaves that want it. I can see no way in which inclusion of endpoint identification at the internetwork layer means it has to go "into the guts of the entire internet". The routers simply don't care about that information; they just forward the packets based on address, or flow, or whatever, as before. (For exmample, in SIPP terms, it could be carried by an "end-end" option.) Does it *have* to be *in* the internetwork layer? No, not really, we could define a separate, small, "end-end naming" layer, and cram that in there, but that's just labelling. The basic mechanisms, information flows, etc are all the same; it's just a matter of which label you put on it. In effect, your proposal is just such a thin layer, above internetworking, but below transport. While we're on this topic of "you only have to do it where it's needed", there's what I would deem a mis-statement in your proposal: It proposes a mechanism which involves no changes in existing packet formats and which permits unmodified systems to continue to function as they do today if they do not need the new services. ... preferring instead to allow incremental adoption by participating hosts. Depending on your interpretation of the phrase "unmodified systems continue to function", this may not be correct. If you view the ability of an unmodified host to talk to an actively mobile host as "continuing to function", your assertion is not true. You clearly need to have this protocol implemented on both ends before one end can be mobile. I would maintain that the majority of users would prefer this definition. Mobile phones wouldn't have made much market penetration if you couldn't talk to one which was moving with a regular phone. Again, not that I disagree with your approach; I think we do need to modify both ends. > The point about "[not] burden it with specialized functions that are not > needed by all participants" also contains no weight. it was at the core of the original decision to create the TCP and IP split. Not burdening everyone with a facility needed only by some is a fundamental architectural choice. Your statement is a gloss on a more complex issue. IP provided a number of functions *at the internetwork layer* that not all clients needed. For example, fragmentation, timestamps, etc. It is true that some of these functions were supported by fields present in all packets (i.e. as part of the fixed internetwork header), not as options (and yes, they probably made some bad choices as to what to include in the fixed header, as Steve has pointed out), but that's an orthagonal question. I mean, strictly speaking, you could make *everything* an option (including hop count, data length, source and destination address, etc). The process by which decide whether to make something an option or not is very simple. Basically, you ask "for function X, is this going to be used by 99% of the packets in the net, or 1%"? If it's 99%, you probably make it a fixed field, and if it's 1%, you make it an option. (No, I don't know where the break-even point is!) So, the first question in this case is "should any support for mobility be provided at the internetwork layer"? Actually, I claim the question is "should any support for the naming of endpoints be provided at the internetwork layer", and I think the answer is "yes". (To explain why, I'll have to go back to that bug I mentioned at the top.) Having answered that question, then you get to ask "should that support be a fixed field, or an option"? That's an engineering detail that I care about a lot less; right at the moment I don't have an opinion. To explain this bug I keep talking about, consider a mobile application, which has a TCP connection identified on its end by (a.b.c, TCP, 11137). It wants to move from the host attached at 1:...:16 (to use SIPP addresses) to the host attached at 2:...:32. Well, that's cool, you say, just add a new TCC (i.e. pair of host addresses). However, suppose that the host at 2:...:32 already has a TCP connection open on port 11137. Oooops. That's why I said, above, that this mechanism cannot be reliably used for mobile applications (as opposed to entire hosts). There is a probablity of a collision. The only way to fix this, without the ability to change port numbers (which involves changing the application interface, since a TCP connection would no longer be identified by a constant port number), and without the ability to add another address to that host (which may not be possible), is to add more information to the packet, to correctly identify which TCP port 11137 you're talking about. The only way to do that is to provide for naming the correct endpoint in the packet. You could include the complete DNS name (ugly), or use a ESEL, or if it's using a flow you could use the flow-id, but somehow you need more bits in the packet than you have (which of course contradicts one of your goals, which is no changes to packet formats). Now, maybe you just want to blow off supporting mobile applications. I don't know whether that's reasonable or not. I'd like to think that any mobility mechanism we use can be used to support that as well. > this applies to more than just mobile hosts, it also applies when the > *path* to a destination changes. yes, well, that's what the 'robustness' use for my proposal covers, and for the same reason. I'm talking about cases in which the addresses on each end stay the same, but the path through the fabric changes. This is quite different from your "robustness" point (which I assume includes changes of address). This may produce changes (to the delay, bandwidth, etc) which affect the transport layer in much the same way as a move by a mobile host. We should not place functionality into it that we don't have to. While you may not think it important to keep ones hands off of something that is fragile, I do. ... And while you may not think it important to keep the core internet technology as simple as we can get away with, I do. Simplicity is utterly useless if the result is something that doesn't do what you want. This mindless mania for simplicity is really misguided. Also, I'm pretty astonished by your characterization of the internetwork layer as "fragile". I can't quite understand where that came from, or what you're thiknking of. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 08:05:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25143; Sat, 15 Oct 1994 08:05:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA08817; Sat, 15 Oct 1994 08:04:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA08812; Sat, 15 Oct 1994 08:03:06 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25079; Sat, 15 Oct 1994 08:02:59 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id SAA12744; Fri, 14 Oct 1994 18:02:48 -0400 Date: Fri, 14 Oct 1994 18:02:48 -0400 From: Vadim Antonov Message-Id: <199410142202.SAA12744@titan.sprintlink.net> To: jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU >Mobile phones wouldn't have made much market penetration if you couldn't talk >to one which was moving with a regular phone. >Again, not that I disagree with your approach; I think we do need to modify >both ends. "I think" is a very polite way to state something as obvious as 2 + 2 = 4. Pure IPv4 and pure IPv6 hosts won't be interoperable. Period. If somebody thinks otherwise he's welcome to explain how my pure IPv4 host 199.0.55.78 will send datagrams to the host 0071.21AA.2912.1201.0000.1FFF.1901.7712. Thus making anything below application layer backward-compatible provides zero benefit. You'll have to run new software anyway and users really don't care how much differences is inside the new revision -- the amount of work to install it is exactly the same. (Don't tell me about NATs -- in the real life they're nearly useless, to the point that we have to switch to the new protocol, IPng). --vadim From owner-Big-Internet@munnari.OZ.AU Sat Oct 15 11:07:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29519; Sat, 15 Oct 1994 10:05:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA08933; Sat, 15 Oct 1994 10:04:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA08928; Sat, 15 Oct 1994 10:04:26 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27700; Sat, 15 Oct 1994 09:19:03 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA04042; Fri, 14 Oct 1994 16:18:35 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 14 Oct 1994 16:18:38 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp At 1:03 PM 10/14/94, Noel Chiappa wrote: >On carefully reading your spec, you're basically correct, so I have to >apologise for getting somewhat confused there by statements implying that your >mechanism was at the transport layer. You're right, your mechanism *is* I view the mechanism as more transport layer than not. A key distinction between transport and internet, as I've mentioned before, is whether it's in the internet infrastructure or only in the end-system leaf nodes. Since the proposal is for mechanism only in the leaves, it's best to class it as part of transport. On the other hand, the control channel mechanism ends up serving as a "shim" mini-layer below regular transport and above regular internet. Also, as you observe, there are significant changes that must be put into the regular transport layer. Later comments in your message suggest that this wasn't clear. Sure seemed clear to me, in the the proposal. >Mind you, I think your approach *is* basically right, and these changes *are* >needed in any reasonable solution. Frankly, I'm much more concerned about the philosophy of the approach than in the particular details in my proposal. Christian Huitema apparently is suggesting that the list of IP addresses be exchanged via TCP options, rather than a separate control channel. It will be interesting to compare complexity and power between the different proposals. >function", this may not be correct. If you view the ability of an unmodified >host to talk to an actively mobile host as "continuing to function", your Noel! Any mobile systems that you can talk to today you can talk to tomorrow. The word 'continue' is supposed to refer to standard CURRNENT practise. >assertion is not true. You clearly need to have this protocol implemented on >both ends before one end can be mobile. Yup. But only two at a time. You do not need to modify all of the intermediate nodes in order to get mobility running. Just the two participating end nodes. Do I believe that all end nodes eventually will be modified? Yes. But the usual transition question arises. Do we require lots of ducks to line up in a row before any useful work can get done or do we require only two at a time? I prefer the latter. >Mobile phones wouldn't have made much market penetration if you couldn't talk >to one which was moving with a regular phone. Mobile phones are an example of link-layer, not internet-layer mobility. The fact of mobility is entirely hidden from everyone but the local loop. >has a TCP connection open on port 11137. Oooops. That's why I said, above, >that this mechanism cannot be reliably used for mobile applications (as Tell you what, Noel. Show me some real world requirements for mobile applications, solving various issues of process migration separate from the protocol portion, and show me these requirements emerging in productions systems, and THEN I'll agree that we should treat that deficiency as a showstopper. I suspect we also can provide a fix. Failing that, what other problems do you see with the proposal? >Now, maybe you just want to blow off supporting mobile applications. I don't Yup. >know whether that's reasonable or not. I'd like to think that any mobility >mechanism we use can be used to support that as well. I'd like world peace, too. But for the moment, I suggest we focus on pragmatic requirements that the community has some plausible understanding of, i.e., requirements which are not strictly in the realm of research. >I'm talking about cases in which the addresses on each end stay the same, but >the path through the fabric changes. This is quite different from your well, how is this visible to the end points? How does recovery from it result in anything different than sending to or from a different host interface? What specific suggestion are you making for changing the proposal or what alternative mechanism are you propsosing? >Also, I'm pretty astonished by your characterization of the internetwork layer >as "fragile". I can't quite understand where that came from, or what you're I'm thinking of the amount and nature of the effort it takes to keep it running and how often there are serious operational problems. The thing works, but we should not go around messing with it. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Mon Oct 17 07:45:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13968; Mon, 17 Oct 1994 07:45:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA11224; Mon, 17 Oct 1994 07:45:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA11208; Mon, 17 Oct 1994 07:26:55 +1000 Precedence: list Received: from orion.nemc.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13371; Mon, 17 Oct 1994 07:26:50 +1000 (from jason@orion.nemc.org) Received: (from jason@localhost) by orion.nemc.org (8.6.9/8.6.9) id LAA23394 for big-internet@munnari.oz.au; Sun, 16 Oct 1994 11:53:20 -0400 From: "Jason A. Kates" Message-Id: <199410161553.LAA23394@orion.nemc.org> Subject: I would like to subscribe. To: big-internet@munnari.OZ.AU Date: Sun, 16 Oct 1994 11:53:19 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 841 subscribe jason@nemc.org I would like to say that I am sorry if I am sending this to the wrong address. I could not find any other address for this group such as major-domo or a list-server at this site. This is why I am sending to this address, even though I am not sure if the program running the list will filter this out. :-( Thanks -Jason ----------------------------------------------------------------------------- Jason A. Kates (jason@nemc.org) New England Medical Center - 80 Boylston St. 11th Floor. - Boston, MA 02116 ----------------------------------------------------------------------------- Disclaimer: The above is my personal opinion, and may not necessarily represent the opinions of NEMC, its management, or its staff. ============================================================================= From owner-Big-Internet@munnari.OZ.AU Mon Oct 17 20:52:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09477; Mon, 17 Oct 1994 19:07:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA11813; Mon, 17 Oct 1994 19:05:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA11808; Mon, 17 Oct 1994 18:58:27 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09109; Mon, 17 Oct 1994 18:57:06 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 17 Oct 94 17:35:22 +0900 From: Masataka Ohta Message-Id: <9410170835.AA01822@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Mon, 17 Oct 94 17:35:20 JST Cc: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 14, 94 4:18 pm X-Mailer: ELM [version 2.3 PL11] > >On carefully reading your spec, you're basically correct, so I have to > >apologise for getting somewhat confused there by statements implying that your > >mechanism was at the transport layer. You're right, your mechanism *is* > > I view the mechanism as more transport layer than not. A key distinction > between transport and internet, as I've mentioned before, is whether it's > in the internet infrastructure or only in the end-system leaf nodes. That's complete misunderstnding on layering. You can connect two IPv6 hosts without modifying all the intermediate routers recognize IPv6 addresses, which does not mean that IP addresses belong to the transport layer. The role of the internet layer is to relay data between hosts. The role of the trasnport layer is to relay data between ports. That's the difference. Ports on a host does not move individually. Ports on a host moves as a whole. Any data exchanged between the hosts are equally afected by the move. Thus, mobility IS at the network layer. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Oct 17 22:08:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12106; Mon, 17 Oct 1994 20:26:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA11903; Mon, 17 Oct 1994 20:25:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA11887; Mon, 17 Oct 1994 20:11:01 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08177; Mon, 17 Oct 1994 04:02:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18892; Sun, 16 Oct 94 14:02:23 -0400 Date: Sun, 16 Oct 94 14:02:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410161802.AA18892@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) I view the mechanism as more transport layer than not. A key distinction between transport and internet ... is whether it's in the internet infrastructure or only in the end-system leaf nodes. I don't think this is a workable distinction. There are a number of things at the internet layer (in which I include ICMP) which are host-host, and not used by the intermediate forwarding nodes. Of course, since the internet layer is mostly concerned with getting the traffic across the forwarding nodes, most of the functions at that layer are indeed related to forwarding. However, as I'll explain below, on thinking about it I do think this is more of a transport level mobility mechanism (something which I think is bad), but not for the reason you give above. On the other hand, the control channel mechanism ends up serving as a "shim" mini-layer below regular transport and above regular internet. I don't see that there's a major utility for a host-host datagram layer on top of the forwarding layer; I think rolling those functions into the internetwork layer does not result in any decreased flexibility, etc. I thus think the internet layer ought to contain everything below individual transports, and which is done network-wide; i.e. addressing, routing, resource allocation, etc. As I mentioned in a previous message, whether you make something an option, as opposed to dedicated a field in the fixed header, is a 'trivial' engineering decision based on the frequency of use. However, to some degree it's just terminology, so let's skip it.. Also, as you observe, there are significant changes that must be put into the regular transport layer. Yes. It's this point that caused me the most thought; not that you propose changes, but the nature of the changes. The reason I had advocated naming endpoints was to allow all transport layers access to a uniform mechanism for identifying the other end of their channels, irrespective of the location of that endpoint, which interface it was using (on a multi-homed host), etc. The intent was that transport levels would not know about addresses at all, so they wouldn't have to get involved in the details of changing addresses; those grubby details would all be invisible to them. They would operate solely on endpoint names. The change you propose unfortunately doesn't have this characteristic. While transport *connections* may be identified by a endpoint name (the DNS name), the *packets* are not. The only thing that indentifies which connection a packet belongs to is the address. As a result, transport layers still have to know about addresses, and have to know when they change. Transport layers have to be prepared to map from addresses to what they use to identify connection (TCN's, including DNS names). Not such a big deal, you say? Well, there are a number of issues. To start with, there's a great irony. One of the big "points" raised against variable length addresses on this list was that it would make finding the connection control block much slower, due to the cost of handling a variable length data item. Of course, this was an utterly bogus argument, since any implementor who's vaguely competent would realize that checking port numbers first would speed this up to more or less what it was before. However, that didn't seem to make people happy with variable length addresses. Your TCCL, which contains a variable number of addresses (any of which might match the one in the packet) is just such a variable length data item, which must be inspected to find the matching CCB. If variable length addresses were unacceptable, why are variable length TCCL's any more so? (As a sidelight, that was one of the goals of EID's as endpoint names; as single, fixed-length, shortish names which never changed, transport layers could be converted to using them without a lot of upheaval.) However, the variable length thing is not a problem for me. I think competent programmers can make this stuff work. What *is* a concern (not quite a problem) to me, one I hadn't really realized was a problem (e.g. with ESEL's too) until now is that the packet does not fully identify which connection it belongs to (using the same info as the application names the connection with). I.e. the endpoint name is not in the packet. This represents a weak point, which could produce either failures (albeit low-probablity) or loss of flexibility. For an example of the former, consider a host H2 which moves to address X just after some other host H1 has left that address. H2 receives a delayed packet that was meant for H1; the packet is a TCP packet which happens to match an open connection, and is a reset. The packet will be accepted, and the connection closed. Of course, this particular scenario is very unlikely, but the fact that I can think one up so quickly is a bit worrisome. One way to attack this part of the problem (lack of endpoint identification in the packet) might be to include the endpoint name in the packet, but I think that's probably too brute force. A more space-efficient way is to use another field which is already there; i.e. to mandate authentication in the transport checksum. Including the endpoint name as part of the pseudo-header is probably the cheapest, as this can be precomputed when the connection is opened, and thus introduces no extra run-time cost. If you want to get really serious, and tamper-proof, encrypt the transport checksum with the endpoint's private key. That private key is as unique an endpoint name as you could hope for, and the approach of encrypting the checksum doesn't actually use any more bits in the packet (although there is more computational cost). Still, none of these are my main objection, which is that each and every transport layer which wishes to support mobility is going to have to include individual mechanisms to support TCCL's, etc. In this sense, it *is* a transport layer mechanism, as I stated above. It's just that you have taken some of the information distribution mechanism and moved that into a single protocol. (BTW, I think ICMP would be the way to go, not UDP). So, it's not as clean as a solution involving use of an endpoint name at the interface between the internet layer and the transport layer. I.e. the binding between address and endpoint name would be done within the internet layer. That would be optimal, and no, none of the mechanism for that has to be in *any* router, and no, it doesn't mean you have to change the internetwork packet header format. Christian Huitema apparently is suggesting that the list of IP addresses be exchanged via TCP options, rather than a separate control channel. In addition to the points above, this will mean that you need a separate mobility protocol for each transport layer. > If you view the ability of an unmodified host to talk to an actively > mobile host as "continuing to function", your assertion is not true. You > clearly need to have this protocol implemented on both ends before one > end can be mobile. Any mobile systems that you can talk to today you can talk to tomorrow. ... You do not need to modify all of the intermediate nodes in order to get mobility running. Just the two participating end nodes. Yes, but an unmodified sessile host cannot talk to a mobile host which is using your new protocol. I'm not saying this is bad; we don't have any SIPP hosts, so we could get this into them all. I just don't think your original statement in the document is completely correct. > Now, maybe you just want to blow off supporting mobile applications. Yup. ... Show me some real world requirements for mobile applications, solving various issues of process migration separate from the protocol portion, and show me these requirements emerging in productions systems, and THEN I'll agree that we should treat that deficiency as a showstopper. I seem to recall some from the previous debate, but I'm not an application wizard. Anyway, I don't care whether or not you support them, just wanted to make sure you realized this limitation. It might be nice to make a note of this design decision in your document. > I'm talking about cases in which the addresses on each end stay the > same, but the path through the fabric changes. how is this visible to the end points? How does recovery from it result in anything different than sending to or from a different host interface? What specific suggestion are you making for changing the proposal or what alternative mechanism are you propsosing? I was saying that if you hide the binding from address to endpoint name in the internetwork layer, so the transport layer doesn't even see it, the result to the transport layer, when mobility happens, is the same as having a path change. I.e. there's no *harm* to the transport layer in hiding that binding. It doesn't lose any info it's not already losing in other cases. > I'm pretty astonished by your characterization of the internetwork layer > as "fragile". I'm thinking of the amount and nature of the effort it takes to keep it running and how often there are serious operational problems. The thing works, but we should not go around messing with it. True, but I don't see what this has to do with that. That's almost 100% caused by the routing. (Since SIPP doesn't include any features which are not in CIDR IPv4 to attack routing problems, I fail to see how SIPP is going to help with that any, but I digress. That case is closed anyway.) Noel From owner-Big-Internet@munnari.OZ.AU Mon Oct 17 22:14:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12786; Mon, 17 Oct 1994 20:46:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA11933; Mon, 17 Oct 1994 20:45:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA11919; Mon, 17 Oct 1994 20:31:06 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07358; Mon, 17 Oct 1994 18:06:10 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 17 Oct 94 16:55:14 +0900 From: Masataka Ohta Message-Id: <9410170755.AA01553@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Mon, 17 Oct 94 16:55:13 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 14, 94 7:09 am X-Mailer: ELM [version 2.3 PL11] > To claim that mobility MUST be at the network layer, Wrong. Mobility IS at the network layer. > no weight? Noel, it was at the core of the original decision to create the > TCP and IP split. Not burdening everyone with a facility needed only by > some is a fundamental architectural choice. If a host moves, ALL transport layer entities on the host are affected equally, which can be processed in exactly the same fashion independent of specific transport layer properties. Thus, the mobility is processed below the transport layer. > Rather than make such an assertion, please offer a substantive critique of > my proposal. "Wrong layering" is substantive critique for architectural discussion. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Oct 17 22:25:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15042; Mon, 17 Oct 1994 22:25:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA12039; Mon, 17 Oct 1994 22:25:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA12023; Mon, 17 Oct 1994 22:15:58 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13361; Mon, 17 Oct 1994 21:10:30 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 17 Oct 94 19:59:37 +0900 From: Masataka Ohta Message-Id: <9410171059.AA02980@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 17 Oct 94 19:59:36 JST Cc: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9410161802.AA18892@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 16, 94 2:02 pm X-Mailer: ELM [version 2.3 PL11] > Christian Huitema apparently is suggesting that the list of IP addresses > be exchanged via TCP options, rather than a separate control channel. > > In addition to the points above, this will mean that you need a separate > mobility protocol for each transport layer. Connectionless way of thinking is so diifficult that one tends to assume TCP is everything. > I was saying that if you hide the binding from address to endpoint name in the > internetwork layer, so the transport layer doesn't even see it, the result to > the transport layer, when mobility happens, is the same as having a path > change. I.e. there's no *harm* to the transport layer in hiding that binding. > It doesn't lose any info it's not already losing in other cases. Yes, yes, yes. As both IP address and host name are at the internetwork layer, IP address hiding, if any, should be performed at the internetwork layer. Or, are there anyone who think host name is not at the internetwork layer? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 01:26:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20387; Tue, 18 Oct 1994 01:26:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12259; Tue, 18 Oct 1994 01:25:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12243; Tue, 18 Oct 1994 01:17:48 +1000 Precedence: list Received: from uu.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20133; Tue, 18 Oct 1994 01:17:38 +1000 (from cheysco!peter@uu.psi.com) Received: from cheysco.UUCP by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA13554 for ; Mon, 17 Oct 94 11:07:43 -0400 From: Peter Liu in CSI X-Mailer: SCO System V Mail (version 3.2) To: big-internet@munnari.OZ.AU Subject: help Date: Mon, 17 Oct 94 10:54:37 EDT Message-Id: <9410171054.aa00716@cheysco.chey.com> help From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 02:25:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22156; Tue, 18 Oct 1994 02:25:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12386; Tue, 18 Oct 1994 02:25:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12312; Tue, 18 Oct 1994 02:06:15 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21466; Tue, 18 Oct 1994 01:58:03 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 18 Oct 94 00:50:24 +0900 From: Masataka Ohta Message-Id: <9410171550.AA04324@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Tue, 18 Oct 94 0:50:23 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 17, 94 8:38 am X-Mailer: ELM [version 2.3 PL11] > As I've attempted to suggest strongly to Noel and will now also strongly > suggest to you, these clever, intense debates about modeling are not very > productive and it would be far more helpful if you would spend some time > reading specs and proposals and making specific criticisms or, better yet, > suggestions. Layering is for specification. Wrong layering makes specification discussion completely unproductive. If you don't think layering important, please don't insist on your layering and accept ours. > >Connectionless way of thinking is so diifficult that one tends to assume > >TCP is everything. > > You're right. finger, DNS, SNMP and those other services that use UDP > aren't all that important anyway, as well as the ones that are likely to > use RTP or the equivalent. And NFS? Anyway, that you use something only 10% of the time does not mean its specification or implementation needs 10% of TCP. > >> I was saying that if you hide the binding from address to endpoint name > >>in the > >> internetwork layer, so the transport layer doesn't even see it, the result to > > Good theory, bad practise. Layering is for thoery, not for practice. > TCP needs to calculate a checksum that includes > the pseudo-header. That includes the IP address. You can look at the hidden IP address at the lower implementation layer. It's no layering violation because implementation layering has only a slight relationships (if any) to specification layering. > If the TCP layer can > cope comfortably with varying contents in the IP address fields, then this > can be done cheaply. Proper specification layering does not prevent you from implementing it cheaply. > >As both IP address and host name are at the internetwork layer, > > Oh? This sounds like another assertion by fiat rather than truth. Just > because you are forceful in the assertion does not make it true. In fact, > it's a curious view, without much experiential basis I believe. Wow! What is the difference between % telnet necom830.cc.titech.ac.jp. and % telnet 131.112.32.132 ? Or are you trying to say that IP address is at the transport layer? > >Or, are there anyone who think host name is not at the internetwork > >layer? > > at least one. I suspected you are. Still, it's a complete surprise. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 02:47:03 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21752; Tue, 18 Oct 1994 02:10:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02997 Tue, 18 Oct 1994 02:08:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12307; Tue, 18 Oct 1994 02:05:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12304; Tue, 18 Oct 1994 02:02:18 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20772; Tue, 18 Oct 1994 01:39:30 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA01477; Mon, 17 Oct 1994 08:37:55 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 08:37:59 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: Big-Internet@munnari.OZ.AU At 12:55 AM 10/17/94, Masataka Ohta wrote: >> To claim that mobility MUST be at the network layer, > >Wrong. Mobility IS at the network layer. once again: please stop debating the fine points of the model and instead debate the fine points of specification. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 02:48:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21743; Tue, 18 Oct 1994 02:10:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12327; Tue, 18 Oct 1994 02:09:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12287; Tue, 18 Oct 1994 01:52:02 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20728; Tue, 18 Oct 1994 01:38:34 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA01480; Mon, 17 Oct 1994 08:38:00 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 08:38:04 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU Ohta-san, As I've attempted to suggest strongly to Noel and will now also strongly suggest to you, these clever, intense debates about modeling are not very productive and it would be far more helpful if you would spend some time reading specs and proposals and making specific criticisms or, better yet, suggestions. I sometimes comment that before the OSI reference model was created, folks in networking spent the first half of a discussion debating terms and reference points and the second half actually discussing useful content. After the OSI reference model was developed, things changed dramatically. People spent the first half of their discussion debating the problems with the OSI reference model. The purpose of a model is to give some cohesion to thought and guidance for design. It is NOT intended to force people to solve problems in the wrong way. At 3:59 AM 10/17/94, Masataka Ohta wrote: >Connectionless way of thinking is so diifficult that one tends to assume >TCP is everything. You're right. finger, DNS, SNMP and those other services that use UDP aren't all that important anyway, as well as the ones that are likely to use RTP or the equivalent. >> I was saying that if you hide the binding from address to endpoint name >>in the >> internetwork layer, so the transport layer doesn't even see it, the result to Good theory, bad practise. TCP needs to calculate a checksum that includes the pseudo-header. That includes the IP address. If the TCP layer can cope comfortably with varying contents in the IP address fields, then this can be done cheaply. >As both IP address and host name are at the internetwork layer, Oh? This sounds like another assertion by fiat rather than truth. Just because you are forceful in the assertion does not make it true. In fact, it's a curious view, without much experiential basis I believe. >Or, are there anyone who think host name is not at the internetwork >layer? at least one. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 02:48:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21881; Tue, 18 Oct 1994 02:16:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA12357; Tue, 18 Oct 1994 02:13:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12290; Tue, 18 Oct 1994 01:53:50 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20726; Tue, 18 Oct 1994 01:38:01 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA01469; Mon, 17 Oct 1994 08:37:39 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 08:37:43 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU Noel (et al), At 11:02 AM 10/16/94, Noel Chiappa wrote: >I don't think this is a workable distinction. There are a number of things at >the internet layer (in which I include ICMP) which are host-host, and not used Well, yes, we COULD spend lots of time debating this kind of issue (and in fact we already have) but let's not spend more. As I say, the useful work lies in debating the details of a spec and not the generics of a model. To the extent that you think my proposal wrong (or worse) then please submit a counter proposal with similar detail. >I don't see that there's a major utility for a host-host datagram layer on top the 'shim' that I referenced is not an added protocol "layer" but IS a way of putting a name-to-address mapping service between transport and internet. The only "protocol" modification is the control protocol for adding/removing name/address associations. Since it exists ONLY in the end-system hosts, I choose to call it transport layer. I don't care much about this, as long as it remains clear that intermediate nodes (routers) do not participate in ANY of the new mechanism. They do not require ANY modification. >them. They would operate solely on endpoint names. > >The change you propose unfortunately doesn't have this characteristic. While Right. I'm trying to make smaller changes, not bigger. We have an operating Internet and I'd like to create changes incrementally, rather than requiring that we change everything. In particular, we have an internet service that we understand reasonably well and which is the core to the world. I want to change it absolutely as little as possible. Perturb a working system and you usually get a non-working system. >packet belongs to is the address. As a result, transport layers still have to >know about addresses, and have to know when they change. Transport layers have The pseudo-header checksum calculation means they already DO know. I'm just trying to provide an easy mechanism for MOST of the work by the transport to be done in names and still allow the address-related calculations to be done cheaply. The level of change you want is fine research and I encourage you to pursue it, but please do not yank the working Internet around until such changes are tested. >didn't seem to make people happy with variable length addresses. Your TCCL, >which contains a variable number of addresses (any of which might match the >one in the packet) is just such a variable length data item, which must be >inspected to find the matching CCB. If variable length addresses were >unacceptable, why are variable length TCCL's any more so? Nice try, Noel. But, First, an incoming packet has a specific address and it is looked up in a connection table in the usual way. There doesn't even need to be any reference to the name/addresses mappings. The mappings are/were used to create the set of table entries for doing dispatch and therefore doesn't need to be consulted in real time for inbound packets. Second, an outgoing packet DOES need to choose an address for itself and an address for the destination. This is much akin to making routing decsisions. I'd class the details of this as extremely important engineering work to develop and get right, but we know how to do routing lookups. Given the reports of previous efforts on retransmission calculation, I suspect that it WILL take careful effort, though. >too) until now is that the packet does not fully identify which connection it >belongs to (using the same info as the application names the connection with). Yes it does. Same as today. The only difference is that now there may be more than one such identification for the same connection. That is, the TCN approach says that you can have multiple TCP connection ids for the same connection, with the source and/or destination IP addresses being different. Clearly, this does not tell you whether any two packets are related -- unless you know the connection table -- and that will make protocol analyzers unhappy, but a given packet very much does have full identification for the connection. >I.e. the endpoint name is not in the packet. This represents a weak point, >which could produce either failures (albeit low-probablity) or loss of No worse than we have today, since it permits the same information we have today. >after some other host H1 has left that address. H2 receives a delayed packet >that was meant for H1; the packet is a TCP packet which happens to match an One hopes that re-use of addresses is subject to the same sort of waiting time as is currently required for TCP port numbers. There is also a small matter of the sequence numbers. >So, it's not as clean as a solution involving use of an endpoint name at the Please tell me how you get the robustness functionality, with quick switching over to an alternate "path", without changing the transport layer. >I was saying that if you hide the binding from address to endpoint name in the >internetwork layer, so the transport layer doesn't even see it, the result to >the transport layer, when mobility happens, is the same as having a path >change. I.e. there's no *harm* to the transport layer in hiding that binding. >It doesn't lose any info it's not already losing in other cases. How does the transport layer recover quickly from outages along one of the paths? It needs to be able to switch over VERY quickly (e.g., one retransmion time) to the other path. Please explain the alternative mechanism that you are proposing for accomplishing this. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 03:45:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25152; Tue, 18 Oct 1994 03:45:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12559; Tue, 18 Oct 1994 03:45:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12554; Tue, 18 Oct 1994 03:41:13 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24824; Tue, 18 Oct 1994 03:41:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24705; Mon, 17 Oct 94 13:40:59 -0400 Date: Mon, 17 Oct 94 13:40:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410171740.AA24705@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) >> I was saying that if you hide the binding from address to endpoint name >> in the internetwork layer, so the transport layer doesn't even see it This is a clip from my message, so I'll reply to it.. Good theory, bad practise. TCP needs to calculate a checksum that includes the pseudo-header. That includes the IP address. If the TCP layer can cope comfortably with varying contents in the IP address fields, then this can be done cheaply. You have to change the TCP anyway. Why not change it so the pseudo-header does not include the address (which can change), but rather the DNS name, which will always be the same? It'll make the TCP simpler; you don't have to update the pseudo-header. It's also basically zero cost, even though the DNS name is a variable length data object, since you can precompute the partial checksum of the pseudo- header once (at connection setup time), and store it for use as a seed in all later checksum calculations. This will be even cheaper than recomputing it for each packet (as some implementations by less competent implementors do now). Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 03:53:59 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24258; Tue, 18 Oct 1994 03:21:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03966 Tue, 18 Oct 1994 03:11:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12487; Tue, 18 Oct 1994 03:05:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12471; Tue, 18 Oct 1994 02:47:01 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22057; Tue, 18 Oct 1994 02:21:10 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA02358; Mon, 17 Oct 1994 09:20:41 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 09:20:44 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU Masataka, At 8:50 AM 10/17/94, Masataka Ohta wrote: >> ... it would be far more helpful if you would spend some time >> reading specs and proposals and making specific criticisms or, better yet, >> suggestions. please read the above request, again. It appears that you either did not understand it the first time or wish to ignore it. If the latter, please state this explicitly, so that it will be clear you want to talk about something other than my proposal and I can let you pursue that on your own. Perhaps you believe that conducting endless discussion about layering theory is useful. It isn't. Please don't. Or at least, not on this thread. > % telnet 131.112.32.132 >Or are you trying to say that IP address is at the transport layer? Surely you jest? You think that the IP layer sees or knows about the domain name? In this case, the names don't even make it to the transport layer. Again, it will be helpful if you argue matters of operational reality and specification detail. Arguing the theory in the absence of these other two, minor perspectives really isn't very productive. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 03:54:31 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24260; Tue, 18 Oct 1994 03:21:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04028 Tue, 18 Oct 1994 03:13:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA12513; Tue, 18 Oct 1994 03:10:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA12468; Tue, 18 Oct 1994 02:46:51 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21753; Tue, 18 Oct 1994 02:10:19 +1000 (from dcrocker@mordor.stanford.edu) Received: from [36.53.0.155] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03000 Tue, 18 Oct 1994 02:08:59 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA01820; Mon, 17 Oct 1994 09:06:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 09:06:13 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.OZ.AU At 1:35 AM 10/17/94, Masataka Ohta wrote: >The role of the internet layer is to relay data between hosts. > >The role of the trasnport layer is to relay data between ports. This is absolutely correct in theory and quite wrong in practise. For the internet layer, we know how to move data between specific network attachment points (interfaces) and do not have any experience with the more general requirement for dealing with 'hosts'. The distinction is fundamental and is the reason for the approach taken in my proposal. A host may have multiple attachment points. We do not currently have a mechanism for treating them in a unified fashion. My proposal provides such a mechanism, but it does it without changing the current role of interent services. So, if you wish to take exception to my approach, please specify an alternative approach that accomplishes the same functions and without requiring changes to the intermediate nodes. To the extent that you think that you can change ONLY the internetwork services in hosts and not in routers, then you will have defined two interetwork services. While there are important differences between routers and hosts, they both use the same definition for IP. You would be making them use different definitions. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 04:12:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25841; Tue, 18 Oct 1994 04:05:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA12591; Tue, 18 Oct 1994 04:05:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12586; Tue, 18 Oct 1994 03:58:35 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24600; Tue, 18 Oct 1994 03:33:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24640; Mon, 17 Oct 94 13:33:28 -0400 Date: Mon, 17 Oct 94 13:33:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410171733.AA24640@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) the 'shim' that I referenced is not an added protocol "layer" but IS a way of putting a name-to-address mapping service between transport and internet. You say "shim", I say "layer". Let's move on. Since it exists ONLY in the end-system hosts, I choose to call it transport layer. Oh. What about the TCP's that are in routers, to make BGP work. I assume since that's in routers it's *not* a transport layer? Is an internet option that is used only in hosts transport level? Sorry, I just don't think the distinction you are drawing is useful. But let's skip it... > The change you propose unfortunately doesn't have this characteristic. Right. I'm trying to make smaller changes, not bigger. We have an operating Internet and I'd like to create changes incrementally, rather than requiring that we change everything. I understand that; you've said that 17 times already. I'm just making sure you understand the consequences of your decision; they aren't spelled out in detail in your draft. The level of change you want is fine research and I encourage you to pursue it, but please do not yank the working Internet around until such changes are tested. Look, I've given up on trying to convince you, and the rest of the IETF, to do anything. I don't give a rat's what you all do. I'm exploring the technical consequences of your proposal. If you want to listen, and make no changes, or not bother to listen, it's all the same to me. Do whatever you want. Now please stop this incessant moaning and whining about research and service; I find it enormously personally insulting and enraging, for reasons I won't belabor. Now, let's pass on to technical stuff. I don't care much about this, as long as it remains clear that intermediate nodes (routers) do not participate in ANY of the new mechanism. They do not require ANY modification. Yes, I think you and I both agree that the routers are best off just dealing in terms of addresses. (I understand that some schemes for retrofitting mobility use routers as base stations.) I don't advocate anything different. > As a result, transport layers still have to know about addresses, and > have to know when they change. The pseudo-header checksum calculation means they already DO know. I'm just trying to provide an easy mechanism for MOST of the work by the transport to be done in names and still allow the address-related calculations to be done cheaply. Sorry, I disagree with that characterization of the results of your proposal. Most of the functions performed by the transport layer which use either the address *or* name (in your new scheme) will continue to use the *address*, e.g. finding CCB's when packets arrive. (It won't be used at the application interface since an intelligently implemented application interface would only pass the DNS name on the "open" call, and use a handle thereafter - for data reads and writes, etc - as the handle will be more efficient.) The pseudo-header is an interesting point. If you indicate in your proposal that it should use the DNS name as the endpoint name to be included there, instead of the address (and in fact, it would have to, or you'd have to have a separate pseduo-header checksum seed for each TCC, if you wanted to precompute the seed), this would provide important protection against one class of bugs, as I pointed out. But it's up to you. In any case, none of this invalidates my main point: much of the mechanism of handling multiple address (e.g. in finding the correct CCB) is *still* going to have to be replicated for each transport layer to provide mobility. Hiding the address<->DNS binding *totally* below the transport layer would avoid this. > Your TCCL, which contains a variable number of addresses (any of which > might match the one in the packet) is just such a variable length data > item, which must be inspected to find the matching CCB. First, an incoming packet has a specific address and it is looked up in a connection table in the usual way. There doesn't even need to be any reference to the name/addresses mappings. The mappings are/were used to create the set of table entries for doing dispatch and therefore doesn't need to be consulted in real time for inbound packets. OK, so instead of looking at one variable length entry you are looking at several fixed length entries. Six of one... (It's also MxN, instead of M+N, if you have M potential source addresses and N potential destinations, but let's move on.) > H2 receives a delayed packet that was meant for H1 There is also a small matter of the sequence numbers. That's why I posited a Reset. Sequence numbers are ignored there... Please tell me how you get the robustness functionality, with quick switching over to an alternate "path", without changing the transport layer. If the transport layer knows *only* of endpoint names (i.e. DNS names), you don't have to do anything at the transport layer. Sure, you have to update the address<->DNS binding, but the mechanism needed to do that is the same whether it is wholly in internet, wholly in transport, or split between the two. Putting it wholly in the internet layer means you don't have to reimplement it again and again, for each transport. Also, a halfway competent implementor would implement the code such that use of the DNS name in the transport<->internet interface had no performance penalty. A database of "active" endpoints (i.e. the DNS names of endpoints which have active bindings, i.e. TCCL's) would allow DNS names to be passed by reference (i.e. a one-word pointer), for the maximally efficient interface. This would also result in very efficient processing at the transport layer. > I was saying that if you hide the binding from address to endpoint name > in the internetwork layer, so the transport layer doesn't even see it, > the result to the transport layer, when mobility happens, is the same as > having a path change. I.e. there's no *harm* to the transport layer in > hiding that binding. It doesn't lose any info it's not already losing in > other cases. How does the transport layer recover quickly from outages along one of the paths? It needs to be able to switch over VERY quickly (e.g., one retransmion time) to the other path. Please explain the alternative mechanism that you are proposing for accomplishing this. You seem to be missing the point I'm trying to make, that hiding the endpoint name <-> address binding where transport can't see it can't have any bad effects, since the routing changes the path now without the transport layer being involved. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 05:45:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27709; Tue, 18 Oct 1994 05:05:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12671; Tue, 18 Oct 1994 05:05:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA12664; Tue, 18 Oct 1994 05:01:27 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26933; Tue, 18 Oct 1994 04:38:49 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA03535; Mon, 17 Oct 1994 11:38:12 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 11:38:17 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: mohta@necom830.cc.titech.ac.jp, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 10:40 AM 10/17/94, Noel Chiappa wrote: >You have to change the TCP anyway. Why not change it so the pseudo-header does >not include the address (which can change), but rather the DNS name, which >will always be the same? It'll make the TCP simpler; you don't have to update >the pseudo-header. yeah, and then it will be useless. If you make the value a constant then it has no business being in the calculation at all. The purpose of having the address in the calculation is as an integrity check against the segment. Has this requirement been changed? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 05:46:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27833; Tue, 18 Oct 1994 05:07:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12686; Tue, 18 Oct 1994 05:07:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12647; Tue, 18 Oct 1994 04:46:00 +1000 Precedence: list Received: from nbkanata.Newbridge.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26480; Tue, 18 Oct 1994 04:19:32 +1000 (from jhalpern@Newbridge.COM) Received: from Newbridge.COM ([138.120.100.14]) by nbkanata.Newbridge.COM (4.1/SMI-4.1) id AA05904; Mon, 17 Oct 94 14:14:18 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA25271; Mon, 17 Oct 94 14:14:17 EDT Received: from lobster.Newbridge.COM by mako.newbridge (4.1/SMI-4.1) id AA02593; Mon, 17 Oct 94 14:20:08 EDT Received: by lobster.Newbridge.COM (5.0/SMI-SVR4) id AA02725; Mon, 17 Oct 1994 14:20:21 +0500 Date: Mon, 17 Oct 1994 14:20:21 +0500 From: jhalpern@Newbridge.COM (Joel Halpern) Message-Id: <9410171820.AA02725@lobster.Newbridge.COM> To: big-internet@munnari.OZ.AU Subject: Re: Draft minutes - Toronto EID BOF X-Sun-Charset: US-ASCII Content-Length: 959 Noel just suggested (and someone else also at least implied) that one could run the TCP pseudo-header checksum over the DNS name. I think that this would require that at least one packet each way have the DNS name in it. Previous discussion highlighted the fact that DNS does not currently require full consistency of names. There may be many names for the same host, and only one known to that host. This means that when the connected arrives, the receiver would have to assume it was for him (since the pseudo-header check would use the same value as was being passed for reference in some option). Once the connection was established, the psuedo-header would at least confirm that traffic was for the same connection. The initial connect would also have to carry the DNS name of the connecting host, so that the responder would have a name to use in its checksum generation. Yours, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 05:52:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27847; Tue, 18 Oct 1994 05:08:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA12705; Tue, 18 Oct 1994 05:08:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12650; Tue, 18 Oct 1994 04:47:01 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26487; Tue, 18 Oct 1994 04:20:26 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA03462; Mon, 17 Oct 1994 11:20:09 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 11:20:19 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU At 10:33 AM 10/17/94, Noel Chiappa wrote: >address *or* name (in your new scheme) will continue to use the *address*, Likely true. >e.g. finding CCB's when packets arrive. (It won't be used at the application >interface since an intelligently implemented application interface would only >pass the DNS name on the "open" call, and use a handle thereafter - for data That's an implementation choice, not a requirement. I think that defining a transport API to use names is fine, but it's not strictly required and, in fact, there is long history to suggest that we need to continue to ALLOW applications to use IP addresses, to get past anomolies with the DNS and local name mechanisms. However, such a change to the transport API is not REQUIRED. My application can pass down an IP address and it can be used as is currently done. Essentially asynchronously, the transport module can derive a DNS name to associate with that address, find (or assert) other IP addresses that are valid and use the control channel exchange to authorize their use for the connection. Modifying the transport API is entirely separate from the TCN spec or requirement. >The pseudo-header is an interesting point. If you indicate in your proposal >that it should use the DNS name as the endpoint name to be included there, Nope. You use the addresses that are supplied in the incoming segment. Same as now. Otherwise, why bother to do the calculation? The whole idea is to check that the address is valid. The change is to permit incoming segments to have different values for the same connection. >instead of the address (and in fact, it would have to, or you'd have to have a >separate pseduo-header checksum seed for each TCC, if you wanted to precompute "Seed"? Please explain. Each segment is an independent calculation. The sequence number is the glue that connects two segments. >In any case, none of this invalidates my main point: much of the mechanism of >handling multiple address (e.g. in finding the correct CCB) is *still* going >to have to be replicated for each transport layer to provide mobility. Hiding Probably true. And I share your basic distaste about this. On the other hand, the rules for determining use of alternate addresses is likely to be highly dependent upon the service requirements for a given transport module. For the moment, retransmission is embedded into the transport layer (or higher, such as with UDP, sigh) and THAT is where the real challenge resides, I believe. > There is also a small matter of the sequence numbers. > >That's why I posited a Reset. Sequence numbers are ignored there... Pardon? This is from RFC 793. And it wasn't changed in 1122. >In all states except SYN-SENT, all reset (RST) segments are validated > by checking their SEQ-fields. A reset is valid if its sequence number > is in the window. In the SYN-SENT state (a RST received in response It would seem to suggest that my previous assertions stands as correct. > Please tell me how you get the robustness functionality, with quick ... >If the transport layer knows *only* of endpoint names (i.e. DNS names), you >don't have to do anything at the transport layer. Sure, you have to update the >address<->DNS binding, but the mechanism needed to do that is the same whether The issue is not "updating the binding" but, rather, using alternate and multiple addresses simultaneously. In particular, it means that a re-transmitted segment may need to go to a different address (and out a different address) than it did originally. How are you going to hide this stateful decision from the transport layer? Just to make sure the functional requirement is clear: I'm sending data on a connection. I do not want large delays in transmission caused by network (or host interface) problems. That is, I want my connection to continue with successful transmissions faster than the internet routing protocols will tolerate (otherwise they start getting unstable.) So, how do you accomplish this without having the transport layer aware of multiple "paths" and without being highly intelligent (i.e., stateful) in their use? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 07:25:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01809; Tue, 18 Oct 1994 07:25:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12843; Tue, 18 Oct 1994 07:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12827; Tue, 18 Oct 1994 07:20:52 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01645; Tue, 18 Oct 1994 07:20:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26222; Mon, 17 Oct 94 17:20:40 -0400 Date: Mon, 17 Oct 94 17:20:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410172120.AA26222@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) > [The DNS name] won't be used at the application interface since an > intelligently implemented application interface would only pass the DNS > name on the "open" call, and use a handle thereafter That's an implementation choice, not a requirement. Well, now I'm confused. If the TCN's are in terms of DNS names, how does that info get into the transport layer? I assume that the application is going to have to tell TCP somehow; might as well be the open. Also, yes, to some extent you can make the details of the application interface a local issue, but basic functionality does need to be specified, and RFC's 793 and 1122 both do this. I'd think such an important point as which namespace the other end of the connection is specified in would be something you'd want to specify. there is long history to suggest that we need to continue to ALLOW applications to use IP addresses, to get past anomolies with the DNS and local name mechanisms. Good point, but then DNS names aren't *really* a first-class namespace for endpoints, just a frill. > The pseudo-header is an interesting point. If ... it should use the DNS > name as the endpoint name to be included there Nope. You use the addresses that are supplied in the incoming segment. Same as now. Otherwise, why bother to do the calculation? The whole idea is to check that the address is valid. The change is to permit incoming segments to have different values for the same connection. The reason the IP address is in the pseudo-header *now* is to make sure the packet is from the person you thought it was from. Since the address was the only identification of the entity on the other end that we had in IPv4, that's why it is used there. The TCN implies that the entity on the other end of connection is named by the DNS name. That's what you should include in the pseudo-header. > a separate pseduo-header checksum seed for each TCC, if you wanted > to precompute "Seed"? Please explain. Each segment is an independent calculation. The sequence number is the glue that connects two segments. If you write a checksum routine which doesn't start with a 0 in the sum register, but which you can pre-load with a value passed as an argument (the "seed"), you can precompute the partial checksum for any invariant part of the buffer (such as the pseudo-header), and skip checksumming that part when you need to compute the checksum of the whole buffer. You just pass in that precomputed partial checksum as the seed, and start checksumming after the part you precomputed the partial checksum for. > much of the mechanism of handling multiple address (e.g. in finding the > correct CCB) is *still* going to have to be replicated for each transport > layer to provide mobility. Probably true. And I share your basic distaste about this. Which is why I prefer to embed the binding in the internetwork layer. But do whatever you want... For the moment, retransmission is embedded into the transport layer (or higher, such as with UDP, sigh) and THAT is where the real challenge resides, I believe. It would be nice to have a reliable datagram protocol that all the applications which currently roll their own use. Some day... > That's why I posited a Reset. Sequence numbers are ignored there... Pardon? This is from RFC 793. And it wasn't changed in 1122. Sorry, you're right, I didn't check the details; I knew you were allowed some variance in sequence numbers, didn't remember about it having to be in the window. Other protocols might be easier to zap with the same basic bug, though. The issue is not "updating the binding" but, rather, using alternate and multiple addresses simultaneously. In particular, it means that a re-transmitted segment may need to go to a different address (and out a different address) than it did originally. ... I do not want large delays in transmission caused by network (or host interface) problems. Ah, now I see what the problem is you're talking about. This isn't really mobility per se. You want, for a host which has multiple interfaces, for the connection to be able to switch to a backup or alternate interface, and do it swiftly, and the best way to trigger this is to notice you have to retransmit a packet. I have to go think about that a bit, but I'll note that there are number of other potential failure modes (such as having the first-hop router drop dead, a.k.a. black hole disease) where the internet layer would benefit from a hook from its applications (i.e. the transports) which says "hi, I'm having to resend data; why don't you check to see if there's a problem at your level". In fact, you can't guarantee that a retransmission is in fact due to an interface failure at the destination; there are a number of other possible causes, most at the internetwork layer. So this probably *is* the right fix; the internetwork layer could use that hook to investigate all the potential failure modes, and try and recover automatically. In fact, putting the binding in the internetwork layer makes even more sense from that perspective; put it together with all the other potential causes, so that one agent can handle them all. If you have such a hook, is there anything that the transport layer could do in the way of maintaining the address-DNS binding which the internet layer couldn't do if it were responsible for maintaining the binding? I can't think of any. That is, I want my connection to continue with successful transmissions faster than the internet routing protocols will tolerate (otherwise they start getting unstable.) If I understand what this is referring to, you want things like BGP connections to be able to use a different interface without having the routing break? I can't think of any other case where the routing protocol would come into it. So, how do you accomplish this without having the transport layer aware of multiple "paths" and without being highly intelligent (i.e., stateful) in their use? This is a complex topic if you bring policy routing into it. I generally think it's best to keep the transport out of routing decisions entirely, and which interface to pick at the destination is just one more routing decision. I.e., not amything I want the transport layer mucking with. Another excellent reason to hide the binding in the internetwork layer. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 08:40:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03201; Tue, 18 Oct 1994 08:07:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA12887; Tue, 18 Oct 1994 08:05:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12871; Tue, 18 Oct 1994 07:48:22 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02207; Tue, 18 Oct 1994 07:35:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26382; Mon, 17 Oct 94 17:35:23 -0400 Date: Mon, 17 Oct 94 17:35:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410172135.AA26382@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > Why not change it so the pseudo-header does not include the address > (which can change), but rather the DNS name, which will always be the > same? yeah, and then it will be useless. If you make the value a constant then it has no business being in the calculation at all. Pardon me? The IPv4 address is a constant now. Oh, I see, I'm assuming you find the CCB first and *then* do the checksum, not checksum the packet *before* you find the CCB. That allows you to avoid dorking with a pseudo-header on each packet, and precompute the partial checksum of the IPv4 addresses, TCP ports, etc. (You still have to add the length in to the checksum, but that's relatively easy.) The fact that many people copy the address out of the IP packet is an accident; you could just as easily copy it from the CCB. (If the copy in the packet didn't match the copy in the CCB, you wouldn't have matched up on the CCB, would you?) The purpose of having the address in the calculation is as an integrity check against the segment. Has this requirement been changed? The reason the IPv4 address is in the TCP pseudo-header is to make sure the packet is from who you think it is, *not* to protect the address field. If a connection is identifed by a TCN which includes the DNS name, that's what you ought to use to make sure the packet is from who you think it's from. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 11:52:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09717; Tue, 18 Oct 1994 11:05:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA13057; Tue, 18 Oct 1994 11:05:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13049; Tue, 18 Oct 1994 11:01:56 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07431; Tue, 18 Oct 1994 10:06:45 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA05214; Mon, 17 Oct 1994 17:06:27 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 17:06:30 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU At 2:35 PM 10/17/94, Noel Chiappa wrote: >The reason the IPv4 address is in the TCP pseudo-header is to make sure the >packet is from who you think it is, *not* to protect the address field. If >a connection is identifed by a TCN which includes the DNS name, that's what >you ought to use to make sure the packet is from who you think it's from. again, from RFC793: > prefixed to the TCP header. This pseudo header contains the Source > Address, the Destination Address, the Protocol, and TCP length. > This gives the TCP protection against misrouted segments. This > information is carried in the Internet Protocol and is transferred > across the TCP/Network interface in the arguments or results of > calls by the TCP on the IP. sounds like classic bit-distortion testing, Noel. Checking to see if the network mucked up the bits. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 11:53:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09788; Tue, 18 Oct 1994 11:08:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA13074; Tue, 18 Oct 1994 11:07:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13052; Tue, 18 Oct 1994 11:02:12 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07424; Tue, 18 Oct 1994 10:06:34 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA05208; Mon, 17 Oct 1994 17:06:15 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 17:06:18 -0700 To: jhalpern@Newbridge.COM (Joel Halpern) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU At 2:20 AM 10/17/94, Joel Halpern wrote: >for the same connection. The initial connect would also have to carry >the DNS name of the connecting host, so that the responder would have a >name to use in its checksum generation. certainly there needs to be a clear and formal basis for associating a particular unique dns name with a particular connection. It does not have to be an initial connection, however. My own proposal tries to allow a sequence in which the connection is established and operates just the same as today, but allow creation and use of a a 'name' list LATER. In effect, the decision by the host pair to create a series of name/address sets is probably entirely asynchronous of a particular connection. (Or, at least, asyncrhonous with the creation of a particular connection.) Nonetheless, the specification of a particular name DOES need to be done explicitly between the pairs, as you state. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 11:59:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10409; Tue, 18 Oct 1994 11:25:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA13122; Tue, 18 Oct 1994 11:25:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13101; Tue, 18 Oct 1994 11:10:16 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07427; Tue, 18 Oct 1994 10:06:40 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA05211; Mon, 17 Oct 1994 17:06:20 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 17:06:23 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU At 2:20 PM 10/17/94, Noel Chiappa wrote: >Well, now I'm confused. If the TCN's are in terms of DNS names, how does that >info get into the transport layer? I assume that the application is going to The name used by the user does not have to be the name used in the TCN specification. Might be the same. Might not. All that is required is that the name in the TCN be globally unique. Since hosts may have multiple names, these uses of a name are (or can be) quite independent. >have to tell TCP somehow; might as well be the open. Nothing requires that the application choose the TCN domain name. One could even argue that it's better if it doesn't, for some scenarios, but I suspect haggling the specifics of better or worse on this will depend on the scenarios that prove most important. >The reason the IP address is in the pseudo-header *now* is to make sure the >packet is from the person you thought it was from. Since the address was the then why also run the checksum over the destination address? That is, the checksum is doing data integrity checking, to make sure that it is both from AND to the right interfaces. >why it is used there. The TCN implies that the entity on the other end of >connection is named by the DNS name. That's what you should include in the >pseudo-header. nope. the purpose of the calculation is to check for distorted bits. Hence, it must be done on the bits that arrive over the wire -- and therefore are subject to mishandling that the checksum will, ummmmm, check -- not some constant. > > a separate pseduo-header checksum seed for each TCC, if you wanted > > to precompute > > "Seed"? Please explain. Each segment is an independent calculation. The > sequence number is the glue that connects two segments. > >"seed"), you can precompute the partial checksum for any invariant part of the Oh, I see. In other words, you defeat the purpose of the calculation over those bits. I.e., by assuming that they are what they should be, you call them 'invariant'. Of course, the whole purpose of the checksum effort was/is to look for distortions. So the question is not whether the pseudo-header checksum bits SHOULD BE invariant, but whether they ARE. >Ah, now I see what the problem is you're talking about. This isn't really >mobility per se. You want, for a host which has multiple interfaces, for the As I have said repeatedly, Noel, this proposal is for TWO functions: mobility AND robustness. I claim they are quite similar, since mobility needs to deal with transition from one 'attachment' to another, and the attendant noisy/lossy behavior that will occur during such transitions. >connection to be able to switch to a backup or alternate interface, and do it >swiftly, and the best way to trigger this is to notice you have to retransmit >a packet. Yes. Thought I made that clear in the proposal text, in the first paragraph in the Introduction. >I have to go think about that a bit, but I'll note that there are number of >other potential failure modes (such as having the first-hop router drop dead, One hopes that anyone seriously interested in full use of the robustness feature has full redunancy and independence in the paths. >from its applications (i.e. the transports) which says "hi, I'm having to >resend data; why don't you check to see if there's a problem at your level". Perfectly fine idea, though it has largely nothing to do with my proposal. Such a feature would make sense even today. >If you have such a hook, is there anything that the transport layer could do >in the way of maintaining the address-DNS binding which the internet layer >couldn't do if it were responsible for maintaining the binding? I can't think >of any. Haven't a clue. Why don't you specify the thing and then we can compare their behaviors. My first reaction is that you've only specified a "complaint" mechanism and what I'm providing is a "recovery" mechanism. While one can get to the latter through the former, it sure seems awkward. But again, why don't you provide some details to your thought and we can see if there's a basis for comparing complexity, robustness, and all that sort of silliness. > That is, I want my connection to continue with successful transmissions > faster than the internet routing protocols will tolerate (otherwise they > start getting unstable.) > >If I understand what this is referring to, you want things like BGP >connections to be able to use a different interface without having the routing >break? I can't think of any other case where the routing protocol would come >into it. well, that was creative. I meant nothing at all like you understood me to mean... What I meant was that today a connection must wait for the routing protocols to detect and "fix" an outage by specifying an alternative path. This takes time; longer than a retransmission time. I want to take only as long as a retransmission time. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 12:53:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11990; Tue, 18 Oct 1994 12:05:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA13171; Tue, 18 Oct 1994 12:05:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13152; Tue, 18 Oct 1994 11:53:03 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11452; Tue, 18 Oct 1994 11:52:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27472; Mon, 17 Oct 94 21:52:48 -0400 Date: Mon, 17 Oct 94 21:52:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410180152.AA27472@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > The reason the IPv4 address is in the TCP pseudo-header is to make sure > the packet is from who you think it is, *not* to protect the address > field. again, from RFC793: This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length. >> This gives the TCP protection against misrouted segments. Note the sentence called out. Just what I said; it makes sure the packet is from the machine you think it's from, i.e. the correct entity on the other end of the connection. Tell me, if they wanted to make sure of that, back when that spec was written (which predated DNS), exactly what should they have checked, if not the IPv4 address? sounds like classic bit-distortion testing, Noel. Checking to see if the network mucked up the bits. Ah, that's just the means. The end is making sure the packet is from who you think it's from. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 12:54:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12121; Tue, 18 Oct 1994 12:07:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA13188; Tue, 18 Oct 1994 12:06:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA13155; Tue, 18 Oct 1994 11:54:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10831; Tue, 18 Oct 1994 11:34:21 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 18 Oct 94 10:24:47 +0859 From: Masataka Ohta Message-Id: <9410180125.AA06746@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 18 Oct 94 10:24:45 JST Cc: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9410172120.AA26222@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 17, 94 5:20 pm X-Mailer: ELM [version 2.3 PL11] > I have to go think about that a bit, but I'll note that there are number of > other potential failure modes (such as having the first-hop router drop dead, > a.k.a. black hole disease) where the internet layer would benefit from a hook > from its applications (i.e. the transports) which says "hi, I'm having to > resend data; why don't you check to see if there's a problem at your level". > In fact, you can't guarantee that a retransmission is in fact due to an > interface failure at the destination; there are a number of other possible > causes, most at the internetwork layer. The only exception is when the receiving process bound to a port is in trouble, in which case, trying other addresses is useless. > So this probably *is* the right fix; > the internetwork layer could use that hook to investigate all the potential > failure modes, and try and recover automatically. Sure. Masataka Ohta PS Dave, both hosts and interfaces belongs to the internet layer. From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 13:46:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15865; Tue, 18 Oct 1994 13:46:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13295; Tue, 18 Oct 1994 13:45:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13287; Tue, 18 Oct 1994 13:44:49 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14787; Tue, 18 Oct 1994 13:16:19 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id UAA05941; Mon, 17 Oct 1994 20:10:59 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 20:11:03 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU At 6:24 PM 10/17/94, Masataka Ohta wrote: >The only exception is when the receiving process bound to a port >is in trouble, in which case, trying other addresses is useless. yup. Not trying to recover from broken applications, just broken network pieces. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 18 13:49:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16130; Tue, 18 Oct 1994 13:49:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13312; Tue, 18 Oct 1994 13:49:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13290; Tue, 18 Oct 1994 13:44:56 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14527; Tue, 18 Oct 1994 13:11:06 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id UAA05938; Mon, 17 Oct 1994 20:10:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 17 Oct 1994 20:10:57 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU At 6:52 PM 10/17/94, Noel Chiappa wrote: >>> This gives the TCP protection against misrouted segments. > >Note the sentence called out. Just what I said; it makes sure the packet is >from the machine you think it's from, i.e. the correct entity on the other Now let's see. Why do we think it's part of the checksum, instead of a simple compare operation? Could it be that the checksum does something extra? Perhaps it checks for changed bits. Whaddaya think? Now, if we instead just put in the constant IP address from our table, rather than from the actual received header, what possible use is there in the checksum calculation? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 03:05:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13544; Wed, 19 Oct 1994 03:05:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14173; Wed, 19 Oct 1994 03:05:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14157; Wed, 19 Oct 1994 02:46:25 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12711; Wed, 19 Oct 1994 02:37:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01749; Tue, 18 Oct 94 12:37:17 -0400 Date: Tue, 18 Oct 94 12:37:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410181637.AA01749@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) > Note the sentence called out. ... it makes sure the packet is > from the machine you think it's from Now let's see. Why do we think it's part of the checksum, instead of a simple compare operation? Could it be that the checksum does something extra? Perhaps it checks for changed bits. Whaddaya think? Yes, but why would anyone give a hoot if those bits *were* busted? Because you want to make sure that the packet is from who that field says it's from; i.e. who you think it's from. *That's* what's important, not the particular mechanism. Now, if we instead just put in the constant IP address from our table, rather than from the actual received header, what possible use is there in the checksum calculation? Very simple. Including that number in the checksum calculation "puts" those bits in the packet, albeit merged into the checksum. True, this isn't as resistant to damage as putting the original data there, *as well as including it in the checksum*, but you have to look at the cost/benefit analysis. (Remember that not even including *both* the data *and* the checksum is not a 100% guarantee; there are possible errors that damage both the data *and* checksum and leave a valid checksum.) Putting the complete field in the packet (i.e. the DNS name of the endpoint) is going to be space- and time-consuming. What do you get for it? Well, you'd probably get somewhat greater protection against errors that damage the packet than you would with the alternative. Let's look at the alternative. With the DNS name included only in the checksum (i.e. in the packet only "indirectly"), you can get a correct checksum for a packet which is "bad" (i.e. not a undamaged packet, delivered to the right place) in the following ways: 1 - The packet is not damaged, but misdelivered, and the DNS name of the intended recipient of the packet has the same contribution to the checksum as the DNS name of the actual receiver. (Alternatively, the DNS names of the actual originator and intended receiver have the same contribution as the supposed originator and the actual receiver.) OK, this might happen; DNS names are not highly random. 2 - The checksum is damaged, and the packet is misdelivered, but the damage is such that it just happens to have a value which produces a correct checksum. The odds against this are probably about 2^(size_of_checksum); someone else can do the math. (Delivering a packet with a damaged checksum to the right place can never produce the correct checksum.) 3 - The checksum and packet contents are damaged, the packet may or may not be misdelivered, but the damage is such that it just happens to have a value which produces a correct checksum. Again, odds against this are probably about 2^(size_of_checksum). If the packet is *also* authenticated, using some public-private key system, that just about kills (i.e. it will produce a probablity of an undetected error whichis on the same order of magnitude as undetected errors when using both the original data and checksum) the chances of case 1 happening. Depending on how the authentication works, it probably kills 2 and 3 as well. In other words, including a piece of static data already known to the sender and receiver in the checksum of a packet can help validate the packet, even if the data itself is not included. You don't *need* the data for itself; each end already has it. Noel From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 04:05:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15224; Wed, 19 Oct 1994 04:05:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA14239; Wed, 19 Oct 1994 04:05:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14225; Wed, 19 Oct 1994 03:46:22 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13118; Wed, 19 Oct 1994 02:51:06 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA06680; Tue, 18 Oct 94 11:47:55 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:dcrocker@mordor.stanford.edu id AA21655; Tue, 18 Oct 94 11:47:45 -0500 Date: Tue, 18 Oct 94 11:47:45 -0500 Message-Id: <9410181647.AA21655@benedick.ctd.anl.gov> To: dcrocker@mordor.stanford.edu Subject: Comments on Dave Crocker's TCN draft Cc: Big-Internet@munnari.OZ.AU From: "Richard Carlson" Dave; Here are my comments on the TCN draft you sent out. First let me say that I agree with the concept. The user application should be able to handle failures of the transport service provider (TCP, UDP, ...) as easily as the transport service handles failures of the Internetwork service provider (IP). However I disagree with the method you propose to use to provide this service to the application. Specifically: >This scheme supports enhanced functionality as incremental >upgrades to end-system nodes, rather than as changes to the >internetwork infrastructure. > >For transport services, like TCP's use of the pseudo-header, that >integrate information about the network layer into the transport >protocol, re-definition of the calculations need to account for >the variability in network-layer headers. These 2 statements seem to be at odds with each other. You say this proposal will require no chnages the the internetwork infrastructure, but you also recognize that TCP/UDP will need to be reworked to deal with the pseudo-header using IP numbers. Are you saying that IP wouldn't change but TCP/UDP will? I realize this is an implementation detail, but I think it is an important one. How will TCN's, TCC's, and TCCL's work over UDP? Don't these concepts depend on the nodes maintaining some type of connection state? I mean that the communicating nodes must exchange some information over the control channel before data can be sent. Am I reading your draft correctly? Your examples all deal with TCP, could you give me an example using UDP. I am having trouble figuring out how the control channel will work. I keep thinking that since the control channel uses the same transport mechanism as the data channel, you will need another control channel to set up the first control channel (infinite loop). I feel this way because I think you modified TCP & UDP in order to support the TCN (pseudo-header problem). (I think if you can explain how UDP will work then this may be a non-issue.) How do you deal with communications between modified and unmodified nodes? If the deployment requires that you modify TCP & UDP to redefine the pseduo-header checksum, then how will a modified TCP talk to an unmodified TCP? Will there be some method for a source node to determine if a destination node is modified? If so what is that method. I think the compatability issue should be addresses in the draft. All this leads me to prefer removing the control channel and having the TCN type information encoded in the header of every TCP/UDP packet. While it is possible to use either FQDN's or a new fixed length value (Transport Address), this really leads us to the fixed vs variable address debate. I think I fall into the fixed length camp. I hope you find these comments usefull. ++Rich ---------------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory Phone: (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 05:05:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17220; Wed, 19 Oct 1994 05:05:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14318; Wed, 19 Oct 1994 05:05:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14308; Wed, 19 Oct 1994 04:56:09 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15885; Wed, 19 Oct 1994 04:27:14 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA10319; Tue, 18 Oct 1994 11:26:55 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Oct 1994 11:26:59 -0700 To: "Richard Carlson" From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Comments on Dave Crocker's TCN draft Cc: Big-Internet@munnari.OZ.AU Rich, Thanks for the comments. To return the favor: At 9:47 AM 10/18/94, Richard Carlson wrote: >service provider (IP). However I disagree with the method you propose I'm more concerned with the philosophy than the details, and mostly now am only concerned with seeing counter-proposals done in enough detail to be able to understand their benefits over the details of my own proposal. >but you also recognize that TCP/UDP will need to be reworked to >deal with the pseudo-header using IP numbers. Are you saying that >IP wouldn't change but TCP/UDP will? I realize this is an Yes. Exactly right. That's still quite alot of work, but the key point is that changing IP changes every single node in the path, whereas changing TCP only requires changes in the two participating nodes. In the long run, that means everyone, of course, but in the short run, adoption is incremental. >How will TCN's, TCC's, and TCCL's work over UDP? Don't these concepts >depend on the nodes maintaining some type of connection state? I >mean that the communicating nodes must exchange some information >over the control channel before data can be sent. Am I reading >your draft correctly? Your examples all deal with TCP, could you >give me an example using UDP. Your understanding is correct. However, note that Berkeley sockets lets you set up 'associations' for UDP, just like for TCP. That is, the application can know about a remote application even though their is no formal virtual circuit set up. The TCN mechanism let's you do the same thing, though it requires a cross-net exchange, so that the apps (well, really, the UDP module on their behalf) know about multiple paths to each other. >mechanism as the data channel, you will need another control The details of bootstrapping are one of the reasons I did a "proposal" rather than a complete spec. Getting these details right is essential and I didn't feel that I could do that quickly or alone. I DO feel that it can be done, though. It's going to be a matter of deciding on the style of the startup that is acceptable. >How do you deal with communications between modified and unmodified must use ONLY current and standard practises. No benefit from the new stuff, unless some sort of proxy works on behalf of the old guy. I don't want to spec or postulate such an engine, though. >TCP talk to an unmodified TCP? Will there be some method for a >source node to determine if a destination node is modified? If so yup. if the source attempts a control channel exchange to an old guy, he'll get back an ICMP Port Unreachable. >what is that method. I think the compatability issue should be >addresses in the draft. Fair point. >All this leads me to prefer removing the control channel and >having the TCN type information encoded in the header of every >TCP/UDP packet. While it is possible to use either FQDN's or No!! That is EXACTLY what I'm trying to avoid. The overhead of puting that long a string into every packet is much, much to high and entirely unnecessary. >I hope you find these comments usefull. yes, indeed. thanks. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 05:50:05 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17719; Wed, 19 Oct 1994 05:20:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07155 Wed, 19 Oct 1994 05:09:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14335; Wed, 19 Oct 1994 05:06:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14311; Wed, 19 Oct 1994 04:56:44 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15818; Wed, 19 Oct 1994 04:22:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02623; Tue, 18 Oct 94 14:21:55 -0400 Date: Tue, 18 Oct 94 14:21:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410181821.AA02623@ginger.lcs.mit.edu> To: dcrocker@mordor.stanford.edu, jnc@ginger.lcs.mit.edu Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) > If the TCN's are in terms of DNS names, how does that info get into the > transport layer? The name used by the user does not have to be the name used in the TCN specification. ... All that is required is that the name in the TCN be globally unique. Since hosts may have multiple names, these uses of a name are (or can be) quite independent. Sure, an endpoint can have multiple names. But still, if I try to open a connection to A.B.C, it would be nice to know if A.B.C is what I got to, even if it calls itself E.F.G most of the time. Nothing requires that the application choose the TCN domain name. Yeah, I can see how that might be useful. In that case, the far end ought to pass back its endpoint name; "Hi, I'm A.B.C". That way, if it moves, or starts using a different interface, etc, you can make sure it's still A.B.C on the other end. > The reason the IP address is in the pseudo-header *now* is to make sure > the packet is from the person you thought it was from. then why also run the checksum over the destination address? ... the checksum is doing data integrity checking, to make sure that it is both from AND to the right interfaces. Right; I didn't bother saying that (my messages are too long already :-), I guess I just assumed it would be obvious. you defeat the purpose of the calculation over those bits. I.e., by assuming that they are what they should be, you call them 'invariant'. Well, if they are invariant, they are invariant, and putting them in the packet, or leaving them out, isn't going to change that. Seeing them in the packet isn't going to give you any information you didn't already have; you already have those bits. Seeing them in the packet just decreases the likelihood of undetected bit errors in the packet. Of course, the whole purpose of the checksum effort was/is to look for distortions. So the question is not whether the pseudo-header checksum bits SHOULD BE invariant, but whether they ARE. Right. Modulo the length (as I mentioned), *iff* the *endpoint name* is in the pseudo-header, instead of the *address*, then the pseudo-header *is* invariant in the presence of mobility or alternate interfaces. > Ah, now I see what the problem is you're talking about. This isn't really > mobility per se. As I have said repeatedly, Noel, this proposal is for TWO functions: mobility AND robustness. ... Thought I made that clear in the proposal text, in the first paragraph in the Introduction. Yes, I apologise, I had missed/forgotten that point in the document. I claim they are quite similar, since mobility needs to deal with transition from one 'attachment' to another, and the attendant noisy/lossy behavior that will occur during such transitions. There is some truth to that, but you're missing a larger similarity, which is that switching interfaces to get to the destination endpoint is but one instance of a general class of robustness mechanism, which is changing the path from the source endpoint to the destination endpoint to avoid a failure. Right now, that's split into three separate parts: if the first-hop router is down, you have to do "black-hole" detection, if an intermediate router is broken the routers have to fix it, and if the destination interface is busted you propose this mechanism to fix it. (The third mechanism also is applied if the broken interface is at this end; it's symmetrical, so I call it one case.) I claim it's not good to split that problem up like that. For instance, if there has been policy input to selecting the path, changing interfaces means you have to go back to pick a new path which meets those policy constraints. (Precomputing all MxN paths seems overkill...) So, instead of using the similarity to mobility to drag the two of them in one direction, I use the similarity to picking an alternate path to drag both of them down with other alternate-path stuff. > is there anything that the transport layer could do in the way of > maintaining the address-DNS binding which the internet layer couldn't do > if it were responsible for maintaining the binding? I can't think of any. Haven't a clue. Why don't you specify the thing and then we can compare their behaviors. You're the person proposing we do it your way. If you don't feel like showing the advantage of doing it your way, don't expect me to be able to figure it out (which I would, anyway, since I really do want the best design). However, I really can't see any, so I asked you. But again, why don't you provide some details to your thought and we can see if there's a basis for comparing complexity, robustness, and all that sort of silliness. The basic idea, and what's in the packets that go back and forth, is all basically the same as yours. The only difference is that the binding is maintained entirely in the internetwork layer, and the interet<->tranport interface is in terms of DNS names, *not* addresses. The transport level deals only in DNS names. The details have been discussed in previous messages. I really don't care if the failure to put all this in whatever final, polished form you demand means you, or the IETF, or anyone, doesn't really listen. If you really do care about doing the best thing possible, you'll listen. If you don't care, there's really no point anyway. >> That is, I want my connection to continue with successful transmissions >> faster than the internet routing protocols will tolerate (otherwise they >> start getting unstable.) > If I understand what this is referring to, you want things like BGP > connections to be able to use a different interface without having the > routing break? well, that was creative. I meant nothing at all like you understood me to mean... Well, I assumed the "they start getting unstable" referred to the routing protocols. What I meant was that today a connection must wait for the routing protocols to detect and "fix" an outage by specifying an alternative path. This takes time; longer than a retransmission time. I want to take only as long as a retransmission time. The problem is that your proposed mechanism can only fix a very small (and, I expect, fairly rare) class of failures; i.e. those where there is an alternate interface available, and the routing to that interface from the other end is already working. For instance, if my machine had two interfaces to different phsical networks inside MIT, and the main external MIT router crashed, until the routing outside MIT stabilized, it wouldn't do any good for sites outside MIT to switch back and forth. Even if MIT had several external routers, and the one a given outside site was using crashed, the site outside MIT would still have to wait for the routing from there to MIT to switch to a different one. If the machine outside MIT had multiple interfaces, and MIT had mutliple external routers, and the one the site was using crashed, it could try going from different interfaces to MIT, to see if one of those interfaces had a path to MIT through another router. However, the further away that outside site is, the greater the chances (unless its mutiple interfaces are connected to the topology at very widely separated locations, topologically speaking) that all its interfaces will use the same MIT external router to get to MIT. So there's no help there either. The analysis of faults and fault-recovery mechanisms, keeps going, but I don't have the energy to type it in. The bottom line is what I said before: I generally think it's best to keep the transport out of routing decisions entirely, and which interface to pick at the destination is just one more routing decision. I.e., not amything I want the transport layer mucking with. Noel From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 07:44:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20481; Wed, 19 Oct 1994 06:46:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA14438; Wed, 19 Oct 1994 06:45:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA14433; Wed, 19 Oct 1994 06:43:46 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19696; Wed, 19 Oct 1994 06:22:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03517; Tue, 18 Oct 94 16:22:28 -0400 Date: Tue, 18 Oct 94 16:22:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410182022.AA03517@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Comments on Dave Crocker's TCN draft Cc: jnc@ginger.lcs.mit.edu While re-reading your spec (actually, I'm quickly throwing together the spec you asked for - "Why don't you specify the thing and then we can compare their behaviors." - I decided to simply edit yours, since that would be quick, and provide the same level of detail) I came across the following text (in section 2), which my brain did not conciously remember: It may well also be useful to permit processes to migrate from one host to another -- assuming that the hosts cooperate among themselves to coordinate the local transfer of the process context. I found this strange, in light of your comments in email to this list (after I pointed out a bug involving collisions with already in-use TCP ports, if you try and support process mobility), viz: Date: Fri, 14 Oct 1994 16:18:38 -0700 From: dcrocker@mordor.stanford.edu (Dave Crocker) > That's why I said, above, that this mechanism cannot be reliably used > for mobile applications Tell you what, Noel. Show me some real world requirements for mobile applications... > Now, maybe you just want to blow off supporting mobile applications. Yup. > I'd like to think that any mobility mechanism we use can be used to > support that as well. I'd like world peace, too. But for the moment, I suggest we focus on pragmatic requirements that the community has some plausible understanding of, i.e., requirements which are not strictly in the realm of research. Perhaps you need to make some changes in this area of your document? Noel From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 09:46:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26140; Wed, 19 Oct 1994 09:46:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA14623; Wed, 19 Oct 1994 09:45:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA14618; Wed, 19 Oct 1994 09:43:35 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23983; Wed, 19 Oct 1994 08:46:55 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA11595; Tue, 18 Oct 1994 15:46:47 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Oct 1994 15:46:50 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Draft minutes - Toronto EID BOF Cc: big-internet@munnari.OZ.AU At 11:21 AM 10/18/94, Noel Chiappa wrote: > But again, why don't you provide some details to your thought and we can > >The basic idea, and what's in the packets that go back and forth, is all >basically the same as yours. The only difference is that the binding is Does this mean that you are proposing something which generates pretty much the same bits over the wire as my proposal? If not, how are they different. If yes, then it sounds like you are debating only matters of implementation and discussion and NOT the protocol. In other words, does "basically the same" mean "the same" or does it mean that there are important differences in what goes over the wire. If the latter, what are those differences? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 09:55:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24722; Wed, 19 Oct 1994 09:07:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA14568; Wed, 19 Oct 1994 09:05:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14550; Wed, 19 Oct 1994 08:47:13 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23985; Wed, 19 Oct 1994 08:47:06 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA11605; Tue, 18 Oct 1994 15:46:57 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 18 Oct 1994 15:47:01 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Comments on Dave Crocker's TCN draft Cc: big-internet@munnari.OZ.AU At 1:22 PM 10/18/94, Noel Chiappa wrote: >try and support process mobility), viz: ... > > Now, maybe you just want to blow off supporting mobile applications. ... >Perhaps you need to make some changes in this area of your document? Yup. I'm planning on taking that piece of text out. I happen to think that my proposal supports the external protocols portion of process mobility, for free, but it's clearly distracting to readers and I DON'T see any real-world use for it in the near term. I put it in for fun and in the hope that it would keep one faction quiet. Didn't work well for either purpose... d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 17:06:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13325; Wed, 19 Oct 1994 17:06:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA15056; Wed, 19 Oct 1994 17:05:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA15051; Wed, 19 Oct 1994 17:03:00 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11338; Wed, 19 Oct 1994 16:19:19 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 19 Oct 94 15:04:44 +0900 From: Masataka Ohta Message-Id: <9410190604.AA03401@necom830.cc.titech.ac.jp> Subject: Re: Draft minutes - Toronto EID BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Wed, 19 Oct 94 15:04:42 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 18, 94 3:46 pm X-Mailer: ELM [version 2.3 PL11] > > But again, why don't you provide some details to your thought and we can > > > >The basic idea, and what's in the packets that go back and forth, is all > >basically the same as yours. The only difference is that the binding is > > Does this mean that you are proposing something which generates pretty much > the same bits over the wire as my proposal? That's why EID should be compact. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 17:07:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11635; Wed, 19 Oct 1994 16:27:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA15008; Wed, 19 Oct 1994 16:25:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA14983; Wed, 19 Oct 1994 16:11:20 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10936; Wed, 19 Oct 1994 16:11:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06530; Wed, 19 Oct 94 02:10:53 -0400 Date: Wed, 19 Oct 94 02:10:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410190610.AA06530@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Comments on Dave Crocker's TCN draft Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) I'm more concerned with the philosophy than the details, and mostly now am only concerned with seeing counter-proposals done in enough detail to be able to understand their benefits over the details of my own proposal. Well, Dave got his wish. I sat down and whipped out the kind of thing he seems to be looking for, by the simple process of taking his document and munging it. I'll be sending the first rough draft out in a few moments. I'm still amazed that we need to take this step before everyone is prepared to discuss an idea, since to me the document contents a simple matter of fairly obvious grind-the-crank protocol engineering that took me only a hour or two to type in. It's not exactly rocket science. Oh well, mine not to reason why. Noel From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 17:25:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10879; Wed, 19 Oct 1994 16:08:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA14965; Wed, 19 Oct 1994 16:05:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA14960; Wed, 19 Oct 1994 15:56:00 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10250; Wed, 19 Oct 1994 15:55:27 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: EIDs from the BOF Date: Wed, 19 Oct 1994 15:55:21 +1000 Message-Id: <9646.782546121@munnari.OZ.AU> From: Robert Elz So far we've had two most dilligent people who have submitted doc as "homework" from the EID BOF in Toronto. That's rather remarkable, as I was supposed to send out requests to the relevant people to solicit this, and I haven't managed to find the time for that yet. My apologies to you all. Because of this, I also accept the blame for neither of those two submissions being exactly what the intention was to request, which was simply to answer a set of questions, with reasons, as to what is the nature of an EID. Now, rather than simply send that request, I'll attempt instead to do my own homework assignment... The task was to define an EID. Nine questions were asked with this in mind. 1. Are EIDs short (generally perceived as no longer than about 64 bits) ? 2. Are EIDs binary (as opposed to printable text) ? 3. Are EIDs globally unique ? 4. Do EIDs exist at the network level ? 5. Do EIDs exist in the transport layer ? 6. Are EIDs used to identify transport connections ? 7. Are EIDs used as a key into any kind of database ? 8. Do EIDs have any internal (administrative) structure ? It was assumed that EIDs have no topological or geographical meaning. 9. Are EIDs present in every packet ? My answers ... 1. Probably (short) 2. Yes (binary) 3. Yes (unique) 4. Probably (network level) 5. No (transport level) 6. Yes (identify transport connections) 7. Yes (database key) 8. Yes (internal admin structure) 9. Probably (in every packet) Now my reasons - first I see an EID as having one, and only one, prime purpose. That is as an identifying mark. Everything else that has been proposed is either simply an application of this, or I don't think is one of applicable or appropriate. I doubt I need to go into reasons as to why we need identity indications of some kind or other - the questions are why this particular form, and why something that exists already can't do the job instead of inventing new mechanism. I'll attempt to answer the secod part of that first. We have two current forms of identifing information (to identify the kind of object to which EIDs are intended to apply), IP addresses, and DNS names. In theory, we could live with only one of those so we already have redundancy. IP addresses are currently the primary identifying mark at the transport and lower levels, which is what is of concern here. I'm afraid that making them continue in this role will much complicate some of what is planned for IPv6. There's already been a lot said about mobility, which is one such application, its an example of a place where stable identity (not affected by topology) can help, and I propose to say no more about it at all, I don't regard it as all that important (as an argument for EIDs). Instead, consider the following. In IPv6 we're planning to make network renumbering much easier, perhaps even close to compulsory from time to time. To that end, protocols to distribute new numbers to hosts are being developed, so that no manual (host) configuration will be needed. We're even developing methods by which the DNS can be updated, so that a host that has obtained a new number can have its name associated with that new number. To go with that, and of course for other purposes, we're also developing authentication. So far that's all fine - but one piece of this hasn't been adequately considered I believe. That is, how we update the number -> name mapping. Now at the basic level that's not functionally different than updating the name -> number mapping, however we have one significant problem to overcome. With name -> number mapping, the host knows (from somewhere) its name, and (similarly, from somewhere) the identity of the (locally administered, in some sense) DNS server that controls this name -> number mapping. Consequently, it can send an update request, in some yet to be defined format, to that DNS server, and when properly authenticated, cause the DNS database to be altered. Number -> name mapping experiences a problem however. Recall that (in IPv4 terms for simplicity) we're not talking here of altering 1.2.3.4 into 1.2.3.5, which is an easy case to handle, we're considering altering 1.2.3.4 into 5.6.3.4 or something similar probably. Now we have to move our reverse mapping from inside 2.1.in-addr.arpa to in 6.5.in-addr.arpa. This is no easy thing to automate, it requires new delegations to appropriate servers, and in general lots of fuss. Since its quite likely that someone, sometime in the past, was using 5.6.x.y for some other network, renumbered in the past, its likely that they have the delegation for this zone, and if not at least they may easily still be running servers for it, meaning that at least some parts of the net (those that previously owned this number) will never see the new servers. Because of the topological nature of numbers, its even likely that those other pars of the net are going to be nearby, and so, potentially significant to your local operations. Because of this I am almost totally convinced that we absolutely don't want any kind of address -> name mapping, at all. When combined with the added restrictions that being a key for the DNS imposes - well known structure that defines zone delegations, which in turn tends to limit flexibility in setting subnet boundaries in arbitrary ways - they work, but politically managing the address->name DNS zone files becomes brudensome enough that its not worth doing - I am even more convinced that address -> name mappings are simply a bad idea. However, we certainly still need some form of packet-sender -> name mapping available, this is an identifying function, and its for this that I would use the EID. This immediately answers question 7 - yes, the EID needs to be useable as a database (the DNS in particular) key. It also answers question 3, the EID will need to be globally unique to be useful for this. Several dozen lines ago, the other identification already existing that might be useful was the DNS name. DNS names are unique, and useable as database keys, so they remain a possibility. I don't like them, because they are subject to political influences - that is, they're a very visible object, and consequently tend to be forced to change for reasons that have no technical merit at all. To me this makes them not stable enough. This is also why I answered question 2 (are EIDs binary) as "yes" - binary gibberish is rarely going to be noticed at corporate executive level, no-one is likely to be instructed to change a binary identifier from one value to another because it doesn't fit current corporate image, organisational structure, or ownership. However this is just a personal preference, and of itself not enough to totally rule out using DNS names. Instead, lets go to question 9 - are EIDs in every packet. Here I say "probably" - I can imagine the possibility that this might not be needed, but I'd imagine even then that most packets would contain EIDs. One reason is for packet filtering and accounting. If addresses are going to be prone to sudden random changes, router filter configurations aren't really going to want to use them for filter purposes, or certainly not any belonging to other organisations. EIDs are stable, and identify owners - they're a much more likely value to use in filter lists. Further, they remain constant as mobile hosts move, meaning that the services that a mobile host can access at its home base can be configured to be the same as those it can access anywhere (but obviously don't have to be). Accounting (for billing, or simply for statistics gathering) collects identifiers from packets, and accumulates counters. Using addresses has been traditional, however if addresses become less constant than they now are this might not be suitable. If you're renumbered into a new number a third of the way through a month, remain at it for the next third, then change again, will you be confident that all the usage accumulated against that number really originated at your host, and none came from a previous, or later, user. Even if technically this is solvable, its going to be a problem to convince the users that everything is really foolproof, and no false accumulations are ever going to happen. On the other hand, an EID will remain stable, and what's more, packets from a mobile host, outside its home base, will be correctly attributed to its home organisation, rather than to its temporary host. For all of this, I believe EIDs really belong in every packet. I say only "probably" because neither filtering nor accounting are fundamental to operation of the internet, and its conceivable that those functions could be eliminated. This then also answers question 1 - if EIDs are probably going to be in every packet, then they're also certainly probably going to be short. Then, because they are short, we really want them to be binary, to obtain full value of the available bits - so confirmation of the "yes" answer to question 2. At this point, DNS names are more or less eliminated from consideration. There are just a few questions left, and by this stage they're easy to answer. EIDs certainly wouldn't want to exist at the transport layer, both because they need to be universal, every transport layer packet, of every transport layer, and packets that have no transport layer data in the conventional sense in them at all (ICMP, IGMP, even perhaps ARP) need this identification. That's question 5 - No. They will probably be at the network layer, as its that that provides end to end connectivity, and which is examined by routers to achieve that, however, an intermediate layer, probably in every packet, between network and transport can be imagined. This would purely be an academic layer though, if its going to be in every IP packet, and immediately follow the IP header, its effectively in the IP header, and IP layer, whatever it's called. So Q4 - probably. Question 6 - do EIDs identify transport connections. This one is obviously yes, as soon as the word "identify" appears in the question, it immediately fits the prime purpose of having an EID at all, so certainly they're used for that purpose. Of course, they are only a part of the transport connection identification, port numbers, etc, still exist, and extend the EID from being one per end-point (which I am purposely not defining) to one per connection. Anything else that needs identifying can have an identifier constructed in a similar way - transactions can be identified by appending a locally unique transaction identifier, of whatever length and composition is required, to the globally unique EID. Finally, question 8 - internal structure. Yes, EIDs have internal structure. That is necessary for administrative assignment purposes, administrations need to be given a block of numbers to assign to their hosts, that of itself is one primitive form of structure. Then, to be useable as a database key - or more precisely, to be useable as a DNS key, the EID needs to be able to be broken down into delegation levels, which will, naturally, follow the administrative assignment hierarchy. This has also, finally, answered the very first question raised in From this I draw my conclusion that EIDs are a short (64 bit) binary number, allocated with administrative structure, and carried in every packet, that are used whenever any question of identity arises. I also conclude that one way or another, they really should be in IPv6, and that if we omit them, we will regret it later. I do understand that using them assumes creating the administrative structure to assign them. I however see this as being identical to the assignment structure for IPv4 addresses - except easier for end sites to manage, as at that level they are simply serial numbers, assigned sequentially, with no topological significance at all. However, this need not be an additional burden over current procedures, as I don't see IPv6 addresses needing anything like the same assignment strategy - given that with EIDs all they're needed for is to route packets to the correct end points (which isn't to say this is trivial) I see no reason for them to not be automatically assigned by routers, radiating out from some well known central point, calculated automatically by the routers. Now, having said all of this, I would ask the other 10 people who had EID models listed at the EID bof to explain their answers to the 9 questions. Naturally, anyone else, whether they attended the BOF or not, is also welcome to contribute. kre From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 17:26:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14026; Wed, 19 Oct 1994 17:26:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA15104; Wed, 19 Oct 1994 17:25:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA15083; Wed, 19 Oct 1994 17:13:24 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12168; Wed, 19 Oct 1994 16:42:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06646; Wed, 19 Oct 94 02:42:12 -0400 Date: Wed, 19 Oct 94 02:42:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410190642.AA06646@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: Comments on Dave Crocker's TCN draft Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) > Perhaps you need to make some changes in this area of your document? Yup. I'm planning on taking that piece of text out. Fair enough. I happen to think that my proposal supports the external protocols portion of process mobility, for free Well, it has this problem, in that you can't migrate a process with a TCP connection open to a machine which already has an open connection that collides with that mobile process' connection. It's not an issue of what info is in the external protocols, you just can't do it with the info in the protocols at the moment (unless you add addresses to hosts on demand). If you don't do that, either i) there's not enough info in the transport packet to disambiguate which of two identical ports at a given address the packet belongs to, or ii) there's not enough info in your new control protocol to allow a switch to a different port. Noel From owner-Big-Internet@munnari.OZ.AU Wed Oct 19 17:27:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14079; Wed, 19 Oct 1994 17:27:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA15121; Wed, 19 Oct 1994 17:27:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA15086; Wed, 19 Oct 1994 17:15:03 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11847; Wed, 19 Oct 1994 16:34:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06606; Wed, 19 Oct 94 02:33:44 -0400 Date: Wed, 19 Oct 94 02:33:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410190633.AA06606@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Comments on Dave Crocker's TCN draft Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) the key point is that changing IP changes every single node in the path, whereas changing TCP only requires changes in the two participating nodes. Not. You can change the internetwork layer without changing the IP protocol, and without having any effect on the intermediate routers. My scheme has these characteristics. > All this leads me to prefer removing the control channel and > having the TCN type information encoded in the header of every > TCP/UDP packet. No!! That is EXACTLY what I'm trying to avoid. The overhead of puting that long a string into every packet is much, much to high and entirely unnecessary. Well, I'm not advocating putting DNS names in all packets (I've learned that some people use "overhead" to shoot down ideas they can't find anything else wrong with, no matter how minor the incremental cost), but I did have a question. The average DNS name seems to be in the range of 20 bytes or 20; ginger.lcs.mit.edu, mordor.stanford.edu, munnari.oz.au, etc, etc. If 16-byte addresses aren't too long, and too much overhead, why are the DNS names too long? > The basic idea, and what's in the packets that go back and forth, is all > basically the same as yours. Does this mean that you are proposing something which generates pretty much the same bits over the wire as my proposal? If not, how are they different. ... In other words, does "basically the same" mean "the same" or does it mean that there are important differences in what goes over the wire. Well, at the level I'm thinking about the problem at, I see them as basically the same, in terms of the info that goes over the wire, but you may not agree. In both, all IP packet are unmodified. In both, TCP data and ack packets are unmodified; in mine, the SYN packet has to contain an option. This is allow interoperation between modified and unmodifed hosts. This seemed cleaner for a number of reasons than a separate protocol. I do calculate the TCP checksum differently, using the DNS names in the TCN, not the IP addresses. I have a very similar protocol (I use ICMP for no amazing good reason; it could use UDP, but I don't like having what looks like a dependency loop, using UDP to bonk UDP, hence ICMP) which adds and deletes entries. Instead of containing TCN's, and address pairs, they contain just DNS names, and single addresses; i.e. a subset of your data. Again, basically the same data, being shuffled around in more or less the same way. The big difference is in the way the info is used. In mine, the binding between DNS names and IP addresses is entirely in the internetwork layer, and the transport layer operates entirely in terms of DNS names, not IP addresses. Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 01:06:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28002; Thu, 20 Oct 1994 01:06:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15589; Thu, 20 Oct 1994 01:05:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA15573; Thu, 20 Oct 1994 00:57:27 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27835; Thu, 20 Oct 1994 00:57:21 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA15064; Wed, 19 Oct 1994 07:57:13 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Oct 1994 07:57:17 -0700 To: Robert Elz From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: Big-Internet@munnari.OZ.AU At 10:55 PM 10/18/94, Robert Elz wrote: >Because of this, I also accept the blame for neither of those >two submissions being exactly what the intention was to request, oh. interesting. well, here are MY answers, based on the TCN proposal: >1. Are EIDs short (generally perceived as no longer than > about 64 bits) ? not particularly. >2. Are EIDs binary (as opposed to printable text) ? no. >3. Are EIDs globally unique ? yes >4. Do EIDs exist at the network level ? silly question... do you mean are handled and carried by the network-level software? Then no. I've no idea what 'exist' means in this context. >5. Do EIDs exist in the transport layer ? Using the above, reformed question: yes. >6. Are EIDs used to identify transport connections ? yes. >7. Are EIDs used as a key into any kind of database ? yes. >8. Do EIDs have any internal (administrative) structure ? yes. > It was assumed that EIDs have no topological or > geographical meaning. right. >9. Are EIDs present in every packet ? no. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 01:47:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28889; Thu, 20 Oct 1994 01:47:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA15644; Thu, 20 Oct 1994 01:45:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA15628; Thu, 20 Oct 1994 01:34:50 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28637; Thu, 20 Oct 1994 01:34:42 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA17388; Wed, 19 Oct 94 10:36:30 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA16294; Wed, 19 Oct 94 10:34:09 CDT Date: Wed, 19 Oct 94 10:34:09 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9410191534.AA16294@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: EIDs from the BOF Your TCNs seem to satisfy almost none of the original notion of EID. It's Noel's word, and it means something very specific, which TCNs are not, so let's not pretend that TCNs are EIDs. It might be fair to say that they're trying to solve a similar set of problems, but they're not EIDs. I feel like some kind of frenchman defending the purity of language here, but it is really ludicrous how some IETFers change around the meaning of words to suit themselves. Andrew From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 02:26:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29697; Thu, 20 Oct 1994 02:26:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA15699; Thu, 20 Oct 1994 02:25:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA15683; Thu, 20 Oct 1994 02:23:37 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29606; Thu, 20 Oct 1994 02:23:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09621; Wed, 19 Oct 94 12:23:11 -0400 Date: Wed, 19 Oct 94 12:23:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410191623.AA09621@ginger.lcs.mit.edu> To: amolitor@anubis.network.com, big-internet@munnari.OZ.AU Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: amolitor@anubis.network.com (Andrew Molitor) Your TCNs seem to satisfy almost none of the original notion of EID. It's Noel's word, and it means something very specific, which TCNs are not, so let's not pretend that TCNs are EIDs. Errr, I'm not sure he was referring to EID's anywhere with TCN's (the term EUD is not used in his TCN document). I suspect his reply about the EID questions was based on using DNS names as "EID's". Actually, you can beat up a bit on KRE for putting the questions that way; he perhaps ought to have said "Are endpoint names ", instead of "Are EID's ". I mean, EID's are just one possible type of names for endpoints. You could use DNS names too, and I'm actively playing with that idea. When I answer the N questions, I'll do one set with "EID" and one set with "endpoint name". Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 03:06:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00708; Thu, 20 Oct 1994 03:06:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA15745; Thu, 20 Oct 1994 03:05:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA15729; Thu, 20 Oct 1994 02:53:00 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00445; Thu, 20 Oct 1994 02:52:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09761; Wed, 19 Oct 94 12:52:40 -0400 Date: Wed, 19 Oct 94 12:52:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410191652.AA09761@ginger.lcs.mit.edu> To: RACarlson@anl.gov, dcrocker@mordor.stanford.edu Subject: Re: Comments on Dave Crocker's TCN draft Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: "Richard Carlson" All this leads me to prefer removing the control channel and having the TCN type information encoded in the header of every TCP/UDP packet. I mused about this for a while last night. I've gone back and forth on that issue. I also have an idea (from Yakov originally) to pass along. At one point I thought endpoint names ought to be in every packet. It's certainly simple, direct, robust, flexible, etc (all properties I treasure highly in designs that have to have a long life-time) if you just include the full globally unique endpoint name directly in all packets. That's why I came up with EID's. They are GU endpoint names which are compact (i.e. minimal space overhead), and fixed length (easy to process). If you're going to have them in every packet, these are nice properties to have. I fell away from EID's, to some degree, since people were saying how hard it would be to have another allocation heirarchy. This never struck me as that big a deal; I think addresses should *all* be assigned automatically anyway (the only config you should do with respect to addresses is draw circles on maps, but that's another topic), so whatever mechanism we are now using to assign addresses could be retasked to assign EID's. Still, people didn't seem to like it, and using DNS names as endpoint names does have some advantages; you can allocate new ones locally to your heart's content, we'll never run out of them, etc. Even if you don't have full endpoint names in all packets (perhaps because they are long and var-len, e.g. DNS names), it's nice to have *something* in the packet which can quickly tell you which endpoint the packet is for, which was the idea behind ESEL's. When my design document gets posted (I decided it was too long to send to the mailing list directly) you can see that you have to go through some contortions to handle incoming packets, since they only have an address in them, not any endpoint identification. The option of not having any endpoint identification in the packet does lead to certain troubling problems. On the other hand, it represents the minimal possible change from what we have now, both in terms of processing overhead, as well as banging on code. I'm still not sure I like that option, but I don't think there is rough consensus on including any kind of endpoint name (EID, or DNS name, or whatever) in every packet. I think the design document I put together shows what the world will look like if you decide to do that. Yakov suggested one thing you can certainly do, without changing the IP header (since I *strongly* believe that the internetwork layer should know about endpoint names), it to include the endpoint name as an option. Even in IPv4, there is plenty of room, and in SIPP if would be an end-end option, which only the hosts on each end see, and thus cause zero processing overhead in the routers in the middle. Of course, this is more overhead, but TANSTAAFL. If anybody wants to see more detail on what some of these other approaches look like, it would only take about an hour or two to crank out modified versions of my design document for them. While it is possible to use either FQDN's or a new fixed length value (Transport Address), this really leads us to the fixed vs variable address debate. Indeed. Let's not do that all over again. I think I fall into the fixed length camp. Why, out of interest? Suppose the endpoint name *was* variable length, but was in an end-end option, so the routers never saw it, padded to a 64-bit boundary, etc (i.e. done with a view to efficient processing). What's the issue? I can show you tricks that mean it will take only a few extra instructions on each end to process TCP packets with these in them. Would this cost be acceptable? Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 03:26:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01068; Thu, 20 Oct 1994 03:26:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA15788; Thu, 20 Oct 1994 03:25:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15756; Thu, 20 Oct 1994 03:07:56 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00724; Thu, 20 Oct 1994 03:07:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09861; Wed, 19 Oct 94 13:07:45 -0400 Date: Wed, 19 Oct 94 13:07:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410191707.AA09861@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: Robert Elz The task was to define an EID. Nine questions were asked with this in mind. As I mentioned, this question could perhaps be better phrased. I'll answer the set of questions three times: once for endpoint names as a general concept, once for EID's as one specific kind of endpoint name, and once for DNS names (used as endpoint names) as another. Noel -------- 1. Are endpoint names short ? Depends on whether you want to put them in every packet, and, if so, what you think of the cost benefit ratio of using variable length ones. 2. Are endpoint names binary ? See above. 3. Are endpoint names globally unique ? Yes, absolutely. They might have a short form for use in packets (ESEL's) which would not be globally unique. 4. Do endpoint names exist at the [inter]network level ? Yes. The binding between endpoint names and addresses needs to be done at the internetwork level. 5. Do endpoint names exist in the transport layer ? Yes. They are the only name for entities in the network which is used at that layer. 6. Are endpoint names used to identify transport connections ? Yes. Along with the protocol and ports, the pair of endpoint names globally uniquely identify a connection. 7. Are endpoint names used as a key into any kind of database ? Depends. If your endpoint name is *not* a DNS name, you generally shouldn't be looking things up based on it; you should have the DNS name too. 8. Do endpoint names have any internal (administrative) structure ? Probably, even if it's only as much as IEEE 48-bit number have. 9. Are endpoint names present in every packet ? Depends on the form of endpoint names you use, and the resulting cost-benfit tradeoff. 1. Are EIDs short ? Shortish, and fixed length. Long enough to never run out. 2. Are EIDs binary ? Yes. 3. Are EIDs globally unique ? 4. Do EIDs exist at the network level ? 5. Do EIDs exist in the transport layer ? 6. Are EIDs used to identify transport connections ? 7. Are EIDs used as a key into any kind of database ? 8. Do EIDs have any internal (administrative) structure ? Same as above. 9. Are EIDs present in every packet ? Pretty much yes; some ICMP, etc packets might not need them. 1. Are DNS names short ? 2. Are DNS names binary ? Obvious. 3. Are DNS names globally unique ? 4. Do DNS names exist at the network level ? 5. Do DNS names exist in the transport layer ? 6. Are DNS names used to identify transport connections ? Same as up top. 7. Are DNS names used as a key into any kind of database ? 8. Do DNS names have any internal (administrative) structure ? Obvious. 9. Are DNS names present in every packet ? Not sure; it has advantages and disadvantages. It makes things simple, direct, robust, flexible, etc but there is a cost. From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 07:11:52 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05877; Thu, 20 Oct 1994 07:11:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08919 Thu, 20 Oct 1994 07:11:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA15981; Thu, 20 Oct 1994 07:05:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA15965; Thu, 20 Oct 1994 06:47:12 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05252; Thu, 20 Oct 1994 06:47:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11243; Wed, 19 Oct 94 16:47:03 -0400 Date: Wed, 19 Oct 94 16:47:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410192047.AA11243@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Mobility, multi-homing, etc.. Cc: jnc@ginger.lcs.mit.edu I'm a total idiot. There is a much, much simpler way to do this in the current architecture. A connection is identified by the (orginal source address, o. destination a., sorurce port, d.p) etc. If you need to relocate one end of the connection, you put the new "actual address" of the host in a loose source route option, and leave the original "identifying address" as the packet's ultimate destination address. In other words, the "address" field in the internetwork header is both an endpoint identifier and a locator, unless it's only only an endpoint identifier, in which case the locator is elsewhere, as the last hop in the loose source route. This is basically Steve's original way of looking at it; you have both functions in one field unless it needs to be in two. The details are all obvious. There's a very similar protocol which can say "bind alternative address Xi to original address A". Upward compatibility is provided automatically, since if the recipient doesn't understand the request, you don't get an ack. The internetwork layer has to notice that outbound packets to A need to have a loose source route to Xn inserted; this can be done efficiently by marking the entry for A in the route cache. If you have fault recovery, you have to have some mechanism for selecting a new Xi if Xn is not working. That's it. One important thing to note is that you can stick the whole thing in the internetwork layer, and there don't have to be any changes to TCP at all (at least, if all you want is mobility; fault recovery means you need a "retransmitting to " downcall). It uses the same interfaces up and down, does the checksum the same way as always, doesn't have to know about alternative addresses, etc, etc. Moreover, if the mechanism is placed in the internetwork layer, all transport layers start to use it automagically (again, for mobility), with no changes to them. I still claim we'd be better off explicity separate out endpoint names from addresses, but that's a lot of work, at least to do it cleanly. Noel From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 11:12:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14200; Thu, 20 Oct 1994 11:12:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA16221; Thu, 20 Oct 1994 11:05:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA16218; Thu, 20 Oct 1994 10:55:27 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13585; Thu, 20 Oct 1994 10:55:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 20 Oct 94 09:45:20 +0900 From: Masataka Ohta Message-Id: <9410200045.AA08159@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 20 Oct 94 9:45:18 JST Cc: amolitor@anubis.network.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9410191623.AA09621@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 19, 94 12:23 pm X-Mailer: ELM [version 2.3 PL11] > Errr, I'm not sure he was referring to EID's anywhere with TCN's (the term EUD > is not used in his TCN document). I suspect his reply about the EID questions > was based on using DNS names as "EID's". Dave should just say DNS host name, not EID. Still, his total misnderstanding on DNS host names is silly. Masataka Ohta PS Don't just say "DNS names". That's no different from just saying "names" and causes layering confusion. A DNS name names an entity at the internet layer only when it is a hostname (have A record) or under in-addr.arpa. A DNS name with MX but no A names a transport layer entity but not an internet layer one. From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 11:37:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14614; Thu, 20 Oct 1994 11:20:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA16251; Thu, 20 Oct 1994 11:20:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA16204; Thu, 20 Oct 1994 10:54:05 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10849; Thu, 20 Oct 1994 09:47:36 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA18972; Wed, 19 Oct 1994 16:45:22 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Oct 1994 16:45:24 -0700 To: amolitor@anubis.network.com (Andrew Molitor) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU At 8:34 AM 10/19/94, Andrew Molitor wrote: > Your TCNs seem to satisfy almost none of the original notion >of EID. It's Noel's word, and it means something very specific, which Having watched the EID debate over about 18 months (or longer? Well, it SEEMED longer...) I have to tell you that while YOU might think the term was and is very specific, there was nothing to indicate a useful consensus about a useful definition. Yes, I did hear many people make assertions like yours, over the course of that time, but when they attempted to provide a specific definition over which even that core of advocates agreed, things bogged down. That was the reason for the EID BOF. All of this convinced me of two things: 1) EIDs were open season, and 2) most of what people thought needed to be done with a major modification to core constructs to the Internet layer didn't. >TCNs are not, so let's not pretend that TCNs are EIDs. It might be fair >to say that they're trying to solve a similar set of problems, but they're Ahh, well now, this gets more interesting. Personally, I think it would be far more interesting to shoot at the specific functions of the proposal than the purity of linguistic reference, especially when the reference is to a term with no operational history and (IMO, of course) no meanginful consensus. (If we REALLY had consensus, Robert would not have held the BOF and we wouldn't have this fun questionnaire to answer. >language here, but it is really ludicrous how some IETFers change many things done by many IETFers are ludicrous. As long as we get back to working on concrete material, it's ok... d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 11:46:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15686; Thu, 20 Oct 1994 11:46:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA16297; Thu, 20 Oct 1994 11:45:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA16292; Thu, 20 Oct 1994 11:42:22 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15368; Thu, 20 Oct 1994 11:39:11 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 20 Oct 94 10:30:32 +0900 From: Masataka Ohta Message-Id: <9410200130.AA08516@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 20 Oct 94 10:30:30 JST Cc: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9410191707.AA09861@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 19, 94 1:07 pm X-Mailer: ELM [version 2.3 PL11] > 5. Do endpoint names exist in the transport layer ? > > Yes. They are the only name for entities in the network which is used at that > layer. Urrr, the endpoint names is "visible" from transport layer protocols. Transport layer protocol specification may have a variable to store endpoint name. But, that is a question which is asked in the next question. 6. Are endpoint names used to identify transport connections ? In question 5, "exist" has narrower meaning. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 12:10:11 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16677; Thu, 20 Oct 1994 12:10:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05194 Thu, 20 Oct 1994 12:08:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA16327; Thu, 20 Oct 1994 12:05:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA16313; Thu, 20 Oct 1994 11:46:57 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15697; Thu, 20 Oct 1994 11:46:54 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Big-Internet@munnari.OZ.AU Subject: Re: EIDs from the BOF In-Reply-To: Your message of "Wed, 19 Oct 1994 13:07:45 -0400." <9410191707.AA09861@ginger.lcs.mit.edu> Date: Thu, 20 Oct 1994 11:46:48 +1000 Message-Id: <9768.782617608@munnari.OZ.AU> From: Robert Elz Date: Wed, 19 Oct 94 13:07:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9410191707.AA09861@ginger.lcs.mit.edu> As I mentioned, this question could perhaps be better phrased. That's probably true, of that, and almost everything else I write ... I'll answer the set of questions three times: If all the answers were the same, this would simply be redundant, as they're not, it misses the point. once for endpoint names as a general concept, This is what we want - ie: the idea is to determine what are the essential properties of these things, so its possible to then decide which specific mechanism may be able to implement them, if any is needed at all. once for EID's as one specific kind of endpoint name, and once for DNS names (used as endpoint names) as another. Those two are simply reciting obvious facts, which is not really useful. kre From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 12:46:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18151; Thu, 20 Oct 1994 12:46:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA16394; Thu, 20 Oct 1994 12:45:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA16368; Thu, 20 Oct 1994 12:26:54 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16531; Thu, 20 Oct 1994 12:05:11 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: From jnc: Mobilty and Multi-homing with Endpoint Names Date: Thu, 20 Oct 1994 12:05:02 +1000 Message-Id: <9786.782618702@munnari.OZ.AU> From: Robert Elz Noel sent me the following message ... ------- Forwarded Message From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 19 Oct 94 03:06:33 -0400 To: big-internet-request@munnari.oz.au Subject: Document, please post and notify big-i list Internet Draft J. Noel Chiappa Expires: April 19, 1995 October 19, 1994 Mobilty and Multi-homing with Endpoint Names Status of this Memo [boilerplate] Abstract When using the Internet protocol suite, processes communicate via transport associations, such as TCP connections; these define end- to-end communication relationships, or contexts, between the processes. Enhanced services, such as for host and service mobility and failure recovery, can be facilitated by distinguishing a transport association from the underlying internetwork service(s) it uses. This distinction will allow relocating one or both ends of the context, while maintaining a consistent and unique reference to that context, independent of its network connectivity. This proposal suggests using domain names to identify the ends of the context, and then uses a combination of domain names, port numbers and protocol identifiers to define transport associations. It then uses an internetwork level control channel between hosts for adding and removing internetwork addresses associated with the ends of the context. This document is a description of the proposed facility, rather than a complete specification. It is intended to convey the concepts and style of the proposed mechanism, saving the details of formats for later. [Text deleted] ------- End of Forwarded Message You can find the full text of this (unpaginated) draft at the URL (if I have the syntax right) ftp://munnari.oz.au/big-internet/jnc-mobility or in a more verbose form, via anon FTP to munnari.oz.au in the directory big-internet the file named "jnc-mobility". Note: I invented the file name, Noel didn't send me one to use, so if its inappropriate, that's my fault. kre From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 15:28:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25601; Thu, 20 Oct 1994 15:28:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA16552; Thu, 20 Oct 1994 15:27:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA16547; Thu, 20 Oct 1994 15:26:41 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25380; Thu, 20 Oct 1994 15:26:35 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id WAA20433; Wed, 19 Oct 1994 22:25:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 19 Oct 1994 22:25:57 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU At 5:45 PM 10/19/94, Masataka Ohta wrote: >> Errr, I'm not sure he was referring to EID's anywhere with TCN's (the >>term EUD >> is not used in his TCN document). I suspect his reply about the EID questions >> was based on using DNS names as "EID's". > >Dave should just say DNS host name, not EID. I can't wait for you and Noel to finally decide on what I meant or what I know or what you agree with or... Let me know when you get done. >Still, his total misnderstanding on DNS host names is silly. Is there some reason that you put so much effort into being so rude? It would not be a significant concern, but you choose to do it so pubicly and -- pardon my using your term -- in such a silly way. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 16:12:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25934; Thu, 20 Oct 1994 15:34:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA16567; Thu, 20 Oct 1994 15:34:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA16522; Thu, 20 Oct 1994 15:07:38 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24529; Thu, 20 Oct 1994 15:07:28 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 20 Oct 94 13:59:48 +0859 From: Masataka Ohta Message-Id: <9410200500.AA10364@necom830.cc.titech.ac.jp> Subject: Re: From jnc: Mobilty and Multi-homing with Endpoint Names To: kre@munnari.OZ.AU (Robert Elz) Date: Thu, 20 Oct 94 13:59:46 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9786.782618702@munnari.OZ.AU>; from "Robert Elz" at Oct 20, 94 12:05 pm X-Mailer: ELM [version 2.3 PL11] > Noel sent me the following message ... > When using the Internet protocol suite, processes communicate via > transport associations, such as TCP connections; Connection! Why? > these define end- > to-end communication relationships, or contexts, between the > processes. Enhanced services, such as for host and service mobility > and failure recovery, can be facilitated by distinguishing a transport > association from the underlying internetwork service(s) it uses. This > distinction will allow relocating one or both ends of the context, > while maintaining a consistent and unique reference to that context, > independent of its network connectivity. This proposal suggests using > domain names to identify the ends of the context, and then uses a > combination of domain names, port numbers and protocol identifiers to > define transport associations. Context is highly connection oriented concept and, thus, uninteresting to me. Trying to relate the transport layer is the source of all the misconceptions. > It then uses an internetwork level > control channel between hosts for adding and removing internetwork > addresses associated with the ends of the context. As for mobility, that's what mobility protocol has effectively done already. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 17:54:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29917; Thu, 20 Oct 1994 17:07:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA16666; Thu, 20 Oct 1994 17:07:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA16648; Thu, 20 Oct 1994 16:49:54 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26152; Thu, 20 Oct 1994 15:40:54 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 20 Oct 94 14:32:04 +0900 From: Masataka Ohta Message-Id: <9410200532.AA10606@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Thu, 20 Oct 94 14:32:02 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 19, 94 10:25 pm X-Mailer: ELM [version 2.3 PL11] > I can't wait for you and Noel to finally decide on what I meant or what I > know or what you agree with or... > > Let me know when you get done. I have finished to decide what you don't understand long before and is trying to protect the discussion from the total chaos. > >Still, his total misnderstanding on DNS host names is silly. > > Is there some reason that you put so much effort into being so rude? Rude? Yes. It's you who said to Robert: :>4. Do EIDs exist at the network level ? : :silly question... and I commented your answer is silly. So, we are rude. I remember you are told to be rude from people of ISO and you answered IETF should be rude, not polite. What's the problem? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Oct 20 22:48:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08598; Thu, 20 Oct 1994 21:47:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA16915; Thu, 20 Oct 1994 21:47:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16910; Thu, 20 Oct 1994 21:41:55 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07260; Thu, 20 Oct 1994 20:57:21 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA10350; Thu, 20 Oct 94 11:00:18 GMT Received: from mcimail.com by mailgate.mcimail.com id ab29137; 20 Oct 94 10:57 WET Date: Thu, 20 Oct 94 05:56 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa , Big Internet Subject: Re: EIDs from the BOF Message-Id: <13941020105631/0003858921NA4EM@MCIMAIL.COM> I have been listening, quietly to this debate, and tend to agree with Noel's comments below. I think that I would need the endpoint in every packet for fast switching for mobile applications. Of course this would depend on how the protocol was developed to switch to another point, I guess. Thus the point that I would change with Noel's answers is small endpoint names for the reason that he states. But again that would depend on implementation of recovery and force move mechanisms? Bob 1. Are endpoint names short ? Depends on whether you want to put them in every packet, and, if so, what you think of the cost benefit ratio of using variable length ones. 2. Are endpoint names binary ? See above. 3. Are endpoint names globally unique ? Yes, absolutely. They might have a short form for use in packets (ESEL's) which would not be globally unique. 4. Do endpoint names exist at the [inter]network level ? Yes. The binding between endpoint names and addresses needs to be done at the internetwork level. 5. Do endpoint names exist in the transport layer ? Yes. They are the only name for entities in the network which is used at that layer. 6. Are endpoint names used to identify transport connections ? Yes. Along with the protocol and ports, the pair of endpoint names globally uniquely identify a connection. 7. Are endpoint names used as a key into any kind of database ? Depends. If your endpoint name is *not* a DNS name, you generally shouldn't be looking things up based on it; you should have the DNS name too. 8. Do endpoint names have any internal (administrative) structure ? Probably, even if it's only as much as IEEE 48-bit number have. 9. Are endpoint names present in every packet ? Depends on the form of endpoint names you use, and the resulting cost-benfit tradeoff. From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 00:30:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14285; Fri, 21 Oct 1994 00:30:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA17150; Fri, 21 Oct 1994 00:27:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA17065; Fri, 21 Oct 1994 00:11:44 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13715; Fri, 21 Oct 1994 00:11:37 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id HAA22555; Thu, 20 Oct 1994 07:10:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Oct 1994 07:11:06 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU At 10:32 PM 10/19/94, Masataka Ohta wrote: >It's you who said to Robert: > >:>4. Do EIDs exist at the network level ? >: >:silly question... Oh, so you were acting to protect Robert? How considerate. On the other hand, my original comment was intended as facetious, however obliquely, given the long and painful history of the particular question on the questionnaire and the details of my proposal. Somehow, I suspect you were being serious. >I remember you are told to be rude from people of ISO and you answered >IETF should be rude, not polite. What's the problem? I would LOVE to find out what you are referring to, complete with some documentation. I almost never condone rudeness between institutions. It's much better to keep it personal. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 01:08:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15574; Fri, 21 Oct 1994 01:08:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17205; Fri, 21 Oct 1994 01:07:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA17187; Fri, 21 Oct 1994 00:50:25 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14931; Fri, 21 Oct 1994 00:50:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16333; Thu, 20 Oct 94 10:49:54 -0400 Date: Thu, 20 Oct 94 10:49:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410201449.AA16333@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, jnc@ginger.lcs.mit.edu Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> I think that I would need the endpoint in every packet for fast switching for mobile applications. Of course this would depend on how the protocol was developed to switch to another point, I guess. What mechanistic use are you seeing for having the endpoint name in every packet? Are you thinking that the routign is somehow going to track endpoints? (Not trying to beat you up, just don't understand! :-) Thus the point that I would change with Noel's answers is small endpoint names for the reason that he states. Well, you can't make them *really* small, not if they are going to be globally unique. E.g., an ESEL is only unique in the context of a single address/locator. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 01:28:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16165; Fri, 21 Oct 1994 01:28:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17248; Fri, 21 Oct 1994 01:27:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA17232; Fri, 21 Oct 1994 01:17:33 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15883; Fri, 21 Oct 1994 01:17:26 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA22773; Thu, 20 Oct 1994 08:16:26 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Oct 1994 08:16:28 -0700 To: Masataka Ohta From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU At 7:36 AM 10/20/94, Masataka Ohta wrote: >Seeing a lot of confusions on layering in every areas of IETF, I'm >so serious. on the other hand, it's not at all clear that all that layering confusion is not, in fact, helpful. It's tough to argue that the IETF's awful modeling has hindered the success of the technology. >Hmmm, I thought ML is as personal as ISOC BOF at Houston where >you have been so proudly rude. attempting to educate a participant about the realities of IETF operations is not rudeness. Calling someone crazy or silly is. >The best way to attack me is to say I'm polite. oh. so that's the secret. somehow, I can seem to get the words out. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 02:07:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16734; Fri, 21 Oct 1994 01:47:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17287; Fri, 21 Oct 1994 01:47:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA17278; Fri, 21 Oct 1994 01:41:02 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15233; Fri, 21 Oct 1994 00:55:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16446; Thu, 20 Oct 94 10:55:20 -0400 Date: Thu, 20 Oct 94 10:55:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410201455.AA16446@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: EIDs from the BOF Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Robert Elz > once for EID's as one specific kind of endpoint name, > and once for DNS names (used as endpoint names) as another. Those two are simply reciting obvious facts, which is not really useful. Well, obvious to you perhaps, but perhaps not to everyone. :-) E.g., I'm not sure everyone realizes that "endpoint names" and "EIDs" are different things; the EIDs being merely a specific instantiation of a general idea. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 02:08:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16758; Fri, 21 Oct 1994 01:49:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17306; Fri, 21 Oct 1994 01:49:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA17281; Fri, 21 Oct 1994 01:44:42 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16253; Fri, 21 Oct 1994 01:30:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17410; Thu, 20 Oct 94 11:30:25 -0400 Date: Thu, 20 Oct 94 11:30:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410201530.AA17410@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: EIDs from the BOF Cc: amolitor@anubis.network.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Masataka Ohta Don't just say "DNS names". That's no different from just saying "names" and causes layering confusion. I'm trying to always use the term "name" in the sense of RFC-1498; i.e. a generic term for any kind of label or identifier for an object. While it may be possible for all readers to figure out from the context whether I mean "DNS name" or just "1498-type name" when I use the term "name", I think it is a source of pontential confusion, and one I would like to avoid if possible. A DNS name names an entity at the internet layer only when it is a hostname (have A record) or under in-addr.arpa. A DNS name with MX but no A names a transport layer entity but not an internet layer one. Right. In general I think of a "DNS name" as naming a node in the DNS database, which may or may not have an internet address attribute (i.e. A record). If we use DNS-type names for endpoints, a DNS-type name could also name an endpoint. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 02:08:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16772; Fri, 21 Oct 1994 01:50:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17321; Fri, 21 Oct 1994 01:50:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA17275; Fri, 21 Oct 1994 01:40:52 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14866; Fri, 21 Oct 1994 00:46:07 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 20 Oct 94 23:36:49 +0859 From: Masataka Ohta Message-Id: <9410201437.AA13634@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Thu, 20 Oct 94 23:36:47 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 20, 94 7:11 am X-Mailer: ELM [version 2.3 PL11] > >It's you who said to Robert: > > > >:>4. Do EIDs exist at the network level ? > >: > >:silly question... > > Oh, so you were acting to protect Robert? Not precisely. I protected Robert's questions. > How considerate. Not so much. > On the other hand, my original comment was intended as facetious, however > obliquely, given the long and painful history of the particular question on > the questionnaire and the details of my proposal. > > Somehow, I suspect you were being serious. As I'm still learning English from all of you, I don't mind if you think me something like a parrot or Eliza which bounces your words. > >I remember you are told to be rude from people of ISO and you answered > >IETF should be rude, not polite. What's the problem? > > I would LOVE to find out what you are referring to, complete with some > documentation. I'm the first to complete the homework on how EID should be. So, you should be asking for a complete layering document. How do you think about forming a WG to write an informational RFC of layering handbook? Seeing a lot of confusions on layering in every areas of IETF, I'm so serious. > I almost never condone rudeness between institutions. I'm very glad to hear that. I respect you being rude. > It's much better to keep it personal. Hmmm, I thought ML is as personal as ISOC BOF at Houston where you have been so proudly rude. Masataka Ohta PS The best way to attack me is to say I'm polite. From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 02:09:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16851; Fri, 21 Oct 1994 01:51:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17338; Fri, 21 Oct 1994 01:51:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA17284; Fri, 21 Oct 1994 01:44:57 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16010; Fri, 21 Oct 1994 01:25:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17363; Thu, 20 Oct 94 11:25:22 -0400 Date: Thu, 20 Oct 94 11:25:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410201525.AA17363@ginger.lcs.mit.edu> To: amolitor@anubis.network.com, dcrocker@mordor.stanford.edu Subject: Re: EIDs from the BOF Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) I have to tell you that while YOU might think the term was and is very specific, there was nothing to indicate a useful consensus about a useful definition. While you may not think so, the person who invented the terms "endpoint", "endpoint name", and "EID" has always had a clear idea of what they meant, which hasn't changed. I will certainly concede that there has been some confusion as to definitions (in part due to lack of a formal document; I have one half-completed, and perhaps I should provide the incomplete form, since it does give these definitions at least), but I'm not sure doing a document is going to fix it. "locator" is very precisely defined in several documents, but people still get that one wrong too. Here are the definitions (from the draft where possible): - An "endpoint" is thus defined as one participant of an end-end communication; i.e. the fundamental agent of end-end communications. It is the entity which is performing a reliable communication on an end-end basis. - An "endpoint name" is a label or identifier for an endpoint. It does not refer to any specific class or type of name, as to form (human readable - ASCII - or computer - binary), scope (globally or locally unique), length (fixed or variable), topological sensitivity, etc. - An "EID" is a specific kind of endpoint name; viz. one which is globally unique, topologically insensitive, fixed length, "shortish" (48-128 bits), binary. There has also certainly been a lack of consensus as the utility of endpoint names, and what form they would take (EID's, or some other form), but I think that's a separate, and legitimate, debate. I did hear many people make assertions like yours ... but when they attempted to provide a specific definition over which even that core of advocates agreed, things bogged down. That was the reason for the EID BOF. I would say the BoF was more caused by debate over the utility, function and form of endpoint names, than by a confusion over definitions. most of what people thought needed to be done with a major modification to core constructs to the Internet layer didn't. Any one thing can be done with a localized change. However, the chief argument for explicit recognition of endpoint, and naming of them, is overall utility, simplicity, directness, robustness, flexibility, etc (all properties I treasure highly in designs that have to have a long life-time). I think it would be far more interesting to shoot at the specific functions of the proposal than the purity of linguistic reference, Well, for people who prefer to look at specific proposals, you've got one now. Comments? especially when the reference is to a term with no operational history Oh, right. So this means we should have never introduced the concept "process", since it had no operational history prior to '62 or so. What a ridiculous argument. If we REALLY had consensus, Robert would not have held the BOF and we wouldn't have this fun questionnaire to answer. Consensus on form and use is a different issue from consensus on terminology and definitions, although of course the latter may have some slight impact on the former. Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 03:08:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19406; Fri, 21 Oct 1994 03:08:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA17421; Fri, 21 Oct 1994 03:07:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA17405; Fri, 21 Oct 1994 02:53:05 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19048; Fri, 21 Oct 1994 02:52:56 +1000 (from rharris@espresso.rt.cs.boeing.com) Received: by atc.boeing.com (5.57) id AA17629; Thu, 20 Oct 94 09:56:09 -0700 Received: from spook.network-b by espresso.rt.cs.boeing.com (4.1/SMI-4.1) id AA16400; Thu, 20 Oct 94 09:52:21 PDT Date: Thu, 20 Oct 94 09:52:21 PDT From: "Richard L. Harris (206) 865-4922" Message-Id: <9410201652.AA16400@espresso.rt.cs.boeing.com> To: Big-Internet@munnari.OZ.AU Subject: Re: EIDs from the BOF Bobs message could have come from me so I'll second it with one small(?) addition. The endpoint id is also needed for security purposes. Besides the required property of global uniqueness they should have as long a lifetime as possible, certainly at least as long as any association. Rich Harris rharris@atc.boeing.com Boeing Computer Services "The opinions expressed are mine, not those of the Boeing Company." > From: "Robert G. Moskowitz" <0003858921@mcimail.com> > > I have been listening, quietly to this debate, and tend to agree with Noel's > comments below. I think that I would need the endpoint in every packet for security and for > fast switching for mobile applications. Of course this would depend on how > the protocol was developed to switch to another point, I guess. > > Thus the point that I would change with Noel's answers is small endpoint > names for the reason that he states. > > But again that would depend on implementation of recovery and force move > mechanisms? > > Bob > > > 1. Are endpoint names short ? > > Depends on whether you want to put them in every packet, and, if so, what > you think of the cost benefit ratio of using variable length ones. > > 2. Are endpoint names binary ? > > See above. > > 3. Are endpoint names globally unique ? > > Yes, absolutely. They might have a short form for use in packets (ESEL's) > which would not be globally unique. > > 4. Do endpoint names exist at the [inter]network level ? > > Yes. The binding between endpoint names and addresses needs to be done at > the internetwork level. > > 5. Do endpoint names exist in the transport layer ? > > Yes. They are the only name for entities in the network which is used at > that layer. > > 6. Are endpoint names used to identify transport connections ? > > Yes. Along with the protocol and ports, the pair of endpoint names globally > uniquely identify a connection. > > 7. Are endpoint names used as a key into any kind of database ? > > Depends. If your endpoint name is *not* a DNS name, you generally shouldn't > be looking things up based on it; you should have the DNS name too. Extending current practices they would potentialy be a key into a collection of security information. > > 8. Do endpoint names have any internal (administrative) structure ? > > Probably, even if it's only as much as IEEE 48-bit number have. > > 9. Are endpoint names present in every packet ? > > Depends on the form of endpoint names you use, and the resulting cost-benfit > tradeoff. > > > > > From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 09:08:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00969; Fri, 21 Oct 1994 09:08:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17733; Fri, 21 Oct 1994 09:07:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17715; Fri, 21 Oct 1994 08:49:20 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00260; Fri, 21 Oct 1994 08:48:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21455; Thu, 20 Oct 94 18:48:11 -0400 Date: Thu, 20 Oct 94 18:48:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410202248.AA21455@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, rharris@espresso.rt.cs.boeing.com Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: "Richard L. Harris" The endpoint id is also needed for security purposes. Besides the required property of global uniqueness they should have as long a lifetime as possible, certainly at least as long as any association. Hmm. That means you can't use an address as an endpoint name (as with the LSR idea), unless you are guaranteed it won't be reused. Hmmm.... Noel From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 12:05:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06610; Fri, 21 Oct 1994 11:28:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA17870; Fri, 21 Oct 1994 11:27:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17854; Fri, 21 Oct 1994 11:19:40 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05614; Fri, 21 Oct 1994 10:58:32 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id RAA25835; Thu, 20 Oct 1994 17:58:00 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 20 Oct 1994 17:58:04 -0700 To: Big-Internet@munnari.OZ.AU From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF > The endpoint id is also needed for security purposes. Besides > the required property of global uniqueness they should have as long a > lifetime as possible, certainly at least as long as any association. current-style IPv4 'addresses' have been deemed entirely adequate by the IETF technical community that provided input to IPng requirements. When did this 'long lifetime' requirement emerge and do others from the security technical community concur. And why? d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 12:07:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08164; Fri, 21 Oct 1994 12:07:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17919; Fri, 21 Oct 1994 12:07:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17911; Fri, 21 Oct 1994 12:00:04 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07760; Fri, 21 Oct 1994 11:58:48 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 10:48:26 +0900 From: Masataka Ohta Message-Id: <9410210148.AA15779@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 21 Oct 94 10:48:24 JST Cc: jnc@ginger.lcs.mit.edu, amolitor@anubis.network.com, big-internet@munnari.OZ.AU In-Reply-To: <9410201530.AA17410@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 20, 94 11:30 am X-Mailer: ELM [version 2.3 PL11] > Right. In general I think of a "DNS name" as naming a node in the DNS > database, which may or may not have an internet address attribute (i.e. A > record). Sure. > If we use DNS-type names for endpoints, a DNS-type name could also > name an endpoint. It's safer to say "DNS host name" (or "DNS endpoint name", if you think it useful) if it is so specific. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 12:10:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08281; Fri, 21 Oct 1994 12:10:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17936; Fri, 21 Oct 1994 12:08:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17914; Fri, 21 Oct 1994 12:04:41 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06944; Fri, 21 Oct 1994 11:37:09 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 10:26:09 +0900 From: Masataka Ohta Message-Id: <9410210126.AA15678@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 21 Oct 94 10:26:07 JST Cc: Big-Internet@munnari.OZ.AU, rharris@espresso.rt.cs.boeing.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9410202248.AA21455@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 20, 94 6:48 pm X-Mailer: ELM [version 2.3 PL11] > The endpoint id is also needed for security purposes. Besides > the required property of global uniqueness they should have as long a > lifetime as possible, certainly at least as long as any association. > > Hmm. That means you can't use an address as an endpoint name (as with the LSR > idea), unless you are guaranteed it won't be reused. Hmmm.... Certicate based security system does have revocation mechanisms of expiration period and redemption list, which gives guaranteed timing on when an ID may be reused, on which sucure DNS proposals are constructed. So, you can rely secure DNS here. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 14:09:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10224; Fri, 21 Oct 1994 13:08:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA18009; Fri, 21 Oct 1994 13:07:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17991; Fri, 21 Oct 1994 12:54:50 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09105; Fri, 21 Oct 1994 12:31:06 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 10:38:37 +0900 From: Masataka Ohta Message-Id: <9410210138.AA15728@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Fri, 21 Oct 94 10:38:35 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 20, 94 8:16 am X-Mailer: ELM [version 2.3 PL11] > >Seeing a lot of confusions on layering in every areas of IETF, I'm > >so serious. > > on the other hand, it's not at all clear that all that layering confusion > is not, in fact, helpful. "confusions on layering" does not mean, so called, "good natured layering violation" which actually is not related too layering but just a proper implementation. > It's tough to argue that the IETF's awful > modeling has hindered the success of the technology. Of course, the handbook should spend a lot of words on how NOT to layer implementations. But the model of TCP/IP is layered quite properly. Separation of TCP and IP is the successful layering for the transport and the internet layers. Catenet model is also the successful layering for the internet and the link layers. > >Hmmm, I thought ML is as personal as ISOC BOF at Houston where > >you have been so proudly rude. > > attempting to educate a participant about the realities of IETF operations > is not rudeness. Calling someone crazy or silly is. At the BOF, you used the word "rude" for you. So, I feel good if you call me rude. > >The best way to attack me is to say I'm polite. > > oh. so that's the secret. > > somehow, I can seem to get the words out. "considerate" was a good shot. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 14:54:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13881; Fri, 21 Oct 1994 14:28:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA18161; Fri, 21 Oct 1994 14:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA18145; Fri, 21 Oct 1994 14:21:25 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13659; Fri, 21 Oct 1994 14:21:03 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA27947; Thu, 20 Oct 94 21:19:55 -0700 Received: by xirtlu.zk3.dec.com; id AA23964; Fri, 21 Oct 1994 00:19:51 -0400 Message-Id: <9410210419.AA23964@xirtlu.zk3.dec.com> To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: PROCESSES : Re: From jnc: Mobilty and Multi-homing ....... In-Reply-To: Your message of "Thu, 20 Oct 94 12:05:02 +1000." <9786.782618702@munnari.OZ.AU> Date: Fri, 21 Oct 94 00:19:45 -0400 X-Mts: smtp >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >Date: Wed, 19 Oct 94 03:06:33 -0400 >To: big-internet-request@munnari.oz.au >Subject: Document, please post and notify big-i list >Internet Draft J. Noel Chiappa >Expires: April 19, 1995 October 19, 1994 > Mobilty and Multi-homing with Endpoint Names >Status of this Memo > [boilerplate] >Abstract >When using the Internet protocol suite, processes communicate via >transport associations, such as TCP connections; these define end- Applications communicate not processes. /jim From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 14:56:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13942; Fri, 21 Oct 1994 14:30:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA18176; Fri, 21 Oct 1994 14:30:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA18142; Fri, 21 Oct 1994 14:19:52 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13546; Fri, 21 Oct 1994 14:19:49 +1000 (from kre@munnari.OZ.AU) Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20435; Fri, 21 Oct 1994 03:34:22 +1000 (from solensky@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 20 Oct 1994 13:33:58 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 20 Oct 1994 13:33:58 -0400 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA17569; Thu, 20 Oct 94 13:33:56 EDT Date: Thu, 20 Oct 94 13:33:56 EDT Message-Id: <9410201733.AA17569@mailserv-D.ftp.com> To: ipv4-ale@research.ftp.com, kre@munnari.OZ.AU Subject: New growth charts From: solensky@ftp.com (Frank T Solensky) Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Thu Oct 20 13:33:52 1994] Originating-Client: fenway.ftp.com Content-Length: 2596 Resent-To: Big-Internet@munnari.OZ.AU Resent-From: Big-Internet-Request@munnari.OZ.AU Resent-Comment: Frank's file is in the B-I archives now Resent-Date: Fri, 21 Oct 1994 14:19:00 +1000 Resent-Message-Id: <10346.782713140@munnari.OZ.AU> Resent-Sender: kre@munnari.OZ.AU I just completed a new set of logistic regressions against the Assigned and Allocated IP Network numbers; the graphs can be gotten via anonFTP at research.ftp.com:pub/ale/nsf-netnumbers-9409.ps and (as soon as kre forwards this message to the big-internet list) munnari.oz.au:big-internet/nsf-netnumbers-9409.ps These graphs have the same basis as prior ones: it's a best-fit curve against the sum of the Assigned and Allocated numbers as reported by the Internic -- this acts as a way of tracking the proportion of the IP address space that IANA has at least delegated to other providers and conversely, the proportion of the address space that they have remaining (I'm going to try writing up an RFC sometime soon that goes deeper into these gory details). ** As always: past performance is no guarantee of future results. *** ** I am not attempting to make predictions about the impact that *** ** unknown technologies will have on these curves. *** Graph 1: the amount of the Class B address space delegated. This doesn't look very different that the last set: the curves still top out well below the ceiling. Graphs 2 and 3: a 'regular' and log-scaled representation of the Class C address space. There are two trend lines on each of these graphs: the first one is based on the data available since September 1992 and includes two large increases in the total (August 1993 and May 1994). The second trend line is based on a 'smoothed' data series where those two jumps are replaced with estimates on the average growth rates near those points with the remaining data pulled upwards by those differences. These reflect the two different assumptions one can make about these jumps: in the former case, one would expect these jumps as a natural occurance and could continue to occur at any time; in the latter, one would say that these were two exceptional events and are unlikely to ever recur. In both cases, these graphs suggest that there's more time available before the Class C address space is threatened: the July graphs suggested early-1996 and late-2000 at the problem points respectively, the new graphs push them out further. The last couple of months had relatively small increases in the number of assigned and allocated numbers and pulled down the trend lines as a result. What's particularly interesting this time is that the _former_ curve is the one that tops out within the existing Class C space while the latter one goes through the top of the Class C space in the year 2000 and the top of the A-sharp space around 2006. -- Frank From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 14:57:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13951; Fri, 21 Oct 1994 14:31:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA18195; Fri, 21 Oct 1994 14:31:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA18139; Fri, 21 Oct 1994 14:15:40 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11421; Fri, 21 Oct 1994 13:33:13 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 21 Oct 94 12:24:50 +0859 From: Masataka Ohta Message-Id: <9410210325.AA16591@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 21 Oct 94 12:24:48 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9646.782546121@munnari.OZ.AU>; from "Robert Elz" at Oct 19, 94 3:55 pm X-Mailer: ELM [version 2.3 PL11] > My answers ... > 1. Probably (short) > 2. Yes (binary) > 3. Yes (unique) > 4. Probably (network level) > 5. No (transport level) > 6. Yes (identify transport connections) > 7. Yes (database key) > 8. Yes (internal admin structure) > 9. Probably (in every packet) Same as mine (presented at the last BOF) and that of IPv4 address, except that 1, 4, 9 are "Yes". And reasons are the same. > There's already been a lot said about mobility, which is one > such application, its an example of a place where stable > identity (not affected by topology) can help, and I propose to > say no more about it at all, I don't regard it as all that > important (as an argument for EIDs). Important part of mobility is on how to notify location changes quickly enough. Unimportant part of mobility is on how to reroute, for which there can be several mechanisms including EID related ones. > Because of this I am almost totally convinced that we absolutely > don't want any kind of address -> name mapping, at all. > > When combined with the added restrictions that being a key > for the DNS imposes - well known structure that defines > zone delegations, which in turn tends to limit flexibility > in setting subnet boundaries in arbitrary ways - they work, > but politically managing the address->name DNS zone files > becomes brudensome enough that its not worth doing - I am > even more convinced that address -> name mappings are simply > a bad idea. I have different reason. If address is controlled by providers, and have provider based hierarchy which is used for DNS hierarchy, address -> name mapping is controlled by providers. Then, end users have some dependency on providers, which I don't think comfortable. > However, we certainly still need some form of packet-sender -> > name mapping available, this is an identifying function, and its > for this that I would use the EID. Sure. > Instead, lets go to question 9 - are EIDs in every packet. > Here I say "probably" - I can imagine the possibility that > this might not be needed, but I'd imagine even then that > most packets would contain EIDs. All IP packets should contain EIDs and a host should accept packets to it only by checking EID match. Thus, multi-homing issues disappear. That's why my answers to 1 and 9 are "Yes". > EIDs certainly wouldn't want to exist at the transport layer, > both because they need to be universal, every transport layer > packet, of every transport layer, and packets that have no > transport layer data in the conventional sense in them at all > (ICMP, IGMP, even perhaps ARP) need this identification. ARP, sure. IPv4 ARP is ------+-------------- | MAC? | IPv4 address | ------+-------------- I wrote: :All packets should contain EIDs and a host should accept packets to :it only by checking EID match. So, EID based ARP will be ------+------------------------ | MAC? | EID | ------+------------------------ Both ARP does not contain provider dependent information, which ease configuration. > That's > question 5 - No. They will probably be at the network layer, as > its that that provides end to end connectivity, and which is > examined by routers to achieve that, however, an intermediate > layer, probably in every packet, between network and transport > can be imagined. Because of ARP, EID layer is proved to be adjacent to the link layer. So, the layer is not thin but just the network layer itself. That's why my answer to 4 is "Yes". > Finally, question 8 - internal structure. Yes, EIDs have > internal structure. That is necessary for administrative > assignment purposes, administrations need to be given a block > of numbers to assign to their hosts, that of itself is one > primitive form of structure. Then, to be useable as a database > key - or more precisely, to be useable as a DNS key, the > EID needs to be able to be broken down into delegation levels, > which will, naturally, follow the administrative assignment > hierarchy. This has also, finally, answered the very first > question raised in How do you think about the assignment plan in my homework? > However, this need > not be an additional burden over current procedures, as I don't > see IPv6 addresses needing anything like the same assignment > strategy - given that with EIDs all they're needed for is to > route packets to the correct end points (which isn't to say this > is trivial) I see no reason for them to not be automatically > assigned by routers, radiating out from some well known central > point, calculated automatically by the routers You should be assuming to advertise the assigned addresses of hosts through dynamic DNS. Then, it is still necessary to configure addresses of name servers as glue A records. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Oct 21 21:50:51 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27423; Fri, 21 Oct 1994 21:50:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11400 Fri, 21 Oct 1994 21:50:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA18560; Fri, 21 Oct 1994 21:47:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18555; Fri, 21 Oct 1994 21:47:16 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26211; Fri, 21 Oct 1994 20:40:32 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA29961; Fri, 21 Oct 1994 11:41:51 +0100 Date: Fri, 21 Oct 1994 11:41:51 +0100 From: Christian Huitema Message-Id: <199410211041.AA29961@mitsou.inria.fr> To: big-internet@munnari.OZ.AU Subject: Multi-homed TCP Folks, During the EID BOF, one of my work assignments was to produce, with Dave, my own version of the EID spec. Well, I did not do that. Rather, in much the same way as Dave and Noel, I produced a specification of a TCP extension for handling multi-homing and mobility. I just got Noel's spec, and we are indeed converging on very similar ideas. I prefer indeed my version, which as two big differences with Noel's and Dave's: 1- It uses addresses as addresses, not identifiers. using an address just means that "packets sent now to this address reach me". 2- It does not use any form of permanent identifier in the EId or DNS sense, but rather "Peter's knife approach to immortality". one may change the blade, then change the handle, it is still Peter's knife. It fact, one may change the source address, then the dest address, it is still the same connection... Details follow. Christian Huitema =================== Multi-homed TCP 1- Context: Current TCP connections are identified by pairs of host addresses and port numbers. This introduce a "fate sharing" dependency between the connection and these values, and specially with the time to live of the host addresses. There are at least three cases where this dependency is unduly harmful: 1) when the host moves to a new location and is assigned a new address, 2) when the interface used by a multi-homed host to initiate the connection is temporarily disconnected, 3) when the host's network is renumbered, e.g. after changing provider. Partial solutions have been proposed, which essentially insert a "permanent identifier" layer between the transport control and the routing process. Instead of identifying the transport contexts by a pair of source and destination addresses, one would use this "more permanent" identifiers, often called "end point identifiers" or EID. The addresses may change but the EID will remain constant. In the "classic" version of the EID proposal, these identifiers will be present in each and every packet, in addition to the addresses. Several implementations have been proposed, e.g. as innovative IPng formats. Including EIDs in the IP or IPng header itself has been ruled out during the debates, but one could design an intermediate layer between IP and TCP that would carry those headers. The proposal, however, suffers from three drawbacks: 1) As EID are likely to have the same size than the IPng addresses, we are considering a sizeable overhead. 2) EID don't exist yet. Creating yet another address space would implies significant administration efforts. 3) Disconnecting identification and routing removes whatever security there is in the current IP protocol. The early SIP and SIPP proposals included a scheme that would alleviate the first concern and eliminate the second one. Instead of creating a new numbering space for EIDs, one would simply specialize one address, e.g. the one that was used for sending the initial synchronization packet of TCP. Most connections will simply go on using that address for their whole duration. If the host moves, or if a new provider is selected, the old address will be still be used as nominal source or destination address, but the packet would be explicitly source routed through the new address. This solution however suffers from the same security problems as the generic EID proposal, and does not entirely cure the "change of provider" problem. If the local network is renumbered, the old addresses ceases to be valid. In fact, that argument applies to all approaches based on "permanent identifiers": we are exchanging a dependency on the IP address for a dependency on these new identifiers. Proponents of the EID approaches are ready to swear on their most sacred books, or on the head of their favorite dog, that these new numbers will remain valid, unique and stable for eternity. We may note however that there is not a single human that ever met that requirement. The case is even more obvious if we focus on network history, where exceptions to the unicity and stability rules have been found for all proposed "unique numbers" that were considered, be they IP addresses, which get renumbered, domain names, which change from time to time, or IEEE-802 "MAC addresses", which can easily be misconfigured. Rather than yet another gigantic administrative effort, we will propose to remove the fate sharing effect altogether, by allowing the set of addresses used by a TCP connection to change over time. In short, we propose to follow Peter's knife approach to resiliency: one may change the blade, then change the handle, it is still Peter's knife. We will do so with minimal overhead, i.e. zero overhead when the addresses don't change, while solving the security problems and allowing "load splitting" or "traffic spreading" for multi-homed hosts. Hence, the proposal is called "multi-homed TCP". 2- Why TCP Our solution focuses on TCP. One may well object that TCP is not the only protocol used over the Internet, that the fate-sharing also occurs with other transport protocols, notably over UDP. However, a quick analysis shows that "user controlled" applications, that use the user datagram protocol, are much less sensitive than those application which relie on the services of a transport layer. This is notably the case of "client server" and "real time" application; this is also the case of "secure" applications. The most popular building block for "client server" applications is the "stateless RPC". In this model, a client simply sends a request to the server, generally a single UDP datagram. Upon reception of this request, the server executes the required actions and sends back a reply, in most cases a single UDP datagram. No "context" is kept by the server, and the time-span of the transaction is generally quite short, which minimizes the risk of observing a move in the middle of a transaction. At worst, if such a transistion occurs, the client may repeat its request. Indeed, if the server moves, the client will have to find its new location, its new address. But that has to be solved by updating the routing process or the name service; it is not a "transport control" problem. It is true that client-server applications may have to maintain long term associations. But they generally do so by identifying "application level contexts", which are identified by the users and servers names: authentication and access controls ought to be based on user names, not on hardware addresses. Real time applications also use UDP, generally in conjunction with "multicast transmission". The practical experience have shown however that the multicast transmission is very often achieved through a cascade of relais, and that the source address received in the packets is not always that of the actual source. The "real time transport protocol" includes an identification mechanism by which stations are assigned numbers within multicast groups. Real time applications go to great length to reduce their packet size, using computation intensive compression techniques; an additional header in each and every packet would be entirely unwelcomed. In fact, one may draw the general conclusion that applications which are using datagram services have to incorporate their own control functions. Identification of the partner, as well as general security measures, are an integral part of these applications. providing them with a "one size fits all" intermediate layer would probably not help. 3- The basic principle The basic mechanism which we are considering is very simple. A TCP entity "A" which is willing to receive or to send data through several interfaces announces those addresses to its partner, "B". The entity "B" will associate these multiple addresses to the local TCP context, and acknowledge the announcement. Once the context has been updated, "A" can use the new addresses as "source addresses" while "B" can use them as destination addresses. Multi-homed hosts can announce their many interface addresses, so that the traffic is spread over several interfaces; mobile hosts can announce their current address so as to avoid dog leg routing; renumbered hosts can annouce their new address so that TCP connections survive the renumbering. How to exchange these addresses will be discussed later. This simple mechanism implies minimal changes in TCP. In fact, the only point that we identified are the "PCP look-up", i.e. the retrieval of the context as a function of the current source address, destination address and port numbers, and the computation of the TCP packet's check-sum. When a packet arrives from the new source address, one must retrieve the "protocol control block" associated to the TCP connection. This retrieval is obviously more complex if there are several possible source address instead of exactly one; however, that complexity is not overwhelming. The only requirement is that incoming packets carry sufficient identifications, so that they can be univocally linked to the old context. The TCP checksum is used to detect transmission errors that would alter a packet content. The checksum is computed by summing in "complement to 1" arithmetic the words. The sum is not initialized to zero, but rather to the checksum of a "pseudo-header" composed of the source and destination addresses and ports. This initialisation adds an additional protection against misdelivery of packets, which could occur if the network randomly changed the header. We propose to associate to each TCP connection exactly one "pseudo header checksum" value, a random number that does not depend from the particular source and destination address in use. 4- How to announce addresses Using network addresses within TCP packets poses an obvious "layer dependency" problem. The TCP program must be aware of the address formats and specific pseudo-header computation rules should be defined for each of these formats. If "translating gateways" are in use, the translation rules must be carefully designed to maintain the pseudo header checksum value; if addresses are passed within the packets, the TCP programs must be made aware of the translation. The use of network addresses also poses obvious practical problems, as this addresses may be quite large: there are only 20 octets available in the current TCP "parameter space", while an IPv6 address already requires 16 octets. This problem can be alleviated by using "implicit transmission". If a TCP program wants to announce an alternate address to its partner, it simply uses that new address as the source address of a TCP packet. This solves our efficiency and transparency concerns: no extra space is needed in the packet, the only constraint to "translating gateways" is that they be reversible. However, we have to find a way to associate the packet to the new context: this is the role of a "context-id" parameter, which is negotiated during the initial transmission exchange. Each TCP entity determines a "context identifier", that uniquely identifies the connection context within this host, and sends it as a parameter of the SYN packet. Each entity memorize the identifier send by its partner. When a host moves, or when the entity decides to use a new address, it sticks the partner's context-id in the packets that it sends, thus guaranteeing that the partner will be able to associate the incoming packets to the existing context. To implement this solution, we must thus define two new TCP parameters, i.e. "my context-id", to be used in the initial SYN, and "your context-id", to be sent in further packets. The negotiation is implicit: by annoucing a context-id, the TCP entity asserts that it is willing to accept packets from alternate addresses. One may, or may not, be concerned with the overhead of the option. A natural "context-id" should be coded over at least 32 bits, which may or may not be an acceptable permanent overhead. One may believe that it is not necessary to repeat this identifier if the source address is already recognized by the TCP peer. The "recognition" procedure is very natural: one may say that a source address is "recognized" if the partner starts using it as a destination address. Hence a set of three rules: 1) Alternate source addresses can only be used if the peer's "context-id" is known. 2) When a packets are sent with a new source address, the peer's context-id must be presented in all packets as long as the source address has not been acknowledged by the TCP peer. 3) When packets are sent to a source which has already been acknowledged, the context-id may be presented in the packet, and may also be omitted. The "acknowledgement" procedure is implicit: we know that the peer is aware of one of our addresses, when we receive a packet send by the peer towards that address. In fact, one could specify the 3rd rule a little further. It is a good idea to always include the peer's context-id in packets which are repeated after a time-out. 5- Pitfalls of mobility In the introduction, we quoted many reasons why we would like to use several alternate addresses: mobility, renumbering, load splitting. The addresses that a host uses may have very different "time to live". If the TCP peer continue using an old address, for example that of a past provider or of a past location, the packets will be lost and the connection will eventually be broken. The "worst case" is probably that of "simultaneous moves". Suppose that, in a mobile to mobile connection, both partners move at the same time: they continue to use the peer's old address, sending the packets to its previous location. They never receive the "new" packets, thus can never update their context and learn about their peer's new address. This is a very classical problem of mobile networking. Location dependent addresses allow for faster transmission, what we may call "cutting the dog- legs". But we must at any moment be able to fall back to a "permanent address", one that will direct the packets towards the "home agent" which keeps a precise knowledge of the mobile's whereabouts. Introducing this mechanisms in TCP is simple: the TCP entity will start suspecting that the current address is "invalid" because the packets transmitted towards that address will not be acknowledeged within a reasonable "time out". At this point, it can decide to fall back to the "permanent address", e.g. the one which was used in the initial SYN packet. Being able to fall back to the previous address, or even to split the traffic over several interfaces, supposes that one associate a "list of addresses" to the TCP context. But this expose another classical pitfall of mobility, the "ever growing list". If one keeps in the TCP context all the addresses that were ever used by the mobile partner, one will end up listing all the mobile's successive locations. This will end up consuming a lot of memory for no good reason: most of these previous addresses are now invalid. One must thus be able to "prune" old addresses from the list, which can be done either "explicitly" or "implicitly". Explicit procedures suppose that the sending TCP program somehow qualifies the addresses that it is using, e.g. by using some kind of "grading" parameter that qualifies the source address: a permanent location, a new location, a new provider. This poses two problems: asynchronism and fuzzy qualifications. The "asynchronicity" problem is easy to understand: packets emitted from different locations travel at different pace, through different routes. There is no guarantee that we will not keep receiving packets from the old location for quite some time after the mobile host has moved: we must maintain the knowledge that this was one of the old of locations, so as to associate these old packets with the TCP context. The fuzzy qualification is also obvious to anyone who ever engaged in taxonomy exercizes: one may foresee a flurry of intermediate cases, like "semi permanent addresses", "secundary but permanent interface", etc. The implicit procedure is much easier. The TCP programs are asked to maintain a cache of the addresses which the partner "recently used". It is easy to qualify an address with attributes such as the earliest and latest dates at which it was used. An address will be deemed acceptable for use as a destination address if it was "recently used", i.e. if its "latest date of use" is larger than the "earliest date of use" of the most recenty used address. This should indeed be modulated with a monitoring of the addresses. If it appears that packets sent to one particular address are never acknowledged, then that address should not be used any more; more precisely, it should not be used unless further data are received from that address. Indeed, there will be graduation of this.. A consequence of the implicit procedure is that the TCP programs should regurlarly use all the valid local addresses. Multihomed hosts should take care to send packets using all the available source addresses; mobile hosts should take care to also use their "home address" as the source of some packets. By doing so, they will "refresh" the set of addresses known by the peer. 6- Security considerations The procedure that we propose introduces a significant security hole. If a third party can obtain the "context-id" used by the TCP connection, then it can send TCP packets using a bogus source address and trick the TCP entity into believing that this is the new address of its partner: it can, in short, "grab the connection". In the current Internet, such connection grabbings require that one somehow subvert the routing protocol, which is more difficult than simply listening to traffic and forging packets. This threat is in fact inherent to the mobility environment which we are willing to accomodate: we have the choice of accepting this mode of operation or implementing a secure version of TCP. Implementing a secure version of TCP may be a good idea in any case, as TCP is currently vulnerable to several forms of attacks: as long as the origin of the packet is not securely authenticated, it is easy for intruders to send forged TCP messages and distort the state of an existing connection. We may be willing to use "IP security" to that effect, wrapping the TCP packets inside an "IP secure" payload: +-----------+-------------------------------+ | | IP +-------------------+| | IP header | security | TCP header + data || | | header +-------------------+| +-----------+-------------------------------+ The IP security header identifies a "security context", to which a key is attached, as well as the type of protection. Once a security context has been established, we obtain a proof of the source Internet address, as well as in some cases an integrity check, an confidentiality, i.e. protection against eavesdropping. How secure IP contexts are established is outside the scope of these memo. If such protections are available, then our procedure becomes entirely acceptable. In fact, we can define three mode of operations: 1) Secure mode, into which only those packets which were transmitted securely can be considered by TCP, 2) Protected mode, into which packets are requested to come either from a well identified address or through a secure channel, 3) Unprotected mode, for users who are willing to take chances. The second mode of operation protects us against the specific threats brought in by mobility, without imposing the performance penalties of cryptography on each and every packet. 7- Acknowledgements and related works Many of the features of this proposal were discussed privately with Lixia Zhang, John Wroclavski, Van Jacobson and Greg Minshall. The support of multiple addresses bears some similarities with the "transport context names" proposal of Dave Crocker. Various authors, notably Steve Deering, have proposed an alternative "context identification" mechanism based on "volatile port numbers": a specific port is assigned to each connexion within the SYN exchange, which is essentially equivalent to our 'context identifier". The scheme that we propose here has the advantage of using larger identifiers: 16 bits does not necessarily allow enough contexts. It also has the advantage of being entirely backward compatible (an additional TCP parameter can be ignored) and of being explicit: alternative addresses can only be used if the peer provided a context identifier. From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 02:12:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05140; Sat, 22 Oct 1994 01:48:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA18866; Sat, 22 Oct 1994 01:47:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA18850; Sat, 22 Oct 1994 01:38:02 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04776; Sat, 22 Oct 1994 01:37:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27873; Fri, 21 Oct 94 11:37:42 -0400 Date: Fri, 21 Oct 94 11:37:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410211537.AA27873@ginger.lcs.mit.edu> To: bound@zk3.dec.com, kre@munnari.OZ.AU Subject: Re: PROCESSES : Re: From jnc: Mobilty and Multi-homing ....... Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com > When using the Internet protocol suite, processes communicate via > transport associations, such as TCP connections; these define end- Applications communicate not processes. Take it up with Crocker; that text is all the same as his original. BTW, are you sure that it's the applications which are communicating, not the humans? Noel PS: Any comments on the rest of the document? From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 02:28:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06552; Sat, 22 Oct 1994 02:28:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA18973; Sat, 22 Oct 1994 02:27:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA18946; Sat, 22 Oct 1994 02:08:29 +1000 Precedence: list Received: from netcom20.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04455; Sat, 22 Oct 1994 01:26:18 +1000 (from kck@netcom.com) Received: by netcom20.netcom.com (8.6.9/Netcom) id IAA09547; Fri, 21 Oct 1994 08:23:19 -0700 Date: Fri, 21 Oct 1994 08:23:19 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199410211523.IAA09547@netcom20.netcom.com> To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed TCP I find it interesting that fire behind the EID debate has started up once again. I am noticing that some of the round of ideas are resurfacing and that coming to closure on this topic as it stands is almost impossible. This has got me thinking WHY does it seem that closure is out of reach? I am also having a hard time trying to side with one view versus another because I think all views are right to a certain degree. This has gotten me to try and really define what an EID is without rehashing all of the arguements that have been presented thus far. What I think I have found is that EIDs mean many different things and the exact meaning, thus the exact representation, depends on the use of the EID. I feel that there are possibly too many uses for EIDs but will attempt to give a few scenarios of a particular use, and implementation of an EID. The prupose of this excercise is not to fully define EID but to hopefully convince the group that we need to pick certain uses of EIDs and define a mechanism that works to solve that mechanism independantly of other uses. At the implementers meeting in Boston someone stated that IPv6 should be able to support the following scenario: ---- subnet A--------------------------------------------- | | Device X router Z | | ---- subnet B---------------------------------------------- Where device X may be commnuicating with a host in the Internet using its subnet A address. If subnet A goes down the desired affect would be to have the connection switch over to subnet B. This sounds like a good case where an EID would be useful. I suggested at the meeting using an End-to-End option (though I think it was suggested long ago on the net) where Device X could specify in an option that it has another interface (or interfaces depending on the definition of the option). Whenever the remote device sends a packet to Device X it can specify (for routing purposes) the interfaces (not being used currently) in an option with a bit that says "still using the real specified destination address". If a router, in this case Z, determines that subnet A is not accessible, it can switch the bit and start routing towards subnet B to reach device X. This allows TCP connections to continue working in the event that one of a multi- homed device's interfaces has become unreachable. Another use of an EID is in the case of mobility. The EID in this case is the devices real IP address, the one in which will accept the packet, and the triangle routing can be specified in a option. I believe that Noel was the latest person just the other day to suggest this. What we see is two cases where an EID like thing is useful but the implementation is slightly different. Others may feel that supplying a DNS name in an End-to-End option would solve certain problems. I think this is perfectly acceptable as long as both ends can agree on what the option means and how to use it. I am not sure thats our problem at this time. I think whats important for this group is to get the mind set that it will take potentially a large number of defined options to realize the large number of applications and requirements that people of this group have. Another example of what might be considered an EID (of sorts) and possibly be handled in an End-to-End option of some sort would be NSAPs. Pick your favorite EID thingy and see if it fits in an option. From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 05:05:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09333; Sat, 22 Oct 1994 03:48:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA19052; Sat, 22 Oct 1994 03:47:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA19047; Sat, 22 Oct 1994 03:46:36 +1000 Precedence: list Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09246; Sat, 22 Oct 1994 03:46:14 +1000 (from jkrawczy@pobox.wellfleet.com) Received: from wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13506; Fri, 21 Oct 94 13:39:35 EDT Received: from maggie.wellfleet by wellfleet (4.1/SMI-4.1) id AA25417; Fri, 21 Oct 94 13:39:09 EDT Date: Fri, 21 Oct 94 13:39:09 EDT From: jkrawczy@pobox.wellfleet.com (John Krawczyk) Message-Id: <9410211739.AA25417@wellfleet> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA00985; Fri, 21 Oct 94 13:46:23 EDT To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed TCP In-Reply-To: <199410211523.IAA09547@netcom20.netcom.com> References: <199410211523.IAA09547@netcom20.netcom.com> Reply-To: jkrawczy@wellfleet.com On Fri, 21 October, Richard Fox (kck@netcom.com) wrote: At the implementers meeting in Boston someone stated that IPv6 should be able to support the following scenario: ---- subnet A--------------------------------------------- | | Device X router Z | | ---- subnet B---------------------------------------------- Where device X may be commnuicating with a host in the Internet using its subnet A address. If subnet A goes down the desired affect would be to have the connection switch over to subnet B. This sounds like a good case where an EID would be useful. Just something to chew on..... One thing that several IP implementations (including ours) do NOW to get around this problem is allow the user to configure an interface to a subnet that is not tied to any physical media. The subnet is really internal to the box. Suppose, in this case, Device X has a third interface to subnet C which is really "internal" to the device itself. The subnet is advertised via whatever routing protocol is being used. If communication with X is now done using it's subnet C address, the device remains reachable as long as one physical interface is up. This approach has several advantages: No new number space needed. No end-end options needed (you rely on the routing protocols to do this). It works now with IPv4. Some of the disadvantages I can think of off the top of my head: It chews up a subnet (at least 4 addresses in IPv4). You need to advertise the subnet (OK if the device is a router, maybe not so OK if it's a host). You're at the mercy of the routing protocols as far as convergence time when an interface goes down. The "endpoint" in this case really represents all of the active interfaces on a device. I won't even pretend to know the ramifications of this approach in regard to mobility. -jj (now officially of Bay Networks, Inc.) From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 08:08:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17463; Sat, 22 Oct 1994 08:08:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA19313; Sat, 22 Oct 1994 08:07:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA19279; Sat, 22 Oct 1994 07:47:55 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16012; Sat, 22 Oct 1994 07:25:23 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id OAA01015; Fri, 21 Oct 1994 14:25:08 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Oct 1994 14:25:12 -0700 To: Valdis.Kletnieks@vt.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: EIDs from the BOF Cc: Big-Internet@munnari.OZ.AU Valdis, At 1:52 AM 5/11/69, Valdis.Kletnieks@vt.edu wrote: >connections. Now, if we are allowing renumbering on the fly, we need to >have *something* (such as an 'endpoint ID') that either remains constant >for the connection or have a way to inform the other end of changes. >Otherwise, code of the form "apply encryption key assigned for session ID >19345" will break horribly.... thanks for the thorough explaination. I'd like to hear from other 'security' folks on this. your characterization of the requirements seems straightfoward and I don't know enough of the minute details of security mechanisms to know whether is fits into the camp of 'generally accepted' requirements. In any event, I'd think that the TCN proposal satisfies your requirements since a) it does have an ID for the lifetime of the connection, and b) it has a protocol for changing the address associations with that ID. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 08:13:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16736; Sat, 22 Oct 1994 07:48:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA19283; Sat, 22 Oct 1994 07:47:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA19276; Sat, 22 Oct 1994 07:45:19 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15356; Sat, 22 Oct 1994 06:50:02 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id QAA36740; Fri, 21 Oct 1994 16:48:39 -0400 Message-Id: <199410212048.QAA36740@black-ice.cc.vt.edu> To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: Big-Internet@munnari.OZ.AU Subject: Re: EIDs from the BOF In-Reply-To: Your message of "Thu, 20 Oct 1994 17:58:04 EDT." From: Valdis.Kletnieks@vt.edu Date: Fri, 21 Oct 1994 16:48:39 +22306356 Sender: valdis@black-ice.cc.vt.edu On Thu, 20 Oct 1994 17:58:04 EDT, you said: > > The endpoint id is also needed for security purposes. Besides > > the required property of global uniqueness they should have as long a > > lifetime as possible, certainly at least as long as any association. > > current-style IPv4 'addresses' have been deemed entirely adequate by the > IETF technical community that provided input to IPng requirements. > > When did this 'long lifetime' requirement emerge and do others from the > security technical community concur. And why? Dave: There's apparently a hidden assumption here - "current-style IPv4 addresses" have the useful feature that they remain nailed down once allocated, at least for the length of the connection - if you renumber, you break all existing connections. Now, if we are allowing renumbering on the fly, we need to have *something* (such as an 'endpoint ID') that either remains constant for the connection or have a way to inform the other end of changes. Otherwise, code of the form "apply encryption key assigned for session ID 19345" will break horribly.... Personally, I'm not convinced the endpoint ID needs a "as long as an association" lifetime - for some machines around here, that would be 200+ days. However, I think we need *either*: a long lifetime *or* a spec for a secured 'change in session parameters' function. Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 10:01:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18581; Sat, 22 Oct 1994 08:48:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA19368; Sat, 22 Oct 1994 08:47:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA19363; Sat, 22 Oct 1994 08:42:30 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18109; Sat, 22 Oct 1994 08:29:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19350 Sat, 22 Oct 1994 08:27:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00771; Fri, 21 Oct 94 18:24:56 -0400 Date: Fri, 21 Oct 94 18:24:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410212224.AA00771@ginger.lcs.mit.edu> To: Valdis.Kletnieks@vt.edu, dcrocker@mordor.stanford.edu Subject: Re: EIDs from the BOF Cc: Big-Internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) In any event, I'd think that the TCN proposal satisfies your requirements since a) it does have an ID for the lifetime of the connection It depends how the security barrier works. If the TCP explicity informs the barrier, yes, that can work. If the barrier is not set up the TCP, however, you lose, since there's no invariant in the *packets* which identifies the connection. *Iff* the security-imposing router *wiretaps* the end-end remapping protocol, it can figure out when an update is happening, but not otherwise. This problem applies equally to the design in my note, as well as yours. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 22 19:42:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07443; Sat, 22 Oct 1994 18:48:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA19864; Sat, 22 Oct 1994 18:48:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA19859; Sat, 22 Oct 1994 18:44:12 +1000 Precedence: list Received: from cheops.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06254; Sat, 22 Oct 1994 18:06:44 +1000 (from avalon@coombs.anu.edu.au) Message-Id: <9410220806.6254@munnari.oz.au> Received: by cheops.anu.edu.au (1.38.193.3/16.2) id AA14489; Sat, 22 Oct 94 18:06:43 +1000 From: Darren Reed Subject: Re: EIDs from the BOF To: kre@munnari.OZ.AU (Robert Elz) Date: Sat, 22 Oct 1994 18:06:42 +1000 (EST) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9646.782546121@munnari.OZ.AU> from "Robert Elz" at Oct 19, 94 03:55:21 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1192 > 1. Are EIDs short (generally perceived as no longer than > about 64 bits) ? 64 ? Hmm...how about 128 (same size as the network address) ? Or what happens when our IPv6 network has greater than 2^64 hosts ? > 2. Are EIDs binary (as opposed to printable text) ? yes > 3. Are EIDs globally unique ? yes > 4. Do EIDs exist at the network level ? yes > 5. Do EIDs exist in the transport layer ? No > 6. Are EIDs used to identify transport connections ? Not on their own, but help when combined with other bits. > 7. Are EIDs used as a key into any kind of database ? yes > 8. Do EIDs have any internal (administrative) structure ? > It was assumed that EIDs have no topological or > geographical meaning. yes > 9. Are EIDs present in every packet ? maybe (not necessary if a flow-id is present, perhaps ?) What I find bizarre is how could the EID be smaller than the network address ? Aren't these things meant to be such that there is a 1:1 association between addresses and EIDs ? IF DNS names were used as EIDs, that would imply 1:1 between EID and address (well, that's not necessarily correct and I'm tempted to say "host" (or "router") instead ). darren From owner-Big-Internet@munnari.OZ.AU Sun Oct 23 13:43:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05641; Sun, 23 Oct 1994 12:48:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA20808; Sun, 23 Oct 1994 12:48:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA20803; Sun, 23 Oct 1994 12:43:48 +1000 Precedence: list From: greg_minshall@Novell.COM Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04953; Sun, 23 Oct 1994 12:21:54 +1000 (from greg_minshall@Novell.COM) Received: from by ns.Novell.COM (4.1/SMI-4.1) id AB29675; Sat, 22 Oct 94 20:21:20 MDT Date: Sat, 22 Oct 94 20:21:20 MDT Message-Id: <9410230221.AB29675@ns.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: kck@netcom.com (Richard Fox) Subject: Re: Multi-homed TCP Cc: big-internet@munnari.OZ.AU Richard, One possibility is that the sender to device X knows X's domain name and, thus, has done a DNS lookup and so knows *both* of X's addresses: A.X and B.X. Given that the other host has a connection with A.X, and that it has noticed that it is having difficulties communicating directly with A.X, the other host can send packets to B.X (which, in the case of your scenario, would be delivered to X). There is a problem though: the *connection* is with A.X, so packets addressed to B.X will not be considered, by X, to be for the A.X connection. Two solutions to this problem occur to me: 1) Use the mobile-ip protocol to send the packet to B.X as if B.X were the "foreign agent" serving A.X. (Thus, the packet sent to B.X would consist of a simple header with the packet to A.X "encapsulated" inside of it.) 2) Design the transport protocol so that its connection identifiers are "locally unique" integers, rather than internet protocol addresses. (SPX, SPP, AT/SP are all of this form; i'm not really sure i understand all the pros and cons.) Greg ps - Note that the corresponding host could do the DNS lookup (gethostbyname()) *after* noticing difficulties talking to A.X; this could help solve problems of "long running connections" (when providers or address plans change, for example). As long as DNS TTLs are low enough, which they have to be for smooth address changing (but never actually are!). From owner-Big-Internet@munnari.OZ.AU Sun Oct 23 17:05:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11944; Sun, 23 Oct 1994 16:48:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA21018; Sun, 23 Oct 1994 16:48:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA21002; Sun, 23 Oct 1994 16:29:38 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11457; Sun, 23 Oct 1994 16:29:35 +1000 (from kre@munnari.OZ.AU) To: Darren Reed Cc: Big-Internet@munnari.OZ.AU Subject: Re: EIDs from the BOF In-Reply-To: Your message of "Sat, 22 Oct 1994 18:06:42 +1000." Date: Sun, 23 Oct 1994 16:29:32 +1000 Message-Id: <10532.782893772@munnari.OZ.AU> From: Robert Elz Date: Sat, 22 Oct 1994 18:06:42 +1000 (EST) From: Darren Reed 64 ? Hmm...how about 128 (same size as the network address) ? Or what happens when our IPv6 network has greater than 2^64 hosts ? Do you have any idea how big a number 2^64 is? There were close to convincing arguments that 64 bits would be enough for addresses, there's no real doubt that (if EIDS were numbered this way) 64 bits would be plenty. What I find bizarre is how could the EID be smaller than the network address ? Aren't these things meant to be such that there is a 1:1 association between addresses and EIDs ? No, as you indicate in the next paragraph, objects will usually have one endpoint name ("eid" is much simpler to type...) but may have many addresses. But that isn't the reason (other objects could have several endpoint names but only a single addres) - that's only going to be an order of magnitude difference (or so) in those numbers. The difference is in the bits wasted in addresses in order to provide the hierarchy to allow routing to scale. We had some rather lengthy discussions on B-I back in June/July on this subject if you want to go and check the archives. EIDs (I can't type the other thing twice in one message...) don't need that kind of lost space, they can be allocated very densely. There have been suggestions that IEEE numbers be EIDs, those are just 48 bits. 64 bits is 65536 complete IEEE spaces, and what's more should be able to be allocated more densely (no-one will be giving blocks of 16 million EIDs to organisations that may only ever assign a few thousand of them in all history). kre From owner-Big-Internet@munnari.OZ.AU Sun Oct 23 23:03:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19868; Sun, 23 Oct 1994 22:48:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA21345; Sun, 23 Oct 1994 22:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA21340; Sun, 23 Oct 1994 22:44:01 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18880; Sun, 23 Oct 1994 22:09:00 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 23 Oct 94 21:01:32 +0900 From: Masataka Ohta Message-Id: <9410231201.AA00857@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 23 Oct 94 21:01:30 JST Cc: avalon@coombs.anu.edu.au, Big-Internet@munnari.OZ.AU In-Reply-To: <10532.782893772@munnari.OZ.AU>; from "Robert Elz" at Oct 23, 94 4:29 pm X-Mailer: ELM [version 2.3 PL11] > The difference is in the bits wasted in addresses in order to > provide the hierarchy to allow routing to scale. We had some > rather lengthy discussions on B-I back in June/July on this > subject if you want to go and check the archives. EIDs (I > can't type the other thing twice in one message...) don't need > that kind of lost space, they can be allocated very densely. The current IPv6 address wastes bits not only for routing but also for the identification hierarchy. That' why I think 64bits are enough if it is purely for routing. > There have been suggestions that IEEE numbers be EIDs, those > are just 48 bits. 64 bits is 65536 complete IEEE spaces, > and what's more should be able to be allocated more densely > (no-one will be giving blocks of 16 million EIDs to organisations > that may only ever assign a few thousand of them in all history). As discussed before, IEEE numbers are no good, because management (including authentication) of identifiers are controlled by vendors, not by end user's organization. For example, if a user replace a machine with new vendor and want to preserve EID, EID must contain a part which identiy the users. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Oct 24 04:46:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27894; Mon, 24 Oct 1994 03:48:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21657; Mon, 24 Oct 1994 03:48:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21652; Mon, 24 Oct 1994 03:41:12 +1000 Precedence: list Received: from netcom11.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27388; Mon, 24 Oct 1994 03:26:27 +1000 (from kck@netcom.com) Received: by netcom11.netcom.com (8.6.9/Netcom) id KAA04093; Sun, 23 Oct 1994 10:23:26 -0700 Date: Sun, 23 Oct 1994 10:23:26 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199410231723.KAA04093@netcom11.netcom.com> To: greg_minshall@Novell.COM Subject: Re: Multi-homed TCP Cc: big-internet@munnari.OZ.AU >One possibility is that the sender to device X knows X's domain name and, >thus, has done a DNS lookup and so knows *both* of X's addresses: A.X and >B.X. You pointed point something interseting here. This observation allows the source of a packet decide if and how many addresses to include in the end-to-end options that I described before, if that host feels that it needs automatic rollover in the case that one address becomes out of service (see below). >Given that the other host has a connection with A.X, and that it has >noticed that it is having difficulties communicating directly with A.X, the >other host can send packets to B.X (which, in the case of your scenario, >would be delivered to X). You are correct this is one way of doing the automatic rollover (if you will). The one advantage of the end-to-end options over this method is that it allows the routers (or the network) to make the decision to do the rollever. The allows packets in flight to switch with out dropping packets. Also, the host may not know packets aren't being received because of congestion, noise on a link, down link or what. The option allows the network to make the correct decision. I think there aqre still some problems with the end-to-end options and I think there are some merits with the DNS scheme. However, I think the end-to-end option may end up being a good mechanism to start work from. >2) Design the transport protocol so that its connection identifiers are >"locally unique" integers, rather than internet protocol addresses. (SPX, >SPP, AT/SP are all of this form; i'm not really sure i understand all the >pros and cons.) Intereseting idea! >Greg rich From owner-Big-Internet@munnari.OZ.AU Mon Oct 24 14:20:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15785; Mon, 24 Oct 1994 13:49:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA22163; Mon, 24 Oct 1994 13:48:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA22147; Mon, 24 Oct 1994 13:38:53 +1000 Precedence: list From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15359; Mon, 24 Oct 1994 13:38:38 +1000 (from bound@zk3.dec.com) Received: from inet-gw-2.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15371 Mon, 24 Oct 1994 13:38:28 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-2.pa.dec.com (5.65/10Aug94) id AA01394; Sun, 23 Oct 94 20:31:23 -0700 Received: by xirtlu.zk3.dec.com; id AA16217; Sun, 23 Oct 1994 23:31:17 -0400 Message-Id: <9410240331.AA16217@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: bound@zk3.dec.com, kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU Subject: Re: PROCESSES : Re: From jnc: Mobilty and Multi-homing ....... In-Reply-To: Your message of "Fri, 21 Oct 94 11:37:42 EDT." <9410211537.AA27873@ginger.lcs.mit.edu> Date: Sun, 23 Oct 94 23:31:11 -0400 X-Mts: smtp From: bound@zk3.dec.com > When using the Internet protocol suite, processes communicate via > transport associations, such as TCP connections; these define end- Applications communicate not processes. >Take it up with Crocker; that text is all the same as his original. Nay. I already did sorry thought it was yours. Processes to me in networking are OS thingees. And I get real nevous when folks talk about context switches and "processes" in the same paragraph for two reasons. One this is generally a list of network experts I can conclude its OS expertise but process context switches in an OS are complex, especially for TCP. The second reason is that a process in UNIX, NT, MVS, MS-DOS, etc. are all different and no standard exists. So I think its a bad choice of words technically in a description. >BTW, are you sure that it's the applications which are communicating, not the >humans? Actually your right. Good point >PS: Any comments on the rest of the document? No not for now. I am just reading them as I can. I feel the community will solve the problem of EID vs Locator but I feel we blew it a few months ago, but I will get over that as I think Paul Francis's work on PIP was the right solution for EIDs at least. Right now it all seems academic and most of what I have read seems technically accurate but that does not mean I want it on my internetwork. I will read the final versions and if I think its of any value I will comment. But generally I am burned out on this subject and all this mail which is not NEW for this discussion. But I "have" to read Big-I as a player but I have not found any of this discussion technically useful to me or my work. That does not mean I don't think its imporant just not useful to me as an individual. /jim From owner-Big-Internet@munnari.OZ.AU Mon Oct 24 19:56:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27997; Mon, 24 Oct 1994 19:49:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA22490; Mon, 24 Oct 1994 19:48:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA22465; Mon, 24 Oct 1994 19:40:03 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25834; Mon, 24 Oct 1994 18:39:27 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 24 Oct 1994 08:38:54 +0000 To: big-internet@munnari.OZ.AU Subject: Re: Multi-homed TCP In-Reply-To: Your message of "Sun, 23 Oct 94 10:23:26 MST." <199410231723.KAA04093@netcom11.netcom.com> Date: Mon, 24 Oct 94 08:38:53 +0000 Message-Id: <650.782987933@cs.ucl.ac.uk> From: Jon Crowcroft this ipng fever infects everyrthing, but at last christian's approach to fixing TCP incrementaly, ratehr than re-writing the transport to IP layer upwards, seems to shed a ray of light... here is a real simple proposal for fixing TCP when you move the end that movesd (if both end moves, we have a problemette) simply sends an unsolicited ACK with a new option which contains the _old_ "socket", perhaps sealed with a PGP key, or soemthing to prevent random "party line pickup" of tcp connections. a conformant mobile TCP on receiving this, simply re-writes the PCB "socket" (the "socket" is the PCB lookup id, i.e. src+dst *port+ipaddr) with the new ipaddr value.... for mobile, read also "change interface on multihomed host" and the rest... dead trivial to implement.... on another note, mobile affects RTT estimation, and window congestion schemes - can we also have this message (or an ICMP redirected (i.e. from host to host, ratehr than the trad router to host redirect), cause rapid discard of history of RTT and window? sine the new ICMP redirected or the TCP party line pickup would go end to end, it would server to seed the RTT (and maybe even helkp start out the cwnd/ssthresh etc...) jon From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 01:56:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05785; Tue, 25 Oct 1994 01:09:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA22815; Tue, 25 Oct 1994 01:08:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA22797; Tue, 25 Oct 1994 00:51:55 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04731; Tue, 25 Oct 1994 00:26:49 +1000 (from dcrocker@mordor.stanford.edu) Received: from Mordor.Stanford.EDU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00925 Mon, 24 Oct 1994 23:38:02 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id GAA10401; Mon, 24 Oct 1994 06:30:54 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 24 Oct 1994 06:30:58 -0700 To: bound@zk3.dec.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: PROCESSES : Re: From jnc: Mobilty and Multi-homing ....... Cc: Big-Internet@munnari.OZ.AU Jim, et al, At 8:31 PM 10/23/94, bound@zk3.dec.com wrote: > Applications communicate not processes. > >>Take it up with Crocker; that text is all the same as his original. > >Nay. I already did sorry thought it was yours. Processes to me in >networking are OS thingees. And I get real nevous when folks talk about >context switches and "processes" in the same paragraph for two reasons. "process" is the formal computer science term for 'code in excecution'. I've no idea what the formal definition of 'application' is; besides, it probably would confuse people about user/kernel space code. In other words, I chose the word that is the simplest and most precise for the, ummmm, context. As to using 'context', first I don't think it says 'context switch' and second the EID Bof and online discussion at some point started referring to these as transport contexts, or communication contexts, or somesuch. And the term is, again, quite precise, so I applied it. If you have an alternatve term to suggest, let me know. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 02:08:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07106; Tue, 25 Oct 1994 01:48:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA22870; Tue, 25 Oct 1994 01:48:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22854; Tue, 25 Oct 1994 01:38:37 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06661; Tue, 25 Oct 1994 01:38:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03193; Mon, 24 Oct 94 11:38:23 -0400 Date: Mon, 24 Oct 94 11:38:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410241538.AA03193@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Mobility Cc: jnc@ginger.lcs.mit.edu Now that I sit and think about it for a bit, this whole debate about mobility is Really Dumb. If all we are doing is designing a mobility mechanism, we are just duplicating the work of the Mobility WG. That's pointless and wasteful at best, and probably disruptive and insulting. Mobility was raised purely as an *example* of one of the things it would be easier to do if we explicitly recognized, and named, endpoints. To center the entire debate around how to do mobility is to miss the point entirely. There is no single mechanism or functionality which is a complete argument for endpoints. Anyone who wants such a simple case, before they can be convinced, is more or less a priori not convinceable. The argument for endpoints is a system-design one, much like the argument for processes (to take a recent example); i.e. they exist, whether you recognize them or not, and the overall structure will be simpler, more flexible, cleaner etc if they are recognized, named, and explicity supported and used in mechanisms. If that justification isn't good enough for anyone, then I give up; you should feel free to think endpoints are a bad idea. I'm willing to try and convey my ideas clearly to anyone who wants to understand them more clearly, but I've given up entirely trying to convince anyone they are correct, or to get the IETF to adopt them. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 04:55:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12561; Tue, 25 Oct 1994 04:29:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA23081; Tue, 25 Oct 1994 04:28:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA23059; Tue, 25 Oct 1994 04:11:38 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11844; Tue, 25 Oct 1994 04:11:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04380; Mon, 24 Oct 94 14:11:24 -0400 Date: Mon, 24 Oct 94 14:11:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410241811.AA04380@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: Robert Elz Instead, lets go to question 9 - are EIDs in every packet. Here I say "probably" - I can imagine the possibility that this might not be needed, but I'd imagine even then that most packets would contain EIDs. In the abstract I agree with you here, that endpoint names ought to be in every packet, but this option has been almost foreclosed in IPv6, unless you add them as end-end options (i.e. in an inner payload). This then also answers question 1 - if EIDs are probably going to be in every packet, then they're also certainly probably going to be short. Then, because they are short, we really want them to be binary, to obtain full value of the available bits - so confirmation of the "yes" answer to question 2. Also fixed length, for ease of processing. Again, I basically agree with you, that EID's are the right form for endpoint names (which, after a great deal of round-about, brings me back to where I was some years ago), but many people didn't like the assignment process for that kind of name. I also conclude that one way or another, they really should be in IPv6, and that if we omit them, we will regret it later. Yes. Good luck convincing everyone! :-) I do understand that using them assumes creating the administrative structure to assign them. I however see this as being identical to the assignment structure for IPv4 addresses .. However, this need not be an additional burden over current procedures, as I don't see IPv6 addresses needing anything like the same assignment strategy Yes, exactly. You can redirect the existing assignment mechanisms to assign EID's. However, note that one goal of IPv6 is to get rid of the necessity to extend this assignment process down to the individual host. Perhaps there's a way to do the same thing for EID's. I see no reason for them to not be automatically assigned by routers, radiating out from some well known central point, calculated automatically by the routers. I don't want to get too sidetracked here, but addresses should be assigned by a slightly differente strategy, in which the only thing the humans get to do is draw circles (boundaries, actually) on maps (or perhaps influence the drawing of the circles), and everything else is automatic; i.e. there *is no* administrative structure which hands out addresses, at any level, and no mechanism for humans to assign or configure them, etc. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 05:46:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13706; Tue, 25 Oct 1994 05:09:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA23127; Tue, 25 Oct 1994 05:08:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA23120; Tue, 25 Oct 1994 04:55:08 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12509; Tue, 25 Oct 1994 04:27:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04611; Mon, 24 Oct 94 14:27:19 -0400 Date: Mon, 24 Oct 94 14:27:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410241827.AA04611@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Mobility, multi-homing, etc.. Cc: jnc@ginger.lcs.mit.edu From: jnc@ginger.lcs.mit.edu (Noel Chiappa) If you need to relocate one end of the connection, you put the new "actual address" of the host in a loose source route option, and leave the original "identifying address" as the packet's ultimate destination address. Yakov tells me that this approach to mobility had problems when he looked into it some time ago. One was that the LSR option was being used to do two things: control the path of the packet, and also inform the other end (via source-route reversal rules) of the path back. (I.e. as he points out, it's a semantic overload of the LSR option.) The latter was a problem since it was an unsecured channel. However, if we remove that latter function from LSR as being insecure, and use a secure channel to pass that info, as I indicated: There's a very similar protocol which can say "bind alternative address Xi to original address A". then that problem goes away. Another problem he found is that not all hosts implement LSR, or implement it correctly. Again, if we implement the secure channel, that too would present less of a problem: Upward compatibility is provided automatically, since if the recipient doesn't understand the request, you don't get an ack. Hopefully all hosts which implemented this mobility mechanims woudl also be fixed to send handle LSR's correctly. Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 05:46:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14402; Tue, 25 Oct 1994 05:29:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA23170; Tue, 25 Oct 1994 05:28:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA23165; Tue, 25 Oct 1994 05:26:16 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14317; Tue, 25 Oct 1994 05:26:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05232; Mon, 24 Oct 94 15:26:04 -0400 Date: Mon, 24 Oct 94 15:26:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410241926.AA05232@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: dcrocker@mordor.stanford.edu (Dave Crocker) It's tough to argue that the IETF's awful modeling has hindered the success of the technology. Actually, I think you can make a good argument that the IETF has had good intellectual models, its just that they were not universally understood. For example, take "fatesharing", *the* principal design principle of TCP. The only paper I know of that talks about it, "Design Philosophy of the DARA Internet Protocols", by Clark, is not well known (although I'm part way through making it an RFC). Noel From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 11:08:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25245; Tue, 25 Oct 1994 10:49:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA23447; Tue, 25 Oct 1994 10:48:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA23431; Tue, 25 Oct 1994 10:39:15 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24830; Tue, 25 Oct 1994 10:39:04 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 25 Oct 94 09:26:09 +0900 From: Masataka Ohta Message-Id: <9410250026.AA09246@necom830.cc.titech.ac.jp> Subject: Re: PROCESSES : Re: From jnc: Mobilty and Multi-homing ....... To: dcrocker@mordor.stanford.edu (Dave Crocker) Date: Tue, 25 Oct 94 9:26:08 JST Cc: bound@zk3.dec.com, Big-Internet@munnari.OZ.AU In-Reply-To: ; from "Dave Crocker" at Oct 24, 94 6:30 am X-Mailer: ELM [version 2.3 PL11] > At 8:31 PM 10/23/94, bound@zk3.dec.com wrote: > > Applications communicate not processes. > > > >>Take it up with Crocker; that text is all the same as his original. > > > >Nay. I already did sorry thought it was yours. Processes to me in > >networking are OS thingees. And I get real nevous when folks talk about > >context switches and "processes" in the same paragraph for two reasons. > > "process" is the formal computer science term for 'code in excecution'. > I've no idea what the formal definition of 'application' is; besides, it > probably would confuse people about user/kernel space code. In other > words, I chose the word that is the simplest and most precise for the, > ummmm, context. Sigh. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 12:00:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26148; Tue, 25 Oct 1994 11:09:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA23481; Tue, 25 Oct 1994 11:08:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA23476; Tue, 25 Oct 1994 11:03:15 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24986; Tue, 25 Oct 1994 10:43:14 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 25 Oct 94 09:33:46 +0859 From: Masataka Ohta Message-Id: <9410250034.AA09291@necom830.cc.titech.ac.jp> Subject: Re: Mobility To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 25 Oct 94 9:33:45 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9410241538.AA03193@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 24, 94 11:38 am X-Mailer: ELM [version 2.3 PL11] > Now that I sit and think about it for a bit, this whole debate about mobility > is Really Dumb. Welcome to our camp. > If all we are doing is designing a mobility mechanism, we are just duplicating > the work of the Mobility WG. We are not. The mobile WG have finished their job a lot better. So, saying "duplicate" is insulting. :-) Masataka Ohta PS The next step is to think connectionless. From owner-Big-Internet@munnari.OZ.AU Tue Oct 25 13:09:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01343; Tue, 25 Oct 1994 13:09:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23599; Tue, 25 Oct 1994 13:08:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23592; Tue, 25 Oct 1994 12:58:54 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28283; Tue, 25 Oct 1994 12:01:41 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 25 Oct 94 10:53:18 +0900 From: Masataka Ohta Message-Id: <9410250153.AA09670@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 25 Oct 94 10:53:17 JST Cc: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9410241811.AA04380@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 24, 94 2:11 pm X-Mailer: ELM [version 2.3 PL11] > Instead, lets go to question 9 - are EIDs in every packet. > Here I say "probably" - I can imagine the possibility that > this might not be needed, but I'd imagine even then that > most packets would contain EIDs. > > In the abstract I agree with you here, that endpoint names ought to be in > every packet, but this option has been almost foreclosed in IPv6, unless you > add them as end-end options (i.e. in an inner payload). What's wrong calling the lower 8byte of IPv6 address EID and adjust address assignment plan appropriately? > Yes, exactly. You can redirect the existing assignment mechanisms to assign > EID's. However, note that one goal of IPv6 is to get rid of the necessity to > extend this assignment process down to the individual host. Perhaps there's > a way to do the same thing for EID's. Sure. I documented how to do it in my homework. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 06:33:52 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04521; Sat, 29 Oct 1994 06:33:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07014 Sat, 29 Oct 1994 06:33:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28394; Sat, 29 Oct 1994 06:30:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28378; Sat, 29 Oct 1994 06:22:28 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04152; Sat, 29 Oct 1994 06:22:20 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA17839; Fri, 28 Oct 94 13:25:39 -0700 Date: Fri, 28 Oct 94 13:25:39 -0700 From: Eric Fleischman Message-Id: <9410282025.AA17839@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: X.400 vs. SMTP Dear Big-Internet: A thousand apologies for posting an issue to this list which is inappropriate for the list. However, I am in a bit of a quandry due to my own personal ignorance and am hoping that several of you could rescue me. [Private replies encouraged.] My problem is that we have some very strong X.400 advocates who are making various claims about X.400 vis-a-vis SMTP. I have never been very concerned personally about Email (hence my ignorance as to even the appropriate list to post this query to) but even I -- as poorly informed as I may be -- have become suspicious that perhaps the truth may differ somewhat from what is apparently being presented as fact. I therefore hope that many of you may help me discern fact from fiction. My goal from this query isn't to win arguments but rather to learn the truth. I believe that the following items have been stated as facts. I do not know if they are true or not. I would appreciate facts and data to demonstrate the truth in regards to each point. The type of facts and data which I seek are raw and accurate details which can be used in polite conversations such as "according to there have been XXX amount of YYY deployed in ZZZ costing PPP with the following QOS characteristics." What I can't use is anything which is in the "flaming" category such as "this is the most stupid thing I have ever read." Specific statements: 1) X.400 is more reliable than SMTP both as a protocol and because it is carried over Value Added Networks (VANs) which provide logging/tracking services which are not available over the Internet. 2) X.400 is more secure than SMTP. Apparently there was a recent addition to X.400 (which I did not follow and thus can't explain) which tremendously raises the security profile of X.400 far above all competitors. They claim that PEM is not adequately secure to be relied upon for business (commercial) communications. 3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. 4) X.400's body parts are immensely flexible, able to carry information of any content. MIME's body parts are almost equivalent but it is not widely supported within SMTP products today. 5) X.400 is a better Email backbone technology because there are more high quality application-layer gateways to X.400 from various existing Email communities than is the case for SMTP -- thus X.400 is well suited to link together a hodge-podge of Email protocols. 6) X.400 gives you receipt notification upon request while SMTP does not. 7) X.400 is an international standard which is officially sanctioned by, and its use encouraged by, virtually every government in the world. 8) X.400 is widely used everywhere in the world except North America. 9) Virtually all Personal Computer Email systems have defined X.400 to be their strategic direction towards which they will evolve their product line. Thus, most proprietary Email systems will soon natively use X.400 which means that it is the "Email system of the future". 10) The Electronic Messaging Association (EMA) has defined rich calendaring and scheduling services -- and other "messaging" services -- which rely upon X.400. 11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but not to SMTP. Exception is the XAPIA's CMC API which is Email protocol independent. 12) I am told that the US Federal Government (DoD???) is asking for bidders for a contract to establish a Federal-wide Email system. The rules of the contract REQUIRE that this system MUST BE based upon X.400. As you can tell, I forget the details and may have misrepresented what is actually happening. However, the bottom line is that this activity convices people that the US Government is really serious about X.400 and that they prefer it over SMTP. 13) X.400 is widely available over the Internet and, like SMTP, can be used to communicate with vast numbers of people. Internet users can not even discern which messages originated from SMTP and which from X.400. [How? Does this require the use of application-layer gateways? Please explain.] Any facts and data which you could supply on any of the above points would be instructional and appreciated. Also, are there any authoritative documents or postings which directly address any these points? In any case, thank you so very much for your patience, tolerance, and help. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 13:13:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16150; Sat, 29 Oct 1994 13:13:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA28738; Sat, 29 Oct 1994 13:10:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA28717; Sat, 29 Oct 1994 12:58:24 +1000 Precedence: list Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15694; Sat, 29 Oct 1994 12:58:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06040; Fri, 28 Oct 94 22:58:11 -0400 Date: Fri, 28 Oct 94 22:58:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410290258.AA06040@ginger.lcs.mit.edu> To: Big-Internet@munnari.OZ.AU, RACarlson@anl.gov Subject: Re: EIDs from the BOF Cc: jnc@ginger.lcs.mit.edu From: "Richard Carlson" There are no changes made to the network layer protocols. The application/process asks the transport layer for service. ... The Dest node may or maynot support EIDs. This can be detected by the Src node by looking in the database for an EID. If none is found, the Src node will find the IPv4 or IP6 address and build appropriate TCP/UDP headers. I'm a little confused as to the benefits of EID's if they are not sure to be there. I.e. you can't design a solution for which requires EID's, since they may not be there. Are you assuming that support for EID's will become basically ubiquitous fairly quickly? Past experience with things like TOS shows that it can be very hard to get stuff like this deployed... Also, the details of this sort of thing may turn out to be grubbier than you expect; you may want to work them out. I found a nasty piece of unpleasantness when I did my modification to Crocker's proposal. (Your proposed change, sticking the EID's in every packet, in what is effectively a shim layer between the internetwork and transport, would fix it, BTW.) This makes EIDs an evolutionary changed to the Internet, as apposed to a revolutionary change. This whole "evolutionary/revolutionary" thing is an utter rathole. I've decided that it's nothing more than loaded terminology used to beat up proposals people don't like; they call their stuff "evolutionary" and deride alternatives as "revolutionary". Get real. The truth is that *NOTHING* is going to get deployed in the Internet unless there's an interoperable transition plan. Was BGP an "evolutionary" change from EGP, or "revolutionary"? Well, a box that speaks BGP only sure can't talk to one that talks EGP only, but somehow the world kept working during the change. As a final note, I view EIDs as a way to make TCP/UDP operate over multiple transport protocols. These include IPv4, IP6, and other protocols like ATM, Fibre Channel, SMDS, and serial lines. I guess I am trying to say that TCP/UDP should be viewed as the API of the future. Applications developers would write programs that use sockets for inter-communications. I think there's a potential flaw here, which is the emphasis on existing transport means. I perceive the future of networking as being one where we need to make statements about resources needed by some important applications. Some of the substates you mention don't provide such guarantees. Unlike building reliable transport on top of unreliable internet, you can't build resource guarantees on top of a best-effort only service. (This is a crucial flaw with IPv6, but let's stay away from that rathole.) I don't think that TCP, or transports in general, is the place to provide this ubiquitous layer, and I persist in thinking that the internetwork layer is the place to do this, but I guess I'm in very small minority in holding that view. Noel From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 14:20:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16428; Sat, 29 Oct 1994 13:21:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA28755; Sat, 29 Oct 1994 13:21:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA28722; Sat, 29 Oct 1994 13:02:57 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15014; Sat, 29 Oct 1994 12:31:04 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id TAA11622; Fri, 28 Oct 1994 19:30:51 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Oct 1994 19:30:54 -0700 To: Eric Fleischman From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: X.400 vs. SMTP Cc: big-internet@munnari.OZ.AU Eric, You will get back a number of responses, each reflecting a point of view. here's mine: At 1:25 PM 10/28/94, Eric Fleischman wrote: >Specific statements: >1) X.400 is more reliable than SMTP both as a protocol and because it is Utterly false, both by bench analysis (compare complexity and make predictions from that) and operational experience (compare duration of production use and amount of traffic and breadth of use). > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. VANs may or may not provide better reliability than simply having "direct" SMTP exchanges. First, there are no statistics to substantiate a claim in either direction (and if I'm wrong, then PLEASE someone should post them.) Second, it certainly is reasonable to have a professional operation pay close attention to good quality performance. That, of course, has zero to do with technology. >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. There is lousy experience with email security of any kind. What little real-world experience there is seems mostly to be PGP. PEM is emerging. My own sense is that the X.400-related work is still fantasy. I'd be interested in hearing about operational experiences to the contrary. It would also be interesting to hear what the technical basis is for claiming inadequacy in the trust/security models and details used by PEM or PGP. I suspect it will hinge of fine points, applicable to specialized business scenarios. >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. I'm told there is minimal deployment and use of X.435. Minimal IS greater than zero, however. There is some informal use of EDI over Mime. An IETF working group has already specified the mime/edi encapsulation, but I'm not aware of any deployment. (Truth is labeling: I chair that working group.) >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. Yeah, right. X.400 has promised flexible body parts for 10 years. The practise has not seemed to meet the promise. Mime has the same promise. My own personal experience is mixed. The mixture is not from technical issues with Mime but rather deployment of Mime-aware user agents. That's improving, but is till early in the adoption curve. Given how slow X.400 adoption has been, it would be silly to make a 'final' assessment based on current numbers. >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing I happen to agree that there aren't enough production-quality email transport packages using Internet technology. On the other hand, perhaps this has something to do with how simple the Internet technology is and how easy it is to get entirely adequate service without complex, expensive software. In any event, look at the real levels of usage, not the theoretical claims. > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. Really? Complex addressing. No routing protocol. Etc. X.400 is better? I don't think so... >6) X.400 gives you receipt notification upon request while SMTP does not. True. And that's being fixed. It's also a very minor issue. Not in theory, but in practise. The reason is that an infrastructure acknowledgement, like delivery reports, is always going to be only as good as the gateways that link the infrastructure of one service to the infrastructure to another. Much email gets gatewayed to "foreign" services. Just how valid or likely are X.400 delivery reports, or any other kind, in those cases? That is, you need an end-to-end mechanism. Going through a gateway usually prevents it. >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. Absolutely true. So, it's kind of amazing that SMTP is used for perhaps 1000 (or more?) times as much traffic. >8) X.400 is widely used everywhere in the world except North America. Widely? How about 'heavily'? These last few questions are trying to run counter to real-world and massive experience. It does appear that X.400 usage is increasing, but I was recently told of significant, linear growth rates. At first that sounded pretty good. But then it occurred to me that this linear growth was taking place in the midst of the exponential explosion of Internet technology use. Linear growth in an exponential market is called "decreasing market share." >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product hmmm. that language was last used some years ago, when talking about other OSI protocols, too. The problem with 'defining strategic direction' is that customers often choose to make tactical purchases. > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". X.400 has been the 'email system of the future' since 1980. It's been published since 1984. My question is, when is this future going to be the present? >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. Defining is easy. Deploying is hard. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol Kind of amazing, isn't it? >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you It will be interesting to see whether this turns into another GOSIP-like sequence, with a later refinement to the requirement which says that an 'open' mail service must be used and X.400 and SMTP are both defined as open. >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even Really? Let me know what my X.400 address is. And how do I send to yours? I bet I have to start with (or go through) SMTP... > discern which messages originated from SMTP and which from X.400. [How? This is probably wrong. X.400 has massively large numbers of different types of headers. And X.400 delivery failure notices usually are distinctive and verbose. > Does this require the use of application-layer gateways? Please explain.] Yes. >In any case, thank you so very much for your patience, tolerance, and help. And thank you for being able to put up with so much silliness from the folks who are feeding you these lines. There is much to legitimately discuss about the virtues and/or realties about X.400 vs. SMTP, but it's best done by folks who have a technical or operational basis for it. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 16:57:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01860; Sat, 29 Oct 1994 05:10:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA28315; Sat, 29 Oct 1994 05:10:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA28297; Sat, 29 Oct 1994 04:59:35 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24202; Sat, 29 Oct 1994 01:37:45 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA02890; Fri, 28 Oct 94 10:37:23 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:Big-Internet@munnari.OZ.AU id AA00866; Fri, 28 Oct 94 10:37:21 -0500 Date: Fri, 28 Oct 94 10:37:21 -0500 Message-Id: <9410281537.AA00866@benedick.ctd.anl.gov> To: Big-Internet@munnari.OZ.AU Subject: Re: EIDs from the BOF From: "Richard Carlson" Well here are my answers to KRE's questions. (Slightly out of order). >9. Are EIDs present in every packet ? Yes >1. Are EIDs short (generally perceived as no longer than > about 64 bits) ? Yes >2. Are EIDs binary (as opposed to printable text) ? Yes Since EIDs are sent between communicating nodes in every packet, it follows that they should be 64 bit binary octet strings. They are carried in every packet for the same reasons that IP addreses and port numbers are, i.e. they identify the connection end points. >3. Are EIDs globally unique ? Yes, they must be! >6. Are EIDs used to identify transport connections ? Yes, in conjunction with the TCP/UDP port number. Without these 2 constraints, EIDs will have very little value. I would use an EID to provide a layer of data abstraction separating the network and transport layers. The EID would map to the IP address just as the IP address maps to the Ethernet MAC address. Applications/processes would communicate with each other using sockets. A socket is formed by concatenating the TCP/UDP port number to the EID. In essence the EID is simply replacing the IP address as the globally unique part of a socket. >7. Are EIDs used as a key into any kind of database ? Yes, a DNS style distributed database. >8. Do EIDs have any internal (administrative) structure ? Maybe I don't have any strong feelings on this question. EIDs have no topological or routing structure. They simply provide a 64 bit binary, globally uinque identifer for a node. This means that they can be densely allocated. As long as they meet these constraints, I don't care where they come from (local or remote administrator). The operation of the database will determine what the admistrative structure is. Now comes the controversial part .-) >4. Do EIDs exist at the network level ? No >5. Do EIDs exist in the transport layer ? Yes As I answer these questions I have a specific definition of what is being asked. My operational model is that the EID is located somewhere in the packet being sent over the physical media. The questions is where in the packet is it located? If the EID is located in the network layer header it is 'at' the network layer. If the EID is located in the transport layer header it is 'in' the transprot layer. I place the EID in the transport header, thus EIDs are 'in' the transport layer. They are NOT assigned to a specific transport protocol (TCP or UDP). They are assigned to an Internet node and a single EID is used by ANY transport protocol that node supports (TCP, UDP, TP4, ...). Using this model, EIDs can allow a transport protocol to run over multiple network layers (IPv4 or IP6). There are no changes made to the network layer protocols. The application/process asks the transport layer for service. The transport layer chooses the best network layer protocol and sends the application data. The Dest node may or maynot support EIDs. This can be detected by the Src node by looking in the database for an EID. If none is found, the Src node will find the IPv4 or IP6 address and build appropriate TCP/UDP headers. This makes EIDs an evolutionary changed to the Internet, as apposed to a revolutionary change. Modified nodes are capable of communicating with unmodified nodes, with no change to the underlying Internetwork IP(ng) infrastructure. As a final note, I view EIDs as a way to make TCP/UDP operate over multiple transport protocols. These include IPv4, IP6, and other protocols like ATM, Fibre Channel, SMDS, and serial lines. I guess I am trying to say that TCP/UDP should be viewed as the API of the future. Applications developers would write programs that use sockets for inter-communications. The TCP/UDP protocol would efficiently send the data over the best available network layer. This is the goal I am striving for. As always I welcome any questions, comments, (snide remarks). Rich Carlson ---------------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory Phone: (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 19:26:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22963; Sat, 29 Oct 1994 17:10:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28963; Sat, 29 Oct 1994 17:10:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28947; Sat, 29 Oct 1994 17:06:45 +1000 Precedence: list Received: from lobby2b.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08111; Sat, 29 Oct 1994 08:42:13 +1000 (from w-rolph@ds.mc.ti.com) Received: from pan.mc.ti.com ([157.87.0.1]) by lobby2b.ti.com (8.6.8.1/) with SMTP id RAA14011; Fri, 28 Oct 1994 17:42:03 -0500 Received: by pan.mc.ti.com (5.57/Ultrix3.0-C) id AA15876; Fri, 28 Oct 94 18:36:44 -0400 Message-Id: <9410282236.AA15876@pan.mc.ti.com> X-Sender: a722756@pan.mc.ti.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Oct 1994 18:43:17 -0400 To: Eric Fleischman , big-internet@munnari.OZ.AU From: w-rolph@ds.mc.ti.com (W. Donald Rolph III) Subject: Re: X.400 vs. SMTP X-Mailer: This is wonderful! I love seeing technical arguments posed in politcal terms. Sigh.... In the X.400 vs SMTP debate inside TI there are very few issues which are judeged to be different in substance. Two which might be mentioned in favor of X.400 are: 1) X.400 allows for reciept verification by the post office, thereby gaining some degree of assurance that the mail has been received. SMTP is much weaker here as part of the post office system (although the applications using mail are free to acknowledge receipt, and some do ;-) ) 2) X.400 is an ISO standard and supported well by a number of VANS, particularly in Europe Some significant points in favor of SMTP: 1) it is widely available in an interoperable manner today on virtually every platform known to god or man 2) it has very wide spread connectivity today throughout the world coutersy of the internet 3) it has very long service experience, and is know to work today. X.400 is still evolving with significant inoperability problems (particularly between releases) and internationalisation problems (e.g. the country of the receiver is part of the X.400 address, but in multinational corps. the receiving gateway post office may be in a different country and.... I believe X.400 has a task force working this right now). In short do you want to get work done today (and presumably return on your email investment quickly), or do you want to be "canonically correct" but have primary returns in the future. Note - this is moving out over SMTP. How many responses did you get? From where? This would make some nice statistics, dont you think? >Specific statements: >1) X.400 is more reliable than SMTP both as a protocol and because it is > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. Possible - although the reciept acknowledgement is more significant from my perspective >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. Properly implementd PEM is effectively uncrackable. The real issue is that there are some organizational roadblock which are stalling PEM proliferation. In any event, if you want security on wide area networks you better encrypt. PEM is nearly as good as you can get! >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. Interesting - what vendors of yours do you have in place now who can usitlize this? Would you be willing to use EDI for business without a secure nonrepudiation capability (such as is included in PEM ;-) ) >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. I challenge you to find anything which cant move through MIME. MIME is available for nearly all platforms, and is increasingly ubiquitous in the pc world (eudora free pc mailer supports it {sort of}). UNIX seems to be lagging, mostly due to lack of file viewers, I suspect. >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. Sigh, you can find anywhere from ok to very good gateways from virtually any commercially available email system to SMTP. I think I smell a red herring! >6) X.400 gives you receipt notification upon request while SMTP does not. Absolutely, and one of the few irrefutable and demonstrable differences. Note, however, this makes the post offices much more complex! >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. SMTP is in use by every country in the world etc. Sigh this is what led us down the OSI network debacle! >8) X.400 is widely used everywhere in the world except North America. So is SMTP. By the way X.400 is widely available in America as well. >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". And virtually none of them are working, all experiencing problems, based on my watching primarily Microsofot's express, on the reciept notification. This is a hard problem. >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. True - although nothing precludes using SMTP for calendaring, and certain gateways support it. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol > independent. The IETF is not a standards body??? It has supported the most open effective open network standards of all time!!! >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you > can tell, I forget the details and may have misrepresented what is > actually happening. However, the bottom line is that this activity > convices people that the US Government is really serious about X.400 > and that they prefer it over SMTP. And virtually all government offices, and the president and vice-president, have SMTP email addresses!!! ;-> Hee Hee Hee... >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even > discern which messages originated from SMTP and which from X.400. [How? > Does this require the use of application-layer gateways? Please explain.] Do you like buying land below low tide in Florida??? This can only be accomplished by gatewaying between X.400 and the internet SMTP. These gateways impose no end of variety of limitiations, and are always a point of weakness. > >Any facts and data which you could supply on any of the above points would >be instructional and appreciated. Also, are there any authoritative >documents or postings which directly address any these points? > >In any case, thank you so very much for your patience, tolerance, and help. > >Sincerely yours, > >--Eric Fleischman > > Enjoy, sounds like you are about to have a lot of fun!!! Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263 From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 19:27:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23465; Sat, 29 Oct 1994 17:30:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28995; Sat, 29 Oct 1994 17:30:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28979; Sat, 29 Oct 1994 17:22:06 +1000 Precedence: list Received: from nacho.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21310; Sat, 29 Oct 1994 16:14:32 +1000 (from fred@cisco.com) Received: from [198.92.30.223] (sl-chattel-01.cisco.com [198.92.30.223]) by nacho.cisco.com (8.6.8+c/CISCO.SERVER.1.1) with SMTP id XAA10223; Fri, 28 Oct 1994 23:14:03 -0700 X-Sender: fred@nacho.cisco.com Message-Id: X-Deleted-Return-Receipt-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 28 Oct 1994 23:14:11 -0700 To: Eric Fleischman From: fred@cisco.com (Fred Baker) Subject: Re: X.400 vs. SMTP Cc: big-internet@munnari.OZ.AU You're correct that this is the wrong place to discuss it; however, neither do I know the right place. I will answer as I can, and others can kibitz. Note that I am an advocate of neither technology: my routers implement neither SMTP nor X.400. At 1:25 PM 10/28/94, Eric Fleischman wrote: >1) X.400 is more reliable than SMTP both as a protocol and because it is > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. Reliability is a matter of the application's ability to deal reliably with disks, and of the reliability of the protocols used by the application. SMTP runs over TCP, which is a class 4 transport. Do you consider TCP to be any more or less reliable than TP-4, which X.400 runs over? Protocol reliability is a nonsense item here. It is true that SENDMAIL, if configured to use a shared NFS disk pool among unix systems without file locking, has some probability of losing messages; this is not a criticism of SMTP, but of the site's configuration of the SENDMAIL application. >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. I will leave this to the security experts. I note that Ran and company walk tall among folks who *really*know* and *really*care* about secure systems, and PEM passed muster with them... >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. You mean you can write a check with X.400, or that you can mail around video and audio files? SMTP+MIME can do the latter but not the former. The reason MIME doesn't do the former is not that postscript or jpeg images cannot be carried as enclosed files, but because people that accept checks don't accept facsimiles - FAXes, xerox copies, or emails - of checks. Fill me in on the question here? >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. It is true that not all SMTP-based products support MIME. Eudora, which I am using, receives MIME but doesn't send it. Go back to question 2, and tell me how many X.400 implementations support that security feature that was recently added to X.400? It is true of any protocol that a change in a standard does not automatically imply instant wide deployment. This is new, or limited to SMTP vs X.400? >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. really? can you name an email package that has an X.400 gateway and has no SMTP gateway? >6) X.400 gives you receipt notification upon request while SMTP does not. I have requested receipt notification on this memo. When I stop getting mashed by replies, I'll tell you how many I got. >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. So is CLNS. How many CLNS-only workstations are there in the world? How many interoperable implementations? How many for IP in each case? Frankly, if you want to throw bricks of this form, you'd do well to inquire about Novell Netware. If I understand the statistics correctly, it's got more market share that TCP/IP and OSI combined. >8) X.400 is widely used everywhere in the world except North America. True, but a vacuous statement. The statement makes it sound like electronic messaging services are heavily used world-wide and America has a different standard (as is the case with TV frame formats and telco trunk encoding standards). That's just not true. Certain parts of the world have a fair level of digital communication, and certain parts don't. Looking at address allocation and bandwidth deployment, it's clear that the US has for a long time had the lion's share, Europe and the Pac Rim are working hard on catching up, and much of the world has no clue of it at all. In the Internet Society's newletter a bit back, there was an article by sombody who was deplkoying one of the first digital messaging services in some African country, poor memory say Xambia or something like that. He had significant difficulty getting a reliable 14.4 KBPS link into FIDONET... SMTP is widely used everywhere in the world including North America, and X.400 is in use among some of my North American customers. The comparison is vacuous. >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". I have heard this line of reasoning regarding OSI protocols at each company I've been at since 1980. It has not materialized. >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. Good for them, and I honestly hope it works well for them. Eudora, which I am using to send this message, also implements calendaring and scheduling services. I use it in a variety of ways. When I have a person who is supposed to update a draft in a working group, for example, I schedule ahead of time to post him/her a note at a certain time asking what the status is. This reduces my need to remember to periodically poll. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol > independent. Good for them. I know who X/Open is... >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you > can tell, I forget the details and may have misrepresented what is > actually happening. However, the bottom line is that this activity > convices people that the US Government is really serious about X.400 > and that they prefer it over SMTP. I think you are referring to one of several bidding activities that have happened under US GOSIP, which was intended to say "thou shalt use OSI", but couldn't at inception because the products weren't there and outside of DOE the agencies didn't buy in. There was an exception clause that permitted the agency to buy something else in the case of compelling need - and few actually have purchased OSI products. GOSIP II puts OSI and DDN standards on equal footing. >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even > discern which messages originated from SMTP and which from X.400. [How? > Does this require the use of application-layer gateways? Please explain.] X.400 is widely used in certain realms, and yes, gateways exist which translate. When they do so, you most emphatically CAN tell - that's when you see addresses that consume several lines and are essentially long lists of various attributes of the sender - his first name, last name, middle initial, designation of cat, favorite beverage, mail stop, street address, altitude above sea level... I have seen replies to such emails of the form "could you please write your return address somewhere in the mailgram, I can't figure out from this mess who in the world you are." With all due respect, it sounds to me like someone is hipped on a technology and doesn't want to be confused by the facts. ============================================================================= If you're not living on the edge, you're taking up too much room! From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 20:06:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27072; Sat, 29 Oct 1994 19:50:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA29127; Sat, 29 Oct 1994 19:50:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA29122; Sat, 29 Oct 1994 19:49:26 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26543; Sat, 29 Oct 1994 19:28:07 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26875; Sat, 29 Oct 1994 10:30:39 +0100 Message-Id: <199410290930.AA26875@mitsou.inria.fr> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU Subject: Re: X.400 vs. SMTP In-Reply-To: Your message of "Fri, 28 Oct 1994 13:25:39 MST." <9410282025.AA17839@atc.boeing.com> Date: Sat, 29 Oct 1994 10:30:37 +0100 From: Christian Huitema Eric, As far as I know, there is no safe place to carry a sound X.400 vs SMTP debate. There are X.400 specific mailing list - look at the "X.400's over Internet" groups charter in the IETF - but there are probably few place where you would find a cool evaluation. I am just out of Paris Interop, where the "great debate" theme was precisely SMTP (and MIME) versus X.400, with Marshall Rose agains David Knight from ISOCORE. Many people will tell you that the main difference is in addressing. At first sight, they may well be true: X.400 addresses are utterly ludicrous, cannot be used without the help of some local directory. Which indeed translate into the necessity of populkating that directory. But that is not the most important point. The main difference between X.400 and SMTP is one of architecture. X.400 is designed as a store and forward infrastructure, while SMTP is primarily designed as an application layed upon a connected IP Internet. X.400 is based on "adding value inside the network", while SMTP/MIME by an large follow the "end to end argument". This has a number of important consequences, notably a much lower average quality of service for X.400, due to the absence of automated routing: in most cases, SMTP mail is exchange over one single TCP-IP connection, while X.400 mail has to be relayed several times. Store-and-forward at the message level, with your messages queued in files, takes longer and is more error prone than store and forward of IP packets. There is no such thing as MX records (nor A record, in fact) within X.400; you have to either use hierarchical routing, i.e. default routing through the hierarchical path of PRMD/ADMD/Country, or start an interesting exercise of "MTA management", generally by copying files around. Now, to come to your list of facts: 1) X.400 sure provides accounting and logging, due to the store and forward nature of the network. The counterpart is mandatory relaying. On the other hand, X.400 is *not* more reliable: lots of relays is not more reliable than direct TCP connections. 2) X.400 security features are ill architected. The standards security feature are located in the envelope - because this is a VAN, and because the envelope is what the provider sees. That feature is only supported by the 1988 version of X.400; most existing commercial services only support the 1984 version. When an 1984 relay receives a security enhanced message, it either refuses the message or remove the security features (this is a fact; we tested it). The same is true for gateways to other technologies: the signatures are on the enveloppes, which the gateways tend to shred. By constrast, PEM, PGP or PEM/MIME adds the security features to the "content", signing the documents rather than the envelope. This is both easier to deploy and more secure. 3) X.400 can do EDI via X.435. This is a fact. The MIME/EDI stuff is embryonic. 4) The support for X.400 extensions and MIME is equivalent. In fact, several X.400 vendors just carry MIME inside - that was one of the point of convergence in Rose vs. Knight. MIME is really the de-facto standard for multimedia. X.400 specific extensions are just messy and vendor-specific. 5) The gateway argument is entirely contradictory with the security argument. Besides, gateways also exist with TCP-IP, are in fact easier to deploy due to the availability of automated routing (MX record) and to the simpler nature of teh protocol and its addressing. Most of the other arguments are politics. And no, I certainly would not recommend you to use X.400/Internet gateways - specially in the absence of automated management. We run such a gateway; the difference in messages is quite visible (look at Jack H. contributions in IPng), the adminsitration is a nightmare, the error rate is extremely high. Christian Huitema PS. I wrote one of the earliest X.400 softwares, back in 1986, and was deeply involved in X.400 deployment between 86 and 91. We have since undeployed X.400. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 01:46:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05269; Sun, 30 Oct 1994 00:53:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA29451; Sun, 30 Oct 1994 00:50:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29437; Sun, 30 Oct 1994 00:41:42 +1000 Precedence: list Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04960; Sun, 30 Oct 1994 00:41:18 +1000 (from bcruucp@thumper.bellcore.com) Received: (from bcruucp@localhost) by thumper.bellcore.com (8.6.9/8.6.6) id KAA17360 for Big-Internet@munnari.OZ.AU; Sat, 29 Oct 1994 10:41:13 -0400 Date: Sat, 29 Oct 1994 10:41:13 -0400 Message-Id: <199410291441.KAA17360@thumper.bellcore.com> Subject: abel has new e-mail address From: PostMaster@Bellcore.COM Apparently-To: Big-Internet@munnari.OZ.AU This is to notify you that abel is no longer at this address: (s)he can now be reached at AWeinrib@ibeam.intel.com. Please update your information reguarding this individual. Thank you John Walden Postmaster@bellcore.com ============================================================== From owner-Big-Internet@munnari.OZ.AU Sat Oct 29 10:41:10 1994 Received: from breeze.bellcore.com (breeze-fddi.bellcore.com [128.96.61.41]) by thumper.bellcore.com (8.6.9/8.6.6) with ESMTP id KAA17344 for ; Sat, 29 Oct 1994 10:41:08 -0400 Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by breeze.bellcore.com (8.6.9/8.6.4) with ESMTP id KAA26036 for ; Sat, 29 Oct 1994 10:40:57 -0400 Received: by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA29408; Sun, 30 Oct 1994 00:20:13 +1000 Date: Sun, 30 Oct 1994 00:20:13 +1000 Precedence: list From: Big-Internet@munnari.OZ.AU Reply-To: Big-Internet@munnari.OZ.AU Subject: Big Internet Digest [3.15] To: Big-Internet-Digest-List:; Message-ID: Big Internet Digest Volume 3 Number 15 Of Saturday, 29th October, 1994 Subjects in today's digest (sorted) ... EIDs from the BOF X.400 vs. SMTP ------------ Date: Fri, 28 Oct 94 10:37:21 -0500 Message-Id: <9410281537.AA00866@benedick.ctd.anl.gov> Subject: Re: EIDs from the BOF From: "Richard Carlson" Well here are my answers to KRE's questions. (Slightly out of order). >9. Are EIDs present in every packet ? Yes >1. Are EIDs short (generally perceived as no longer than > about 64 bits) ? Yes >2. Are EIDs binary (as opposed to printable text) ? Yes Since EIDs are sent between communicating nodes in every packet, it follows that they should be 64 bit binary octet strings. They are carried in every packet for the same reasons that IP addreses and port numbers are, i.e. they identify the connection end points. >3. Are EIDs globally unique ? Yes, they must be! >6. Are EIDs used to identify transport connections ? Yes, in conjunction with the TCP/UDP port number. Without these 2 constraints, EIDs will have very little value. I would use an EID to provide a layer of data abstraction separating the network and transport layers. The EID would map to the IP address just as the IP address maps to the Ethernet MAC address. Applications/processes would communicate with each other using sockets. A socket is formed by concatenating the TCP/UDP port number to the EID. In essence the EID is simply replacing the IP address as the globally unique part of a socket. >7. Are EIDs used as a key into any kind of database ? Yes, a DNS style distributed database. >8. Do EIDs have any internal (administrative) structure ? Maybe I don't have any strong feelings on this question. EIDs have no topological or routing structure. They simply provide a 64 bit binary, globally uinque identifer for a node. This means that they can be densely allocated. As long as they meet these constraints, I don't care where they come from (local or remote administrator). The operation of the database will determine what the admistrative structure is. Now comes the controversial part .-) >4. Do EIDs exist at the network level ? No >5. Do EIDs exist in the transport layer ? Yes As I answer these questions I have a specific definition of what is being asked. My operational model is that the EID is located somewhere in the packet being sent over the physical media. The questions is where in the packet is it located? If the EID is located in the network layer header it is 'at' the network layer. If the EID is located in the transport layer header it is 'in' the transprot layer. I place the EID in the transport header, thus EIDs are 'in' the transport layer. They are NOT assigned to a specific transport protocol (TCP or UDP). They are assigned to an Internet node and a single EID is used by ANY transport protocol that node supports (TCP, UDP, TP4, ...). Using this model, EIDs can allow a transport protocol to run over multiple network layers (IPv4 or IP6). There are no changes made to the network layer protocols. The application/process asks the transport layer for service. The transport layer chooses the best network layer protocol and sends the application data. The Dest node may or maynot support EIDs. This can be detected by the Src node by looking in the database for an EID. If none is found, the Src node will find the IPv4 or IP6 address and build appropriate TCP/UDP headers. This makes EIDs an evolutionary changed to the Internet, as apposed to a revolutionary change. Modified nodes are capable of communicating with unmodified nodes, with no change to the underlying Internetwork IP(ng) infrastructure. As a final note, I view EIDs as a way to make TCP/UDP operate over multiple transport protocols. These include IPv4, IP6, and other protocols like ATM, Fibre Channel, SMDS, and serial lines. I guess I am trying to say that TCP/UDP should be viewed as the API of the future. Applications developers would write programs that use sockets for inter-communications. The TCP/UDP protocol would efficiently send the data over the best available network layer. This is the goal I am striving for. As always I welcome any questions, comments, (snide remarks). Rich Carlson ---------------------------- Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory Phone: (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 ------------ Date: Fri, 28 Oct 94 22:58:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9410290258.AA06040@ginger.lcs.mit.edu> Subject: Re: EIDs from the BOF From: "Richard Carlson" There are no changes made to the network layer protocols. The application/process asks the transport layer for service. ... The Dest node may or maynot support EIDs. This can be detected by the Src node by looking in the database for an EID. If none is found, the Src node will find the IPv4 or IP6 address and build appropriate TCP/UDP headers. I'm a little confused as to the benefits of EID's if they are not sure to be there. I.e. you can't design a solution for which requires EID's, since they may not be there. Are you assuming that support for EID's will become basically ubiquitous fairly quickly? Past experience with things like TOS shows that it can be very hard to get stuff like this deployed... Also, the details of this sort of thing may turn out to be grubbier than you expect; you may want to work them out. I found a nasty piece of unpleasantness when I did my modification to Crocker's proposal. (Your proposed change, sticking the EID's in every packet, in what is effectively a shim layer between the internetwork and transport, would fix it, BTW.) This makes EIDs an evolutionary changed to the Internet, as apposed to a revolutionary change. This whole "evolutionary/revolutionary" thing is an utter rathole. I've decided that it's nothing more than loaded terminology used to beat up proposals people don't like; they call their stuff "evolutionary" and deride alternatives as "revolutionary". Get real. The truth is that *NOTHING* is going to get deployed in the Internet unless there's an interoperable transition plan. Was BGP an "evolutionary" change from EGP, or "revolutionary"? Well, a box that speaks BGP only sure can't talk to one that talks EGP only, but somehow the world kept working during the change. As a final note, I view EIDs as a way to make TCP/UDP operate over multiple transport protocols. These include IPv4, IP6, and other protocols like ATM, Fibre Channel, SMDS, and serial lines. I guess I am trying to say that TCP/UDP should be viewed as the API of the future. Applications developers would write programs that use sockets for inter-communications. I think there's a potential flaw here, which is the emphasis on existing transport means. I perceive the future of networking as being one where we need to make statements about resources needed by some important applications. Some of the substates you mention don't provide such guarantees. Unlike building reliable transport on top of unreliable internet, you can't build resource guarantees on top of a best-effort only service. (This is a crucial flaw with IPv6, but let's stay away from that rathole.) I don't think that TCP, or transports in general, is the place to provide this ubiquitous layer, and I persist in thinking that the internetwork layer is the place to do this, but I guess I'm in very small minority in holding that view. Noel ------------ Date: Fri, 28 Oct 94 13:25:39 -0700 From: Eric Fleischman Message-Id: <9410282025.AA17839@atc.boeing.com> Subject: X.400 vs. SMTP Dear Big-Internet: A thousand apologies for posting an issue to this list which is inappropriate for the list. However, I am in a bit of a quandry due to my own personal ignorance and am hoping that several of you could rescue me. [Private replies encouraged.] My problem is that we have some very strong X.400 advocates who are making various claims about X.400 vis-a-vis SMTP. I have never been very concerned personally about Email (hence my ignorance as to even the appropriate list to post this query to) but even I -- as poorly informed as I may be -- have become suspicious that perhaps the truth may differ somewhat from what is apparently being presented as fact. I therefore hope that many of you may help me discern fact from fiction. My goal from this query isn't to win arguments but rather to learn the truth. I believe that the following items have been stated as facts. I do not know if they are true or not. I would appreciate facts and data to demonstrate the truth in regards to each point. The type of facts and data which I seek are raw and accurate details which can be used in polite conversations such as "according to there have been XXX amount of YYY deployed in ZZZ costing PPP with the following QOS characteristics." What I can't use is anything which is in the "flaming" category such as "this is the most stupid thing I have ever read." Specific statements: 1) X.400 is more reliable than SMTP both as a protocol and because it is carried over Value Added Networks (VANs) which provide logging/tracking services which are not available over the Internet. 2) X.400 is more secure than SMTP. Apparently there was a recent addition to X.400 (which I did not follow and thus can't explain) which tremendously raises the security profile of X.400 far above all competitors. They claim that PEM is not adequately secure to be relied upon for business (commercial) communications. 3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. 4) X.400's body parts are immensely flexible, able to carry information of any content. MIME's body parts are almost equivalent but it is not widely supported within SMTP products today. 5) X.400 is a better Email backbone technology because there are more high quality application-layer gateways to X.400 from various existing Email communities than is the case for SMTP -- thus X.400 is well suited to link together a hodge-podge of Email protocols. 6) X.400 gives you receipt notification upon request while SMTP does not. 7) X.400 is an international standard which is officially sanctioned by, and its use encouraged by, virtually every government in the world. 8) X.400 is widely used everywhere in the world except North America. 9) Virtually all Personal Computer Email systems have defined X.400 to be their strategic direction towards which they will evolve their product line. Thus, most proprietary Email systems will soon natively use X.400 which means that it is the "Email system of the future". 10) The Electronic Messaging Association (EMA) has defined rich calendaring and scheduling services -- and other "messaging" services -- which rely upon X.400. 11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but not to SMTP. Exception is the XAPIA's CMC API which is Email protocol independent. 12) I am told that the US Federal Government (DoD???) is asking for bidders for a contract to establish a Federal-wide Email system. The rules of the contract REQUIRE that this system MUST BE based upon X.400. As you can tell, I forget the details and may have misrepresented what is actually happening. However, the bottom line is that this activity convices people that the US Government is really serious about X.400 and that they prefer it over SMTP. 13) X.400 is widely available over the Internet and, like SMTP, can be used to communicate with vast numbers of people. Internet users can not even discern which messages originated from SMTP and which from X.400. [How? Does this require the use of application-layer gateways? Please explain.] Any facts and data which you could supply on any of the above points would be instructional and appreciated. Also, are there any authoritative documents or postings which directly address any these points? In any case, thank you so very much for your patience, tolerance, and help. Sincerely yours, --Eric Fleischman ------------ Message-Id: Date: Fri, 28 Oct 1994 19:30:54 -0700 From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: X.400 vs. SMTP Eric, You will get back a number of responses, each reflecting a point of view. here's mine: At 1:25 PM 10/28/94, Eric Fleischman wrote: >Specific statements: >1) X.400 is more reliable than SMTP both as a protocol and because it is Utterly false, both by bench analysis (compare complexity and make predictions from that) and operational experience (compare duration of production use and amount of traffic and breadth of use). > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. VANs may or may not provide better reliability than simply having "direct" SMTP exchanges. First, there are no statistics to substantiate a claim in either direction (and if I'm wrong, then PLEASE someone should post them.) Second, it certainly is reasonable to have a professional operation pay close attention to good quality performance. That, of course, has zero to do with technology. >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. There is lousy experience with email security of any kind. What little real-world experience there is seems mostly to be PGP. PEM is emerging. My own sense is that the X.400-related work is still fantasy. I'd be interested in hearing about operational experiences to the contrary. It would also be interesting to hear what the technical basis is for claiming inadequacy in the trust/security models and details used by PEM or PGP. I suspect it will hinge of fine points, applicable to specialized business scenarios. >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. I'm told there is minimal deployment and use of X.435. Minimal IS greater than zero, however. There is some informal use of EDI over Mime. An IETF working group has already specified the mime/edi encapsulation, but I'm not aware of any deployment. (Truth is labeling: I chair that working group.) >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. Yeah, right. X.400 has promised flexible body parts for 10 years. The practise has not seemed to meet the promise. Mime has the same promise. My own personal experience is mixed. The mixture is not from technical issues with Mime but rather deployment of Mime-aware user agents. That's improving, but is till early in the adoption curve. Given how slow X.400 adoption has been, it would be silly to make a 'final' assessment based on current numbers. >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing I happen to agree that there aren't enough production-quality email transport packages using Internet technology. On the other hand, perhaps this has something to do with how simple the Internet technology is and how easy it is to get entirely adequate service without complex, expensive software. In any event, look at the real levels of usage, not the theoretical claims. > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. Really? Complex addressing. No routing protocol. Etc. X.400 is better? I don't think so... >6) X.400 gives you receipt notification upon request while SMTP does not. True. And that's being fixed. It's also a very minor issue. Not in theory, but in practise. The reason is that an infrastructure acknowledgement, like delivery reports, is always going to be only as good as the gateways that link the infrastructure of one service to the infrastructure to another. Much email gets gatewayed to "foreign" services. Just how valid or likely are X.400 delivery reports, or any other kind, in those cases? That is, you need an end-to-end mechanism. Going through a gateway usually prevents it. >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. Absolutely true. So, it's kind of amazing that SMTP is used for perhaps 1000 (or more?) times as much traffic. >8) X.400 is widely used everywhere in the world except North America. Widely? How about 'heavily'? These last few questions are trying to run counter to real-world and massive experience. It does appear that X.400 usage is increasing, but I was recently told of significant, linear growth rates. At first that sounded pretty good. But then it occurred to me that this linear growth was taking place in the midst of the exponential explosion of Internet technology use. Linear growth in an exponential market is called "decreasing market share." >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product hmmm. that language was last used some years ago, when talking about other OSI protocols, too. The problem with 'defining strategic direction' is that customers often choose to make tactical purchases. > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". X.400 has been the 'email system of the future' since 1980. It's been published since 1984. My question is, when is this future going to be the present? >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. Defining is easy. Deploying is hard. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol Kind of amazing, isn't it? >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you It will be interesting to see whether this turns into another GOSIP-like sequence, with a later refinement to the requirement which says that an 'open' mail service must be used and X.400 and SMTP are both defined as open. >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even Really? Let me know what my X.400 address is. And how do I send to yours? I bet I have to start with (or go through) SMTP... > discern which messages originated from SMTP and which from X.400. [How? This is probably wrong. X.400 has massively large numbers of different types of headers. And X.400 delivery failure notices usually are distinctive and verbose. > Does this require the use of application-layer gateways? Please explain.] Yes. >In any case, thank you so very much for your patience, tolerance, and help. And thank you for being able to put up with so much silliness from the folks who are feeding you these lines. There is much to legitimately discuss about the virtues and/or realties about X.400 vs. SMTP, but it's best done by folks who have a technical or operational basis for it. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu ------------ Message-Id: <9410282236.AA15876@pan.mc.ti.com> Date: Fri, 28 Oct 1994 18:43:17 -0400 From: w-rolph@ds.mc.ti.com (W. Donald Rolph III) Subject: Re: X.400 vs. SMTP This is wonderful! I love seeing technical arguments posed in politcal terms. Sigh.... In the X.400 vs SMTP debate inside TI there are very few issues which are judeged to be different in substance. Two which might be mentioned in favor of X.400 are: 1) X.400 allows for reciept verification by the post office, thereby gaining some degree of assurance that the mail has been received. SMTP is much weaker here as part of the post office system (although the applications using mail are free to acknowledge receipt, and some do ;-) ) 2) X.400 is an ISO standard and supported well by a number of VANS, particularly in Europe Some significant points in favor of SMTP: 1) it is widely available in an interoperable manner today on virtually every platform known to god or man 2) it has very wide spread connectivity today throughout the world coutersy of the internet 3) it has very long service experience, and is know to work today. X.400 is still evolving with significant inoperability problems (particularly between releases) and internationalisation problems (e.g. the country of the receiver is part of the X.400 address, but in multinational corps. the receiving gateway post office may be in a different country and.... I believe X.400 has a task force working this right now). In short do you want to get work done today (and presumably return on your email investment quickly), or do you want to be "canonically correct" but have primary returns in the future. Note - this is moving out over SMTP. How many responses did you get? From where? This would make some nice statistics, dont you think? >Specific statements: >1) X.400 is more reliable than SMTP both as a protocol and because it is > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. Possible - although the reciept acknowledgement is more significant from my perspective >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. Properly implementd PEM is effectively uncrackable. The real issue is that there are some organizational roadblock which are stalling PEM proliferation. In any event, if you want security on wide area networks you better encrypt. PEM is nearly as good as you can get! >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. Interesting - what vendors of yours do you have in place now who can usitlize this? Would you be willing to use EDI for business without a secure nonrepudiation capability (such as is included in PEM ;-) ) >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. I challenge you to find anything which cant move through MIME. MIME is available for nearly all platforms, and is increasingly ubiquitous in the pc world (eudora free pc mailer supports it {sort of}). UNIX seems to be lagging, mostly due to lack of file viewers, I suspect. >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. Sigh, you can find anywhere from ok to very good gateways from virtually any commercially available email system to SMTP. I think I smell a red herring! >6) X.400 gives you receipt notification upon request while SMTP does not. Absolutely, and one of the few irrefutable and demonstrable differences. Note, however, this makes the post offices much more complex! >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. SMTP is in use by every country in the world etc. Sigh this is what led us down the OSI network debacle! >8) X.400 is widely used everywhere in the world except North America. So is SMTP. By the way X.400 is widely available in America as well. >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". And virtually none of them are working, all experiencing problems, based on my watching primarily Microsofot's express, on the reciept notification. This is a hard problem. >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. True - although nothing precludes using SMTP for calendaring, and certain gateways support it. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol > independent. The IETF is not a standards body??? It has supported the most open effective open network standards of all time!!! >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you > can tell, I forget the details and may have misrepresented what is > actually happening. However, the bottom line is that this activity > convices people that the US Government is really serious about X.400 > and that they prefer it over SMTP. And virtually all government offices, and the president and vice-president, have SMTP email addresses!!! ;-> Hee Hee Hee... >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even > discern which messages originated from SMTP and which from X.400. [How? > Does this require the use of application-layer gateways? Please explain.] Do you like buying land below low tide in Florida??? This can only be accomplished by gatewaying between X.400 and the internet SMTP. These gateways impose no end of variety of limitiations, and are always a point of weakness. > >Any facts and data which you could supply on any of the above points would >be instructional and appreciated. Also, are there any authoritative >documents or postings which directly address any these points? > >In any case, thank you so very much for your patience, tolerance, and help. > >Sincerely yours, > >--Eric Fleischman > > Enjoy, sounds like you are about to have a lot of fun!!! Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-699-1263 ------------ Message-Id: Date: Fri, 28 Oct 1994 23:14:11 -0700 From: fred@cisco.com (Fred Baker) Subject: Re: X.400 vs. SMTP You're correct that this is the wrong place to discuss it; however, neither do I know the right place. I will answer as I can, and others can kibitz. Note that I am an advocate of neither technology: my routers implement neither SMTP nor X.400. At 1:25 PM 10/28/94, Eric Fleischman wrote: >1) X.400 is more reliable than SMTP both as a protocol and because it is > carried over Value Added Networks (VANs) which provide logging/tracking > services which are not available over the Internet. Reliability is a matter of the application's ability to deal reliably with disks, and of the reliability of the protocols used by the application. SMTP runs over TCP, which is a class 4 transport. Do you consider TCP to be any more or less reliable than TP-4, which X.400 runs over? Protocol reliability is a nonsense item here. It is true that SENDMAIL, if configured to use a shared NFS disk pool among unix systems without file locking, has some probability of losing messages; this is not a criticism of SMTP, but of the site's configuration of the SENDMAIL application. >2) X.400 is more secure than SMTP. Apparently there was a recent addition > to X.400 (which I did not follow and thus can't explain) which tremendously > raises the security profile of X.400 far above all competitors. They > claim that PEM is not adequately secure to be relied upon for business > (commercial) communications. I will leave this to the security experts. I note that Ran and company walk tall among folks who *really*know* and *really*care* about secure systems, and PEM passed muster with them... >3) X.400 can do EDI via X.435 while SMTP can't do EDI at all -- even with MIME. You mean you can write a check with X.400, or that you can mail around video and audio files? SMTP+MIME can do the latter but not the former. The reason MIME doesn't do the former is not that postscript or jpeg images cannot be carried as enclosed files, but because people that accept checks don't accept facsimiles - FAXes, xerox copies, or emails - of checks. Fill me in on the question here? >4) X.400's body parts are immensely flexible, able to carry information of > any content. MIME's body parts are almost equivalent but it is not widely > supported within SMTP products today. It is true that not all SMTP-based products support MIME. Eudora, which I am using, receives MIME but doesn't send it. Go back to question 2, and tell me how many X.400 implementations support that security feature that was recently added to X.400? It is true of any protocol that a change in a standard does not automatically imply instant wide deployment. This is new, or limited to SMTP vs X.400? >5) X.400 is a better Email backbone technology because there are more > high quality application-layer gateways to X.400 from various existing > Email communities than is the case for SMTP -- thus X.400 is well suited > to link together a hodge-podge of Email protocols. really? can you name an email package that has an X.400 gateway and has no SMTP gateway? >6) X.400 gives you receipt notification upon request while SMTP does not. I have requested receipt notification on this memo. When I stop getting mashed by replies, I'll tell you how many I got. >7) X.400 is an international standard which is officially sanctioned by, > and its use encouraged by, virtually every government in the world. So is CLNS. How many CLNS-only workstations are there in the world? How many interoperable implementations? How many for IP in each case? Frankly, if you want to throw bricks of this form, you'd do well to inquire about Novell Netware. If I understand the statistics correctly, it's got more market share that TCP/IP and OSI combined. >8) X.400 is widely used everywhere in the world except North America. True, but a vacuous statement. The statement makes it sound like electronic messaging services are heavily used world-wide and America has a different standard (as is the case with TV frame formats and telco trunk encoding standards). That's just not true. Certain parts of the world have a fair level of digital communication, and certain parts don't. Looking at address allocation and bandwidth deployment, it's clear that the US has for a long time had the lion's share, Europe and the Pac Rim are working hard on catching up, and much of the world has no clue of it at all. In the Internet Society's newletter a bit back, there was an article by sombody who was deplkoying one of the first digital messaging services in some African country, poor memory say Xambia or something like that. He had significant difficulty getting a reliable 14.4 KBPS link into FIDONET... SMTP is widely used everywhere in the world including North America, and X.400 is in use among some of my North American customers. The comparison is vacuous. >9) Virtually all Personal Computer Email systems have defined X.400 to be > their strategic direction towards which they will evolve their product > line. Thus, most proprietary Email systems will soon natively use X.400 > which means that it is the "Email system of the future". I have heard this line of reasoning regarding OSI protocols at each company I've been at since 1980. It has not materialized. >10) The Electronic Messaging Association (EMA) has defined rich calendaring > and scheduling services -- and other "messaging" services -- which rely > upon X.400. Good for them, and I honestly hope it works well for them. Eudora, which I am using to send this message, also implements calendaring and scheduling services. I use it in a variety of ways. When I have a person who is supposed to update a draft in a working group, for example, I schedule ahead of time to post him/her a note at a certain time asking what the status is. This reduces my need to remember to periodically poll. >11) Other standards bodies (e.g., X/Open, EMA, XAPIA) refer to X.400 but > not to SMTP. Exception is the XAPIA's CMC API which is Email protocol > independent. Good for them. I know who X/Open is... >12) I am told that the US Federal Government (DoD???) is asking for bidders > for a contract to establish a Federal-wide Email system. The rules of > the contract REQUIRE that this system MUST BE based upon X.400. As you > can tell, I forget the details and may have misrepresented what is > actually happening. However, the bottom line is that this activity > convices people that the US Government is really serious about X.400 > and that they prefer it over SMTP. I think you are referring to one of several bidding activities that have happened under US GOSIP, which was intended to say "thou shalt use OSI", but couldn't at inception because the products weren't there and outside of DOE the agencies didn't buy in. There was an exception clause that permitted the agency to buy something else in the case of compelling need - and few actually have purchased OSI products. GOSIP II puts OSI and DDN standards on equal footing. >13) X.400 is widely available over the Internet and, like SMTP, can be used > to communicate with vast numbers of people. Internet users can not even > discern which messages originated from SMTP and which from X.400. [How? > Does this require the use of application-layer gateways? Please explain.] X.400 is widely used in certain realms, and yes, gateways exist which translate. When they do so, you most emphatically CAN tell - that's when you see addresses that consume several lines and are essentially long lists of various attributes of the sender - his first name, last name, middle initial, designation of cat, favorite beverage, mail stop, street address, altitude above sea level... I have seen replies to such emails of the form "could you please write your return address somewhere in the mailgram, I can't figure out from this mess who in the world you are." With all due respect, it sounds to me like someone is hipped on a technology and doesn't want to be confused by the facts. ============================================================================= If you're not living on the edge, you're taking up too much room! ------------ Message-Id: <199410290930.AA26875@mitsou.inria.fr> Subject: Re: X.400 vs. SMTP Date: Sat, 29 Oct 1994 10:30:37 +0100 From: Christian Huitema Eric, As far as I know, there is no safe place to carry a sound X.400 vs SMTP debate. There are X.400 specific mailing list - look at the "X.400's over Internet" groups charter in the IETF - but there are probably few place where you would find a cool evaluation. I am just out of Paris Interop, where the "great debate" theme was precisely SMTP (and MIME) versus X.400, with Marshall Rose agains David Knight from ISOCORE. Many people will tell you that the main difference is in addressing. At first sight, they may well be true: X.400 addresses are utterly ludicrous, cannot be used without the help of some local directory. Which indeed translate into the necessity of populkating that directory. But that is not the most important point. The main difference between X.400 and SMTP is one of architecture. X.400 is designed as a store and forward infrastructure, while SMTP is primarily designed as an application layed upon a connected IP Internet. X.400 is based on "adding value inside the network", while SMTP/MIME by an large follow the "end to end argument". This has a number of important consequences, notably a much lower average quality of service for X.400, due to the absence of automated routing: in most cases, SMTP mail is exchange over one single TCP-IP connection, while X.400 mail has to be relayed several times. Store-and-forward at the message level, with your messages queued in files, takes longer and is more error prone than store and forward of IP packets. There is no such thing as MX records (nor A record, in fact) within X.400; you have to either use hierarchical routing, i.e. default routing through the hierarchical path of PRMD/ADMD/Country, or start an interesting exercise of "MTA management", generally by copying files around. Now, to come to your list of facts: 1) X.400 sure provides accounting and logging, due to the store and forward nature of the network. The counterpart is mandatory relaying. On the other hand, X.400 is *not* more reliable: lots of relays is not more reliable than direct TCP connections. 2) X.400 security features are ill architected. The standards security feature are located in the envelope - because this is a VAN, and because the envelope is what the provider sees. That feature is only supported by the 1988 version of X.400; most existing commercial services only support the 1984 version. When an 1984 relay receives a security enhanced message, it either refuses the message or remove the security features (this is a fact; we tested it). The same is true for gateways to other technologies: the signatures are on the enveloppes, which the gateways tend to shred. By constrast, PEM, PGP or PEM/MIME adds the security features to the "content", signing the documents rather than the envelope. This is both easier to deploy and more secure. 3) X.400 can do EDI via X.435. This is a fact. The MIME/EDI stuff is embryonic. 4) The support for X.400 extensions and MIME is equivalent. In fact, several X.400 vendors just carry MIME inside - that was one of the point of convergence in Rose vs. Knight. MIME is really the de-facto standard for multimedia. X.400 specific extensions are just messy and vendor-specific. 5) The gateway argument is entirely contradictory with the security argument. Besides, gateways also exist with TCP-IP, are in fact easier to deploy due to the availability of automated routing (MX record) and to the simpler nature of teh protocol and its addressing. Most of the other arguments are politics. And no, I certainly would not recommend you to use X.400/Internet gateways - specially in the absence of automated management. We run such a gateway; the difference in messages is quite visible (look at Jack H. contributions in IPng), the adminsitration is a nightmare, the error rate is extremely high. Christian Huitema PS. I wrote one of the earliest X.400 softwares, back in 1986, and was deeply involved in X.400 deployment between 86 and 91. We have since undeployed X.400. Christian Huitema ------------ This has been a (usually daily) digested form of the Big-Internet list. Send messages for the list to Big-Internet@munnari.OZ.AU Please do not reply to this message, the subject would be meaningless to anyone not getting the digest form of the list, and not very specific in any case. Please construct a new message with an appropriate subject. Send administrative requests (in any comprehensible form of English) to Big-Internet-Request@munnari.OZ.AU Big Internet Digest Volume 3 Number 15 Of Saturday, 29th October, 1994 From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 03:40:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07853; Sun, 30 Oct 1994 03:33:19 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA29536; Sun, 30 Oct 1994 03:30:29 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29531; Sun, 30 Oct 1994 03:21:34 +1100 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07574; Sun, 30 Oct 1994 03:21:31 +1100 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA13756; Sat, 29 Oct 1994 09:21:17 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 29 Oct 1994 09:21:21 -0700 To: Christian Huitema From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: X.400 vs. SMTP Cc: Eric Fleischman , big-internet@munnari.OZ.AU Folks, I'm sending this to save the effort by an X.400 advocate... At 2:30 AM 10/29/94, Christian Huitema wrote: >The main difference between X.400 and SMTP is one of architecture. X.400 is >designed as a store and forward infrastructure, while SMTP is primarily >designed as an application layed upon a connected IP Internet. X.400 >is based on "adding value inside the network", while SMTP/MIME by an large >follow the "end to end argument". This has a number of important consequences, If we use the term SMTP to refer only to the one protocol, SMTP, then the above is correct. Usually, the term these days is used to refer to the Internet email suite of facilities, including RFC822, Mime, DNS MX records, etc. As such, I'm afraid I have to disagree with Christian's assessment. Both models are store and forward. Both conform to the classic UA/MTA model. (Many Internet implementations put UA functions into an MTA and this causes people to get confused, but that's a different concern.) I'd guess that the majority (and, perhaps, the vast majority) of Internet (SMTP) email is relayed. The use of globally unique host naming which is maintained and reused as Internet email is relayed is fundamental to the store-and-forward behavior, since it allows re-evaluation at each hop (the same as for IP addresses. That is, routing is done by the infrastructure and not by the 'address'.) The use of DNS MX records is fundamental to maintenance of a global naming space, independent of the real location and often involving multiple email "hops". The X.400 error is to have the ADMD routing information in the address, rather than maintained separately. The Received header is another facility intended to aid in store and forward operation. On the other hand, SMTP has less total mechanism in its core than does X.400 and, in my view, this is a major difference between the two, since simpler core facilities make for easier implementation and deployment and better operation. Rose refers to this as the core-vs-edges distinction. d/ -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 03:40:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07869; Sun, 30 Oct 1994 03:35:46 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA29553; Sun, 30 Oct 1994 03:35:26 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29528; Sun, 30 Oct 1994 03:21:29 +1100 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07570; Sun, 30 Oct 1994 03:21:24 +1100 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id JAA13753; Sat, 29 Oct 1994 09:21:02 -0700 Message-Id: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="========================_10242612==_" Date: Sat, 29 Oct 1994 09:21:05 -0700 To: fred@cisco.com (Fred Baker) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: X.400 vs. SMTP Cc: Eric Fleischman , big-internet@munnari.OZ.AU --========================_10242612==_ Content-Type: text/plain; charset="us-ascii" At 11:14 PM 10/28/94, Fred Baker wrote: >It is true that not all SMTP-based products support MIME. Eudora, which I >am using, receives MIME but doesn't send it. Go back to question 2, and Well, I've got the current version and it sends Mime, just fine. For example: --========================_10242612==_ Content-Type: image/gif; name="dcrocker.gif" ; x-mac-type="47494666" ; x-mac-creator="4A565752" Content-Disposition: attachment; filename="dcrocker.gif" Content-Transfer-Encoding: base64 R0lGODlhUABkAPUAABQeIgIbJFdgP1FMPgMRDwIPASI7KCArJAs5JgkoJqX4/pH4/ggn SgQiN76fiL2OgCBOQh08PkxpfShSfgADCgACAHeNxYSQmcykm7WgmT1hZ0JZTyRYYB1A WomPgXd3fb/8/rH5/uj9/t7+/q2GbKV7V9u2u762unVtSHBaPAEJIRgjDwIiC1hkZFdh T5B/Zo9yUHl8YnNpXjtOOTU6MD9koRswQVVMJlWQv06WjTpJVKiSf5fd93yv7XvMxNH9 /iwAAAAAUABkAAAG/sCFcDhUKBbGZDKkCDmfTeYTuoxKpcqjEUnser/II7c6LYPKU/GC x+utQecrlakcE9VgoTYrNzvjIXCBRj45EAgsBQUEDTg8gH9oTk1ZRXljfFNncJyCnXFC ODkICSwVp6cUHT2bn4KRdHR2emp7lFaBka6uITw+EhyIiYoEiooVAT1MPz+8ua9QdHi0 S2i7nM3MIDyGiajH4IoBDSodOG6BIM280LDSRbh/13Dr6wqjBaj6qBSpFBTjGjBgMOHc Anra2EmSRknXLm3Z1P0I4QNCuGP7vukjEEBFAIKOJDKLuOsJJFyfImYbqe2eN2MZFVEo 8C9fhX//VFAgQCCB/rkQP0aMlHjNXbqU2IayBOGDg6kKwypg1JhK379UKlQQoKBiQo8f IoRCxNYpl8lO9VQyE0sRQT6aBPbhLIZTqt27WHnqbFCDR1iWQ4seTSoy6I8tPjQ8NRZX n8cEDTryhNnP37edOVcZXjqW3rWVgBcUQpSRQKJ+NAUySBAgAM/JPF0nQIDA9WWcKr6K CCtW5GfAI0eMYDrqaca7ORlwYNCgQYLnAWZD0KBhhoYNGiAYOGCTMgNHa8UCTzje8PCK MI+fsrmTAYQICCK0DgABwoYNAly0cMF/Q30I3jjGQA3KBCXUgeJBxJJYwjGFCEY2UXUK IxEM1EEDtB3QQgsx/ngQQw4oxIACfwIIMMMMh0xVASMFFfjXWuUFZ9gCOQSonlUNdNDB BBrooEMEOkiQgwdDeughCiOWaN+JBiSw1U1cNTABgQcJl+B4B/6VQzCL3XiTCspx0KMG QrbgwZloxqCmiCWWuMGJNBiAQGMACdTiQQYKBxiCa4nwQ402eplVBBEkEIGYHKKZAZov iCgiCm2aeMMMNNCQwFsqCMRBQTwssKeem1kZFnoR4lWaDRzMdqIAHe7ggAcO7LDDmWrC 8GikMwwwQwQGNMaIcjriYMQIL25mnp4+kHZMZaXmA5CPByRwHwoeyOqqtbJWq+YLMCCJ q4lyXlqBQDoOJKxf/lbKaCWxIQAI4VXrlWqDdjN0eGassuJr7QsekNAoDN16WyKTB0RQ TKYMlGvOQX4yCKpwIizwoDHOFSOVMTRJm18M1lZ7rQMgh7wDCdV68C+bbp54gA1xMaLj BB1s6gafekK8mw8s5CxVAsrlnE8xBbCwwgbbomltBq6CfAIGIu/7Agq2Qlqirgc0SYxy MH9HYJ4Qi+onoMRAAHPOr+XMQr1FH/2xAxmwfQLS+JJQArdqhujCwDMYYMAimXag3IA9 1BACbxAHtdsPFflcQQIc5MDAIoausMIMAoQYg78jYxsryBlg0HnIr478ArdIosxkk79y ELOOPDgSFm+7xe6g/uINcCCBWwQgoPcNJSIJw+gkBL9DBm07gMHxnpvANMhOAxww3nqv UABBE3Cg+netE05s1xUJU8A41eecgN4G3JACklDDMPcOL5AwfAYPGI/80pxb62/A3Vau pJzTd1DDBLQZUAhwABavhYUpZssZAqQEgQDozgCUugH6AIaC9s2NBA9IGgaUd4KlHY95 7pObv0IUojahyC0R2BHMFjiBEOiGWLsp3CiEwYKepCp3AVjBpCRYuhLAIITuc8AD4HY8 4hkvZMFL4uh8KDABvAkCLDrUhSDTgxeui1h/MhsiCMAADTwHQOWj3Pli8LsLJnEHD8ig /JbHNDQmkQQAi8G//pDUnxPNZgIYYkBAzlFAm4XlHrShjcsASBsWhLFyIfrd6KrlvjTG r3PFE5kDMBhCRTpqRPypjwGm85iA9GV7fmRKMArJRYK4J2eUK1EKZPCBGKzvBWl0n6zS 6DmQLW9ksXqjItFXORf4h3ETaE0CPNIVdL0udr7QAA2dgwAIpKoAKxDAACongwqa7AXW GmL8HPkApn1wc0CU1egaJSIXyOBuEEiADTrAESd1pAaxi+FuQEAjGrJgNsqBwCkO0CYU yGBbs5IV/LRJvM99E4n5mpWHGkXHc76phhVzzkdwEM/YjYAih9Bi7hoAxRXRYAP8+eea Rne0zmXQc53DQAdV/npLfdHqnzJogUNnYApGMIIcDOhBPGE4AkBq0UnMPMXkZsAfEoVo kcMbogmWulTiMXWpHXzbojzQShmYiAYz2MB+7mOAm+iRAjgdXEXDsoANFJI1PHFOPliA VV++SXoHGIALBrChCwzvBCaIHVSXKgIT/KCDF4hBC/JWtThJrwA0iKl/4vKRTAkELGMV AQ8KyYIt3jMBQj3RW3lygPdEwAYAKJgGPnCBDvp1N3gFQVQX1QLtHOAAM9DBdSJw2Bls 1RRgjQwCGOCXyOKssjXkidlOAcFcJYIFEWgBaVvgn2Zq1UwFjSpeT+CBC+TAP4SKgH6I FAOuroAGG3IBAk7x/pGPNIINY/VB0Mj2mgDYxABvMoDQbHsBD/jgBD7wwH5kyqHRZaCD /z2BA9SkX8GS9r5TFSwEJEfXFnR1Rc1hIQ6EVVH1VtY1r3lSAbIq38lBl3hRPdPobHU5 B0T1g+yz1Qc+UK3/Io19H9iAnGwrgQik4iMMqNCOdBpPQNWmNZNZjw42IDkDuOBDJovB XAcwgBR8QAYBe4HxmIoBOKIgBTCQgQyYnCsXrPhMH5hB1TgEgX60RzUCrHABaBM00xhn aDpAwH0EwCGaSg8VLRgA71JwvhJM2QQOgIH5UnADugIAFQkI7QZiylwICCAHM7AYmJoz JR7HUwGIKOQiLIaM/jfVKwclytkGcgDNGKxgBBcQAJ8J/cMjkmDVhP5ADxpAgxhU4AIW SESDYwwBX04GTAMhUGRHoBhSLmI9xRXAmQQQSFaZzQDUFQDvUGA+P2PgASW4AQwIfYMH mMAGBTgABS5wgQNIRdke6s9WuJIwC0A2sjzIGYAS0RjEnohajRIABFCQgw/Zy1E7EFG1 Y5ltLG+7yTqogY8YbaIZ0MqXNP0SQSw97BmS7RiGpByS69YhpE0XdILWdgkw+ABBp2Dk Jf/AA05gAR/U95IyaJQLshqACSU8shVFnALFlTsI2m1brhw5yKjsgBJcudojL0HBlX5t lb6tX4/y5wv+OfMN/mC2Agf4gAXyinOLkrqy+XCg3krnSucpXendZJrSqY10pZv85N2M +9mdB7AniyirK6jACmSAa653fTeTXYHObACfGVgOamc/e/xCxkRCn7wE2M72DdDOTR9a HsurzLILdBCMCgwAlhb4e0W/jgAVWO9srPKd+khOy6K7ne2PxzafB35tRybe7avU8pts gIAKfsDvohcBCBDRJGUiQOOVOzsGkXftxHN78pAvueMh/9TjpXHuWUbBYLXjAg/IIPTB h6EIFKO3253NW4iH/JSRB7K13wDp2IaBnk++wacqD9ty23Y1ZeCfrO9ABzx2RV0DSrtB anKiTIbUTyj3Z0u1/jxW9n6xB0cpQAP0pzz114DB40Pb1h8LRlo6wHUCCEp+dAHQhAAI SDkzIHLL91RI9H43oEOUJ3vvBwPctEF9VWX5JwMpwB8owgJeBk8xJIDyZDOktgIQUByU M4Pqd4HBM0kFB4E0eH9TB4GUREt5ZQKRl2UDAFI9uHmWJoJcI34iUIQQIAEAciK8oz4h 80FKFzwm934+5G1YOHWOFz9JJIdYGDxalgJbmDcIIAEdAHw7RYA9VgGbJAEScDYpiAJK Bzqul3TUdmVYVgIYsBtVBmuQp3jedm0ZqIN3kzcG8AFAOGzbM1YWMQMcUAMSkAApSDln h0RtyES8Uzk/9AB9/nUCJaCD0qY+bhd9tfdkfLaF8hUBODCKFeU1YjgC+pRVOaBMEJCC yVcCrtKLo3M+OjiBWJZ2GfACfLZlAIN70fcAehhTMzdjF2CMYyWG8aRPRqiKx2citNiI O6A+v7NlA3BOTHaPNFiNTXZw37htJ4dBH5CLW+ZLBhABZIKOO9V1OQAVZagYRNVPvBhH qzRzOrACBEADPsJc5+RlA0ADAyA53QgwfBY8o6NlbkUoElAD6FiKryMqMBQCbvGHTpFK iHRUjgJfOhAnBHAARHYA1yEBLaADM0AB3wUAFHAAGklXV1aPJdCN+oGQFiBsMBmCCLI9 ilEAwPCMMVAiPGQ5/s+IXD9iMBCgAz1pAzrQAjZwABgJADrAMlgHAACQWFqWZVqGSRuQ cDjgbtqjPetCOH7CAYoADMfnbzdZImwWHxxlKDYwG0qpAypgAzSgAgCAljUnl5RJgVM3 dVrWaDpgAa5DOKFyIHnyOn8iFebXax0iQU8jXgCCDABQMZARACxgAxKgA0m5Mv8AWhUg lwCgFSswTi+wYt01AxNgAT3AU1cEIwzSR4iTDxwAIEPTAhlQIh3iAvOWCgCwFVsRAAAw ACsGAOJpA3l3ACqwIjmhd9I4nDHQSvWRA+cQhDVjHnliIK8jMYbYAQEAQco2c2oyc4kg OfmwArBFZBS4YhP4/pY6gZSn8JuHFpwk00oeoAFNMpUBCIbiQZoIIgLtsmajdHweogEh wlw58355VwG1RlVLFow+4iN591064JYAMAMf0CjK9QE6sDI1YAHGtJwPE4LCJ5gIEJ2X Ui8cAlIfQH4GQGgnugIpUC0X8GTkJlM3QAN6Zz4foAI0sAIr9mQyNQBv2QEWwJelmC4L oi5YRGoFYD3Sk1Ubgh8eIGOrUqWS86Ip8ADcQgIyoJSSU6V82AKZ+WQfQFcboJEdsJIX ap9Xsi6lOQKTVQGHogOVZQAbkh8kWiIGUCI0UKWVYj5b5oL5yGQUGKM2AJ4bAKZD6SMa wJLoMp+gEiNZAgIN/lkBpxc0mjVYkfaMOsSHq1aXJQCMe6iDA3AAMRVaB5CWcZWqK7mj fTSfSlEYCyIcOFMBZVgKBWAABLoBVXOs0qlqBjdyKvcAH0ACT7aHbDl1kAleObohaLmS rrOcMQKrPKBPLMABDcACFJAzKyAfz0ii15orMfcBO8BKO1CjrHRO5kYBWiYDkrmTttkB NjAlx/kipDkWaYElQpFrhugcp1BDYvlcD1Iwm/dRc4mjeaaRMWqUMYWjNoCtG9kBLTAl 6BIe4uEZKgGthsENpzCkZmMaJhheYrYi6rSWNhCZGwBaLbqWSclogBhaNAAkKhR6jGos 5KEgGNsDCEABAMBO/vekOwRAHRLwJgOAdRFQmRr5m0GCljZQAzQAAG4JpitGqjSwMjtC lXzCGesQCBe7Jz8gAfmQtYsQHysCszSQHwQ6ADaQuDZALhIwAS2qA0w2lBopARogbizT FcfpMEtBD+kAFL6hDjg7rxdzE2uGWQgZkXFyrDbQEYrboi2gcPeIoz5CuRFAATbQHgR0 JYBhs62AEKALrTjTZoqAXDrxHncjbXTVtiqwMq0rU1oGnkGScPIxLlyxCn7CGbmwDpBQ FqABGvE2IVthAHFGH/sZUi5wA0q5MjH6trH7ZD7CIzXQGlBCEINjtUThCZrwEKDLDDzA AfzQEx3wI/QxPs47/gDls5NgGqMaSZcyIJQoC5n8QA7Jib3yUAbxMBjYsAD+CyU3kVar 2wEJ4CMrNrfoawOS+5E7yUoyJQGJOwG3CyUEoBM5tRmfYBaUwANWoACAUBYawA/7QACL GwENMLu3CZKS+QEsvJE20MCI+AGJa69mNhOVoQJbMxRmgQXVUMEmEQKkVgFZcZ76MA6G QihBMpQb8pY6ILtB4pYxu5J+M0yVMSH+QMU9wAPaOxHSgMNGIAWPMBiTxRVfzME3gSEs IBBkUrlpyWRpmcg00Lo60gFZEcP8gBtgDCZTgpx9nAsKwAP5+wiPAAezGshVcWPqNA4a 0AGVmZcbqQMujJYW/sIAiasTPXEVTwLIGVG9BFLHvbDLnMzJueDJV5cV8DIT/GADzBEA EAtaAXybb6m6ZjnEfsMAV4ExK1AZXBHHcXwKmeIVvmwEvbzLZzCrgJwV/gATAWDMQJy4 DVCZZAKxQEwO7OY3wlwTUnGiXqwTk5zN2uwVutwLcdAEC6BP40zOUrETxrATv5kji6u1 lfmW6+waXGFeWmvQ0CQ5/EDQx5HNYMIGm8wGvcADGhDFXxzH1Qw0NLEClJm4SCnM8DzQ HXGe6yY9dXrRYGwVUQwvFYDDOLwGPbCKNI3TxFAM1XwVWmvM5BDJX5IVR/2bilCnL2rP gKzPN6EebNA6ypTN0biB1XVa0U7ttm4ZmW5LmR1hu0hZ1k69qTM9zlJ9y/0gClmb0TpR F6nAEzL91Gz5m4qrFaHVGGHttgRKoK/l1Eld01OtHmttFTqR2BiJCkJTp8b6168V2Ytw AF7NWYEtOYGNWBaNFYTtJZ492FwRZE3d1QQ6t0pZKZVy2gaA2oH9WnNbKV1NyZ2d0TgN 18Ls18YQoAAA2Gzp2lj1uDtJKanr2nzK2pKT2MCG0Yb92QOdaNt5MQSA2bzt21iVK/eh K6z92pFt3Cvwm1nBAKL82UEAADs= --========================_10242612==_ Content-Type: text/plain; charset="us-ascii" -------------------- Dave Crocker Brandenburg Consulting Phone: +1 408 246 8253 675 Spruce Dr. Fax: +1 408 249 6205 Sunnyvale, CA 94086 Email: dcrocker@mordor.stanford.edu --========================_10242612==_-- From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 13:51:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21722; Sun, 30 Oct 1994 13:51:19 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA29616; Sun, 30 Oct 1994 13:50:50 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA29611; Sun, 30 Oct 1994 13:35:49 +1100 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21169; Sun, 30 Oct 1994 13:35:41 +1100 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id WAA18904; Sat, 29 Oct 1994 22:35:35 -0400 Date: Sat, 29 Oct 1994 22:35:35 -0400 From: Vadim Antonov Message-Id: <199410300235.WAA18904@titan.sprintlink.net> To: ericf@atc.boeing.com, fred@cisco.com Subject: Re: X.400 vs. SMTP Cc: big-internet@munnari.OZ.AU >>8) X.400 is widely used everywhere in the world except North America. Also, Russia, Ukraine, India and China -- in all those countries you can find lots of RFC-822-capable hosts but only few (if any) X.400-capable ones. European telcos serve only a tiny part of the world. Yawn. The discussion about merits of X.400 as a world standard is stupid -- it is simply not. --vadim From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 21:41:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01375; Sun, 30 Oct 1994 21:34:20 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA29665; Sun, 30 Oct 1994 21:30:54 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA29660; Sun, 30 Oct 1994 21:11:16 +1100 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00890; Sun, 30 Oct 1994 21:11:09 +1100 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sun, 30 Oct 94 19:03:32 +0900 From: Masataka Ohta Message-Id: <9410301003.AA02939@necom830.cc.titech.ac.jp> Subject: Re: EIDs from the BOF To: RACarlson@anl.gov (Richard Carlson) Date: Sun, 30 Oct 94 19:03:30 JST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9410281537.AA00866@benedick.ctd.anl.gov>; from "Richard Carlson" at Oct 28, 94 10:37 am X-Mailer: ELM [version 2.3 PL11] Richard A Carlson wrote; > >9. Are EIDs present in every packet ? > Yes > >6. Are EIDs used to identify transport connections ? > Yes, in conjunction with the TCP/UDP port number. So, EID is in every UDP packets and in every TCP packets. EID is in every packets regardless of the transprot layer. > Now comes the controversial part .-) Sure. > As I answer these questions I have a specific definition of what > is being asked. My operational model is that the EID is located > somewhere in the packet being sent over the physical media. The > questions is where in the packet is it located? If the EID is > located in the network layer header it is 'at' the network layer. > If the EID is located in the transport layer header it is 'in' > the transprot layer. What "the network layer header" and "the transport layer header" mean? > I place the EID in the transport header, thus EIDs are 'in' the > transport layer. The above statement is meaningless unless you specify what "the transport header" is. > As a final note, I view EIDs as a way to make TCP/UDP operate over > multiple transport protocols. These include IPv4, IP6, IPv4 and IPv6 are network layer protocols. > and other protocols like ATM, Fibre Channel, SMDS, and serial lines. ATM, Fibre Channel, SMDS, and serial lines are link layer protocols. So, don't say "over multiple transport protocols". > I guess > I am trying to say that TCP/UDP should be viewed as the API of the > future. API is the interface between the transport and the application layer. > Applications developers would write programs that use > sockets for inter-communications. The TCP/UDP protocol would > efficiently send the data over the best available network layer. > This is the goal I am striving for. It seems to me that such a goal is already reached long before. Could you be more specific on what's new? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sun Oct 30 23:41:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02977; Sun, 30 Oct 1994 22:51:18 +1100 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA29689; Sun, 30 Oct 1994 22:50:54 +1100 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA29684; Sun, 30 Oct 1994 22:42:50 +1100 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02423; Sun, 30 Oct 1994 22:22:30 +1100 (from ses@tipper.oit.unc.edu) Received: by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA03906; Sun, 30 Oct 94 06:22:17 EST Date: Sun, 30 Oct 1994 06:22:16 -0500 (EST) From: Simon E Spero To: Vadim Antonov Cc: ericf@atc.boeing.com, fred@cisco.com, big-internet@munnari.OZ.AU Subject: Re: X.400 vs. SMTP In-Reply-To: <199410300235.WAA18904@titan.sprintlink.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII > Also, Russia, Ukraine, India and China -- in all those countries > you can find lots of RFC-822-capable hosts but only few (if any) > X.400-capable ones. European telcos serve only a tiny part of the world. One of the guys at UNC worked on an X.400 implementation in China. However, at the mere mention of the words he has a tendency to hide under a desk and whimper, so that's probably not a vote in favour. Anyway - isn't this big internet? We're supposed to be flaming the CLNP. Simon