doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4450.txt b/doc/rfc/rfc4450.txt
new file mode 100644
index 0000000..52d9257
--- /dev/null
+++ b/doc/rfc/rfc4450.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                            E. Lear
+Request for Comments: 4450                            Cisco Systems GmbH
+Category: Informational                                    H. Alvestrand
+                                                           Cisco Systems
+                                                              March 2006
+
+
+ Getting Rid of the Cruft: Report from an Experiment in Identifying and
+               Reclassifying Obsolete Standards Documents
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This memo documents an experiment to review and classify Proposed
+   Standards as not reflecting documented practice within the world
+   today.  The results identify a set of documents that were marked as
+   Proposed Standards that are now reclassified as Historic.
+
+Table of Contents
+
+   1. Introduction and History ........................................1
+   2. Bulk Decommissioning Procedure ..................................2
+   3. Input, Mailing list, Output, and Observations ...................2
+   4. Discussion ......................................................4
+   5. Next Steps ......................................................5
+   6. IANA Considerations .............................................6
+   7. Security Considerations .........................................6
+   8. Acknowledgements ................................................6
+   9. Normative References ............................................6
+
+1.  Introduction and History
+
+   RFC 2026, and RFC 1602 before it, specified timelines for review of
+   immature (draft or proposed) standards.  The purpose of such review
+   was to determine whether such documents should be advanced, retired,
+   or developed further [1].
+
+
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 1]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   This procedure has never been followed in the history of the IETF.
+   Since this procedure has not been followed, members of the community
+   have suggested that the retiring of a document to Historic is a
+   significant event, which should be justified carefully -- leading to
+   the production of documents such as RFC 2556 (OSI Connectionless
+   Transport Services on top of UDP Applicability Statement for Historic
+    Status) and RFC 3166 (Request to Move RFC 1403 to Historic Status).
+
+   Such documents require significant time and effort on the part of
+   authors, area directors, and the RFC Editor.
+
+2.  Bulk Decommissioning Procedure
+
+   From the Fall of 2004 through the Spring of 2005, the authors
+   conducted an experiment to determine how many Proposed Standards
+   could be considered obsolete.  The experiment was operated as
+   follows:
+
+   o  Identify a group of documents that are standards.
+   o  Assume by default that each document will be retired.
+   o  Create a mailing list for discussion with a policy of open access.
+   o  Allow any document to be removed from the list of those to be
+      retired for virtually any reason, so long as a reason is provided.
+   o  Present the list to the working group, IETF, and IESG for review.
+   o  Revise list based on comments.
+   o  Write up results.
+
+   The initial intent of the authors was to present a list of documents
+   to be reclassified as Historic.  The NEWTRK working group supported
+   this view.  The IESG, and the IETF as a community, makes the final
+   decision.  We will discuss this further below.
+
+3.  Input, Mailing list, Output, and Observations
+
+   We started with our initial document set being all RFCs with numbers
+   less than 2000 and a status of Proposed Standard.  The input we used,
+   starting November 25, 2004, can be found in Appendix A.  There were
+   some 125 documents in all.
+
+   A mailing list, old-standards@alvestrand.no, was created to discuss
+   and remove candidates from this list.  A call for participation was
+   issued to the IETF-Announce list on or around the November 15, 2004.
+   There were 29 members of the mailing list.  Approximately 244
+   messages were sent to the list.  People were encouraged to consider
+   the question of whether or not an implementer would either write a
+   new implementation or maintain an existing one.
+
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 2]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   After some months the list of documents to be considered was reduced
+   considerably.  This list was then forwarded to the IETF discussion
+   list on December 16, 2004, and to the NEWTRK working group list for
+   wider review.
+
+   During review, RFCs 1518 and 1519 were removed, based on the fact
+   that work is ongoing to revise them.  Similarly, RFCs 1381, 1382,
+   1471, 1472, 1473, 1582, 1598, and 1755 were removed based on the
+   belief that they were actively in use.  RFC 1584 was removed based on
+   an expected future dependency.
+
+   Here are the results:
+
+   RFC 1234 (Tunneling IPX Traffic through IP Networks)
+   RFC 1239 (Reassignment of Experimental MIBs to Standard MIBs)
+   RFC 1276 (Replication and Distributed Operations Extensions to
+            provide an Internet Directory Using X.500)
+   RFC 1285 (FDDI Management Information Base)
+   RFC 1314 (A File Format for the Exchange of Images in the Internet)
+   RFC 1328 (X.400 1988 to 1984 Downgrading)
+   RFC 1370 (Applicability Statement for OSPF)
+   RFC 1378 (The PPP AppleTalk Control Protocol (ATCP))
+   RFC 1397 (Default Route Advertisement in BGP2 and BGP3 Version of
+            the Border Gateway Protocol)
+   RFC 1414 (Identification MIB)
+   RFC 1415 (FTP-FTAM Gateway Specification)
+   RFC 1418 (SNMP over OSI)
+   RFC 1419 (SNMP over AppleTalk)
+   RFC 1421 (Privacy Enhancement for Internet Electronic Mail: Part I:
+            Message Encryption and Authentication Procedures)
+   RFC 1422 (Privacy Enhancement for Internet Electronic Mail: Part
+            II: Certificate-Based Key Management)
+   RFC 1423 (Privacy Enhancement for Internet Electronic Mail: Part
+            III: Algorithms, Modes, and Identifiers)
+   RFC 1424 (Privacy Enhancement for Internet Electronic Mail: Part
+            IV: Key Certification and Related Services)
+   RFC 1461 (SNMP MIB Extension for Multiprotocol Interconnect over
+            X.25)
+   RFC 1469 (IP Multicast over Token-Ring Local Area Networks)
+   RFC 1474 (The Definitions of Managed Objects for the Bridge Network
+            Control Protocol of the Point-to-Point Protocol)
+   RFC 1478 (An Architecture for Inter-Domain Policy Routing)
+   RFC 1479 (Inter-Domain Policy Routing Protocol Specification:
+            Version 1)
+   RFC 1494 (Equivalences between 1988 X.400 and RFC-822 Message
+            Bodies)
+   RFC 1496 (Rules for Downgrading Messages from X.400/88 to X.400/84)
+            when MIME Content-types Are Present in the Messages
+
+
+
+Lear & Alvestrand            Informational                      [Page 3]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   RFC 1502 (X.400 Use of Extended Character Sets)
+   RFC 1512 (FDDI Management Information Base)
+   RFC 1513 (Token Ring Extensions to the Remote Network Monitoring
+            MIB)
+   RFC 1525 (Definitions of Managed Objects for Source Routing
+            Bridges)
+   RFC 1552 (The PPP Internetworking Packet Exchange Control Protocol
+            (IPXCP))
+   RFC 1553 (Compressing IPX Headers over WAN Media (CIPX))
+   RFC 1648 (Postmaster Convention for X.400 Operations)
+   RFC 1666 (Definitions of Managed Objects for SNA NAUs using SMIv2)
+   RFC 1692 (Transport Multiplexing Protocol (TMux))
+   RFC 1696 (Modem Management Information Base (MIB) Using SMIv2)
+   RFC 1742 (AppleTalk Management Information Base II)
+   RFC 1747 (Definitions of Managed Objects for SNA Data Link Control
+            (SDLC) Using SMIv2)
+   RFC 1749 (IEEE 802.5 Station Source Routing MIB using SMIv2)
+   RFC 1763 (The PPP Banyan Vines Control Protocol (BVCP))
+   RFC 1764 (The PPP XNS IDP Control Protocol (XNSCP))
+   RFC 1828 (IP Authentication using Keyed MD5)
+   RFC 1835 (Architecture of the WHOIS++ Service)
+   RFC 1848 (MIME Object Security Services)
+   RFC 1913 (Architecture of the Whois++ Index Service)
+   RFC 1914 (How to Interact with a Whois++ Mesh)
+
+   One additional document, RFC 1829, the ESP DES-CBC transform, was
+   suggested for Historic status, but in this case, the group consensus
+   is that the community would benefit from a separate document
+   describing the security implications of using this algorithm.
+
+4.  Discussion
+
+   As one peruses this list one sees several classes of documents:
+
+   o  Multiprotocol functions for protocols that are obsolete, such as
+      Appletalk or X.400.
+   o  Protocols that were defined but not used, such as PEM or Whois++
+
+   In either case above, a judgment is necessary as to whether or not a
+   protocol is both in use and likely to be supported.  The parameters
+   of our experiment were sufficiently conservative to avoid cases where
+   protocols were likely to continue to be supported.  That is, anyone
+   could remove a document from the list for any reason.  In fact, in
+   some cases we may have been too conservative.  Thus, it is also worth
+   considering the categories of documents that were removed from the
+   list:
+
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 4]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   o  specifications known to be in full use that should be considered
+      for advancement
+   o  specifications that are currently under review within the IETF
+      process
+   o  Specifications that were previously considered for deprecation and
+      rejected.
+
+   The last category is exclusive to telnet options, which were reviewed
+   in the late 1990s.  Arguably, such options should be reconsidered for
+   deprecation.  Realistically, nobody is going to develop a new version
+   of telnet that supports the TACACS option, for instance.
+   Nevertheless, as a first cut we were still left with 61 documents
+   that could be reclassified.
+
+   In at least one case, discussion of deprecation has spurred work on
+   documents.  For instance, there is a Classless Inter-Domain Routing
+   (CIDR) update in progress.
+
+5.  Next Steps
+
+   As we mention in the introduction, the current process requires
+   reconsideration of immature standards, and this review currently does
+   not occur.  This experiment has been an attempt at a procedure that
+   could ease that review.  The final step was working group
+   consideration of what to do next.  There were four options:
+
+   1.  Accept the results of this experiment, issue a last call, and
+       deprecate standards that remain on the list past last call.  This
+       is an aggressive approach that would preserve the intent of RFC
+       2026.
+   2.  Do not accept the results of this experiment and update RFC 2026
+       to indicate a new practice.
+   3.  Revise the procedure based on the results of this experiment,
+       based on feedback from the IESG.  This option might take into
+       account the different types of old standards as described above.
+   4.  Do nothing.  This would leave the IETF and the IESG practice
+       inconsistent with documented practice.
+
+   The working group chose the first option.  The RFC Editor is
+   requested to mark the above listed standards as Historic.
+
+   It should be pointed out that we only looked at proposed standards
+   and only those RFCs with numbers less than 2000.  Should either the
+   first or third of the above options be accepted, draft standards and
+   those older than several years should be considered.
+
+
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 5]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   Finally, should NEWTRK deliver a new document classification system,
+   these documents may provide a basis for one or more new categories of
+   that.
+
+6.  IANA Considerations
+
+   The IANA databases contain references to many of these documents.
+   The documents are still the normative definitions for these values,
+   and the IANA databases do not contain information about the status of
+   the RFCs referred to.
+
+   Therefore, the IANA should not need to do anything based on this
+   document.
+
+7.  Security Considerations
+
+   Documents that have security problems may require special attention
+   and individual documents to indicate what concerns exist, and when or
+   in what ways an implementation can be deployed to alleviate concerns.
+
+8.  Acknowledgements
+
+   This experiment would have been completely useless without
+   participation of the members of the old-standards mailing list.  Most
+   notably, Pekka Savalo, Bob Braden, and John Klensin were very active
+   contributors to the discussions.
+
+9.  Normative References
+
+   [1]  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 6]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+Appendix A.  Input RFCs
+
+   RFC 0698 (Telnet Extended ASCII Option)
+   RFC 0726 (Remote Controlled Transmission and Echoing Telnet Option)
+   RFC 0727 (Telnet Logout Option)
+   RFC 0735 (Revised Telnet Byte Macro Option)
+   RFC 0736 (Telnet SUPDUP Option)
+   RFC 0749 (Telnet SUPDUP-Output Option)
+   RFC 0779 (Telnet send-location Option)
+   RFC 0885 (Telnet End of Record Option)
+   RFC 0927 (TACACS User Identification Telnet Option)
+   RFC 0933 (Output Marking Telnet Option)
+   RFC 0946 (Telnet Terminal Location Number Option)
+   RFC 0977 (Network News Transfer Protocol)
+   RFC 1041 (Telnet 3270 Regime Option)
+   RFC 1043 (Telnet Data Entry Terminal Option: DODIIS Implementation)
+   RFC 1053 (Telnet X.3 PAD Option)
+   RFC 1073 (Telnet Window sSize Option)
+   RFC 1079 (Telnet Terminal Speed Option)
+   RFC 1091 (Telnet Terminal-type Option)
+   RFC 1096 (Telnet X Display Location Option)
+   RFC 1144 (Compressing TCP/IP Headers for Low-speed Serial Links)
+   RFC 1195 (Use of OSI IS-IS for Routing in TCP/IP and Dual)
+   RFC 1234 (Tunneling IPX Traffic through IP Networks)
+   RFC 1239 (Reassignment of Experimental MIBs to Standard MIBs)
+   RFC 1256 (ICMP Router Discovery Messages)
+   RFC 1269 (Definitions of Managed Objects for the Border Gateway
+            Protocol: Version 3)
+   RFC 1274 (The COSINE and Internet X.500 Schema)
+   RFC 1276 (Replication and Distributed Operations Extensions to
+            Provide an Internet Directory Using X.500)
+   RFC 1277 (Encoding Network Addresses to Support Operation over Non-
+            OSI Lower Layers)
+   RFC 1285 (FDDI Management Information Base)
+   RFC 1314 (A File Format for the Exchange of Images in the Internet)
+   RFC 1323 (TCP Extensions for High Performance)
+   RFC 1328 (X.400 1988 to 1984 Downgrading)
+   RFC 1332 (The PPP Internet Protocol Control Protocol (IPCP))
+   RFC 1370 (Applicability Statement for OSPF)
+   RFC 1372 (Telnet Remote Flow Control Option)
+   RFC 1377 (The PPP OSI Network Layer Control Protocol (OSINLCP))
+   RFC 1378 (The PPP AppleTalk Control Protocol (ATCP))
+   RFC 1381 (SNMP MIB Extension for X.25 LAPB)
+   RFC 1382 (SNMP MIB Extension for the X.25 Packet Layer)
+   RFC 1397 (Default Route Advertisement in BGP2 and BGP3 Version of
+            the Border Gateway Protocol)
+   RFC 1413 (Identification Protocol)
+   RFC 1414 (Identification MIB)
+
+
+
+Lear & Alvestrand            Informational                      [Page 7]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   RFC 1415 (FTP-FTAM Gateway Specification)
+   RFC 1418 (SNMP over OSI)
+   RFC 1419 (SNMP over AppleTalk)
+   RFC 1420 (SNMP over IPX)
+   RFC 1421 (Privacy Enhancement for Internet Electronic Mail: Part I:
+            Message Encryption and Authentication Procedures)
+   RFC 1422 (Privacy Enhancement for Internet Electronic Mail: Part
+            II: Certificate-Based Key Management)
+   RFC 1423 (Privacy Enhancement for Internet Electronic Mail: Part
+            III: Algorithms, Modes, and Identifiers)
+   RFC 1424 (Privacy Enhancement for Internet Electronic Mail: Part
+            IV: Key Certification and Related Services)
+   RFC 1461 (SNMP MIB extension for Multiprotocol Interconnect over
+            X.25)
+   RFC 1469 (IP Multicast over Token-Ring Local Area Networks)
+   RFC 1471 (The Definitions of Managed Objects for the Link Control
+            Protocol of the Point-to-Point Protocol)
+   RFC 1472 (The Definitions of Managed Objects for the Security
+            Protocols of the Point-to-Point Protocol)
+   RFC 1473 (The Definitions of Managed Objects for the IP Network
+            Control Protocol of the Point-to-Point Protocol)
+   RFC 1474 (The Definitions of Managed Objects for the Bridge Network
+            Control Protocol of the Point-to-Point Protocol)
+   RFC 1478 (An Architecture for Inter-Domain Policy Routing)
+   RFC 1479 (Inter-Domain Policy Routing Protocol Specification:
+            Version 1)
+   RFC 1494 (Equivalences between 1988 X.400 and RFC-822 Message
+            Bodies)
+   RFC 1496 (Rules for Downgrading Messages from X.400/88 to X.400/84)
+   RFC 1502 (X.400 Use of Extended Character Sets)
+   RFC 1510 (The Kerberos Network Authentication Service (V5))
+   RFC 1512 (FDDI Management Information Base)
+   RFC 1513 (Token Ring Extensions to the Remote Network Monitoring
+            MIB)
+   RFC 1517 (Applicability Statement for the Implementation of
+            Classless Inter-Domain Routing (CIDR))
+   RFC 1518 (An Architecture for IP Address Allocation with CIDR)
+   RFC 1519 (Classless Inter-Domain Routing (CIDR): an Address
+            Assignment and Aggregation Strategy)
+   RFC 1525 (Definitions of Managed Objects for Source Routing
+            Bridges)
+   RFC 1552 (The PPP Internetworking Packet Exchange Control Protocol)
+   RFC 1553 (Compressing IPX Headers over WAN Media (CIPX))
+   RFC 1570 (PPP LCP Extensions)
+   RFC 1572 (Telnet Environment Option)
+   RFC 1582 (Extensions to RIP to Support Demand Circuits)
+   RFC 1584 (Multicast Extensions to OSPF)
+   RFC 1598 (PPP in X.25)
+
+
+
+Lear & Alvestrand            Informational                      [Page 8]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+   RFC 1618 (PPP over ISDN)
+   RFC 1628 (UPS Management Information Base)
+   RFC 1648 (Postmaster Convention for X.400 Operations)
+   RFC 1663 (PPP Reliable Transmission)
+   RFC 1666 (Definitions of Managed Objects for SNA NAUs Using SMIv2)
+   RFC 1692 (Transport Multiplexing Protocol (TMux))
+   RFC 1696 (Modem Management Information Base (MIB) Using SMIv2)
+   RFC 1697 (Relational Database Management System (RDBMS) Management)
+   RFC 1731 (IMAP4 Authentication Mechanisms)
+   RFC 1734 (POP3 AUTHentication command)
+   RFC 1738 (Uniform Resource Locators (URL))
+   RFC 1740 (MIME Encapsulation of Macintosh Files - MacMIME)
+   RFC 1742 (AppleTalk Management Information Base II)
+   RFC 1747 (Definitions of Managed Objects for SNA Data Link Control)
+   RFC 1749 (IEEE 802.5 Station Source Routing MIB Using SMIv2)
+   RFC 1752 (The Recommendation for the IP Next Generation Protocol)
+   RFC 1755 (ATM Signaling Support for IP over ATM)
+   RFC 1763 (The PPP Banyan Vines Control Protocol (BVCP))
+   RFC 1764 (The PPP XNS IDP Control Protocol (XNSCP))
+   RFC 1767 (MIME Encapsulation of EDI Objects)
+   RFC 1793 (Extending OSPF to Support Demand Circuits)
+   RFC 1808 (Relative Uniform Resource Locators)
+   RFC 1812 (Requirements for IP Version 4 Routers)
+   RFC 1828 (IP Authentication using Keyed MD5)
+   RFC 1829 (The ESP DES-CBC Transform)
+   RFC 1831 (RPC: Remote Procedure Call Protocol Specification Version
+            2)
+   RFC 1833 (Binding Protocols for ONC RPC Version 2)
+   RFC 1835 (Architecture of the WHOIS++ Service)
+   RFC 1847 (Security Multiparts for MIME: Multipart/Signed and
+            Multipart/Encrypted)
+   RFC 1848 (MIME Object Security Services)
+   RFC 1913 (Architecture of the Whois++ Index Service)
+   RFC 1914 (How to Interact with a Whois++ Mesh)
+   RFC 1928 (SOCKS Protocol Version 5)
+   RFC 1929 (Username/Password Authentication for SOCKS V5)
+   RFC 1961 (GSS-API Authentication Method for SOCKS Version 5)
+   RFC 1962 (The PPP Compression Control Protocol (CCP))
+   RFC 1964 (The Kerberos Version 5 GSS-API Mechanism)
+   RFC 1968 (The PPP Encryption Control Protocol (ECP))
+   RFC 1973 (PPP in Frame Relay)
+   RFC 1982 (Serial Number Arithmetic)
+   RFC 1985 (SMTP Service Extension for Remote Message Queue Starting)
+   RFC 1995 (Incremental Zone Transfer in DNS)
+   RFC 1996 (A Mechanism for Prompt Notification of Zone Changes (DNS
+            NOTIFY))
+   RFC 1997 (BGP Communities Attribute)
+
+
+
+
+Lear & Alvestrand            Informational                      [Page 9]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+Authors' Addresses
+
+   Eliot Lear
+   Cisco Systems GmbH
+   Glatt-com
+   Glattzentrum, ZH  CH-8301
+   Switzerland
+
+   Phone: +41 1 878 7525
+   EMail: lear@cisco.com
+
+
+   Harald Tveit Alvestrand
+   Cisco Systems
+   Weidemanns vei 27
+   7043 Trondheim
+   Norway
+
+   EMail: harald@alvestrand.no
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Lear & Alvestrand            Informational                     [Page 10]
+
+RFC 4450                     Cruft Removal                    March 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Lear & Alvestrand            Informational                     [Page 11]
+