From owner-wrec@cs.utk.edu Wed Jan 5 04:25:59 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29776 for ; Wed, 5 Jan 2000 04:25:58 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA20914; Wed, 5 Jan 2000 04:16:08 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 04:16:07 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id EAA20895; Wed, 5 Jan 2000 04:16:07 -0500 (EST) Received: from mx01-ext.netapp.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA20882; Wed, 5 Jan 2000 04:16:00 -0500 (EST) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 04:16:00 -0500 Received: (qmail 935 invoked from network); 5 Jan 2000 09:30:55 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 5 Jan 2000 09:30:55 -0000 Received: from johnm ([192.168.199.21]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id BAA14124 for ; Wed, 5 Jan 2000 01:15:42 -0800 (PST) Message-Id: <4.2.0.58.20000105095714.05e1eab0@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2000 10:07:39 +0100 To: wrec@cs.utk.edu From: John Martin Subject: draft-cerpa-necp-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: Dear WREC group, I ask your indulgence once more. On sending the NECP I-D to the IESG for publication as an "Informational" RFC, the IESG have asked the WREC chairs to confirm that NECP did not conflict with the work currently being undertaken by WREC. This is normal practice for the IESG where there exists an IETF WG working in a similar area. Since NECP has been presented on multiple occasions already to WREC, most recently, on 29-11-1999 without issue, I believe, Bill Maggs and I, as co-chairs, determine that there is no conflict. However, there has been some confusion over the name of the draft - it was mistakenly named "draft-cerpa-wrec-necp-01.txt", which would imply that it was a direct product of this group (which it is not). I am therefore re-sending the draft with its correct name - "draft-cerpa-necp-00.txt", which is identical to the previous version in all but name. It will also be re-published in its new form. We will re-submit this to the IESG in exactly one week. Regards, John -- INTERNET-DRAFT A. Cerpa Expires: May 2000 USC draft-cerpa-necp-00.txt J. Elson USC H. Beheshti Radware, Inc. A. Chankhunthod Network Appliance, Inc. P. Danzig Akamai Technologies R. Jalan Foundry Networks C. Neerdaels Inktomi Corporation T. Schroeder Alteon Web Systems G. Tomlinson Novell Inc. November 23, 1999 NECP the Network Element Control Protocol draft-cerpa-necp-00.txt STATUS OF THIS MEMO This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Cerpa & Elson, et. al. Expiration: May 2000 [Page 1] INTERNET-DRAFT Network Element Control Protocol November 1999 ABSTRACT This document describes "NECP", a lightweight protocol for signalling between servers and the network elements that forward traffic to them. It is intended for use in a wide variety of server applications, including for origin servers, proxies, and network transparent proxies. The network element may also be a range of devices, including so-called L4 or content-aware switches and load-balancing routers. NECP provides methods for network elements to learn about servers' capabilities, availability, and hints as to which flows can and can not be serviced. This allows network elements to perform load balancing across a farm of servers, redirection to network transparent proxies, and cut-through of flows that can not be served by the farm. TABLE OF CONTENTS 1 Introduction 2 Terminology 3 Protocol Overview 4 Related Protocols 5 Specification 5.1 Transport and Basic Protocol Operation 5.2 Packet format 5.2.1 Header Format 5.2.2 Header Field Descriptions 5.2.3 Payload Format 5.2.3.1 Basic Payloads 5.2.3.2 Variable Length Payloads 5.3 Control Message Identifier Table 5.4 Initialization Procedure 5.4.1 NECP_INIT 5.4.2 NECP_INIT_ACK 5.5 Device Liveness Detection and Performance Measurement 5.5.1 Extended Performance Metrics 5.5.2 NECP_KEEPALIVE 5.5.3 NECP_KEEPALIVE_ACK 5.6 Flow Control 5.6.1 NECP_START 5.6.2 NECP_START_ACK 5.6.3 NECP_STOP 5.6.4 NECP_STOP_ACK 5.7 Flow Exception List Management 5.7.1 NECP_EXCEPTION_ADD 5.7.2 NECP_EXCEPTION_ADD_ACK 5.7.3 NECP_EXCEPTION_DEL 5.7.4 NECP_EXCEPTION_DEL_ACK Cerpa & Elson, et. al. Expiration: May 2000 [Page 2] INTERNET-DRAFT Network Element Control Protocol November 1999 5.7.5 NECP_EXCEPTION_RESET 5.7.6 NECP_EXCEPTION_RESET_ACK 5.7.7 NECP_EXCEPTION_QUERY 5.7.8 NECP_EXCEPTION_RESP 5.8 Authenticated Messages 5.8.1 Generating a Credential 5.8.2 Authenticating a Message 5.8.3 Rejecting Messages whose Authentication Failed 5.9 Sequence Numbers 5.9.1 Unauthenticated Connections 5.9.2 Authenticated Connections 6 Motivations and Design Alternatives 6.1 Protocols for Configuration vs. Control 6.2 Use of TCP as a Transport Protocol 6.3 Flow Control of NECP Control Messages 6.4 Stream Framing 6.5 Message Segmentation and Chaining 6.6 Initialization in STOP State 6.7 The Per-Flow State Requirement 6.8 SEs and NEs that are on Different Networks 6.9 Mandatory Implementation of Security Features 6.10 Denial of Service Attacks 6.11 Future Extensions 7 Implementation Notes 7.1 Buffer Management 7.2 Non-Blocking Library Design 8 Security Considerations 9 Acknowledgments 10 Bibliography 11 Authors' Address 1 Introduction Scalable server farms with intelligent support from elements of the network infrastructure are becoming increasingly prevalent in today's Internet. The servers may be simple farms of origin servers or proxies, or more complex configurations such as network transparent proxies as described below. The intelligent network elements may also be any of a range of devices, including so-called L4 switches, content-aware switches, and load-balancing routers. Before NECP, manual configuration or proprietary and mutually incompatible protocols were the only way for network elements to learn about servers' capabilities, availability, or hints as to which flows they could or could not service. NECP now provides a standard server-to-network signalling interface. This allows network elements in heterogenous environments to perform load Cerpa & Elson, et. al. Expiration: May 2000 [Page 3] INTERNET-DRAFT Network Element Control Protocol November 1999 balancing across a server farm, redirection to network transparent proxies, and cut-through of flows that can not be served by the farm. Cut-through is particularly important for network transparent proxies. A network transparent proxy is generally one that services a client's request for some service from somewhere inside the network, even though the client thinks that it is connected directly to an origin server at a network endpoint. This is often useful in that it allows network managers to realize the benefits of local proxies without requiring that all local clients configure their software to be aware of the proxy. However, it can cause problems: users have no way to go directly to origin servers, as may be required in some cases (e.g., servers that authenticate using a client's source IP address). The proxy has a high-level understanding of the application protocol; it can detect these cases and decide which flows should be cut through to origin servers. However, it is the network element that implements the forwarding policy. Thus, signalling between the proxy and the network element is required. NECP provides a standard method for this signalling. NECP does not dictate or even address specific load balancing policies. In contrast, it provides a method for network elements to gather the data required to make logical load balancing decisions. The algorithms used to assign user requests to servers remain entirely in the purview of the network elements. We expect that this will continue to be an area of innovation among vendors and a basis for differentiation of competing products. Section 2 of this document defines some of the terms used herein. Section 3 gives a general overview of NECP, and its relationship to other protocols is described in Section 4. Section 5 contains the canonical and complete description of NECP's semantics. Section 6 describes the motivations behind many of our design decisions; however, in contrast to the previous Section, it does not specify any part of the protocol or carry the same "force of law". We conclude in Section 7 with some implementation hints. 2 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. The special terminology used in this document is defined below. The majority of these terms are taken as-is from RFC 2616 [4] and "Internet Web Replication and Caching Taxonomy" [3], and are included for here for reference. Additional standardized terminology is also given in those references. APPLICATION PROTOCOL Cerpa & Elson, et. al. Expiration: May 2000 [Page 4] INTERNET-DRAFT Network Element Control Protocol November 1999 A set of rules describing how to transmit information between clients and servers. In this context, all application protocols are assumed to make use of IP [9], the Internet Protocol. A transport protocol identifier and (if applicable) a TCP or UDP port number uniquely identify an application protocol and its associated requests. Examples are HTTP (TCP port 80), FTP (TCP ports 20 and 21), DNS (TCP/UDP port 53), and RTSP (TCP/UDP port 554). SERVER (as given in [4]) An application program that accepts connections in order to service requests by sending back responses. Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request. CLIENT (as given in [4]) A program that establishes connections for the purpose of sending requests. FLOW An IP session between two IP endpoints; often TCP connection, but possibly any other IP protocol. A single connection between a server and a client, for example, is a flow. PROXY (as given in [3]) An intermediary program which acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, with possible translation, to other servers. A proxy MUST implement both the client and server requirements of this specification. A "transparent proxy" is a proxy that does not modify the request or response beyond what is required for proxy authentication and identification. A "non-transparent proxy" is a proxy that modifies the request or response in order to provide some added service to the user agent, such as group annotation services, media type transformation, protocol reduction, or anonymity filtering. Except where either transparent or non-transparent behavior is explicitly stated, the HTTP proxy requirements apply to both types of proxies. Note: The term "transparent proxy" refers to a semantically transparent proxy as described in [1], not what is commonly understood within the caching community. We recommend that the term "transparent proxy" is always prefixed to avoid confusion (e.g. "network transparent proxy"). The above condition requiring implementation of both the server and client requirements of HTTP/1.1 is only appropriate for a non-network transparent proxy. Cerpa & Elson, et. al. Expiration: May 2000 [Page 5] INTERNET-DRAFT Network Element Control Protocol November 1999 (NETWORK) TRANSPARENT PROXY (as defined in [3]) A proxy that receives traffic as a result of network traffic redirection. The term "transparent proxy" is typically used to refer to a network transparent proxy and the additional systems that perform traffic redirection. The use of this type of proxy is transparent to both user and client. Due to a conflicting definition in [1], caution should be exercised when referring to a "transparent proxy". As stated above, it is recommended that the phrase "transparent proxy" is prepended with appropriate terminology to avoid confusion. SERVER ELEMENT A general term that involves any device in the network offering a service to a client. This involves servers, proxies, and network transparent proxies as defined above. In this document, the acronym "SE" will be used in place of "Server Element". NETWORK ELEMENT An IP packet-forwarding device in the network. A Network Element can recognize flows that belong to a specific application protocols based on their transport protocol and destination port number, as described above. The network element is what does the interception of client-to-server requests on behalf of a network transparent proxy. Examples are so-called "L4 switches", "content-aware switches", and "load-balancing routers". In this document, the acronym "NE" will be used in place of "network element". Note that the term "network element" as defined by this document is narrower in scope than that described in [3]. PEER One of a pair of cooperating network entities for which there is no clearly defined master/server, or slave/client. That is, each peer can both send requests and service requests. In NECP, server elements and network elements are peers. CACHE (as given in [3]) A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. (Note that there are additional motivations for caching such as to reduce server load or increase availability.) Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. The term "cache" used alone often means "caching proxy". Cerpa & Elson, et. al. Expiration: May 2000 [Page 6] INTERNET-DRAFT Network Element Control Protocol November 1999 3 Protocol Overview NECP is used to exchange information and control messages between a server element (SE) and a network element (NE). The SE is configured with the IP address used for management of the NE. When the SE is initialized (for example, when it boots), it establishes a TCP connection to the NE using a well-known port number. Messages can then be sent, bi-directionally, between the SE and NE. Application level KEEPALIVE messages are exchanged so that a dead peer can be more quickly detected. All messages consist of a fixed-length header and variable length data. The fixed-length header contains the total length of the data so that the incoming TCP stream can be quickly re-segmented into its constituent messages. At the application layer, most messages consist of a request followed by a reply or acknowledgement. TCP handles network-layer retransmissions of messages in the case of lost packets, so the application need only transmit each request once. This protocol uses the "hard state" model; that is to say, if a positive acknowledgement is received that implies some state has been installed in the peer, that state can be assumed to remain in the peer until it expires or the peer crashes. A crashed peer can be detected using NECP KEEPALIVE messages in addition to errors that come from the TCP layer. When a node detects that its peer has crashed, it should assume that all state in that peer needs to be reinstalled after the peer revives. Details of the packet format and the exact semantics of the messages exchanged will be described in the next section. However, in the remainder of this section, we will give a general overview of the types of messages exchanged: "I'm here and ready for work." This message is sent to an NE by an SE when it comes on-line or has become ready to service requests. It lets the NE know that the network element can start forwarding requests to the SE. "Stop sending me work." An SE can request that an NE stop sending it new requests from clients. This can be useful in various situations; for example, when an SE is overloaded, or when an SE wants to shut down for maintenance after completing all currently outstanding requests. "A client needs a direct connection for future requests." Sometimes, a network transparent proxy fails in satisfying a client's request that would have succeeded if the client had been talking directly to the server. For example, a server might authenticate clients based on their source IP address; it might have allowed the client but does not allow network transparent proxies. In these cases, the network transparent proxy SE can ask the NE to allow that particular client's requests to pass directly to the Internet instead of being Cerpa & Elson, et. al. Expiration: May 2000 [Page 7] INTERNET-DRAFT Network Element Control Protocol November 1999 diverted to the SE. Then, the client can be asked to retry its request, if the application protocol in use allows such a message. For example, in HTTP, an HTTP Redirect redirecting the client back to the same URL might be used. 4 Related Protocols This section will describe various protocols that are related to NECP, and the nature of the relationship. WPAD [6], the Web Proxy Auto-Discovery Protocol (work in progress), can be used by clients to learn of the existence of an appropriate proxy that is willing to service their requests. An NE that uses NECP to learn of active SEs may also give that information directly to clients using WPAD. ICP [13], the Internet Cache Protocol, is a "de-facto standard" used by some caches to cooperate in the formation of a cache hierarchy. Caches use ICP to query sibling and parent caches to determine if objects have been cached there. This is complementary to NECP, which governs the signalling between a proxy (such as a cache) and a network element. NECP could conceivably run in parallel with ICP. SNMP [2], the Simple Network Management Protocol, is a general protocol used for management of Internet nodes. The functionality of NECP could have been implemented as a new SNMP MIB instead of an entirely new protocol. Indeed, some of our original design efforts were directed towards an SNMP version of NECP. However, we later settled on a TCP-based protocol after we found ourselves adding features to the SNMP version that already existed in TCP. Section 6.2 explains in more detail our reasons for not using SNMP. HTTP [4], the Hypertext Transfer Protocol, and RTSP [12], the Real Time Streaming Protocol, are two examples of widely deployed protocols used by clients to request content from servers. These protocols are not directly related to NECP, although their design does, of course, have a profound impact on the design of proxies. 5 Specification 5.1 Transport and Basic Protocol Operation NECP uses TCP as a transport protocol. The NE listens on well-known port 3262. The SE is responsible for active opens to the NE. The exact initialization procedure is described in Section 5.4. 5.2 Packet Format NECP messages always begin with a fixed-length, 20-byte header. Cerpa & Elson, et. al. Expiration: May 2000 [Page 8] INTERNET-DRAFT Network Element Control Protocol November 1999 The payload is variable length, and can be 0. The length of the payload is indicated in the header. All data are in network byte order (big endian). The version number of the protocol defined by this standard is 1. 5.2.1 Header Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |NECP Protocol ID (Magic Cookie)| Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Opcode | Request Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number (Upper 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Sequence Number (Lower 32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Payload Length in Bytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ typedef struct { /* We'll start with an identifier so we can check for * correct protocol format, framing, etc. */ U16 protocol_identifier = 0x414a /* ("AJ") */ /* 16-bit flags field */ U16 flags; 0x0001 F_Basic_Payload (see Section 5.2.3) 0x0002 F_Auth_Credential_Provided (see Section 5.8) 0x0004 F_Error 0x0008 F_Protocol_Version_Mismatch (see Section 5.2.1) 0x0010 F_Auth_Required (see Section 5.8) 0x0020 F_Bad_Sequence_Number (see Section 5.9) /* Protocol version number -- always 0x1 */ U8 version; /* Message type (see Section 5.3) */ U8 opcode; /* Number used to match up requests and responses (see * Section 5.2.2) U16 request_id; /* Monotonically increasing sequence number; used to * prevent replay attacks (see Section 5.9) */ U64 seq_num; /* The length of the payload only -- might be 0 */ U32 payload_len; } hdr_t Cerpa & Elson, et. al. Expiration: May 2000 [Page 9] INTERNET-DRAFT Network Element Control Protocol November 1999 5.2.2 Header Field Descriptions protocol_identifier: MUST contain the value 0x414a. Any incoming message whose protocol identifier field does not contain this value MUST be discarded. The protocol identifier is a "magic cookie" that is useful for detecting stream framing errors. version: Indicates the version number of the protocol in use. All implementations that adhere to the standard specified in this document MUST set the version number to 0x1. Behavior in the case of version mismatches is described below. opcode: Specifies the operation that this message requests. Section 5.3 contains the opcode table. Semantics of the opcodes are described in detail later in this document. request_id: Contains a number that identifies this transaction. NECP operations typically consist of a request followed by a response. The request_id helps requesters match incoming responses to their currently outstanding requests. A node that is sending a request SHOULD select a request_id that is distinct from the IDs of all its other currently outstanding requests. The requester may use any convenient algorithm for the selection of these identifiers, and they may be reused frequently. Correspondingly, a responding node MUST include the same request_id in its response. The identifier has no meaning to the responding node and should not be treated as a sequence number. seq_num: Contains the sequence number of the message (used only for authenticated connections); its use is described in Section 5.9. payload_length: indicates the total length of the payload in bytes. The payload length does not include the header, which is 20 bytes. The payload length can be 0. The payload format is described in the next section. flags: Indications of various binary conditions. F_Basic_Payload: Indicates the payload type as described in Section 5.2.3. F_Error: Potentially used by all response opcodes to indicate that some or all of the corresponding request was not satisfied. For some types of errors, F_Error can be used in conjunction with F_Protocol_Version_Mismatch (see below), F_Auth_Required (see Section 5.8), and F_Bad_Sequence_Number (see Section 5.9). Some reply opcodes will also send additional error indications in the message's payload, as described in detail in future sections. Cerpa & Elson, et. al. Expiration: May 2000 [Page 10] INTERNET-DRAFT Network Element Control Protocol November 1999 F_Version_Mismatch: Used to tell a peer "I don't know how to speak your version of the protocol." The protocol version in use is advertised in each message's "version" header field, as described above. A node that receives any NECP message with a version number that it does not understand MUST send a reply with the F_Error and F_Protocol_Version_Mismatch flags set, and the "version" field set to the highest version number that the node is capable of accepting. This type of reply MUST NOT have a payload. F_Auth_Credential_Provided, F_Auth_Required, and F_Bad_Sequence_Number are all used for authenticated connections and are described in Sections 5.8 and 5.9. 5.2.3 Payload Format There are two payload types: a "Basic" payload (F_Basic_Payload set in the header flags), and a "Variable Length" payload (F_Basic_Payload cleared). If the NECP connection is authenticated, each message's payload MUST be followed by a credential, as described in Section 5.8. 5.2.3.1 Basic Payloads The message is known to have a basic payload if its header has the F_Basic_Payload flag set. A basic payload is made up of one or more "basic payload units". Each basic payload unit is a fixed size (32-byte) structure consisting of 8 4-byte integers. The number of basic payload units contained in the message can be determined by dividing the total length of payload indicated in the header by the number of bytes per basic payload unit (32). Note that authenticated connections have an extra 20 bytes after the basic payload units that must be removed before this calculation; see Section 5.8.2 for details. The meaning of the 8 integers in each basic payload unit depends on the message type (opcode). Not all opcodes will use all data positions; unused data positions MUST be set to 0. Format of a basic payload unit: typedef struct { U32 data0; U32 data1; U32 data2; U32 data3; U32 data4; U32 data5; Cerpa & Elson, et. al. Expiration: May 2000 [Page 11] INTERNET-DRAFT Network Element Control Protocol November 1999 U32 data6; U32 data7; } payload_unit_t; As mentioned earlier, a Basic Payload consists of one or more 32-byte Basic Payload Units (as defined above). A message containing a Basic Payload therefore has the following general form: +------------------------+ | NECP Header | | 20 bytes | +------------------------+ | Basic Payload Unit [0] | | 32 bytes | +------------------------+ | Basic Payload Unit [1] | | 32 bytes | +------------------------+ | . | | . | | . | +------------------------+ | Basic Payload Unit [n] | | 32 bytes | +------------------------+ 5.2.3.2 Variable Length Payloads This type of payload has no structure imposed by this standard. Variable length payloads can be used by future extensions of NECP to transmit arbitrarily formatted data of any length up to 2**32-1 (the maximum size representable by the 32-bit payload length in the header). Future extensions of NECP can define opcode-specific data formats to suit their needs using the variable length binary payload option. 5.3 Control Message Identifier Table The following is a list of message types (opcodes) used by NECP. An OPCODE is a control message identifier that is included in the message header (see Section 5.2.1) to identify the type of control message. NECP_NOOP 0x00 /* NO OPeration -- do nothing */ NECP_INIT 0x01 NECP_INIT_ACK 0x02 NECP_KEEPALIVE 0x03 NECP_KEEPALIVE_ACK 0x04 NECP_START 0x05 NECP_START_ACK 0x06 Cerpa & Elson, et. al. Expiration: May 2000 [Page 12] INTERNET-DRAFT Network Element Control Protocol November 1999 NECP_STOP 0x07 NECP_STOP_ACK 0x08 [ 0x08 - 0x19 Reserved for future use ] NECP_EXCEPTION_ADD 0x20 NECP_EXCEPTION_ADD_ACK 0x21 NECP_EXCEPTION_DEL 0x22 NECP_EXCEPTION_DEL_ACK 0x23 NECP_EXCEPTION_RESET 0x24 NECP_EXCEPTION_RESET_ACK 0x25 NECP_EXCEPTION_QUERY 0x26 NECP_EXCEPTION_RESP 0x27 [ 0x28 - 0xFF Reserved for future use ] The following sections describe in detail the semantics of the different opcodes. NECP_NOOP is a "No Operation" opcode that can be ignored. It primarily exists for testing and to prevent accidentally zeroed-out packets from having an effect. 5.4 Initialization Procedure When an NE becomes ready for service, it MUST passively listen for TCP connections on NECP's well-known port (see Section 5.1). When an SE becomes ready for service, it establishes a connection to its associated NE. NECP is not used for peer discovery; an SE is expected to know the NE's address a priori (for example, through manual configuration). Once the TCP connection has been established, the SE MUST send an NECP_INIT message to the NE, and wait for an NECP_INIT_ACK message from the NE in response. Note that NECP initialization is asymmetrical. SEs always perform active TCP opens and send NECP_INIT; NEs always passively listen for connections from SEs, and respond with NECP_INIT_ACK. When an SE tries to establish a connection to an NE, the NE might not be available. In some cases, the TCP connection to the NE might fail (for example, due to a timeout, or an NE that is up but not listening on the NECP port). Another possibility is that the TCP connection will be successfully established, but the NECP_INIT message sent by the SE is not met with a NECP_INIT_ACK reply. In cases such as these where the NE is unavailable, the SE MAY periodically retry the connection. In other words, the SE MAY periodically retry its attempt to initiate a TCP connection; and, after a TCP connection has been established, MAY periodically send NECP_INIT messages until a response is received. Cerpa & Elson, et. al. Expiration: May 2000 [Page 13] INTERNET-DRAFT Network Element Control Protocol November 1999 The retry interval for both of these operations SHOULD have an exponential backoff. The suggested limits of the exponential backoff are between [1 - 256] seconds, although different limits may be provided depending on users' needs. For instance, if waiting 256 seconds for the SE(s) to reconnect to the NE is too long in some environment, the administrator SHOULD be able to reduce the upper limit. An upper limit of 1 second means that the client does not want exponential backoff and the SE(s) retry every second. This "hard state" protocol assumes that all the state in an NE needs to be refreshed after a crash. When an SE sends a NECP_INIT to an NE, the NE SHOULD delete all state associated with that SE. Similarly, the SE MUST assume that the NE has no installed state. It is important to note that the initialization procedure opens a channel for control messages, but does not start the forwarding of client application requests from the NE to the SE. The default condition after initialization is "stop" (see Section 5.6). Redirection of packets will occur only after an SE sends a "start" flow control message to the NE (see Section 5.6). One reason for this default is that it allows the creation of a control channel from a node that will *never* receive actual work, such as a management interface. Further motivations for this decision are given in Section 6.6. 5.4.1 NECP_INIT SE->NE An SE MUST send this message to an NE after opening a TCP connection to that NE. The payload is a single basic payload unit of the following format: - data0: Flags (32 bits). 0x1: If set, all NECP messages on this connection MUST be authenticated as described in Section 5.8. If data0 indicates that this is an authenticated connection, data1 and data2 MUST contain the SE's desired initial sequence number, as described in Section 5.9. If no authentication is required, data1 and data2 MUST be 0. 5.4.2 NECP_INIT_ACK NE->SE Upon receiving an NECP_INIT message from SE, an NE MUST respond with an NECP_INIT_ACK. The payload is a single basic payload unit. Cerpa & Elson, et. al. Expiration: May 2000 [Page 14] INTERNET-DRAFT Network Element Control Protocol November 1999 If data0 of the incoming NECP_INIT is set (i.e., indicates that this is an authenticated connection), data0 and data1 of the outgoing NECP_INIT_ACK MUST contain the NE's desired initial sequence number, as described in Section 5.9. If data0 is not set (indicating an unauthenticated connection), but the NE does not want to use unauthenticated connections, the NE MAY return an NECP_INIT_ACK with F_Error and F_Auth_Required both set. In this case, both sides must immediately close the connection. The SE MAY retry the connection using authentication as described in the previous section. If no authentication is required, data0 and data1 of the outgoing NECP_INIT_ACK MUST be 0. 5.5 Device Liveliness Detection and Performance Measurement The purpose of the NECP_KEEPALIVE opcode and its reply, NECP_KEEPALIVE_ACK, is to allow either an NE or SE to determine the responsiveness and performance of its peer. The keepalive messages themselves provide the most basic, binary performance metric ("are you alive or not?"), but the messages may also carry more explicit and descriptive metrics. Nodes may use these performance metrics in any number of ways; for example, an NE may compare performance metrics from several SEs in a server farm in order to improve load balancing among them. SEs and NEs both MUST periodically send NECP_KEEPALIVE messages to all their NECP control channels. The RECOMMENDED time interval is 5 seconds +/- a randomized interval from 0 to 1 second. NECP_KEEPALIVE queries should elicit NECP_KEEPALIVE_ACK responses, described in more detail below. If a node sends 3 consecutive NECP_KEEPALIVE queries to a peer without any responses, the node SHOULD consider its peer dead. After a node declares a peer dead, it MUST close the NECP connection to that peer. The node MUST NOT use the "dead" connection for future control messages. If the node wishes to continue using the timed out peer, the connection to the peer MUST be reinitialized using the procedure described in Section 5.4. 5.5.1 Extended Performance Metrics NECP_KEEPALIVE messages MAY contain one or more basic payload units, each of which contains a request for a particular performance metric. Each metric is identified by a unique 32-bit number called the Performance Query Type. These numbers will be assigned manually as new metrics are created. An SE may simultaneously support more than one application Cerpa & Elson, et. al. Expiration: May 2000 [Page 15] INTERNET-DRAFT Network Element Control Protocol November 1999 protocol, and its performance in servicing some of these protocols may differ from its performance for others at any given moment. Therefore, a performance query is fully specified with a tuple consisting of (IP Protocol, Port Number, Performance Query Type). Not all nodes will be required to support all possible performance queries; thus, a method of reporting "unsupported performance query" is described below. For reasons explained in Section 6.11, this standard only defines a single performance query type that MUST be implemented by all NECP nodes: 0x1 Health Index. A measurement of the "health" of the node in the range of 0-100 (decimal). 100 means the node is in "perfect health," meaning it is operating at its peak performance; that is to say, approaching the performance advertised in marketing literature. A Health Index of 1 means the node is on the verge of being unable to service new requests, but is still capable of doing so (albeit extremely poorly). A Health Index of 0 is a special value meaning that the node is completely unable to service requests and should not be sent any work until its Health Index increases to some value above 0. Different implementations will likely have different implementation-specific methods of determining their health. For example, a node may choose to use the number of requests currently being serviced, available disk or memory resources, number of open file descriptors, measured quality of network connectivity, or any other means. 5.5.2 NECP_KEEPALIVE This message is used by either an NE or SE to determine whether its peer is responsive. It can contain 0 or more basic payload units, each of which contains an extended performance query, in the following format: - data0: Performance Query Type (32 bits) - data1: Protocol ID (8 bits, the LSB). Identifies the next-layer protocol above IP used by the application protocol whose performance is being queried; for example, TCP (0x6) or UDP (0x11). The mapping of protocols to protocol numbers is the same as that described in [11]. - data2: Destination port number (16 bits, the 2 LSBs). Identifies the port number of the application protocol whose performance is being queried. This value has no meaning if data0 does not indicate TCP Cerpa & Elson, et. al. Expiration: May 2000 [Page 16] INTERNET-DRAFT Network Element Control Protocol November 1999 or UDP. 5.5.3 NECP_KEEPALIVE_ACK This message is used by the SE or NE to respond to a previous NECP_KEEPALIVE query. It can contain 0 or more basic payload units. If the NECP_KEEPALIVE request did not contain any extended performance queries (i.e., had no basic payload units), the NECP_KEEPALIVE_ACK, correspondingly, MUST NOT contain any basic payload units. If the NECP_KEEPALIVE request contained one or more extended performance queries, and the node supports every query in the request, the node MUST send an NECP_KEEPALIVE_ACK with the same number of basic payload units as were in the request. Each basic payload unit in the response MUST correspond to one of the queries that was requested. The basic payload units are in the following format: - data0: Same as in 5.5.2. - data1: Same as in 5.5.2. - data2: Same as in 5.5.2. - data3: Performance Query Response (32 bits). The definition of this value depends on the Performance Query Type. If the NECP_KEEPALIVE request contained any performance queries that the node does not support, the F_Error flag in the NECP_KEEPALIVE_ACK message MUST be set. The payload MUST be a copy of all basic payload units that contained unsupported performance queries. A node that receives such an error indication SHOULD NOT send future NECP_KEEPALIVE queries containing extended performance query types that are not supported by its peer. Responses to queries that are supported, if any, MUST NOT be included in an NECP_KEEPALIVE_ACK error message. In other words, the NECP_KEEPALIVE_ACK might contain valid performance query responses, or indications of unsupported query types, but never both. A node that receives an NECP_KEEPALIVE_ACK with an error indication MAY immediately send another NECP_KEEPALIVE query in order to retrieve the performance metrics that are supported by its peer. 5.6 Flow Control The NECP_START and NECP_STOP opcodes that allow an SE to indicate to the NE its interest in having application-level protocol Cerpa & Elson, et. al. Expiration: May 2000 [Page 17] INTERNET-DRAFT Network Element Control Protocol November 1999 requests directed to it. For example, NECP_START can be used to tell the NE "I am ready to have TCP port 80 requests forwarded to me." NECP_STOP, conversely, tells the NE to stop forwarding these flows. It is very important to note that changes to the NE's list of forwarded protocols MUST only apply to future flows. Existing flows MUST NOT be affected by changes in the forwarding state. This implies that the NE MUST keep per-flow state, instead of matching packets against the current forwarding state as the packets arrive. Motivations for this requirement are described in Section 6.7. 5.6.1 NECP_START SE->NE An SE sends this message to an NE to inform the NE that it is ready to service application-level protocol requests. The payload consists of one or more basic payload units; each payload unit represents a request to start forwarding packets for a single application protocol. Each payload unit has the following information: - data0: Forwarding Type (8 bits, the LSB). Indicates the type of packet forwarding requested by the SE. 0x1: Layer 2 Forwarding. Packets are unchanged at the IP layer and above, and forwarded using the destination SE's datalink-layer address. In the common case of Ethernet, this means that the NE sends the unchanged IP datagrams using the SE's MAC address. This option MUST NOT be used if the NE and SE are not on the same datalink network; i.e., separated by a router. 0x2: GRE Forwarding. Packets are unchanged at the IP layer and above, and forwarded from the NE to the SE using GRE encapsulation. The NE and SE may be on the same datalink network, or separated by a router. 0x3: Layer 3 Forwarding. Packets are changed at the IP layer so that the real destination IP address of packets is the SE. (Other changes are also made as necessary; e.g. recomputation of checksums.) This option is useful for certain types of load balancing; for example, where the NE has a virtual IP address that represents a farm of SEs. - data1: Protocol ID (8 bits, the LSB). Identifies the next-layer protocol above IP used by the application protocol; for example, TCP (0x6) or UDP (0x11). The Cerpa & Elson, et. al. Expiration: May 2000 [Page 18] INTERNET-DRAFT Network Element Control Protocol November 1999 mapping of protocols to protocol numbers is the same as that described in [11]. - data2: Destination port number (16 bits, the 2 LSBs). Identifies the port number of the application protocol that the SE is ready to service. This value has no meaning if data1 does not indicate TCP or UDP. 5.6.2 NECP_START_ACK NE->SE This message is used by an NE to confirm the action taken as a result of a previous NECP_START_ACK from an SE. In the absence of errors, no payload is required and the F_Error Flag MUST be cleared. Recall that the Request Identifier field of the NECP header should allow an SE to match up its own NECP_START requests with an NE's NECP_START_ACK responses (see Section 5.2.2). If an error occurred with one or more of the requests, the F_Error Flag in the message header MUST be set. The payload MUST be a copy of all the basic payload units that contained failed requests. Successful requests, if any, MUST NOT be included in this error message. 5.6.3 NECP_STOP SE->NE Similar to the message described in 5.6.1, but used to stop requests instead of starting them. 5.6.4 NECP_STOP_ACK NE->SE Similar to the message described in 5.6.2, but used to acknowledge stop requests instead of start requests. 5.7 Flow Exception List Management NECP allows an SE to give an NE a list of (IP address, port number) tuples to indicate which flows are "exceptions." These opcodes allow the SE to maintain the NE's flow exception list; that is, add to, delete from, and query the list. In this context, an "exception" is always a flow that should NOT be forwarded to the SE, even though it is in a class of flows that are currently being directed to SEs due to a previous NECP_START message. It is not possible to do the opposite; i.e., forward to the SE individual flows from a class of normally un-forwarded flows. Cerpa & Elson, et. al. Expiration: May 2000 [Page 19] INTERNET-DRAFT Network Element Control Protocol November 1999 There are two types of exceptions that an SE can request: Local Exception: "Don't forward this flow to me, but it's okay to forward it to other servers in the farm." An SE might use this if it is unable to service a flow due to (for example) a local resource shortage. Global Exception: "Don't forward this flow to any server in the farm." An SE might use this if it believes that a flow can not be serviced by any SE in the farm; for example, if the forwarding to a network transparent proxy server is causing authentication problems. The exception type is only advisory, not mandatory. An NE MAY choose to treat any exception as local even if the exception is marked as global by the SE. The motivation for this is described in Section 6.10. It is very important to note that changes to the NE's flow exception list MUST only apply to future flows. Existing flows MUST NOT be affected by changes in the exception list. This implies that the NE MUST keep per-flow state, instead of matching packets against the current forwarding state as the packets arrive. Motivations for this requirement are described in Section 6.7. 5.7.1 NECP_EXCEPTION_ADD SE->NE This message is used by an SE to add one or more entries to the NE's flow exception list. The payload is basic. Each basic payload unit contains a single request, in the following format: - data0: Scope Advisory (8 bits, the LSB): 0x0 No Scope Indicated (NE discretion) 0x1 Local Exception ("do not forward to me") 0x2 Global Exception ("do not forward to farm") - data1: TTL (32 bits). Time To Live in seconds; the length of time that the NE should honor this request before deleting it. Although this value is specified in seconds, the NE MAY round up to the next higher minute, or whatever reasonable time interval is convenient for the implementation. Special Value: 0x0: Static. This item should never time out. - data2: Source IP Address (32 bits). Special Value: 0x0: Wild card. Apply this rule to all source Cerpa & Elson, et. al. Expiration: May 2000 [Page 20] INTERNET-DRAFT Network Element Control Protocol November 1999 addresses. - data3: Source Address Netmask (8 bits, the LSB). Gives the CIDR netmask applied to the Source Address. This value has no meaning if data2 is 0. - data4: Destination IP Address (32 bits). Special Value: 0x0: Wild card. Apply this rule to all destination addresses. - data5: Destination Address Netmask (8 bits, the LSB). Gives the CIDR netmask applied to the Destination Address. This value has no meaning if data4 is 0. - data6: Protocol ID (8 bits, the LSB). Identifies the next-layer protocol above IP; for example, TCP (0x6) or UDP (0x11). The mapping of protocols to protocol numbers is the same as that described in [11]. Special Value: 0x0: Wild card. Apply this rule to all IP protocols. - data7: Destination port number (16 bits, the 2 LSBs). This value has no meaning if data7 does not indicate TCP or UDP. Special Value: 0x0: Wild card. Apply this rule to all destination port numbers. If an NE receives an NECP_EXCEPTION_ADD message requesting an entry in its flow exception list that already exists, the TTL of the entry in the list should be updated to reflect the value in the message just received. In other words, new entries overwrite old entries. 5.7.2 NECP_EXCEPTION_ADD_ACK NE->SE This message is used by an NE to confirm the action taken as a result of a previous NECP_EXCEPTION_ADD from an SE. In the absence of errors, no payload is required and the F_Error Flag MUST be cleared. Recall that the Request Identifier field of the NECP header should allow an SE to match up its own NECP_EXCEPTION_ADD requests with an NE's NECP_EXCEPTION_ADD_ACK responses (see Section 5.2.2). If an error occurred with one or more of the requests, the F_Error Flag in the message header MUST be set. The payload MUST be a copy of all the basic payload units that contained Cerpa & Elson, et. al. Expiration: May 2000 [Page 21] INTERNET-DRAFT Network Element Control Protocol November 1999 failed requests. Successful requests, if any, MUST NOT be included in this error message. 5.7.3 NECP_EXCEPTION_DEL SE->NE This message is used by an SE to delete one or more entries from the NE's flow exception list. An SE can only delete its own entries from the NE's flow exception list; in other words, it can not delete exceptions that were installed by other SEs. An SE may delete any exception it has previously installed -- both local and global. The payload and format is analogous to the one described in Section 5.7.1. 5.7.4 NECP_EXCEPTION_DEL_ACK NE->SE This message is used by an NE to confirm the action taken as a result of a previous NECP_EXCEPTION_DEL from an SE. In the absence of errors, no payload is required and the F_Error Flag MUST be cleared. Recall that the Request Identifier field of the NECP header should allow an SE to match up its own NECP_EXCEPTION_DEL requests with an NE's NECP_EXCEPTION_DEL_ACK responses (see Section 5.2.2). If an error occurred with one or more of the requests, the F_Error Flag in the message header MUST be set. The payload MUST be a copy of all the basic payload units that contained failed requests. Successful requests, if any, MUST NOT be included in this error message. 5.7.5 NECP_EXCEPTION_RESET SE->NE This message is used by the SE to reset (i.e., delete) the NE's entire flow exception list. The NE, upon receiving this opcode, MUST empty its list of flows that were excepted on behalf of the SE sending the request. No payload is required. 5.7.6 NECP_EXCEPTION_RESET_ACK NE->SE This message is used by an NE to confirm the SE of a previous NECP_EXCEPTION_RESET_ACK. No payload is required. 5.7.7 NECP_EXCEPTION_QUERY SE->NE This message is used by the SE to query the active flow exception list in an NE. The entire exception list is queried, i.e., all entries added by all SEs. The payload consists of a single basic payload unit, similar (but not identical) in format to a basic payload unit described in Section 5.7.1, with the exception of data1 as Cerpa & Elson, et. al. Expiration: May 2000 [Page 22] INTERNET-DRAFT Network Element Control Protocol November 1999 described below. This payload unit specifies a filter for the flow exception list query. The expected response from the NE will be all flow exception list entries that match the query. The fields that are valid for filtering are: - data0: Scope advisory. - data1: Installer's IP Address (32 bits). The IP address of the SE that installed this exception. - data2: Source IP Address. - data3: Source Address Netmask. - data4: Destination IP Address. - data5: Destination Address Netmask. - data6: Protocol ID. - data7: Destination Port Number. A non-zero value in any of the valid fields indicates an attribute filter of the query. A zero value in a field indicates a wildcard that matches any flow exception list entry. This implies that query with a payload unit containing all zero-valued data fields MUST effect a query for all the entries in the NE's flow exception list. 5.7.8 NECP_EXCEPTION_RESP NE->SE This message is used by the NE to respond to an NECP_EXCEPTION_QUERY. The payload is basic, containing 0 or more basic payload units. Each payload unit MUST contain an active IP list entry that matches the query given in the NECP_EXCEPTION_QUERY message. The response MUST contain a basic payload unit for each of the NE's active flow exception list entries. Note that if the NECP_EXCEPTION_QUERY had a zero value in the SE IP Address field (data1), the NE should send its entire flow exception list, including exceptions installed on behalf of other SEs. The format of each basic payload unit is the same as the one described in Section 5.7.1, except that the data1 field indicates the IP address of the SE that installed the exception returned in the basic payload unit. 5.8 Authenticated Messages NECP can use a "keyed hash" on messages for authentication purposes. Authentication is based on a shared secret key of up to 160 bits (i.e., a 20 character long password). The SHA-1 [5] algorithm is used to compute a 160-bit hash over an NECP message followed by the shared secret. The result of the hash function is the credential that authenticates the message. This document does not specify how the shared secret is distributed. All NECP implementations MUST support the authenticated message format described in this section. However, nodes may opt to use or not use the authenticated message format on a per-connection Cerpa & Elson, et. al. Expiration: May 2000 [Page 23] INTERNET-DRAFT Network Element Control Protocol November 1999 basis. The use of authentication is negotiated when the SE initiates the NECP connection (see Section 5.4). The NE MUST be able to support authenticated messages if the SE requests an authenticated connections. In addition, the NE MAY force the use of authentication by rejecting unauthenticated connections from the SE. If a connection uses authentication, ALL messages in both directions MUST be authenticated; that is, they MUST contain a credential after the header and payload, and the NECP header MUST have the F_Auth_Credential_Provided flag set. 5.8.1 Generating a Credential The credential of a message is the SHA-1 [5] hash over the header, the payload, and the shared secret (in that order). The output of SHA-1 is a 20-byte hash. This hash value is then appended to the header and other payload. This extends the payload by the size of the credential (20 bytes). The "payload_len" field of the header (Section 5.2) should be increased accordingly. The hash MUST be computed AFTER payload_len is increased to reflect the size of the total (credential-bearing) packet, and AFTER F_Auth_Credential_Provided is set in the header. Graphically, the computation looks like this: | the header | the whole payload (if any) | shared secret | \_________________________________________________________/ SHA-1 over this data = 20-byte credential After the hash is computed, the credential is appended to the message in place of the shared secret. The hash MUST be stored with its most significant byte first. The transmitted message then looks like this: | the header | the whole payload (if any) | hash output | \_________________________________________________________/ The length of the shared secret (20 bytes) was chosen to be the same as the size of the hash output to make this easy to do in-place. The shared secret MUST be padded with NULL values (0x0) if the user configures the SE or NE with a shared secret that is less than 20 bytes long. In summary, the steps required to generate an authenticated message are: 1. Append the shared secret to the end of the unauthenticated Cerpa & Elson, et. al. Expiration: May 2000 [Page 24] INTERNET-DRAFT Network Element Control Protocol November 1999 message. 2. Set F_Auth_Credential_Provided in the header flags, and increase the payload_len in the header by the size of the credential (20 bytes). 3. Calculate the SHA-1 hash over the message and secret. 4. Replace the shared secret with the hash value. 5.8.2 Authenticating a Message When an authenticated message is received (that is, a message that has F_Auth_Credential_Provided set in the header), it the authentication is verified using the reverse of the procedure described in Section 5.8.1. Specifically: 1. Store the credential sent by the peer. 2. Put the shared secret at the end of the payload; i.e., overwrite the credential with the shared secret. 3. Calculate the SHA-1 hash over the message and secret. 4. Compare the hash value with the credential sent by the peer. 5. Decrement the payload_len in the header by the size of the credential (20 bytes). The message MUST be rejected, as described in the next section, if and only if the newly calculated hash does not match the credential sent by the peer. In addition, if a message is received on an authenticated connection that does not have the F_Auth_Credential_Provided flag set, the message MUST be rejected as described in the next section. 5.8.3 Rejecting Messages whose Authentication Failed If the message whose authentication failed was a request, the normal (opcode-specific) procedure for reporting a failed request MUST be followed, as described in previous sections. However, in addition to the F_Error flag that is always set on a response when reporting a failure, the F_Auth_Required flag MUST also be set. If the message whose authentication failed was an acknowledgement of a request, the requester MUST assume that the request was not successfully executed and MAY retry the same operation again with the correct credential. After three consecutive failures, the requester SHOULD give up, and MAY report the authentication failure (e.g., via a system log). Note that due to the idempotent nature of NECP operations, retrying a request that actually succeeded the first time (e.g., if a requester receives and rejects an authentic positive acknowledgement due to a corrupted hash) should not be harmful. Cerpa & Elson, et. al. Expiration: May 2000 [Page 25] INTERNET-DRAFT Network Element Control Protocol November 1999 5.9 Sequence Numbers Although authenticated messages are resistant to forgery by an attacker, they are still vulnerable to replay attacks. In other words, an attacker might record a correctly authenticated messages transmitted by one of the nodes, and replay the same message back to the intended recipient some time later. Security against replay attacks is provided by monotonically increasing sequence numbers in the message header. All NECP implementations MUST support the semantics of sequence numbers described in this section. 5.9.1 Unauthenticated Connections Unauthenticated connections (i.e., connections that do not use the authentication; see Section 5.4.1) MUST set the seq_num field of all outgoing messages to 0, and MUST ignore the sequence number on all incoming messages. In other words, connections that do not use authenticated messages also do not use sequence numbers. 5.9.2 Authenticated Connections Authenticated connections use sequence numbers to avoid replay attacks. The SE and NE first learn their initial sequence numbers (see below). Then, every time a node sends a new message, it increments its sequence number. Each node remembers the last seen sequence number of valid messages from its peers. If a message is received with a sequence number smaller than the sequence number of the last authenticated message, the message MUST be rejected. A message is rejected using a procedure similar to the one described in Section 5.8.3, except that the F_Bad_Sequence_Number flag is set instead of F_Auth_Required. When an authenticated connection starts (i.e., when a NECP_INIT and NECP_INIT_ACK are exchanged, and the NECP_INIT indicates that the connection should use authentication), the two nodes MUST exchange initial sequence numbers. Each node tells its peer what sequence number it wants to RECEIVE. To be more explicit: the SE adds a sequence number to the data portion of its NECP_INIT message, and for the remainder of the connection, the packets emitted by the NE MUST start with that sequence number. Similarly, in the other direction, the NE sends a sequence number to the SE as part of the data in its NECP_INIT_ACK message, and the packets emitted by the SE MUST start with that sequence number. In the following explanation, take care not to confuse the sequence number of the message itself (i.e., the sequence Cerpa & Elson, et. al. Expiration: May 2000 [Page 26] INTERNET-DRAFT Network Element Control Protocol November 1999 number in the NECP message header) with the sequence number being transmitted in the basic payload portion of the packet. 1. Each side MUST select an initial sequence number for the connection. Sequence numbers are 64 bits long. The high 32 bits SHOULD be the node's local clock, which hopefully is monotonically increasing. The low 32 bits SHOULD be 0. 2. The SE MUST send its NECP_INIT message to the NE (see Section 5.4.1), including its selected sequence number in the data1 (MSB) and data2 (LSB) fields of the NECP_INIT basic payload. The sequence number in the header of this message MUST be 0. 3. The NE receives this NECP_INIT message and notes the sequence number sent in the payload. Note that this is the only case where a message with an invalid sequence number in the header may be accepted. 4. The NE sends an NECP_INIT_ACK, sending its selected sequence number in the data0 (MSB) and data1 (LSB) fields of the NECP_INIT_ACK basic payload. The sequence number in the header of this message MUST be the sequence number that was received from the SE in step 3. 5. The SE receives the NECP_INIT_ACK and notes the sequence number sent in the payload. It MUST use this number as the initial sequence number for future messages to the NE. 6. Once the initial sequence number is in place for both the SE and the NE, they will monotonically increase these numbers in future messages send to their respective peers. Initialization Example: SE sends NECP_INIT with Header Sequence Number = 0 (This is always 0 on NECP_INIT) Payload data0 = 0x1 (Flag that requests auth) Payload data1 = 0x22222222 Payload data2 = 0x33333333 NE replies with an NECP_INIT_ACK with Header Sequence Number = 0x2222222233333333 Payload data0 = 0x44444444 Payload data1 = 0x55555555 Now, the messages sent from SE->NE have sequence numbers starting from 0x4444444455555555. Messages sent from NE->SE have sequence numbers starting from 0x2222222233333333. Cerpa & Elson, et. al. Expiration: May 2000 [Page 27] INTERNET-DRAFT Network Element Control Protocol November 1999 6 Motivations and Design Alternatives This section describes some of our design decisions in more detail, and describes the ideas and motivations behind them. This section does not define protocol requirements, but hopefully sheds light on the requirements defined in previous sections. Nothing in this section carries the "force of law" or is part of the formal protocol specification. In general, our guiding principle was to make NECP the simplest possible protocol that would do the job, and no simpler. Many features were rejected where alternative (non-protocol-based) solutions could be found. In addition, we have intentionally left many issues at the discretion of the implementor, where we believe that doing so does not compromise interoperability. 6.1 Protocols for Configuration vs. Control NECP was designed strictly as a control protocol, not a configuration protocol. That is to say, NECP focuses solely on the coordination that is required between an NE and the SEs in its server farm. Data such as the current flow exception list and current load information can not be configured a priori; it must be exchanged while the network is operating. This is the space in which NECP operates. Of course, in order for a server farm to actually work, additional configuration is likely required, possibly including: * selection of a load-balancing policy for the NE. * a list in the NE of IP addresses of SEs from which it should accept connections, for security purposes. * a list in the NE of SEs that do not understand NECP, and should be included in a load-balancing group even without an NECP control channel. * values of the various backoff timers that NECP uses. NECP does not specify how these values are configured; we assume that some other method for configuring the SE and NE exists. This is likely to be vendor-specific. Our goal was to find the minimum information that an SE and NE need to share in order to interoperate, so as to make NECP as simple as possible. The details that do not need to be shared, such as the NE's load balancing algorithm, we feel are better left at the discretion of the implementor. Note, however, that the above comments do not preclude the use of NECP as part of a more comprehensive management interface. Such an interface might be useful to administrators who, for example, want to manually add flows to the flow exception list. Cerpa & Elson, et. al. Expiration: May 2000 [Page 28] INTERNET-DRAFT Network Element Control Protocol November 1999 6.2 Use of TCP as a Transport Protocol SNMP [2], the Simple Network Management Protocol, is a general protocol used for management of Internet nodes. The functionality of NECP could have been implemented as a new SNMP MIB instead of an entirely new protocol. Indeed, some of our original design efforts were directed towards an SNMP version of NECP. However, we later settled on a TCP-based protocol after we found ourselves designing features in the SNMP version that already existed in TCP. Similar in this sense to protocols such as BGP4 [10], NECP leverages off of TCP's retransmission policy, flow control, congestion control mechanisms, packetization of large messages, and stream demultiplexing facilities. In addition, we felt that SNMP was too heavyweight and general of a protocol for this application. Related to our choice of transport protocol was our choice between a "hard state" vs. "soft state" model. Soft state protocols tend to recover more gracefully from errors because they do not depend on reliable detection of failures; they periodically refresh all state as part of normal operations. However, our decision to use TCP made peer failure detection reliable, so we opted for a simpler hard state model instead. 6.3 Flow Control of NECP Control Messages Earlier versions of NECP allowed the SE and NE to impose explicit flow control on their NECP control messages. Special cases of the NECP_START and NECP_STOP messages were defined to apply to future NECP messages themselves, instead of application protocol requests. Ultimately, we decided this feature was more trouble (complexity-wise) than it was worth; it required a large number of exceptions, clarifications, and special cases. We decided instead to use TCP's flow control mechanisms to govern the flow rate of NECP control messages. If a node running NECP is falling behind in its message processing, it will stop reading messages from its TCP. This, in turn, will cause TCP's advertised window to close, which will signal the sender that its peer is falling behind in its message processing. We feel that this simpler (and already implemented) TCP-based mechanism is as effective as application-layer flow control. 6.4 Stream Framing We intentionally designed NECP with a fixed-length header that contains a field indicating the length of the data to follow it. This design was meant to help implementations quickly segment streams into their constituent messages. The fact that the Cerpa & Elson, et. al. Expiration: May 2000 [Page 29] INTERNET-DRAFT Network Element Control Protocol November 1999 header contains the total length means that a node can read an entire message off of a stream before parsing the message. We feel that this design is superior to other designs, where the total length of the message can only be determined by incrementally parsing the message. The 2-byte protocol_identifier field at the beginning is a "magic cookie" to help identify framing errors. If such an error is detected, the safest policy is to simply close the connection and reopen it according to the procedure in Section 5.4. 6.5 Message Segmentation and Chaining Many protocols have a reasonable bound on the size of an individual message (say, 64K). In the case that a logical message exceeds the size of a network message, these protocols often contain an explicit mechanism to indicate that more data is coming. In contrast, the size of an NECP message is, for all practical purposes, unbounded (2^32 bytes), and NECP contains no message chaining facility. Like many of our design decisions, we did this to simplify the protocol and leverage off of the facilities provided to us by TCP. By allowing such large messages, we hope that all NECP messages will "fit", and thus can do away the complexity of chaining. This approach is reasonable because the design of the protocol allows for efficient incremental handling of large messages; for implementation advice, see Section 7.1. 6.6 Initialization in STOP State When an NE comes up (for example, after a crash), it initializes into the STOP state -- that is, it does not forward flows to SEs until it receives an NECP_START message from one of them. An alternative would be to have it start forwarding again where it left off, assuming it has some way of knowing what its forwarding state was before its crash. Both of these alternatives are reasonable, but we made our decision because it seemed more consistent with the "hard state" model at the heart of the protocol. The SEs do not periodically refresh the state that they expect the NE is holding; they install it once and assume that it is persistent. After an NE crash, the NE state might potentially be corrupted, and the hard state model means that this corrupted state may never be corrected. A safer design seemed to be to have the NE delete all of its state and let the SEs reconstruct it. 6.7 The Per-Flow State Requirement In Sections 5.6 and 5.7, we stressed that the burden of keeping per-flow state rested on the NE. This might seem bizarre, since an NE is typically a very high-speed device that switches at Cerpa & Elson, et. al. Expiration: May 2000 [Page 30] INTERNET-DRAFT Network Element Control Protocol November 1999 wire speed. The requirement was actually one of three options that we considered for maintaining the forwarding of existing flows while changing the forwarding of new flows. The three options we considered were the following: 1. Since the SE is already maintaining state on connections that it is servicing, have it send that list to the NE as "exceptions" to a forwarding request. 2. Require the NE to keep per-flow state, and mandate that forwarding requests do not affect existing flows. 3. Ignore the problem, and let existing flows break when a new forwarding command is issued. Option 1 seemed unattractive for a number of reasons. First, it would have made the protocol significantly more complex, which we wished to avoid if at all possible. Second, the solution was not complete. An SE will only have canonical information about flows that it is currently servicing. Although it might theoretically tell the NE "cut through flows from IP address X to the Internet EXCEPT for the following flows," it would never be able to do the opposite. In other words, when asking that flows be directed from the Internet back to the SE, there is no way for the SE to know which direct-to-Internet flows would need to be excepted. Our next choice actually was Option 3, because it seemed unreasonable to expect an NE to be able to keep per-flow state. However, after discussions with NE vendors, we learned that the leading switch implementations already keep per-flow state. We therefore settled on Option 2, and mandated that NEs keep per-flow state to ensure the consistency of all implementations that claim to be NECP compliant. 6.8 SEs and NEs that are on Different Networks If an SE and NE are directly connected by the same datalink network, the NE can divert packets to the SE simply by putting the original (unmodified) IP packet into a datalink-layer frame addressed to the SE. When the SE receives this diverted packet, it will still bear the original packet's destination IP address -- that is, the server that the client was trying to contact. Alternatively, in some some cases, the NE and SE are separated by several router hops. In these cases, the NE has two options for diverting the client's packet to the SE. The first option is encapsulation: the client's original packet is encapsulated in another packet that is addressed to the SE. The second option is for the NE to overwrite the destination address of the client's packet with the SE's address, and send the modified packet on its way. Cerpa & Elson, et. al. Expiration: May 2000 [Page 31] INTERNET-DRAFT Network Element Control Protocol November 1999 In the latter case, the SE needs some way to determine what the original IP address of the packet was -- that is, the address of the server that the client was originally trying to contact. (Note that some application protocols may repeat this information anyway; for example, the Host: field in HTTP.) Earlier versions of NECP included features that would allow a SE to query the the NE for a packet's original destination IP address. After consulting various vendors who plan to implement NECP, it was decided that encapsulation was a much better solution than destination IP address rewriting. Rewriting the destination IP address opens a can of worms, one of which was the extra features required in NECP. Therefore, the entire idea of NE address rewriting was scrapped in favor of an official recommendation that GRE [7] encapsulation be used instead. Some vendors in fact prefer using GRE even when the SE and NE are on the same network. For this reason, a "Use GRE" flag was added to the NECP_START opcode. 6.9 Mandatory Implementation of Security Features We have chosen to make support for the security architecture described in Sections 5.8 and 5.9 mandatory, even though implementations may choose to use it or not use it on a per-connection basis. The reasoning behind this seeming contradiction is as follows. On the one hand, we believe the security architecture to be an important part of the protocol, and mandating it -- rather than making its implementation optional -- will improve interoperability. In addition, assuming universal implementation allowed us to simplify the protocol because the SE and NE do not need to negotiate their "lowest common denominator" abilities. On the other hand, we recognize that our security architecture can impose a significant computational burden on the nodes that are implementing it, so we made its use optional. Users in low-risk environments may wish to get better performance by disabling NECP's authentication features. 6.10 Denial of Service Attacks We believe that our security architecture is sufficient to prevent attackers (who do not have the nodes' shared secret) from successfully forging NECP control messages. We believe that the use of a 64-bit sequence number should prevent replay attacks by guaranteeing that sequence numbers are never re-used. (The high 32 bits come from the clock at the beginning of the connection, and are unique for the lifetime of the device; the low bits start at 0 and are incremented for each message.) Cerpa & Elson, et. al. Expiration: May 2000 [Page 32] INTERNET-DRAFT Network Element Control Protocol November 1999 Nevertheless, it is possible to construct a scenario where a sufficiently resourceful attacker can cause a denial of NECP message service. Specifically, an attacker might replay an old NECP_INIT message so as to trick the NE into using old sequence numbers from a previous connection. The SE will subsequently ignore messages from the NE because the NE's messages will have incorrect sequence numbers. We considered modifications to the protocol that would prevent this type of denial of service attack. However, we decided that protection from this attack was not worth the significant complexity required to prevent it. In particular, we found the benefits to be minimal in light of the fact that TCP itself is vulnerable to denial of service attacks (for example, from forged TCP RST packets). Another type of Denial of Service we considered, although an unlikely one, is the denial of service that one SE may be able to cause for other SEs. An SE may accidentally or maliciously mark many flows with "global exceptions." This would cause flows to not be directed to the server farm that properly functioning SEs normally would have been able to service. To prevent this, we made the "global" vs. "local" exception flag advisory rather than mandatory. An NE that is serving mutually untrustworthy SEs can simply treat all exceptions as local. 6.11 Future Extensions We have left a number of "hooks" in NECP that will allow future development in a number of directions. The most generic of these is the variable length payload (see Section 5.2.3.2). We found no need for unstructured messages in the current version of NECP, but nevertheless included this feature. Our hope was that future NECP features that need more data than the 128-bit basic payload will be implemented using the variable-length payload, instead of throwing the entire protocol away. For example, commands that pass URLs, or even XML-encoded commands, can use the variable length payload. The other major area of extensibility is in the definition of performance metrics (see Section 5.5). It seems difficult now to predict which services will be used by SEs in the future, let alone what kinds of performance metrics will be meaningful in the context of those services. Instead of trying to see the future, we created a framework in which future performance metrics can be created without breaking the protocol. As new metrics are designed, they can each be assigned new numbers. Depending on interest, a block of the 32-bit query type space might even be set aside for "privately defined queries," analogous to the 192.168 netblock of IP. Another possible direction is a new protocol message that allows an NE and SE to define new performance query types at run time; for example, by associating a performance query type identifier with an SNMP MIB Cerpa & Elson, et. al. Expiration: May 2000 [Page 33] INTERNET-DRAFT Network Element Control Protocol November 1999 OID. 7 Implementation Notes This section has advice for implementors, based on our own implementation experience. 7.1 Buffer Management The maximum size of an NECP message is very large, which might be alarming to implementors who are expecting to need 4GB of buffer space for every NECP stream. However, the nature of the protocol allows us to get away with reasonably sized buffers, even when processing very large messages. It should be noted that in NECP request messages, a message header and any one of the basic payload units of a message are a complete, autonomous request. Therefore, even if a very large message comes in, an NECP library might pass it to the library, one basic payload unit at a time, as it arrives. This eliminates the need to buffer the entire message, because the data read off of the network can be discarded as it is passed to the application. In addition, it is important to observe that the lack of a chaining feature in the NECP protocol does not preclude the use of a "chaining API" between an NECP library and an application that uses it. Implementors can use any method of turning a large message into a chain of smaller ones that suits the implementation. Authenticated connections are slightly more complex in that it is not known whether or not ANY of the message should be processed until the entire message has arrived. In this case, it is still possible for an NECP library to incrementally pass requests or replies to the application, but perhaps with some qualification that the application should not act on the data until the authentication has been verified at the end. The library might then calculate the SHA-1 hash incrementally, as the message is passed from the network to the application, and then authenticate the message at the end. We intentionally selected a hashing algorithm that requires only one pass over the data so that this would be possible. Indeed, we decided against the slightly more secure HMAC [8] variant of SHA-1 solely because it requires two passes over the data. 7.2 Non-Blocking Library Design Clearly, it is not acceptable for an NECP library to block while waiting for NECP messages to arrive, because the application using the library almost certainly has other things it would like to do. One possible solution would be for the NECP library to block with a timeout that would call an Cerpa & Elson, et. al. Expiration: May 2000 [Page 34] INTERNET-DRAFT Network Element Control Protocol November 1999 application-supplied function periodically; this is the solution used by the standard UNIX X Window System programming interface. However, we opted for the reverse approach: let the application "run the show", and ask that the application periodically call the library, instead of having the library periodically call the application. The call that is the library's "hook" is guaranteed to be nonblocking. The function reads from readable NECP control channels (if any), and, if any complete messages are received, passes an appropriately parsed representation of the message to the application via an application-supplied callback. We briefly considered telling the application to call the library only when there was useful work to be done (i.e., when a socket was readable) instead of periodically, but we later decided against this approach for two reasons. First, NECP has certain periodic housekeeping activities (e.g., retrying failed connections), so the library needs to be given control -- even if there is no incoming data. Second, an NE might have many potentially readable file descriptors, and it seemed too complex an API -- and too much of a burden on the application programmer -- to pass all those FDs to the application and ask that it check to see if any of them are readable. Yet a third option is to use a second thread that does the readability checking and periodic housekeeping; however, in our implementation, we did not want to assume that we were running on a multi-threaded operating system. 8 Security Considerations See Sections 5.8, 5.9, 6.9, and 6.10. 9 Acknowledgments Cerpa and Elson would like to thank Network Appliance, Inc. for support received for the development of this protocol. Funding for the RFC editor function is currently provided by the Internet Society. 10 Bibliography [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", Request for Comments 2119, Harvard University, March 1997. [2] Case, J., et. al., "A Simple Network Management Protocol", Request for Comments 1157, SNMP Research, May 1990. [3] Cooper, I., et. al., "Internet Web Replication and Caching Cerpa & Elson, et. al. Expiration: May 2000 [Page 35] INTERNET-DRAFT Network Element Control Protocol November 1999 Taxonomy", Internet Draft (work in progress), November 1999. [4] Fielding, R., et. al., "Hypertext Transfer Protocol -- HTTP/1.1", Request for Comments 2068, January 1997. [5] FIPS PUB 180-1, "Secure Hash Standard", FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, April 17, 1995. [6] Gauthier, P., et. al., "The Web Proxy Auto-Discovery Protocol," Internet Draft (work in progress), October 1998. [7] Hanks, S., Li, T., Farinacci, D., and Traina, P. "Generic Routing Encapsulation over IPv4 networks". RFC1702. October 1994. [8] Krawczyk, H., Bellare, M., and Canetti, R. "HMAC: Keyed Hash Exchange for Message Authentication". RFC2104. February, 1997. [9] Postel, J., "Internet Protocol", Request for Comments 791, USC/Information Science Institute, Sep 01 1981. [10] Rekhter, Y., and Li, T., "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, T.J. Watson Research Center, IBM Corp., Cisco Systems, July 1994. [11] Reynolds, J., and Postel, J., "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. [12] Schulzrinne, H., Rao, A., and Lanphier, R., "Real Time Streaming Protocol (RTSP)", Request for Comments 2326, Columbia University and RealNetworks, April 1998. [13] Wessels, D., and Claffy, K., "Internet Cache Protocol (ICP), version 2", Request for Comments 2186, National Laboratory for Applied Network Research/UCSD, September 1997. Cerpa & Elson, et. al. Expiration: May 2000 [Page 36] INTERNET-DRAFT Network Element Control Protocol November 1999 11 Authors' Addresses Alberto Cerpa University of Southern California Department of Computer Science 941 W. 37th Place, SAL 300 Los Angeles, CA 90089-0781 USA Phone: (213) 740-4496 Email: cerpa@usc.edu Jeremy Elson University of Southern California Department of Computer Science 941 W. 37th Place, SAL 300 Los Angeles, CA 90089-0781 USA Phone: (213) 740-4496 Email: jelson@usc.edu Hooman Beheshti Radware, Inc. 3505 Cadillac Ave., Suite G5 Costa Mesa, CA 92626 USA Phone: (714) 436-9700 Email: hooman@radware.com Anawat Chankhunthod Network Appliance, Inc. 495 East Java Dr. Sunnyvale, CA 94089 USA Phone: (408) 822-6000 Email: anawat@netapp.com Peter Danzig Akamai Technologies 1400 Fashion Island Blvd San Mateo, CA 94404 USA Phone: (650) 372-5757 Email: danzig@akamai.com Raj Jalan Foundry Networks, Inc. 680 W. Maude Ave. Suite 3 Sunnyvale, CA 94086 USA Phone: (408) 530-3317 Email: jalan@foundrynet.com Chuck Neerdaels Inktomi Corporation 1900 S. Norfolk St Suite 310 San Mateo, CA 94403 USA Phone: (650) 653-2800 Email: chuckn@inktomi.com Ted Schroeder Cerpa & Elson, et. al. Expiration: May 2000 [Page 37] INTERNET-DRAFT Network Element Control Protocol November 1999 Alteon Web Systems 50 Great Oaks Blvd. San Jose, CA 95119 USA Phone: (408) 360-5500 Email: ted@alteon.com Gary Tomlinson Novell, Inc. 122 East 1700 South Provo, UT 84606 USA Phone: (801) 861-7021 Email: garyt@novell.com FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cerpa & Elson, et. al. Expiration: May 2000 [Page 38] --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Wed Jan 5 04:59:24 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00399 for ; Wed, 5 Jan 2000 04:59:23 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA21744; Wed, 5 Jan 2000 04:40:21 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 04:40:21 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id EAA21726; Wed, 5 Jan 2000 04:40:21 -0500 (EST) Received: from mx01-ext.netapp.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id EAA21710; Wed, 5 Jan 2000 04:40:18 -0500 (EST) Received: from mx01-ext.netapp.com (198.95.224.34 -> mx01-ext.netapp.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 04:40:18 -0500 Received: (qmail 27378 invoked from network); 5 Jan 2000 09:55:14 -0000 Received: from herra.netapp.com (HELO herra.corp.netapp.com) (198.95.224.184) by mx01-ext.netapp.com with SMTP; 5 Jan 2000 09:55:14 -0000 Received: from johnm ([192.168.199.21]) by herra.corp.netapp.com (8.9.3/8.9.3/NTAP-1.0) with ESMTP id BAA16331; Wed, 5 Jan 2000 01:40:12 -0800 (PST) Message-Id: <4.2.0.58.20000105101410.00beab60@pop.netapp.com> X-Sender: jmartin@pop.netapp.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 05 Jan 2000 10:34:51 +0100 To: wrec@cs.utk.edu From: John Martin Subject: definitions and use of "transparency" in the taxonomy Cc: IESG , iab@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed List-Unsubscribe: WREC, There has been a recent discussion among various members of the IESG and IAB with regards elements within the taxonomy document, specifically the usage and definition of the word "transparency". I have asked those who feel strongly to consult the WREC archives and to continue their discussion here. Rather than attempt to summarize their conflicting opinions, I will paste a few comments below, without attribution. If you reach the end, you will notice that a compromise suggestion "interception proxies" was at least partially accepted but I would like to see it discussed here also. Rgds, John -- I have tried to keep them in order, separated by ***: >p.s. "Transparent proxy" is indeed common usage. It is also a >barefaced lie. I have strongly objected to the NAT proponents' attempts >to characterize NATs as transparent (since they break things right and >left) and I will also strongly object to any attempt to legitimize >the term "transparent web proxy". *** >As for the terminology battle, the use of the term "transparent" for proxies >of one type or another was, I thought, covered in the taxonomy doc in our WG. *** >the biggest problem with the use of the term "transparent proxy" as defined >in the terminology document is that it's too likely to be confused with other >uses of "transparent proxy". even "network transparent proxy" is still a >misnomer. > >I think it would be more appropriate to avoid use of the term "transparent" >for a proxy that doesn't modify the request, since "transparent" is so >widely used to mean a proxy that surreptiously intercepts traffic which is >intended for the origin server. were it not for the widespread misuse, >"transparent" would be a good word for this case. *** >And one shouldn't use "transparent" at all to refer to the kind of proxy >that intercepts traffic not intended for it, except to the limited extent >necessary to acknowledge the widespread misuse of the term. Words like >"fradulent", "misdirecting", "plagiarizing", and "hijacking" >all seem more appropriate. *** >I understand that the WG spent a lot of time on the document. I still >feel that its use of the term "transparent proxy" is inappropriate because >the term is so widely misused elsewhere that it has an accepted meaning >which is different than the one that WREC wants to use. *** >I disagree with X on this - "transparent proxy" is a well known term >of the art - one may disagree with the level of transparency but >just about anyone in the networking business knows what you are talking >about when you use that term - I think the use of any other term >would be confusing to most if not many readers - you could put it >in quotes when it is used and have a parententhetical comment >when the term is 1st used that notes the quite real issues that Keith >refers to but I find it hard to see that it would be a good idea >to use a different name for something when a well known name already >exists *** >The problem is that the phrase is a marketing lie and an abuse of language. >The fact that it is in widsepread use makes it worse. I think the minimum >that's acceptable is text stating that so-called transparent proxies are >not transparent, because they change the packets that pass through them, >and all our documents should consistently use the phrase "so-called >transparent proxies". *** >Agreed. Trying to change the accepted meaning of the term "transparent >proxy" is like trying to change back the meaning of "hacker". It would >have been nice if some other word were used in both cases, but language >is defined by usage, not purists. *** >I'm not suggesting that we try to change the meaning of this term, but to >use another term which is less misleading and more accurately describes >the function of such devices. *** >I can not see that it would be a good idea to use another term >"transparent proxy" is the term in use even if it is not what >we would like the term to be - to use anything else to name >the devices that network managers call "transparent proxies" >would not help the community understand what was being talked about *** >I would like to find a better term than "so-called transparent proxies". >however, if no better term can be identified (and I haven't come up >with one yet), then "so-called transparent proxies" would be an improvement. *** >Hidden proxies? Intermediary proxies? Interception proxies? *** >Interception proxies seems to carry the spirit of what is going >on......nomination seconded by some people around here. *** >"interception proxies" would be fine w/me. *** >The whole term "transparent proxies" has been the most debated in WREC, >maybe we'll finally put it to rest. I suggest we keep the also known as >"transparent proxies" in the definition so that the general cache community >will know the definition change. *** >I've found that adding a trailer like > >"Note: froobnitz is also known as bumblebar, but the term bumblebar is often >associated with the property of bumbleness, and also used about bumblebees. >The term "bumblebar" is therefore not used in this document" > >kinda works the way I want it. --end --------------------------------------------------------------- Network Appliance Direct / Voicemail: +31 23 567 9615 Kruisweg 799 Fax: +31 23 567 9699 NL-2132 NG Hoofddorp Main Office: +31 23 567 9600 --------------------------------------------------------------- From owner-wrec@cs.utk.edu Wed Jan 5 14:42:47 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14461 for ; Wed, 5 Jan 2000 14:42:47 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA01047; Wed, 5 Jan 2000 14:33:29 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 14:33:29 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id OAA01029; Wed, 5 Jan 2000 14:33:28 -0500 (EST) Received: from riddler.ebuilt.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA01016; Wed, 5 Jan 2000 14:33:22 -0500 (EST) From: Received: from riddler.ebuilt.net (216.237.34.34 -> 34.34.237.216.globalpac.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 14:33:26 -0500 To: John Martin Cc: iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 5 Jan 2000 11:39:18 -0800 X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/05/2000 11:39:27 AM, Serialize complete at 01/05/2000 11:39:27 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: I am glad that this topic has come up -- I have been trying to access the wrec mail archives for the past couple weeks in order to figure out why "transparent proxy" was being used for an element that is neither transparent (according to HTTP) nor a proxy (according to any traditional definition of that term, including HTTP's). HTTP has always used "gateway" to refer to an intermediary that was not known to the client. Yes, I know that gateway is also an overused term, but the reason it was used is that all of the HTTP protocol requirements are the same for HTTP-to-HTTP gateways as for HTTP-to-other gateways, whereas they are considerably different from the protocol requirements for a proxy which, by definition and accepted practice, is an intermediary *chosen* by the client. I don't buy the argument that "transparent proxy" is the common term for this in the industry. I am in this industry and yet I have never heard that term used outside a wrec-related discussion, aside from its use to indicate a non-transforming proxy of HTTP content within RFC 2616. Given that the definition conflicts with that of "proxy" under HTTP and therefore conflicts with the HTTP protocol requirements placed on a proxy, I think it is foolish to use this term within specifications that are supposed to be subsidiary to the HTTP standard. It therefore doesn't make sense for an IETF RFC to recommend that it be used within the taxonomy. A new term should be created; one that doesn't conflict with the existing protocol specifications, and preferably one that doesn't conflict with its meaning in English. It doesn't have to match the marketing terms -- it just needs to be consistent within the standards. BTW, the mail archive at has been inaccessible for weeks. Is there another one not listed in the charter? ........................................................... Roy T. Fielding, Chief Scientist fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 9401 Jeronimo Rd., Suite 100 fax:+1.949.609.0001 Irvine, CA 92618 USA http://www.eBuilt.com ........................................................... From owner-wrec@cs.utk.edu Wed Jan 5 14:52:42 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14624 for ; Wed, 5 Jan 2000 14:52:41 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA01895; Wed, 5 Jan 2000 14:42:31 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 14:42:31 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id OAA01877; Wed, 5 Jan 2000 14:42:31 -0500 (EST) Received: from ircache.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA01863; Wed, 5 Jan 2000 14:42:28 -0500 (EST) Received: from ircache.net (192.52.106.29 -> ack.ircache.net) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 14:42:29 -0500 Received: from surf.ircache.net (surf.scd.ucar.edu [128.117.28.53]) by ircache.net (8.8.6/8.8.6) with ESMTP id LAA14005; Wed, 5 Jan 2000 11:42:27 -0800 (PST) Received: from localhost (wessels@localhost) by surf.ircache.net (8.8.6/8.8.6) with ESMTP id MAA03656; Wed, 5 Jan 2000 12:41:56 -0700 (MST) Date: Wed, 5 Jan 2000 12:41:56 -0700 From: Duane Wessels To: fielding@ebuilt.com cc: John Martin , iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII List-Unsubscribe: On Wed, 5 Jan 2000 fielding@ebuilt.com wrote: > BTW, the mail archive at has been > inaccessible for weeks. Is there another one not listed in the > charter? www.wrec.org From owner-wrec@cs.utk.edu Wed Jan 5 15:11:07 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15206 for ; Wed, 5 Jan 2000 15:11:06 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA03125; Wed, 5 Jan 2000 14:58:18 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 14:58:18 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id OAA03093; Wed, 5 Jan 2000 14:58:18 -0500 (EST) Received: from justice.atc-bos.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA03051; Wed, 5 Jan 2000 14:58:15 -0500 (EST) Received: from justice.atc-bos.com (24.128.100.160 -> h00a02468fb48.ne.mediaone.net) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 14:58:16 -0500 Received: (from mcmanus@localhost) by justice.atc-bos.com (8.9.3/8.8.7) id OAA00982; Wed, 5 Jan 2000 14:55:16 -0500 From: Patrick McManus Message-Id: <200001051955.OAA00982@justice.atc-bos.com> Subject: Re: definitions and use of "transparency" in the taxonomy To: fielding@ebuilt.com Date: Wed, 5 Jan 2000 14:55:16 -0500 (EST) Cc: jmartin@netapp.com, iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Reply-To: mcmanus@appliedtheory.com In-Reply-To: from "fielding@ebuilt.com" at Jan 5, 0 11:39:18 am X-Mailer: Franken-ELM-2K [version 2.9X PL99 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit In a previous episode fielding@ebuilt.com said... :: :: I don't buy the argument that "transparent proxy" is the common term :: for this in the industry. I am in this industry and yet I have never :: heard that term used outside a wrec-related discussion, first three sites I tried: Alteon: "for use with transparent caches" http://www.alteonwebsystems.com/products/cachedirector.shtml Inktomi: "deploying transparent caching with inktomi's traffic server" http://www.inktomi.com/products/network/traffic/tech/deploy.html (there were 15 other documents with references to transparent caching on inktomi's site) Network Appliance: "Netcache: Transparent Caching" http://www.netapp.com/tech_library/alt2.html (there were 30 other documents with references to transparent caching on netapp) That's 3 for 3.. this is a very prominent term; like it or not. And I don't.. but that's not the point of the taxonomy. What we can't do is say that these things are "transparent" in the way the vendors who created them want to imply.. and I think we do a good job of avoiding that. (Altavista has 3260 pages with "+transparent +proxy" and 16,804 with "+transparent +cache").. heck even CERN the home of the first httpd has http://sunstats.cern.ch/mrtg/webcache.html titled "CERN-USA Transparent Web Cache(s) Traffic". -P From owner-wrec@cs.utk.edu Wed Jan 5 15:11:14 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15217 for ; Wed, 5 Jan 2000 15:11:14 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id OAA03294; Wed, 5 Jan 2000 14:59:01 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 14:59:01 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id OAA03275; Wed, 5 Jan 2000 14:59:01 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id OAA03259; Wed, 5 Jan 2000 14:58:59 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 14:58:59 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id OAA09758; Wed, 5 Jan 2000 14:56:19 -0500 (EST) Message-Id: <200001051956.OAA09758@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: fielding@ebuilt.com cc: John Martin , iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy In-reply-to: Your message of "Wed, 05 Jan 2000 11:39:18 PST." Date: Wed, 05 Jan 2000 14:56:19 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > BTW, the mail archive at has been > inaccessible for weeks. I don't know what the problem is; it works for me from my home net:. lust.indecency.org$ ftp cs.utk.edu Connected to cs.utk.edu. 220 CS.UTK.EDU FTP server (Version wu-2.6.0(1) Sat Oct 30 21:31:07 EDT 1999) ready. Name (cs.utk.edu:moore): ftp 331 Guest login ok, send your complete e-mail address as password. Password: 230-Please read the file README.FTP 230- it was last modified on Fri Apr 2 15:51:50 1993 - 2468 days ago 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> cd pub/wrec 250 CWD command successful. ftp> ls 227 Entering Passive Mode (128,169,94,1,62,61) 150 Opening ASCII mode data connection for file list. mail-archive.1999-02 mail-archive.1999-03 mail-archive.1999-04 mail-archive.1999-05 mail-archive.1999-06 mail-archive.1999-07 mail-archive.1999-08 mail-archive.1999-09 mail-archive.1999-10 mail-archive.1999-11 mail-archive.1999-12 mail-archive.2000-01 226 Transfer complete. ftp> get mail-archive.2000-01 local: mail-archive.2000-01 remote: mail-archive.2000-01 227 Entering Passive Mode (128,169,94,1,40,212) 150 Opening BINARY mode data connection for mail-archive.2000-01 (115418 bytes). 100% |*************************************| 112 KB 7.56 KB/s 00:00 ETA 226 Transfer complete. 115418 bytes received in 00:15 (7.41 KB/s) From owner-wrec@cs.utk.edu Wed Jan 5 15:31:37 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15623 for ; Wed, 5 Jan 2000 15:31:35 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA05179; Wed, 5 Jan 2000 15:22:14 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 15:22:14 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA05161; Wed, 5 Jan 2000 15:22:13 -0500 (EST) Received: from justice.atc-bos.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA05145; Wed, 5 Jan 2000 15:22:10 -0500 (EST) Received: from justice.atc-bos.com (24.128.100.160 -> h00a02468fb48.ne.mediaone.net) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 15:22:11 -0500 Received: (from mcmanus@localhost) by justice.atc-bos.com (8.9.3/8.8.7) id PAA01041; Wed, 5 Jan 2000 15:21:21 -0500 From: Patrick McManus Message-Id: <200001052021.PAA01041@justice.atc-bos.com> Subject: Re: definitions and use of "transparency" in the taxonomy To: jmartin@netapp.com (John Martin) Date: Wed, 5 Jan 2000 15:21:20 -0500 (EST) Cc: wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Reply-To: mcmanus@appliedtheory.com In-Reply-To: <4.2.0.58.20000105101410.00beab60@pop.netapp.com> from "John Martin" at Jan 5, 0 10:34:51 am X-Mailer: Franken-ELM-2K [version 2.9X PL99 PGP2] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit On whether or not to rename (network) transparent proxy I'd point to the abstract of the taxonomy: Abstract This memo specifies standard terminology and the current taxonomy of web replication and caching infrastructure deployed today. It which is basically to say we set out a series of X = Y statements.. The set of X's are not up to us to define beyond a diligent review of current practice.. they are the terms of the "current taxonomy of web replication and caching infrastructure deployed today".. The terms people use are not always those that we'd like for them to use.. but not documenting them makes this document essentially a censored dictionary.. put your head in the sand and pretend it doesn't exist. as for the Y's we have a lot of discretion and should use it wisely. transparent proxy is definitely a well known X. not "interception proxy".. heck, not even '(network) transparent proxy' but in the Y we try and tell people that would be a better thing to say! (and I concur.. but we can only really get away with this because of the overloading of the term against HTTP..) The wrec archives will show that I've gone to great lengths of tomato dodging to make sure that nowhere in this document do we say that this proxy provides some sort of lossless and undetectable service. There was one last change I offered that removed language that said this type of proxy was transparent to the user to be "the use of this type of proxy requires no configuration of the client".. the fact that they break some things is undeniable. The fact that they are heavily deployed is also undeniable. We've simply defined what they are ("a device that receives network traffic redirection".. we also define that latter term as interception.. doesn't leave a lot to the imagination) for better or for worse.. it's not for a taxonomy to judge. What I'd like from the IAB is some support in finishing up the book-keeping of the taxonomy and an endorsement of work on some *protocols* to address these problems of resource discovery so that we don't have to deploy switches that can read packets at optical line speeds just so caches can be effectively utilized. There are lots of deployments that don't want the enforcement nature of these devices, they simply have a configuration problem on the clients and the switches solve that problem by default. under an auto-discovery protocol the client can be made aware of any resources made to it and use (or not) of it is an application/political decision. Sites that need enforcement of course have firewalls available to them. It would seem to be a lot more productive to write down what currently is (rather than wishing it weren't that way), and then proceed to address the problem. I like to think that the IETF addresses protocol problems that require interoperability.. and that that provides a much greater value to the community than taxonomy or known problem documents. -P From owner-wrec@cs.utk.edu Wed Jan 5 15:48:14 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15784 for ; Wed, 5 Jan 2000 15:48:14 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA06567; Wed, 5 Jan 2000 15:38:17 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 15:38:17 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA06549; Wed, 5 Jan 2000 15:38:16 -0500 (EST) Received: from mauve.innosoft.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA06531; Wed, 5 Jan 2000 15:38:08 -0500 (EST) From: Received: from mauve.innosoft.com (192.160.253.247 -> mauve.innosoft.com.253.160.192.IN-ADDR.ARPA) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 15:38:13 -0500 Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-17 #35243) id <01JKCPOPEFFK0002IE@MAUVE.INNOSOFT.COM>; Wed, 05 Jan 2000 17:22:52 -0800 (PST) Date: Wed, 05 Jan 2000 17:22:16 -0800 (PST) Subject: Re: definitions and use of "transparency" in the taxonomy In-reply-to: "Your message dated Wed, 05 Jan 2000 14:56:19 -0500" <200001051956.OAA09758@astro.cs.utk.edu> To: Keith Moore Cc: fielding@ebuilt.com, John Martin , iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Message-id: <01JKCQHENUES0002IE@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii References: List-Unsubscribe: > > BTW, the mail archive at has been > > inaccessible for weeks. > I don't know what the problem is; it works for me from my home net:. FWIW, just tried it from here as well -- I was able to FTP the entire archive with no trouble whatsoever. Ned From owner-wrec@cs.utk.edu Wed Jan 5 16:05:33 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16030 for ; Wed, 5 Jan 2000 16:05:32 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id PAA07758; Wed, 5 Jan 2000 15:47:53 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 15:47:53 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id PAA07740; Wed, 5 Jan 2000 15:47:52 -0500 (EST) Received: from riddler.ebuilt.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id PAA07706; Wed, 5 Jan 2000 15:47:36 -0500 (EST) From: Received: from riddler.ebuilt.net (216.237.34.34 -> 34.34.237.216.globalpac.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 15:47:36 -0500 To: ned.freed@innosoft.com Cc: jmartin@netapp.com, moore@cs.utk.edu, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 5 Jan 2000 12:53:30 -0800 X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/05/2000 12:53:37 PM, Serialize complete at 01/05/2000 12:53:37 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: > > > BTW, the mail archive at has been > > > inaccessible for weeks. > > > I don't know what the problem is; it works for me from my home net:. > > FWIW, just tried it from here as well -- I was able to FTP the entire archive > with no trouble whatsoever. Weird. I get a "421 Service not available" from both MSIE and a normal ftp client on Linux. www.wrec.org works fine, so I can see the past now. Hmmm, just tried it from my UCI account and got in fine. Maybe it has a security screen (like reverse DNS lookup) that doesn't like ebuilt.com. Thanks for checking. ........................................................... Roy T. Fielding, Chief Scientist fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 9401 Jeronimo Rd., Suite 100 fax:+1.949.609.0001 Irvine, CA 92618 USA http://www.eBuilt.com ........................................................... From owner-wrec@cs.utk.edu Wed Jan 5 16:29:08 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16325 for ; Wed, 5 Jan 2000 16:29:07 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA10328; Wed, 5 Jan 2000 16:18:29 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 16:18:29 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA10310; Wed, 5 Jan 2000 16:18:28 -0500 (EST) Received: from atol.icm.edu.pl (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA10297; Wed, 5 Jan 2000 16:18:25 -0500 (EST) Received: from atol.icm.edu.pl (212.87.0.35 -> atol.icm.edu.pl) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 16:18:25 -0500 Received: from burza.icm.edu.pl ([148.81.208.198]:63972 "EHLO burza.icm.edu.pl") by atol.icm.edu.pl with ESMTP id ; Wed, 5 Jan 2000 22:18:04 +0100 Received: (from wojsyl@localhost) by burza.icm.edu.pl (8.9.3/8.9.3/rzm-2.6/icm) id WAA15049; Wed, 5 Jan 2000 22:16:00 +0100 (MET) From: Wojtek Sylwestrzak Message-Id: <200001052116.WAA15049@burza.icm.edu.pl> Subject: Re: definitions and use of "transparency" in the taxonomy In-Reply-To: <200001051955.OAA00982@justice.atc-bos.com> from Patrick McManus at "Jan 5, 2000 02:55:16 pm" To: mcmanus@appliedtheory.com Date: Wed, 5 Jan 2000 22:16:00 +0100 (MET) Cc: fielding@ebuilt.com, jmartin@netapp.com, iab@ietf.org, iesg@ietf.org, wrec@cs.utk.edu Organization: ICM, Warsaw University Address: Pawinskiego 5A, 02-106 Warszawa, Poland Reply-To: W.Sylwestrzak@icm.edu.pl X-PGP-Key-Fingerprint: AF C5 80 1C 7F EE 74 DB 5A F3 0B 54 AE 2F A4 99 X-Accept-Charset: ISO-8859-2 X-Mailer: ELM [version 2.4ME+ PL53 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Patrick: > In a previous episode fielding@ebuilt.com said... > :: > :: I don't buy the argument that "transparent proxy" is the common term > :: for this in the industry. I am in this industry and yet I have never > :: heard that term used outside a wrec-related discussion, > [...] > > (Altavista has 3260 pages with "+transparent +proxy" and 16,804 with > "+transparent +cache").. heck even CERN the home of the first httpd > has http://sunstats.cern.ch/mrtg/webcache.html titled "CERN-USA > Transparent Web Cache(s) Traffic". > > -P > Exactly. Like it or not, this *is* the term in common use and *this is* how the vocabulary gets (re)defined. The goal of the taxonomy draft was to document the current practice, not to impose new definitions or artificial terminology even if it seems more appropriate for a reason. --w From owner-wrec@cs.utk.edu Wed Jan 5 16:42:21 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16461 for ; Wed, 5 Jan 2000 16:42:20 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA11701; Wed, 5 Jan 2000 16:31:14 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 16:31:14 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA11683; Wed, 5 Jan 2000 16:31:14 -0500 (EST) Received: from mail-gw.hursley.ibm.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA11669; Wed, 5 Jan 2000 16:31:10 -0500 (EST) Received: from mail-gw.hursley.ibm.com (194.196.110.15 -> mail-gw.hursley.ibm.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 16:31:11 -0500 Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA37972 for ; Wed, 5 Jan 2000 21:31:07 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA11908 for ; Wed, 5 Jan 2000 21:31:07 GMT Message-ID: <3873B7E7.DAAA34BD@hursley.ibm.com> Date: Wed, 05 Jan 2000 15:30:15 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy References: <200001051955.OAA00982@justice.atc-bos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Can't resist, but I have trimmed the cc's somewhat... Patrick McManus wrote: > ... >.. heck even CERN the home of the first httpd > has http://sunstats.cern.ch/mrtg/webcache.html titled "CERN-USA > Transparent Web Cache(s) Traffic". Indeed. Firstly, that happened after I left CERN. Secondly, it was that very "transparent" cache that taught me the hard way that it wasn't transparent, when I was back at CERN earlier this year trying to experiment with a toy diffserv setup across the Atlantic. Brian From owner-wrec@cs.utk.edu Wed Jan 5 16:42:30 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16472 for ; Wed, 5 Jan 2000 16:42:29 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA11385; Wed, 5 Jan 2000 16:28:26 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 16:28:26 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA11367; Wed, 5 Jan 2000 16:28:25 -0500 (EST) Received: from riddler.ebuilt.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA11353; Wed, 5 Jan 2000 16:28:13 -0500 (EST) From: Received: from riddler.ebuilt.net (216.237.34.34 -> 34.34.237.216.globalpac.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 16:28:13 -0500 To: mcmanus@appliedtheory.com Cc: iab@ietf.org, iesg@ietf.org, jmartin@netapp.com (John Martin), wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 5 Jan 2000 13:34:09 -0800 X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/05/2000 01:34:15 PM, Serialize complete at 01/05/2000 01:34:15 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: >On whether or not to rename (network) transparent proxy I'd point to >the abstract of the taxonomy: > >Abstract > > This memo specifies standard terminology and the current taxonomy > of web replication and caching infrastructure deployed today. It > >which is basically to say we set out a series of X = Y >statements.. The set of X's are not up to us to define beyond a >diligent review of current practice.. they are the terms of the >"current taxonomy of web replication and caching infrastructure >deployed today".. The terms people use are not always those that we'd >like for them to use.. but not documenting them makes this document >essentially a censored dictionary.. put your head in the sand and >pretend it doesn't exist. as for the Y's we have a lot of discretion >and should use it wisely. Now this is why the IETF traditionally prevents informational documents from using the word "standard" even when they don't talk about a protocol. What the abstract says to me is that the specification defines a consistent set of terminology that will be used by future specifications. What the abstract should really say is: This memo describes frequently used terminology within the Web replication and caching industry. And under such terms as "transparent proxy" and "reverse proxy" it should say that these things are not necessarily transparent and never proxies. I have no doubt that people can find any number of marketing plans and proto-specs that use these terms frequently. After all, they are written by the same people and companies that are represented within WREC. The problem is that those terms conflict with their definitions within standards-track protocols, and the terminology within those protocols is intended to be self-consistent and unambiguous and not subject to the whims of marketing departments. This document, OTOH, is adding inconsistency and ambiguity to existing terms just because some people use them in inconsistent and ambiguous ways. That's okay for casual conversations, but not for protocol specs. There's not much I can do about the charter, but I would have preferred a consistent terminology over documenting practice. Given the state of the caching industry, any new terms created here could entirely replace usage in industry within six months. ........................................................... Roy T. Fielding, Chief Scientist fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 9401 Jeronimo Rd., Suite 100 fax:+1.949.609.0001 Irvine, CA 92618 USA http://www.eBuilt.com ........................................................... From owner-wrec@cs.utk.edu Wed Jan 5 16:48:39 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16536 for ; Wed, 5 Jan 2000 16:48:38 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA12371; Wed, 5 Jan 2000 16:37:21 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 16:37:21 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA12348; Wed, 5 Jan 2000 16:37:20 -0500 (EST) Received: from prv-mail20.provo.novell.com (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA12333; Wed, 5 Jan 2000 16:37:18 -0500 (EST) Received: from prv-mail20.provo.novell.com (137.65.82.195 -> prv-mail20.provo.novell.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 16:37:18 -0500 Received: from INET-PRV-Message_Server by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 05 Jan 2000 14:34:36 -0700 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.2.1 Date: Wed, 05 Jan 2000 14:34:22 -0700 From: "Gary Tomlinson" To: , Cc: , , Subject: Re: definitions and use of "transparency" in the taxonomy Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id QAA16536 >>> 01/05/00 12:39PM >>> ... excerpt > I don't buy the argument that "transparent proxy" is the common term > for this in the industry. I am in this industry and yet I have never > heard that term used outside a wrec-related discussion, aside from its > use to indicate a non-transforming proxy of HTTP content within RFC 2616. > Given that the definition conflicts with that of "proxy" under HTTP and > therefore conflicts with the HTTP protocol requirements placed on a > proxy, I think it is foolish to use this term within specifications > that are supposed to be subsidiary to the HTTP standard. It therefore > doesn't make sense for an IETF RFC to recommend that it be used within > the taxonomy. Albeit HTTP is a major protocol in the web, but its not the only one. The WREC taxonomy covers the broader web including other protocols such as FTP, WCCP, NECP, ICP, etc. In fact, there are even streaming media caches now, so the web is getting more comprehensive everyday. Given this broader scope, I don't see how the taxonomy can be subiduary to RFC2616. However, I agree that terms should not be invented that conflict with existing terminology, especially those in RFC2616. We have made an attempt to distinguish the terms "transparent proxy" and "transparent cache" by classifying them as "network transparent proxy". Apparently this term is still quite controversial since it doesn't really reflect the semantics of this mechanism. We are actively seeking help in creating a term and clarifying it unambiguously per the IESG review. Gary From owner-wrec@cs.utk.edu Wed Jan 5 16:52:54 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16579 for ; Wed, 5 Jan 2000 16:52:53 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id QAA12863; Wed, 5 Jan 2000 16:43:27 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 16:43:27 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id QAA12841; Wed, 5 Jan 2000 16:43:25 -0500 (EST) Received: from mail-gw.hursley.ibm.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id QAA12824; Wed, 5 Jan 2000 16:43:21 -0500 (EST) Received: from mail-gw.hursley.ibm.com (194.196.110.15 -> mail-gw.hursley.ibm.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 16:43:22 -0500 Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id VAA26094; Wed, 5 Jan 2000 21:42:45 GMT Received: from hursley.ibm.com (gsine04.us.sine.ibm.com [9.14.6.44]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id VAA11958; Wed, 5 Jan 2000 21:42:39 GMT Message-ID: <3873BAA5.8C225DE0@hursley.ibm.com> Date: Wed, 05 Jan 2000 15:41:57 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: mcmanus@appliedtheory.com CC: John Martin , wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy References: <200001052021.PAA01041@justice.atc-bos.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Patrick McManus wrote: ... > What I'd like from the IAB is some support in finishing up the > book-keeping of the taxonomy I've made some direct suggestions to [some of] the taxonomy authors and I hope anyone with issues will do the same. > ...and an endorsement of work on some > *protocols* to address these problems of resource discovery I can't speak for everybody but I think that this is an absolutely key area. However, IAB/IESG don't endorse generalities; there would have to be a fairly concrete work plan. BTW an idea that came up a while back - don't recall from who - was this: A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analagous to the MX record would be of benefit. > ...so that we > don't have to deploy switches that can read packets at optical line > speeds just so caches can be effectively utilized. Absolutely Brian From owner-wrec@cs.utk.edu Wed Jan 5 17:10:54 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16862 for ; Wed, 5 Jan 2000 17:10:53 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA14373; Wed, 5 Jan 2000 17:02:29 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 17:02:29 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA14355; Wed, 5 Jan 2000 17:02:28 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA14339; Wed, 5 Jan 2000 17:02:27 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 17:02:27 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id QAA10628; Wed, 5 Jan 2000 16:59:29 -0500 (EST) Message-Id: <200001052159.QAA10628@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: W.Sylwestrzak@icm.edu.pl cc: mcmanus@appliedtheory.com, fielding@ebuilt.com, jmartin@netapp.com, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy In-reply-to: Your message of "Wed, 05 Jan 2000 22:16:00 +0100." <200001052116.WAA15049@burza.icm.edu.pl> Date: Wed, 05 Jan 2000 16:59:29 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: [followups trimmed] > The goal of the taxonomy draft was to document the current > practice, not to impose new definitions or artificial terminology > even if it seems more appropriate for a reason. then why were people defending use of that term in another document by citing the taxonomy draft? I think the primary goal of a taxonomy document should be to *establish* terminology so that everyone is using the same terms to mean the same thing in subsequent discussions and documents. i.e., to get everyone on the same page. Keith From owner-wrec@cs.utk.edu Wed Jan 5 17:24:20 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17028 for ; Wed, 5 Jan 2000 17:24:20 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA15294; Wed, 5 Jan 2000 17:15:51 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 17:15:51 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA15276; Wed, 5 Jan 2000 17:15:50 -0500 (EST) Received: from atol.icm.edu.pl (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA15259; Wed, 5 Jan 2000 17:15:46 -0500 (EST) Received: from atol.icm.edu.pl (212.87.0.35 -> atol.icm.edu.pl) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 17:15:47 -0500 Received: from burza.icm.edu.pl ([148.81.208.198]:7660 "EHLO burza.icm.edu.pl") by atol.icm.edu.pl with ESMTP id ; Wed, 5 Jan 2000 23:15:25 +0100 Received: (from wojsyl@localhost) by burza.icm.edu.pl (8.9.3/8.9.3/rzm-2.6/icm) id XAA17776; Wed, 5 Jan 2000 23:13:30 +0100 (MET) From: Wojtek Sylwestrzak Message-Id: <200001052213.XAA17776@burza.icm.edu.pl> Subject: Re: definitions and use of "transparency" in the taxonomy In-Reply-To: <200001052159.QAA10628@astro.cs.utk.edu> from Keith Moore at "Jan 5, 2000 04:59:29 pm" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 5 Jan 2000 23:13:30 +0100 (MET) Cc: W.Sylwestrzak@icm.edu.pl, mcmanus@appliedtheory.com, fielding@ebuilt.com, jmartin@netapp.com, wrec@cs.utk.edu Organization: ICM, Warsaw University Address: Pawinskiego 5A, 02-106 Warszawa, Poland Reply-To: W.Sylwestrzak@icm.edu.pl X-PGP-Key-Fingerprint: AF C5 80 1C 7F EE 74 DB 5A F3 0B 54 AE 2F A4 99 X-Accept-Charset: ISO-8859-2 X-Mailer: ELM [version 2.4ME+ PL53 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit > [followups trimmed] > > > The goal of the taxonomy draft was to document the current > > practice, not to impose new definitions or artificial terminology > > even if it seems more appropriate for a reason. > > then why were people defending use of that term in another document > by citing the taxonomy draft? > > I think the primary goal of a taxonomy document should be > to *establish* terminology so that everyone is using the same terms > to mean the same thing in subsequent discussions and documents. > i.e., to get everyone on the same page. > > Keith > On the second thought, yes, the purpose is not just documenting for it's own sake (or for future historians), but in order to have a common understanding of the terminology as a basis for other works. And this controversy proves, that this is indeed needed. --w From owner-wrec@cs.utk.edu Wed Jan 5 21:17:28 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19510 for ; Wed, 5 Jan 2000 21:17:21 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA28542; Wed, 5 Jan 2000 21:12:35 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 21:12:35 -0500 Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id VAA28525; Wed, 5 Jan 2000 21:12:32 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 21:12:33 -0500 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id VAA11374 for dist-wrec@cs.utk.edu; Wed, 5 Jan 2000 21:10:51 -0500 (EST) Received: from thrintun.hactrn.net (marvin@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA15082; Wed, 5 Jan 2000 17:13:01 -0500 (EST) Received: from thrintun.hactrn.net (216.254.11.215 -> thrintun.hactrn.net) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 17:13:02 -0500 Received: from localhost ([127.0.0.1]:13 "EHLO hactrn.net" ident: "IDENT-NOT-QUERIED [port 13]") by thrintun.hactrn.net with ESMTP id <23196-5655>; Wed, 5 Jan 2000 17:12:47 -0500 To: Brian E Carpenter cc: mcmanus@appliedtheory.com, John Martin , wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy In-Reply-To: Message from Brian E Carpenter dated "Wed, 05 Jan 2000 17:06:13 EST" <3873BAA5.8C225DE0@hursley.ibm.com> References: <3873BAA5.8C225DE0@hursley.ibm.com> <200001052021.PAA01041@justice.atc-bos.com> Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII From: Rob Austein Message-Id: <20000105221253Z23196-5655+34@thrintun.hactrn.net> Date: Wed, 5 Jan 2000 17:12:47 -0500 List-Unsubscribe: Date: Wed, 5 Jan 2000 17:06:13 -0500 From: Brian E Carpenter BTW an idea that came up a while back - don't recall from who - was this: A possible conclusion is that even for non-store-and-forward protocols, a generic diversion mechanism analagous to the MX record would be of benefit. We have one. It's called the SRV RR. Your mileage may vary :). From owner-wrec@cs.utk.edu Wed Jan 5 21:17:38 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19530 for ; Wed, 5 Jan 2000 21:17:31 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA28568; Wed, 5 Jan 2000 21:12:45 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Wed, 5 Jan 2000 21:12:45 -0500 Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id VAA28552; Wed, 5 Jan 2000 21:12:44 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 21:12:44 -0500 Received: (from moore@localhost) by astro.cs.utk.edu (cf 8.9.3) id VAA11389 for dist-wrec@cs.utk.edu; Wed, 5 Jan 2000 21:11:03 -0500 (EST) Received: from riddler.ebuilt.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA14542; Wed, 5 Jan 2000 17:04:39 -0500 (EST) From: Received: from riddler.ebuilt.net (216.237.34.34 -> 34.34.237.216.globalpac.com) by CS.UTK.EDU (smtpshim v1.0); Wed, 5 Jan 2000 17:04:39 -0500 To: W.Sylwestrzak@icm.edu.pl Cc: iab@ietf.org, iesg@ietf.org, jmartin@netapp.com, mcmanus@appliedtheory.com, wrec@cs.utk.edu Subject: Re: definitions and use of "transparency" in the taxonomy X-Mailer: Lotus Notes Release 5.0.1b September 30, 1999 Message-ID: Date: Wed, 5 Jan 2000 14:10:10 -0800 X-MIMETrack: Serialize by Router on riddler/Ebuilt(Release 5.0.2a |November 23, 1999) at 01/05/2000 02:09:50 PM, Serialize complete at 01/05/2000 02:09:50 PM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" List-Unsubscribe: >Exactly. Like it or not, this *is* the term in common use >and *this is* how the vocabulary gets (re)defined. It is fundamentally impossible for me to use these terms within any protocol that requires consistency in requirements, which pretty much covers anything I'd care to write for the IETF. They are self-contradictory. >The goal of the taxonomy draft was to document the current >practice, not to impose new definitions or artificial terminology >even if it seems more appropriate for a reason. Was that the goal, or the task at hand? It seems to me that the fundamental goal is to produce a document that is useful for the Internet community. If the taxonomy produced cannot be used, then it is better not to produce it at all and let the ugly terminology be replaced as ephemera. This is all very confusing to me. A taxonomy is, by definition, a classification in order to create a standard terminology. And yet this one is just supposed to document current practice? ........................................................... Roy T. Fielding, Chief Scientist fielding@ebuilt.com eBuilt, Inc. tel:+1.949.609.0000 9401 Jeronimo Rd., Suite 100 fax:+1.949.609.0001 Irvine, CA 92618 USA http://www.eBuilt.com ........................................................... From owner-wrec@cs.utk.edu Thu Jan 6 10:03:32 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13915 for ; Thu, 6 Jan 2000 10:03:32 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id JAA10051; Thu, 6 Jan 2000 09:58:14 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 6 Jan 2000 09:58:14 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id JAA10031; Thu, 6 Jan 2000 09:58:14 -0500 (EST) Received: from mail-gw.hursley.ibm.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id JAA10007; Thu, 6 Jan 2000 09:58:05 -0500 (EST) Received: from mail-gw.hursley.ibm.com (194.196.110.15 -> mail-gw.hursley.ibm.com) by CS.UTK.EDU (smtpshim v1.0); Thu, 6 Jan 2000 09:58:06 -0500 Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id OAA43486; Thu, 6 Jan 2000 14:57:24 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id OAA19964; Thu, 6 Jan 2000 14:57:21 GMT Message-ID: <3874ADCB.580385D1@hursley.ibm.com> Date: Thu, 06 Jan 2000 08:59:23 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: Rob Austein CC: mcmanus@appliedtheory.com, John Martin , wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy References: <3873BAA5.8C225DE0@hursley.ibm.com> <200001052021.PAA01041@justice.atc-bos.com> <20000105221253Z23196-5655+34@thrintun.hactrn.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit It was pointed out by Erik Nordmark that SRV doesn't allow arbitrary wild cards: > I think there is one "bug": In section 3.6 you are saying that > SRV records can achieve a diversion mechanism similar to MX records. > I don't think that is the case since it would require non-terminal wildcards as > in > _ftp._tcp.*.example.com > to do a diversion akin to MX records - such things are not allowed in the DNS. > Brian Rob Austein wrote: > > Date: Wed, 5 Jan 2000 17:06:13 -0500 > From: Brian E Carpenter > > BTW an idea that came up a while back - don't recall from who - > was this: > A possible conclusion is that even for > non-store-and-forward protocols, a generic diversion mechanism > analagous to the MX record would be of benefit. > > We have one. It's called the SRV RR. Your mileage may vary :). -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Brian E Carpenter (IAB Chair) Program Director, Internet Standards & Technology, IBM On assignment for IBM at http://www.iCAIR.org Attend INET 2000: http://www.isoc.org/inet2000 Non-IBM email: brian@icair.org From owner-wrec@cs.utk.edu Thu Jan 6 12:33:57 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17561 for ; Thu, 6 Jan 2000 12:33:51 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id MAA20964; Thu, 6 Jan 2000 12:28:58 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 6 Jan 2000 12:28:58 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id MAA20946; Thu, 6 Jan 2000 12:28:57 -0500 (EST) Received: from nix.swip.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id MAA20930; Thu, 6 Jan 2000 12:28:54 -0500 (EST) Received: from nix.swip.net (192.71.220.2 -> nix.swip.net) by CS.UTK.EDU (smtpshim v1.0); Thu, 6 Jan 2000 12:28:54 -0500 Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id SAA27992; Thu, 6 Jan 2000 18:23:33 +0100 (MET) Date: Thu, 06 Jan 2000 18:23:24 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brian E Carpenter , Rob Austein cc: mcmanus@appliedtheory.com, John Martin , wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy Message-ID: <683519.3156171804@[192.168.111.25]> In-Reply-To: <3874ADCB.580385D1@hursley.ibm.com> X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2000-01-06 08.59 -0600, Brian E Carpenter wrote: > It was pointed out by Erik Nordmark that SRV doesn't allow arbitrary > wild cards: > >> I think there is one "bug": In section 3.6 you are saying that >> SRV records can achieve a diversion mechanism similar to MX records. >> I don't think that is the case since it would require non-terminal >> wildcards as in >> _ftp._tcp.*.example.com >> to do a diversion akin to MX records - such things are not allowed in >> the DNS. The MX wildcard doesn't work the way people think. It only matches if there is no other record with the same name, for example an A record or CNAME. It is also the case that the wildcard only works when the wildcard itself is the first label in the name, and not third like the example above for what one wants in SRVs. For operations with DNS in Sweden, I have only seen one place where MX wildcards really work, and that is when you have a domain which is not at all connected to the Internet, and mail is going for that domain (and sub-domains) via UUCP or such non-internet protocols. THEN one can create the wildcard MX. In all other cases, you can get so confused by the matching rules between wildcard in MX and other RR types that I always recommend people to if nothing else generate the resource records they need. I.e. what one wants (normally) is to have all mail to all subdomains to a parent domain go to the same host. You don't want arbitrary tokens (also non-existing subdomains) to go to the mail host, because the error to the sender of the email might be confusing, and not reflect the existence of the subdomain or not. So, yes, wildcards are somewhat useful, but MX wildcards doesn't work well, and no, we don't have wildcards for SRV records, BUT one can quite easilly generate all RR one need in the scripts one have anyways(?) to keep the zones together. I.e. this doesn't need to be a function of DNS, but the tool one uses to keep the zone up to date. paf From owner-wrec@cs.utk.edu Thu Jan 6 13:29:46 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19024 for ; Thu, 6 Jan 2000 13:29:43 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA26401; Thu, 6 Jan 2000 13:24:42 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 6 Jan 2000 13:24:42 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id NAA26383; Thu, 6 Jan 2000 13:24:42 -0500 (EST) Received: from mauve.innosoft.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA26315; Thu, 6 Jan 2000 13:24:18 -0500 (EST) From: Received: from mauve.innosoft.com (192.160.253.247 -> mauve.innosoft.com.253.160.192.IN-ADDR.ARPA) by CS.UTK.EDU (smtpshim v1.0); Thu, 6 Jan 2000 13:24:23 -0500 Received: from MAUVE.INNOSOFT.COM by MAUVE.INNOSOFT.COM (PMDF V6.0-17 #35243) id <01JKDLROXQNK00008R@MAUVE.INNOSOFT.COM> for wrec@cs.utk.edu; Thu, 06 Jan 2000 10:24:06 -0800 (PST) Date: Thu, 06 Jan 2000 10:09:23 -0800 (PST) Subject: Re: definitions and use of "transparency" in the taxonomy In-reply-to: "Your message dated Thu, 06 Jan 2000 18:23:24 +0100" <683519.3156171804@[192.168.111.25]> To: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= Cc: Brian E Carpenter , Rob Austein , mcmanus@appliedtheory.com, John Martin , wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Message-id: <01JKDQ5JH9YG00008R@MAUVE.INNOSOFT.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii References: <3874ADCB.580385D1@hursley.ibm.com> List-Unsubscribe: > > I think there is one "bug": In section 3.6 you are saying that > > SRV records can achieve a diversion mechanism similar to MX records. > > I don't think that is the case since it would require non-terminal > > wildcards as in > > _ftp._tcp.*.example.com > > to do a diversion akin to MX records - such things are not allowed in > > the DNS. > The MX wildcard doesn't work the way people think. It only matches if there > is no other record with the same name, for example an A record or CNAME. It > is also the case that the wildcard only works when the wildcard itself is > the first label in the name, and not third like the example above for what > one wants in SRVs. The way I've dealt with this for MX records is to use a preprocessor to generate the database for the domain. The preprocessor has rules that tell it when *.foo.com is specified and a.foo.com appears as an A or CNAME without its own MX to add an explicit MX entry for a.foo.com that duplicates the wildcard entry's value. It is a reasonably straightforward thing to do. And besides, you want to run your tables through a preprocessor to make sure there are PTR records for all the A records and similar boring stuff. I see no reason why a similar preprocessor could not be used to generate the necessary SRV records so that wildcard SRV records appear to work. > For operations with DNS in Sweden, I have only seen one place where MX > wildcards really work, and that is when you have a domain which is not at > all connected to the Internet, and mail is going for that domain (and > sub-domains) via UUCP or such non-internet protocols. THEN one can create > the wildcard MX. In all other cases, you can get so confused by the > matching rules between wildcard in MX and other RR types that I always > recommend people to if nothing else generate the resource records they need. FWIW, one place where we've found simple wildcard MX entries to be quite useful is to map the subdomains of a given system's name back onto itself. We routinely use such subdomains to provide various special email services (gateways to other mail systems, for example), and since this segment of the namespace never has A records in it that correspond to these service names we don't have a problem with the limited scope of MX wildcards. And perhaps more to the point, it saves us having to mess with the DNS every time one of these services gets defined. This can be a big win, especially when dealing with a site where the DNS stuff is managed by different people than the mail systems and the DNS people are, shall we say, less than responsive to change requests. > I.e. what one wants (normally) is to have all mail to all subdomains to a > parent domain go to the same host. You don't want arbitrary tokens (also > non-existing subdomains) to go to the mail host, because the error to the > sender of the email might be confusing, and not reflect the existence of > the subdomain or not. > So, yes, wildcards are somewhat useful, but MX wildcards doesn't work well, > and no, we don't have wildcards for SRV records, BUT one can quite easilly > generate all RR one need in the scripts one have anyways(?) to keep the > zones together. I.e. this doesn't need to be a function of DNS, but the > tool one uses to keep the zone up to date. Exactly. And not only is generating explicit entries of this sort fairly simple, it keeps a bunch of wildcard handling complexity out of the DNS server itself. And that I view as a Good Thing -- we're well past the point where all the extra entries you end up with as a result of this are significant, whereas the deployment costs of bug fixes for broken wildcard handling code grow more significant every day. Ned From owner-wrec@cs.utk.edu Thu Jan 6 17:33:16 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23698 for ; Thu, 6 Jan 2000 17:33:09 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id RAA16393; Thu, 6 Jan 2000 17:27:25 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 6 Jan 2000 17:27:25 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id RAA16367; Thu, 6 Jan 2000 17:27:24 -0500 (EST) Received: from mail-gw.hursley.ibm.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id RAA16345; Thu, 6 Jan 2000 17:27:21 -0500 (EST) Received: from mail-gw.hursley.ibm.com (194.196.110.15 -> mail-gw.hursley.ibm.com) by CS.UTK.EDU (smtpshim v1.0); Thu, 6 Jan 2000 17:27:21 -0500 Received: from sp3at21.hursley.ibm.com (sp3at21.hursley.ibm.com [9.20.45.21]) by mail-gw.hursley.ibm.com (AIX4.3/UCB 8.8.8/8.8.8) with ESMTP id WAA05538; Thu, 6 Jan 2000 22:26:32 GMT Received: from hursley.ibm.com (gsine02.us.sine.ibm.com [9.14.6.42]) by sp3at21.hursley.ibm.com (AIX4.2/UCB 8.7/8.7.3) with ESMTP id WAA26636; Thu, 6 Jan 2000 22:26:30 GMT Message-ID: <38751256.ECD68E51@hursley.ibm.com> Date: Thu, 06 Jan 2000 16:08:22 -0600 From: Brian E Carpenter Organization: IBM X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en,fr MIME-Version: 1.0 To: ned.freed@innosoft.com CC: wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy References: <3874ADCB.580385D1@hursley.ibm.com> <01JKDQ5JH9YG00008R@MAUVE.INNOSOFT.COM> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit So, for an ignoramus such as me, does that mean that an SRV record starting with _http. could be used to redirect HTTP in a clean way? Presumably, however, the WREC community needs finer granularity than that. Brian ned.freed@innosoft.com wrote: > > > > I think there is one "bug": In section 3.6 you are saying that > > > SRV records can achieve a diversion mechanism similar to MX records. > > > I don't think that is the case since it would require non-terminal > > > wildcards as in > > > > _ftp._tcp.*.example.com > > > > to do a diversion akin to MX records - such things are not allowed in > > > the DNS. > > > The MX wildcard doesn't work the way people think. It only matches if there > > is no other record with the same name, for example an A record or CNAME. It > > is also the case that the wildcard only works when the wildcard itself is > > the first label in the name, and not third like the example above for what > > one wants in SRVs. > > The way I've dealt with this for MX records is to use a preprocessor to > generate the database for the domain. The preprocessor has rules that tell it > when *.foo.com is specified and a.foo.com appears as an A or CNAME without its > own MX to add an explicit MX entry for a.foo.com that duplicates the wildcard > entry's value. It is a reasonably straightforward thing to do. And besides, you > want to run your tables through a preprocessor to make sure there are PTR > records for all the A records and similar boring stuff. > > I see no reason why a similar preprocessor could not be used to generate > the necessary SRV records so that wildcard SRV records appear to work. > > > For operations with DNS in Sweden, I have only seen one place where MX > > wildcards really work, and that is when you have a domain which is not at > > all connected to the Internet, and mail is going for that domain (and > > sub-domains) via UUCP or such non-internet protocols. THEN one can create > > the wildcard MX. In all other cases, you can get so confused by the > > matching rules between wildcard in MX and other RR types that I always > > recommend people to if nothing else generate the resource records they need. > > FWIW, one place where we've found simple wildcard MX entries to be quite useful > is to map the subdomains of a given system's name back onto itself. We > routinely use such subdomains to provide various special email services > (gateways to other mail systems, for example), and since this segment of the > namespace never has A records in it that correspond to these service names we > don't have a problem with the limited scope of MX wildcards. And perhaps more > to the point, it saves us having to mess with the DNS every time one of these > services gets defined. This can be a big win, especially when dealing with a > site where the DNS stuff is managed by different people than the mail systems > and the DNS people are, shall we say, less than responsive to change requests. > > > I.e. what one wants (normally) is to have all mail to all subdomains to a > > parent domain go to the same host. You don't want arbitrary tokens (also > > non-existing subdomains) to go to the mail host, because the error to the > > sender of the email might be confusing, and not reflect the existence of > > the subdomain or not. > > > So, yes, wildcards are somewhat useful, but MX wildcards doesn't work well, > > and no, we don't have wildcards for SRV records, BUT one can quite easilly > > generate all RR one need in the scripts one have anyways(?) to keep the > > zones together. I.e. this doesn't need to be a function of DNS, but the > > tool one uses to keep the zone up to date. > > Exactly. And not only is generating explicit entries of this sort fairly > simple, it keeps a bunch of wildcard handling complexity out of the DNS server > itself. And that I view as a Good Thing -- we're well past the point where all > the extra entries you end up with as a result of this are significant, whereas > the deployment costs of bug fixes for broken wildcard handling code grow > more significant every day. > > Ned From owner-wrec@cs.utk.edu Thu Jan 6 18:06:13 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24562 for ; Thu, 6 Jan 2000 18:06:07 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id SAA18737; Thu, 6 Jan 2000 18:01:00 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 6 Jan 2000 18:01:00 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id SAA18719; Thu, 6 Jan 2000 18:00:59 -0500 (EST) Received: from astro.cs.utk.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id SAA18703; Thu, 6 Jan 2000 18:00:58 -0500 (EST) Received: from astro.cs.utk.edu (128.169.93.168 -> ASTRO.CS.UTK.EDU) by CS.UTK.EDU (smtpshim v1.0); Thu, 6 Jan 2000 18:00:58 -0500 Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id RAA01666; Thu, 6 Jan 2000 17:59:03 -0500 (EST) Message-Id: <200001062259.RAA01666@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brian E Carpenter cc: ned.freed@innosoft.com, wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy In-reply-to: Your message of "Thu, 06 Jan 2000 16:08:22 CST." <38751256.ECD68E51@hursley.ibm.com> Date: Thu, 06 Jan 2000 17:59:02 -0500 Sender: moore@cs.utk.edu List-Unsubscribe: > So, for an ignoramus such as me, does that mean that an SRV record > starting with _http. could be used to redirect HTTP in a clean way? yes. > Presumably, however, the WREC community needs finer granularity than that. the NAPTR record was designed with this in mind, and to dovetail with SRV. So you can use SRV if just coarse granularity is needed and you can use SRV+NAPTR if you need fine granularity. fleshing out the details of how to find information about URLs - including perhaps the location of replicas - is arguably within the scope of the rescap group. though rescap is just supposed to develop the mechanism, not the schemas. so the development of a schema for describing replicated web sites/pages should be done in WREC. Keith From owner-wrec@cs.utk.edu Fri Jan 7 02:15:00 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12138 for ; Fri, 7 Jan 2000 02:15:00 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA16074; Fri, 7 Jan 2000 02:10:35 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Fri, 7 Jan 2000 02:10:35 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id CAA16056; Fri, 7 Jan 2000 02:10:35 -0500 (EST) Received: from nix.swip.net (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id CAA16043; Fri, 7 Jan 2000 02:10:32 -0500 (EST) Received: from nix.swip.net (192.71.220.2 -> nix.swip.net) by CS.UTK.EDU (smtpshim v1.0); Fri, 7 Jan 2000 02:10:32 -0500 Received: from 192.168.111.25 (workstation1.swip.net [130.244.254.1]) by nix.swip.net (8.8.8/8.8.8) with ESMTP id IAA13076; Fri, 7 Jan 2000 08:08:42 +0100 (MET) Date: Fri, 07 Jan 2000 08:08:41 +0100 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= To: Brian E Carpenter , ned.freed@innosoft.com cc: wrec@cs.utk.edu, iesg@ietf.org, iab@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy Message-ID: <1162435.3156221321@[192.168.111.25]> In-Reply-To: <38751256.ECD68E51@hursley.ibm.com> X-Mailer: Mulberry (MacOS) [2.0.0b7, s/n U-301169] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline List-Unsubscribe: Content-Transfer-Encoding: 7bit --On 2000-01-06 16.08 -0600, Brian E Carpenter wrote: > So, for an ignoramus such as me, does that mean that an SRV record > starting with _http. could be used to redirect HTTP in a clean way? Yes, but not with wildcards, and only after someone have written a paper on how it really should work. I.e. HTTP usage is quite complicated already if you start with a URI. The paper can be quite short though...is my guess. paf From owner-wrec@cs.utk.edu Sun Jan 9 21:27:58 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11796 for ; Sun, 9 Jan 2000 21:27:58 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA28740; Sun, 9 Jan 2000 21:20:02 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sun, 9 Jan 2000 21:20:02 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id VAA28722; Sun, 9 Jan 2000 21:20:01 -0500 (EST) Received: from mailman.cs.ucla.edu (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id VAA28700; Sun, 9 Jan 2000 21:19:58 -0500 (EST) Received: from mailman.cs.ucla.edu (131.179.128.30 -> Mailman.CS.UCLA.EDU) by CS.UTK.EDU (smtpshim v1.0); Sun, 9 Jan 2000 21:19:59 -0500 Received: from mordred.cs.ucla.edu (mordred.cs.ucla.edu [131.179.192.128]) by mailman.cs.ucla.edu (8.9.1/UCLACS-5.0) with ESMTP id SAA25905; Sun, 9 Jan 2000 18:20:57 -0800 (PST) Received: from cs.ucla.edu (localhost.cs.ucla.edu [127.0.0.1]) by mordred.cs.ucla.edu (8.9.3/UCLACS-5.0) with ESMTP id SAA09035; Sun, 9 Jan 2000 18:19:45 -0800 (PST) Sender: scottm@CS.UCLA.EDU Message-ID: <387941C0.5B9C0BF@cs.ucla.edu> Date: Sun, 09 Jan 2000 18:19:44 -0800 From: "B. Scott Michel" Organization: UCLA Computer Chaos X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.4-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: Gary Tomlinson CC: wrec@cs.utk.edu, iesg@ietf.org Subject: Re: definitions and use of "transparency" in the taxonomy References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Marketdroids aside (an unfortunately necessary evil in these dark times), perhaps the draft might contrive another term and mention that it is AKA "transparent cache" and "transparent proxy". This would allow us to define a more precise term that doesn't conflict with the established standards and yet allows even the marketdroids to translate to tech. Just my $0.02. -scooter (who still feels rather partisan about "transparent" anythings... :-) Gary Tomlinson wrote: > > >>> 01/05/00 12:39PM >>> > > ... excerpt > > > I don't buy the argument that "transparent proxy" is the common term > > for this in the industry. I am in this industry and yet I have never > > heard that term used outside a wrec-related discussion, aside from its > > use to indicate a non-transforming proxy of HTTP content within RFC 2616. > > Given that the definition conflicts with that of "proxy" under HTTP and > > therefore conflicts with the HTTP protocol requirements placed on a > > proxy, I think it is foolish to use this term within specifications > > that are supposed to be subsidiary to the HTTP standard. It therefore > > doesn't make sense for an IETF RFC to recommend that it be used within > > the taxonomy. > > Albeit HTTP is a major protocol in the web, but its not the only one. The WREC > taxonomy covers the broader web including other protocols such as FTP, WCCP, NECP, > ICP, etc. In fact, there are even streaming media caches now, so the web is getting more > comprehensive everyday. Given this broader scope, I don't see how the taxonomy can be > subiduary to RFC2616. However, I agree that terms should not be invented that conflict with > existing terminology, especially those in RFC2616. We have made an attempt to distinguish > the terms "transparent proxy" and "transparent cache" by classifying them as "network > transparent proxy". Apparently this term is still quite controversial since it doesn't really > reflect the semantics of this mechanism. We are actively seeking help in creating a > term and clarifying it unambiguously per the IESG review. > > Gary -- Scott Michel | UCLA Computer Science | PhD Graduate Student | Futuaris nisi irrisus ridebis From owner-wrec@cs.utk.edu Sun Jan 9 22:01:31 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12963 for ; Sun, 9 Jan 2000 22:01:30 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id VAA00359; Sun, 9 Jan 2000 21:57:04 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sun, 9 Jan 2000 21:57:03 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id VAA00341; Sun, 9 Jan 2000 21:57:03 -0500 (EST) Received: from mailhost.iprg.nokia.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id VAA00328; Sun, 9 Jan 2000 21:57:00 -0500 (EST) Received: from mailhost.iprg.nokia.com (205.226.5.12 -> mailhost.iprg.nokia.com) by CS.UTK.EDU (smtpshim v1.0); Sun, 9 Jan 2000 21:57:01 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id SAA01060 for ; Sun, 9 Jan 2000 18:56:58 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id SAA00404 for webrepl@cs.utk.edu; Sun, 9 Jan 2000 18:56:58 -0800 (PST) Date: Sun, 9 Jan 2000 18:56:58 -0800 (PST) Message-Id: <200001100256.SAA00404@aspen.iprg.nokia.com> To: webrepl@cs.utk.edu Subject: INFOCOM 2000 Call For Participation List-Unsubscribe: CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies Download the complete advanced program http://www.comnet.technion.ac.il/infocom2000/infocom00apv7.pdf IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (only two more weeks to go) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-wrec@cs.utk.edu Mon Jan 17 13:21:15 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05132 for ; Mon, 17 Jan 2000 13:21:14 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id NAA25509; Mon, 17 Jan 2000 13:15:38 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Mon, 17 Jan 2000 13:15:38 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id NAA25490; Mon, 17 Jan 2000 13:15:37 -0500 (EST) Received: from mailhost.iprg.nokia.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id NAA25477; Mon, 17 Jan 2000 13:15:29 -0500 (EST) Received: from mailhost.iprg.nokia.com (205.226.5.12 -> mailhost.iprg.nokia.com) by CS.UTK.EDU (smtpshim v1.0); Mon, 17 Jan 2000 13:15:30 -0500 Received: from vienna.iprg.nokia.com (vienna.iprg.nokia.com [205.226.11.35]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id KAA23745 for ; Mon, 17 Jan 2000 10:15:27 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by vienna.iprg.nokia.com (8.8.8/8.6.12) id KAA04422 for webrepl@cs.utk.edu; Mon, 17 Jan 2000 10:15:27 -0800 (PST) Date: Mon, 17 Jan 2000 10:15:27 -0800 (PST) Message-Id: <200001171815.KAA04422@vienna.iprg.nokia.com> To: webrepl@cs.utk.edu Subject: INFOCOM 2000 Call For Participation List-Unsubscribe: CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (only ONE more week to go) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-wrec@cs.utk.edu Fri Jan 21 19:06:24 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19198 for ; Fri, 21 Jan 2000 19:06:24 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id TAA02106; Fri, 21 Jan 2000 19:01:33 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Fri, 21 Jan 2000 19:01:33 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id TAA02088; Fri, 21 Jan 2000 19:01:32 -0500 (EST) Received: from mail1.giga.net.tw (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id TAA02065; Fri, 21 Jan 2000 19:01:17 -0500 (EST) Received: from mail1.giga.net.tw (203.133.1.12 -> mdns1.giga.net.tw) by CS.UTK.EDU (smtpshim v1.0); Fri, 21 Jan 2000 19:01:18 -0500 Received: from cs.nchu.edu.tw ([203.133.42.141]) by mail1.giga.net.tw with Microsoft SMTPSVC(5.5.1877.197.19); Sat, 22 Jan 2000 08:00:58 +0800 Message-ID: <3888F389.D1ACEBA7@cs.nchu.edu.tw> Date: Sat, 22 Jan 2000 08:02:17 +0800 From: Wen-Shyen Eric Chen Organization: Institute of Computer Science, National Chung-Hsing University X-Mailer: Mozilla 4.7 [en]C-CCK-MCD (Win98; I) X-Accept-Language: zh-TW,en MIME-Version: 1.0 To: webrepl@cs.utk.edu, isp-caching@isp-caching.com CC: Haruhisa Ichikawa Subject: Call for Papaers: (SAINT2001) The 2001 Symposium on Applications and the Internet Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear Colleagues: I would be most grateful if you could help distribute the attached Call For Papers for a new conference about applications and the Internet. My apology if you receive multiple copies of the CFPs. Thank you. ---Wen-Shyen Eric Chen ==================================================================== Call for Papers and Participation The 2001 Symposium on Applications and the Internet SAINT-2001 http://computer.org/tab/TCI/SAINT/ http://www.ipsj.or.jp/kokusai/saint.htm (mirror site) San Diego, California, USA, January 8-12, 2001 This conference provides a forum for engineers and scientists in academia, industry, and government to present their latest findings in the area of Internet applications and the underlying technologies to support those applications. Areas of particular interest include, but anot limited to: - Agents and the Internet - Collaboration Technology - Digital Libraries - Distributed & Parallel Applications - Domain Specific Languages - E-Commerce - Internet Services - Mobile Computing - Multimedia Technology Tutorial & Workshops -------------------- Tutorial and workshops related to Internet technologies and applications will be held during the conference. Tutorials and workshops proposals should be submitted to Tutorial Chair Prof. Sumi Helal (helal@cisc.ufl.edu) and Workshops Chair Dr. Shiro Sakata (sakata@hml.cl.nec.co.jp), respectively, by March 1, 2000. Paper Submission ---------------- Form of Manuscript: Not to exceed 25 double-spaced, 8.5x11-inch pages (including figures, tables and regerences) in 10-12 point font. Number each page, include an abstract, five to ten keywords, and the technical area(s) most relevant to your pape, and the corresponding author's e-mail address. Subnmission: All submissions will be done electronically. To submit a paper, go to http:www.computer.org/tab/TCI/SAINT/submit and follow the instructions. Important Deadlines ------------------- Tutorial Proposals: March 1, 2000 Workshop Proposals: March 1, 2000 Paper Submission: May 1, 2000 Author Notification: August 15, 2000 Final Manuscript: October 1, 2000 Proceedings ----------- The Proceedings of the conference and the workshops will be published by the IEEE Computer Society Press. Organizing & Program Committees ------------------------------- General Co-Chairs Ming T. Liu, The Ohio State Univ., USA Iwao Toda, Fujitsu Labs, Japan Program Co-Chairs Fred Douglis, AT&T Labs-Research, USA Katsuo Ikeda, Kyoto Univ., Japan For Further Information, Please Contact --------------------------------------- Mike Liu, The Ohio State University, Dept. of CIS, Columbus, OH43210-1277, USA Phone: +1-614-292-6552; Fax: +1-614-292-2911; E-mail: mike.liu@osu.edu or see the conference home page: http://computer.org/tab/TCI/SAINT/ ==================================================================== From owner-wrec@cs.utk.edu Sun Jan 23 19:05:48 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12618 for ; Sun, 23 Jan 2000 19:05:47 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id TAA19705; Sun, 23 Jan 2000 19:01:05 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Sun, 23 Jan 2000 19:01:05 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id TAA19686; Sun, 23 Jan 2000 19:01:04 -0500 (EST) Received: from mailhost.iprg.nokia.com (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id TAA19672; Sun, 23 Jan 2000 19:01:01 -0500 (EST) Received: from mailhost.iprg.nokia.com (205.226.5.12 -> mailhost.iprg.nokia.com) by CS.UTK.EDU (smtpshim v1.0); Sun, 23 Jan 2000 19:01:02 -0500 Received: from aspen.iprg.nokia.com ([205.226.14.73]) by mailhost.iprg.nokia.com (8.8.8/8.6.10) with ESMTP id QAA01627 for ; Sun, 23 Jan 2000 16:00:59 -0800 (PST) From: Fred Bauer Received: (fred@localhost) by aspen.iprg.nokia.com (8.8.8/8.6.12) id QAA00407 for webrepl@cs.utk.edu; Sun, 23 Jan 2000 16:00:58 -0800 (PST) Date: Sun, 23 Jan 2000 16:00:58 -0800 (PST) Message-Id: <200001240000.QAA00407@aspen.iprg.nokia.com> To: webrepl@cs.utk.edu Subject: INFOCOM 2000: LAST DAY for special-rate hotel reservation List-Unsubscribe: >>>>> LAST DAY for special-rate hotel reservation - INFOCOM 2000 <<<<< CALL FOR PARTICIPATION ------------------------ IEEE Infocom 2000 (Israel) http://www.comnet.technion.ac.il/infocom2000 (U.S.A.) http://www.cse.ucsc.edu/~rom/infocom2000 (Japan) http://halo.kuamp.kyoto-u.ac.jp/~infocom Dan Panorama Hotel, Tel Aviv, Israel March 26-30, 2000 Sponsored by the IEEE Communications and Computer Societies IMPORTANT DATES =============== Cut-off dates for special lower rates: Hotel reservation cut-off date* January 24, 2000 (LAST DAY!) Early registration cut-off date February 28, 2000 Infocom 2000 dates: Tutorials March 26-27, 2000 Conference March 28-30, 2000 * Israel is expected to be crowded with tourists during the year 2000. Furthermore, the Pope is scheduled to visit Israel the week before the conference. Hence, it is advised to make HOTEL and FLIGHT reservations for the conference as soon as possible. HOTEL RATES =========== Double Occupancy $157.50 Single Occupancy $139.00 Rates are per room per night and include full Israeli buffet breakfast. The rates also include all taxes for non-israelis. For more details consult the web pages. http://www.comnet.technion.ac.il/infocom2000/reservation.html REGISTRATION FEES ================= Registration fees for an IEEE member prior to February 28, 2000 will be $500 and it will include all technical sessions, open receptions, proceedings (CD) and three lunches. For other fees consult the web pages. ------------- On-line registration: https://secure.computer.org/conf/infocom/register.htm VENUE ===== For the last 18 years, Infocom has been the major conference on computer communications and networking, bringing together researchers and implementors of every aspect of data communications and networks presenting the most up-to-date results and achievements in the field. The 19th annual conference on Computer Communications, Infocom 2000, will be held at the Dan Panorama Hotel in Tel-Aviv, Israel, during the week of March 26-30, 2000. Overlooking the Mediterranean, the Dan Panorama Tel Aviv is a city hotel in a resort setting. Just a few steps away are fine shops, theaters, restaurants and the corporate world of Tel Aviv, contrasted by the ancient port city of Jaffa with its picturesque corners and flea markets for bargain hunters. The hotel features a large swimming pool, beach access and a fully equipped health & fitness center. SCOPE ===== Original papers and panel discussions describing state-of-the-art research and development in all areas of computer networking and data communications will be presented. Browse the excellent technical program and see the papers at http://www.comnet.technion.ac.il/infocom2000/program.html KEYNOTE SPEAKER =============== Prof. Leonard Kleinrock, Chairman, Nomadix, Inc. Keynote title: Nomadic Computing and Smart Spaces http://www.comnet.technion.ac.il/infocom2000/key.html TUTORIALS ========= Full Day -------- - Wavelength-routing optical networks (Kumar Sivarajan, Indian Institute of Science) - The evolution of QoS in the Internet standards community (Jon Crowcroft, University College London) - Overview of network security (Radia Perlman, Sun Microsystems) - Teletraffic Models and Tools: From Basics to Advanced(Khosrow Sohraby, University of Missouri, Kansas City) - IP Multicast: past, present and future (Radia Perlman, Sun Microsystems & Christophe Diot, Sprint) Half Day -------- - MPLS (Loa Andersson, Nortel Networks) - New technologies for LAN systems (Dono Van-Mierop, IBM Israel) - Satellite IP networking (Catherine Rosenberg, Purdue University) - Mobile IP: adding mobility to the Internet (Charles Perkins, Nokia Research) http://www.comnet.technion.ac.il/infocom2000/tutorial.html QUESTIONS? =========================== Write to infocom@comnet.technion.ac.il] From owner-wrec@cs.utk.edu Thu Jan 27 02:57:04 2000 Received: from CS.UTK.EDU (CS.UTK.EDU [128.169.94.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01236 for ; Thu, 27 Jan 2000 02:57:04 -0500 (EST) Received: from localhost (daemon@localhost) by CS.UTK.EDU with SMTP (cf v2.9s-UTK) id CAA08958; Thu, 27 Jan 2000 02:52:32 -0500 (EST) Received: by CS.UTK.EDU (bulk_mailer v1.12); Thu, 27 Jan 2000 02:52:32 -0500 Received: by CS.UTK.EDU (cf v2.9s-UTK) id CAA08940; Thu, 27 Jan 2000 02:52:32 -0500 (EST) Received: from imc01.ex.nus.edu.sg (marvin@localhost) by CS.UTK.EDU with ESMTP (cf v2.9s-UTK) id CAA08907; Thu, 27 Jan 2000 02:52:27 -0500 (EST) Received: from imc01.ex.nus.edu.sg (137.132.14.60 -> imc01.ex.nus.edu.sg) by CS.UTK.EDU (smtpshim v1.0); Thu, 27 Jan 2000 02:52:28 -0500 Received: by imc01.ex.nus.edu.sg with Internet Mail Service (5.5.2650.21) id ; Thu, 27 Jan 2000 15:49:15 +0800 Message-ID: From: P A Centre Visitor Subject: RE: IEEE ICON' 2000 Conference - Call for Papers, Tutorials ... Date: Thu, 27 Jan 2000 15:48:17 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" List-Unsubscribe: Dear All >The 8th IEEE International Conference On Networks will be held from >September 5- 8, 2000 in Singapore. ]The aim of the conference is to >provide >an international forum for experts to promote, share and discuss various >>issues and developments in the broad field of computer and communication networks. >>We thus seek and solicit your contributions >in the form of original/unpublished papers, tutorials, and topics for >special sessions/panel discussions. More information on the scope of the conference and the guidelines for the submission of contributions can >>>be obtained at this web site : http://www.comp.nus.edu.sg/~icon/ > >We look forward to your participation. Thank you. > >Icon 2000 organizing Committee Best Regards Catherine Kua (Mrs) ICON Secretariat c/o Professional Activities Centre Faculty of Engineering Tel: (65) 8745113 Fax: (65) 8745097 Email: engpac@nus.edu.sg