From rfc-editor at rfc-editor.org Sun Mar 11 16:39:47 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 11 Mar 2007 16:39:47 -0700 Subject: [rfc-dist] RFC 4766 on Intrusion Detection Message Exchange Requirements Message-ID: <200703112339.l2BNdlAP018408@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4766 Title: Intrusion Detection Message Exchange Requirements Author: M. Wood, M. Erlinger Status: Informational Date: March 2007 Mailbox: mark1 at iss.net, mike at cs.hmc.edu Pages: 25 Characters: 50816 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idwg-requirements-10.txt URL: http://www.rfc-editor.org/rfc/rfc4766.txt The purpose of the Intrusion Detection Exchange Format Working Group (IDWG) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes the high-level requirements for such a communication mechanism, including the rationale for those requirements where clarification is needed. Scenarios are used to illustrate some requirements. This memo provides information for the Internet community. This document is a product of the Intrusion Detection Exchange Format Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 11 16:40:06 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 11 Mar 2007 16:40:06 -0700 Subject: [rfc-dist] RFC 4805 on Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types Message-ID: <200703112340.l2BNe6M6018430@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4805 Title: Definitions of Managed Objects for the DS1, J1, E1, DS2, and E2 Interface Types Author: O. Nicklass, Ed. Status: Standards Track Date: March 2007 Mailbox: orly_n at rad.com Pages: 94 Characters: 189927 Obsoletes: RFC3895 See-Also: I-D Tag: draft-orly-atommib-rfc3895bis-01.txt URL: http://www.rfc-editor.org/rfc/rfc4805.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes objects used for managing DS1, J1, E1, DS2, and E2 interfaces. This document is a companion to the documents that define managed objects for the DS0, DS3/E3, and Synchronous Optical Network/Synchronous Digital Hierarchy (SONET/SDH) Interface Types. This document obsoletes RFC 3895. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 11 16:39:53 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 11 Mar 2007 16:39:53 -0700 Subject: [rfc-dist] RFC 4767 on The Intrusion Detection Exchange Protocol (IDXP) Message-ID: <200703112339.l2BNdrWi018413@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4767 Title: The Intrusion Detection Exchange Protocol (IDXP) Author: B. Feinstein, G. Matthews Status: Experimental Date: March 2007 Mailbox: bfeinstein at acm.org, gmatthew at nas.nasa.gov Pages: 28 Characters: 56048 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idwg-beep-idxp-07.txt URL: http://www.rfc-editor.org/rfc/rfc4767.txt This memo describes the Intrusion Detection Exchange Protocol (IDXP), an application-level protocol for exchanging data between intrusion detection entities. IDXP supports mutual-authentication, integrity, and confidentiality over a connection-oriented protocol. The protocol provides for the exchange of IDMEF messages, unstructured text, and binary data. The IDMEF message elements are described in RFC 4765, "The Intrusion Detection Message Exchange Format (IDMEF)", a companion document of the Intrusion Detection Exchange Format Working Group (IDWG) of the IETF. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Intrusion Detection Exchange Format Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 11 16:39:58 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 11 Mar 2007 16:39:58 -0700 Subject: [rfc-dist] RFC 4765 on The Intrusion Detection Message Exchange Format (IDMEF) Message-ID: <200703112339.l2BNdwn0018418@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4765 Title: The Intrusion Detection Message Exchange Format (IDMEF) Author: H. Debar, D. Curry, B. Feinstein Status: Experimental Date: March 2007 Mailbox: herve.debar at orange-ftgroup.com, david_a_curry at glic.com, feinstein at acm.org Pages: 157 Characters: 307966 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-idwg-idmef-xml-16.txt URL: http://www.rfc-editor.org/rfc/rfc4765.txt The purpose of the Intrusion Detection Message Exchange Format (IDMEF) is to define data formats and exchange procedures for sharing information of interest to intrusion detection and response systems and to the management systems that may need to interact with them. This document describes a data model to represent information exported by intrusion detection systems and explains the rationale for using this model. An implementation of the data model in the Extensible Markup Language (XML) is presented, an XML Document Type Definition is developed, and examples are provided. This memo defines an Experimental Protocol for the Internet community. This document is a product of the Intrusion Detection Exchange Format Working Group of the IETF. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 11 16:39:43 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 11 Mar 2007 16:39:43 -0700 Subject: [rfc-dist] RFC 4807 on IPsec Security Policy Database Configuration MIB Message-ID: <200703112339.l2BNdh67018403@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4807 Title: IPsec Security Policy Database Configuration MIB Author: M. Baer, R. Charlet, W. Hardaker, R. Story, C. Wang Status: Standards Track Date: March 2007 Mailbox: baerm at tislabs.com, rcharlet at alumni.calpoly.edu, hardaker at tislabs.com, rstory at ipsp.revelstone.com, cliffwangmail at yahoo.com Pages: 71 Characters: 136747 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ipsp-spd-mib-07.txt URL: http://www.rfc-editor.org/rfc/rfc4807.txt This document defines a Structure of Management Information Version 2 (SMIv2) Management Information Base (MIB) module for configuring the security policy database of a device implementing the IPsec protocol. The policy-based packet filtering and the corresponding execution of actions described in this document are of a more general nature than for IPsec configuration alone, such as for configuration of a firewall. This MIB module is designed to be extensible with other enterprise or standards-based defined packet filters and actions. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Mon Mar 12 16:55:14 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Mon, 12 Mar 2007 16:55:14 -0700 Subject: [rfc-dist] RFC 4819 on Secure Shell Public Key Subsystem Message-ID: <200703122355.l2CNtE7B023420@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4819 Title: Secure Shell Public Key Subsystem Author: J. Galbraith, J. Van Dyke, J. Bright Status: Standards Track Date: March 2007 Mailbox: galb at vandyke.com, jpv at vandyke.com, jon at siliconcircus.com Pages: 17 Characters: 32794 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-secsh-publickey-subsystem-08.txt URL: http://www.rfc-editor.org/rfc/rfc4819.txt Secure Shell defines a user authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. The Public Key Subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. A public key may also be associated with various restrictions, including a mandatory command or subsystem. [STANDARDS TRACK] This document is a product of the Secure Shell Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 15 14:51:26 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 15 Mar 2007 14:51:26 -0700 Subject: [rfc-dist] RFC 4791 on Calendaring Extensions to WebDAV (CalDAV) Message-ID: <200703152151.l2FLpQPj009953@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4791 Title: Calendaring Extensions to WebDAV (CalDAV) Author: C. Daboo, B. Desruisseaux, L. Dusseault Status: Standards Track Date: March 2007 Mailbox: cyrus at daboo.name, bernard.desruisseaux at oracle.com, ldusseault at commerce.net Pages: 107 Characters: 206801 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-dusseault-caldav-15.txt URL: http://www.rfc-editor.org/rfc/rfc4791.txt This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 15 14:51:18 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 15 Mar 2007 14:51:18 -0700 Subject: [rfc-dist] RFC 4790 on Internet Application Protocol Collation Registry Message-ID: <200703152151.l2FLpIuM009948@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4790 Title: Internet Application Protocol Collation Registry Author: C. Newman, M. Duerst, A. Gulbrandsen Status: Standards Track Date: March 2007 Mailbox: chris.newman at sun.com, duerst at it.aoyama.ac.jp, arnt at oryx.com Pages: 26 Characters: 55591 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-newman-i18n-comparator-14.txt URL: http://www.rfc-editor.org/rfc/rfc4790.txt Many Internet application protocols include string-based lookup, searching, or sorting operations. However, the problem space for searching and sorting international strings is large, not fully explored, and is outside the area of expertise for the Internet Engineering Task Force (IETF). Rather than attempt to solve such a large problem, this specification creates an abstraction framework so that application protocols can precisely identify a comparison function, and the repertoire of comparison functions can be extended in the future. [STANDARDS TRACK] This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 18 11:42:55 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 18 Mar 2007 11:42:55 -0700 Subject: [rfc-dist] RFC 3659 on Extensions to FTP Message-ID: <200703181842.l2IIgtkj013014@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 3659 Title: Extensions to FTP Author: P. Hethmon Status: Standards Track Date: March 2007 Mailbox: phethmon at hethmon.com Pages: 61 Characters: 137962 Updates: RFC0959 See-Also: I-D Tag: draft-ietf-ftpext-mlst-16.txt URL: http://www.rfc-editor.org/rfc/rfc3659.txt This document specifies new FTP commands to obtain listings of remote directories in a defined format, and to permit restarts of interrupted data transfers in STREAM mode. It allows character sets other than US-ASCII, and also defines an optional virtual file storage structure. [STANDARDS TRACK] This document is a product of the Extensions to FTP Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Sun Mar 18 11:43:25 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Sun, 18 Mar 2007 11:43:25 -0700 Subject: [rfc-dist] RFC 4808 on Key Change Strategies for TCP-MD5 Message-ID: <200703181843.l2IIhP8d013019@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4808 Title: Key Change Strategies for TCP-MD5 Author: S. Bellovin Status: Informational Date: March 2007 Mailbox: bellovin at acm.org Pages: 8 Characters: 14939 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-bellovin-keyroll2385-04.txt URL: http://www.rfc-editor.org/rfc/rfc4808.txt The TCP-MD5 option is most commonly used to secure BGP sessions between routers. However, changing the long-term key is difficult, since the change needs to be synchronized between different organizations. We describe single-ended strategies that will permit (mostly) unsynchronized key changes. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Mar 21 02:12:09 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 21 Mar 2007 02:12:09 -0700 Subject: [rfc-dist] RFC 4813 on OSPF Link-Local Signaling Message-ID: <200703210912.l2L9C9tW022615@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4813 Title: OSPF Link-Local Signaling Author: B. Friedman, L. Nguyen, A. Roy, D. Yeung, A. Zinin Status: Experimental Date: March 2007 Mailbox: friedman at cisco.com, lhnguyen at cisco.com, akr at cisco.com, myeung at cisco.com, alex.zinin at alcatel-lucent.com Pages: 10 Characters: 19687 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nguyen-ospf-lls-06.txt URL: http://www.rfc-editor.org/rfc/rfc4813.txt OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link. This memo defines an Experimental Protocol for the Internet community. EXPERIMENTAL: This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Mar 21 02:12:36 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 21 Mar 2007 02:12:36 -0700 Subject: [rfc-dist] RFC 4812 on OSPF Restart Signaling Message-ID: <200703210912.l2L9Ca68022620@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4812 Title: OSPF Restart Signaling Author: L. Nguyen, A. Roy, A. Zinin Status: Informational Date: March 2007 Mailbox: lhnguyen at cisco.com, akr at cisco.com, alex.zinin at alcatel-lucent.com Pages: 7 Characters: 12111 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nguyen-ospf-restart-06.txt URL: http://www.rfc-editor.org/rfc/rfc4812.txt OSPF is a link-state intra-domain routing protocol used in IP networks. Routers find new and detect unreachable neighbors via the Hello subprotocol. Hello OSPF packets are also used to ensure two-way connectivity within time. When a router restarts its OSPF software, it may not know its neighbors. If such a router sends a Hello packet on an interface, its neighbors are going to reset the adjacency, which may not be desirable in certain conditions. This memo describes a vendor-specific mechanism that allows OSPF routers to inform their neighbors about the restart process. Note that this mechanism requires support from neighboring routers. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Wed Mar 21 02:12:43 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Wed, 21 Mar 2007 02:12:43 -0700 Subject: [rfc-dist] RFC 4811 on OSPF Out-of-Band Link State Database (LSDB) Resynchronization Message-ID: <200703210912.l2L9Ch2D022625@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4811 Title: OSPF Out-of-Band Link State Database (LSDB) Resynchronization Author: L. Nguyen, A. Roy, A. Zinin Status: Informational Date: March 2007 Mailbox: lhnguyen at cisco.com, akr at cisco.com, alex.zinin at alcatel-lucent.com Pages: 10 Characters: 18976 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-nguyen-ospf-oob-resync-06.txt URL: http://www.rfc-editor.org/rfc/rfc4811.txt OSPF is a link-state intra-domain routing protocol used in IP networks. Link State Database (LSDB) synchronization in OSPF is achieved via two methods -- initial LSDB synchronization when an OSPF router has just been connected to the network and asynchronous flooding that ensures continuous LSDB synchronization in the presence of topology changes after the initial procedure was completed. It may sometime be necessary for OSPF routers to resynchronize their LSDBs. The OSPF standard, however, does not allow routers to do so without actually changing the topology view of the network. This memo describes a vendor-specific mechanism to perform such a form of out-of-band LSDB synchronization. The mechanism described in this document was proposed before Graceful OSPF Restart, as described in RFC 3623, came into existence. It is implemented/supported by at least one major vendor and is currently deployed in the field. The purpose of this document is to capture the details of this mechanism for public use. This mechanism is not an IETF standard. This memo provides information for the Internet community. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Tue Mar 27 13:21:57 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Tue, 27 Mar 2007 13:21:57 -0700 Subject: [rfc-dist] BCP 111, RFC 4841 on RFC 4181 Update to Recognize the IETF Trust Message-ID: <200703272021.l2RKLvtS026052@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. BCP 111 RFC 4841 Title: RFC 4181 Update to Recognize the IETF Trust Author: C. Heard, Ed. Status: Best Current Practice Date: March 2007 Mailbox: heard at pobox.com Pages: 3 Characters: 4414 Updates: 4841 SeeAlso: BCP 111 I-D Tag: draft-heard-rfc4181-update-00.txt URL: http://www.rfc-editor.org/rfc/rfc4841.txt This document updates RFC 4181, "Guidelines for Authors and Reviewers of MIB Documents", to recognize the creation of the IETF Trust. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 29 17:56:56 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 29 Mar 2007 17:56:56 -0700 Subject: [rfc-dist] RFC 4810 on Long-Term Archive Service Requirements Message-ID: <200703300056.l2U0uuq6004124@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4810 Title: Long-Term Archive Service Requirements Author: C. Wallace, U. Pordesch, R. Brandner Status: Informational Date: March 2007 Mailbox: cwallace at cygnacom.com, ulrich.pordesch at zv.fraunhofer.de, ralf.brandner at intercomponentware.com Pages: 17 Characters: 35690 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ltans-reqs-10.txt URL: http://www.rfc-editor.org/rfc/rfc4810.txt There are many scenarios in which users must be able to prove the existence of data at a specific point in time and be able to demonstrate the integrity of data since that time, even when the duration from time of existence to time of demonstration spans a large period of time. Additionally, users must be able to verify signatures on digitally signed data many years after the generation of the signature. This document describes a class of long-term archive services to support such scenarios and the technical requirements for interacting with such services. This memo provides information for the Internet community. This document is a product of the Long-Term Archive and Notary Services Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 29 17:57:14 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 29 Mar 2007 17:57:14 -0700 Subject: [rfc-dist] RFC 4814 on Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Message-ID: <200703300057.l2U0vELY004131@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4814 Title: Hash and Stuffing: Overlooked Factors in Network Device Benchmarking Author: D. Newman, T. Player Status: Informational Date: March 2007 Mailbox: dnewman at networktest.com, timmons.player at spirent.com Pages: 26 Characters: 59272 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-bmwg-hash-stuffing-08.txt URL: http://www.rfc-editor.org/rfc/rfc4814.txt Test engineers take pains to declare all factors that affect a given measurement, including intended load, packet length, test duration, and traffic orientation. However, current benchmarking practice overlooks two factors that have a profound impact on test results. First, existing methodologies do not require the reporting of addresses or other test traffic contents, even though these fields can affect test results. Second, "stuff" bits and bytes inserted in test traffic by some link-layer technologies add significant and variable overhead, which in turn affects test results. This document describes the effects of these factors; recommends guidelines for test traffic contents; and offers formulas for determining the probability of bit- and byte-stuffing in test traffic. This memo provides information for the Internet community. This document is a product of the Benchmarking Methodology Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 29 17:57:49 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 29 Mar 2007 17:57:49 -0700 Subject: [rfc-dist] RFC 4820 on Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) Message-ID: <200703300057.l2U0vnN7004141@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4820 Title: Padding Chunk and Parameter for the Stream Control Transmission Protocol (SCTP) Author: M. Tuexen, R. Stewart, P. Lei Status: Standards Track Date: March 2007 Mailbox: tuexen at fh-muenster.de, rrs at cisco.com, peterlei at cisco.com Pages: 6 Characters: 11597 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tsvwg-sctp-padding-02.txt URL: http://www.rfc-editor.org/rfc/rfc4820.txt This document defines a padding chunk and a padding parameter and describes the required receiver side procedures. The padding chunk is used to pad a Stream Control Transmission Protocol (SCTP) packet to an arbitrary size. The padding parameter is used to pad an SCTP INIT chunk to an arbitrary size. [STANDARDS TRACK] This document is a product of the Transport Area Working Group Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 29 17:57:28 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 29 Mar 2007 17:57:28 -0700 Subject: [rfc-dist] RFC 4817 on Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 Message-ID: <200703300057.l2U0vSkC004136@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4817 Title: Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3 Author: M. Townsley, C. Pignataro, S. Wainner, T. Seely, J. Young Status: Standards Track Date: March 2007 Mailbox: mark at townsley.net, cpignata at cisco.com, swainner at cisco.com, tseely at sprint.net, young at jsyoung.net Pages: 12 Characters: 26538 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-over-l2tpv3-03.txt URL: http://www.rfc-editor.org/rfc/rfc4817.txt The Layer 2 Tunneling Protocol, Version 3 (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks. This document defines how to carry an MPLS label stack and its payload over the L2TPv3 data encapsulation. This enables an application that traditionally requires an MPLS-enabled core network, to utilize an L2TPv3 encapsulation over an IP network instead. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ... From rfc-editor at rfc-editor.org Thu Mar 29 17:58:05 2007 From: rfc-editor at rfc-editor.org (rfc-editor@rfc-editor.org) Date: Thu, 29 Mar 2007 17:58:05 -0700 Subject: [rfc-dist] RFC 4821 on Packetization Layer Path MTU Discovery Message-ID: <200703300058.l2U0w5Zu004146@nit.isi.edu> A new Request for Comments is now available in online RFC libraries. RFC 4821 Title: Packetization Layer Path MTU Discovery Author: M. Mathis, J. Heffner Status: Standards Track Date: March 2007 Mailbox: mathis at psc.edu, jheffner at psc.edu Pages: 32 Characters: 75665 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-pmtud-method-11.txt URL: http://www.rfc-editor.org/rfc/rfc4821.txt This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS TRACK] This document is a product of the Path MTU Discovery Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements.Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST at IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST at RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info at RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info at RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager at RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR at RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. The RFC Editor Team USC/Information Sciences Institute ...