From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2436.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc2436.txt (limited to 'doc/rfc/rfc2436.txt') diff --git a/doc/rfc/rfc2436.txt b/doc/rfc/rfc2436.txt new file mode 100644 index 0000000..b7b2077 --- /dev/null +++ b/doc/rfc/rfc2436.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group R. Brett +Request for Comments: 2436 Nortel Networks +Category: Informational S. Bradner + Harvard University + G. Parsons + Nortel Networks + October 1998 + + + Collaboration between ISOC/IETF and ITU-T + +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 (1998). All Rights Reserved. + +Overview + + This document describes the collaboration process between the ITU-T + and ISOC/IETF. The process was documented by ITU-T at its TSAG + (Telecommunication Standardization Advisory Group) meeting in + September 1998. All participants of this meeting (including Study + Group chairmen and the ISOC Vice President for Standards) assisted in + the creation of this document. Subsequently, it was sent to all + ITU-T Study Groups and ISOC/IETF to ensure that everyone was aware of + the process. Feedback is requested by the next meeting of TSAG in + April 1999. This document is identical to the document produced by + TSAG. + + Please send any comments on this document to ISOC at poised@tis.com + and for information to the ITU-T TSAG group at tsagco-op@itu.int + +ISOC/IETF and ITU-T Collaboration + +1 Scope + + This Liaison is sent to all ITU-T Study Groups to encourage and aid + in the understanding of collaboration on standards development + between the ITU-T and the Internet Society (ISOC) / Internet + Engineering Task Force (IETF). Feedback to TSAG is encouraged before + its next meeting in April 1999. + + + + + +Brett, et. al. Informational [Page 1] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + +2 Introduction + + The telecommunication industry is faced with an explosion in growth + of the Internet and other IP (Internet Protocol) based networks. + Operators, manufacturers and software/application providers alike are + reconsidering their business directions and Standards Development + Organizations and Forums and Consortia are facing an immense + challenge to address this situation. These challenges were + considered by TSAG at its meeting in Geneva, 7-11 September 1998, + where it recognized that although the ITU-T and ISOC/IETF are already + collaborating in a number of areas, this collaboration must be + strengthened within the context of changes in work emphasis and + direction within the ITU-T on studies related to IP based networks. + + For example, many Study Groups (e.g., 7, 8 & 16) already address + several the aspects of IP based networks. Further, new IP related + work activities are starting in other Study Groups (e.g., 4, 11 & + 13). There are many potential areas of interest to ITU-T Study + Groups in the IP area that should be investigated (e.g., signaling, + routing, security, numbering & addressing, integrated management, + performance, IP - telecom interworking, access). Since many of these + areas are also being investigated by the IETF, there is a requirement + for close collaboration. + + Recommendations A.4, A.5 and A.6 already document the process for + working with other organizations and their documents. Since there + are no specific guidelines on the process of collaboration with the + IETF, this liaison is meant to provide that information. The current + level of cooperation between the ITU-T and the IETF should be built + upon to ensure that the competence and experience of each + organization is brought to bear in the most effective manner and in + collaboration with the other. + +3 Guidance on Collaboration + + TSAG has been made aware of several instances of existing successful + collaboration between the ITU-T and ISOC/IETF. This section builds + on this existing process and details some of the more important + guidance points that Study Groups should be aware of in their + collaboration with ISOC/IETF. + +3.1 How to interact on ITU-T or IETF work items. + + Study Groups that have identified work topics that are Internet + related should evaluate the relationship with topics defined in the + IETF. Current IETF Working Groups and their charters (IETF + definition of the scope of work) are listed in the IETF archives (see + + + + +Brett, et. al. Informational [Page 2] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + section 3.5). A Study Group may decide that development of a + Recommendation on a particular topic may benefit from collaboration + with the IETF. + + The Study Group should identify this collaboration in its work plan + (specifically in that of each Question involved), describing the goal + of the collaboration and its expected outcome. It is anticipated + that an IETF Working Group would also evaluate and identify areas of + relationship with the ITU-T and document the collaboration with the + ITU-T Study Group in its charter. + + The following sections outline a process that can be used to enable + each group to learn about the others new work items. + +3.1.1 How the ITU-T learns about existing IETF work items + + The responsibility is on individual Study Groups to review the + current IETF Working Groups to determine if there are any topics of + mutual interest. Should a Study Group believe that there is an + opportunity for collaboration on a topic of mutual interest it should + contact both the IETF Working Group Chair and the Area Director + responsible. + +3.1.2 How the ITU-T learns about proposed new IETF work items + + The IETF maintains a mailing list for the distribution and discussion + of proposed new Working Group charters amongst the management team. + To add or change a subscription to this list, send a message to + iesg-secretary@ietf.org indicating who you are and that you would + like to subscribe to the New Work mailing list. Details on the list + process will be emailed to each subscriber. + + It is recommended that each Study Group chairman (or a delegate) + subscribe to this list and monitor the new work items for possible + overlap or interest to their Study Group. It is expected that this + mailing list will see one or two messages per month. Chairmen should + identify their comments on these charters by responding to the IESG + mailing list at iesg@ietf.org clearly indicating their ITU-T position + and the nature of their concern. It should be noted that the IETF + turnaround time for new Working Group charters is one week. As a + result, the mailing list should be consistently monitored. + +3.1.3 How the IETF learns about ITU-T work items + + An initial list of Internet related topics in ITU-T Study Groups + based on the situation as of 11 September is being provided to the + Vice President of Standards for ISOC for distribution to the + appropriate IETF interested individuals and will be copied to all + + + +Brett, et. al. Informational [Page 3] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + ITU-T Study Group Chairmen. The intention is for Study Groups to + forward updates to the Vice President of Standards for ISOC as they + occur. + + It is expected that any IETF Working Group interest with the topics + being covered by the ITU-T will be forwarded to individual Study + Group Chairmen (or the lead Study Group Chairman) by the Vice + President of Standards for ISOC. + +3.2 Representation + + ISOC, including its standards body IETF, have been admitted by the + ITU Council to participate in the work of the ITU-T. As a result, + ISOC delegates are therefore afforded equivalent rights to those of + other ITU-T Study Group participants (see 3.2.1). Conversely, ITU-T + delegates may participate in the work of the IETF as individuals or + be recognized as ITU-T delegates (see 3.2.2). To promote + collaboration it is useful to facilitate communication between the + organizations as further described below. + +3.2.1 IETF Recognition at ITU-T + + Participants from the IETF may participate in ITU-T meetings as ISOC + delegates if the appropriate IETF Working Group (or area) has + approved their attendance. This approval will be communicated to the + TSB in the form of a registration for a particular ITU-T meeting by + the Vice President of Standards for ISOC. + +3.2.2 ITU-T Recognition at ISOC/IETF + + ITU-T Study Group Chairmen can authorize one or more members to + attend an IETF meeting as an official ITU-T delegate speaking on + behalf of the Study Group (or a particular Rapporteur Group). The + Study Group Chairman communicates the ITU-T list of delegates by + email to the Vice President of Standards for ISOC and also to the + Study Group. The email address of the Vice President of Standards + for ISOC is vp-standards@isoc.org. + +3.2.3 Communication contacts + + To foster ongoing communication between the ITU-T and ISOC/IETF, it + is important to identify and establish contact points within ITU-T + Study Groups for specific IETF topics of mutual interest. It is + beneficial to identify these contact points early and in some cases + the contact point identified by each organization may be the same + individual. It is responsibility of a Study Group to establish the + contact points with the IETF and maintain the list on its web page. + + + + +Brett, et. al. Informational [Page 4] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + An example of communication contacts that is suggested to Study + Groups has both a high level and a working level: + + 1. ITU-T Study Group Chairman and IETF Area Director + + An IETF Area Director is the individual responsible for overseeing + a major focus of activity with a scope similar to that of an ITU-T + Study Group Chairman. These positions are both relatively long- + term (of several years) and offer the stability of contact points + between the two organizations for a given topic. + + 2. ITU-T Rapporteur and IETF Working Group Chair + + An IETF Working Group Chair is an individual who is assigned to + lead the work on a specific task within one particular area with a + scope similar to that of an ITU-T Rapporteur. These positions are + working positions (of a year or more) that typically end when the + work on a specific topic ends. Collaboration here is very + beneficial to ensure the actual work gets done. Note that the + current IETF Area Directors and Working Group chairs can be found + in the IETF Working Group charters. The current ITU-T Study Group + chairmen and Rapporteurs are listed on the ITU-T web page. + + Both the ITU-T and IETF may assign their contact point function(s) to + other individuals than those suggested as it deems appropriate. + +3.2.4 Communication + + Informal communication between contact points and experts of both + organizations is encouraged. However, note that formal communication + from an ITU-T Study Group, Working Party or Rapporteur to an + associated IETF contact point must be explicitly approved and + identified as coming from the Study Group, Working Party or + Rapporteur Group, respectively. Conversely, formal communication + from an IETF Working Group or Area Director must also be explicitly + approved and identified before forwarding to any ITU-T contact. + Formal communication is intended to allow the sharing of positions + between the IETF and the ITU-T outside of actual documents (as + described in 3.3). This would cover such things as comments on + documents and requests for input. The approved communication is + simply emailed from one body contact to another (the appropriate + mailing lists, as described in 3.2.5 may be copied). + +3.2.5 Mailing Lists + + All IETF Working Groups and all ITU-T Study Group Questions have + associated mailing lists. + + + + +Brett, et. al. Informational [Page 5] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + In the IETF, the mailing list is the primary vehicle for discussion + and decision making. It is recommended the ITU-T experts interested + in particular IETF working group topics subscribe to and participate + in these lists. The IETF Working Group mailing list subscription and + archive information are noted in each Working Group's charter. In the + ITU-T, the TSB has set up formal mailing lists for Questions, Working + Parties and other topics within Study Groups (more detail can be + found on the ITU website.). These mailing lists are typically used + for discussion of ITU-T contributions. Note that individual + subscribers to this list must be affiliated with an ITU-T member (at + this time, there is no blanket inclusion of all IETF participants as + members, however, as a member ISOC may designate representatives to + subscribe). Alternatively, ITU-T members operate personal mailing + lists on various topics with no restrictions on membership (e.g., + IETF participants are welcome). + +3.3 Document Sharing + + During the course of ITU-T and IETF collaboration it is important to + share working drafts and documents among the technical working + groups. Initial proposed concepts and specifications typically can + be circulated by email (often just repeating the concept and not + including the details of the specification) on both the IETF and + ITU-T mailing lists. In addition, working texts (or URLs) of draft + Recommendations or RFCs (Internet Drafts) may also be sent between + the organizations as described below. + +3.3.1 IETF to ITU-T + + IETF documents (e.g., Internet Drafts) can be submitted to a Study + Group as a Contribution from ISOC. In order to ensure that the IETF + has properly authorized this, the IETF Working Group must agree that + the specific drafts are of mutual interest and that there is a + benefit in forwarding them to the ITU-T for review, comment and + potential use. Once agreed, the Vice President Standards for ISOC + would review the Working Group request and give approval. The + contributions would then be forwarded (with the noted approval) to + the TSB for circulation as a Study Group Contribution. + +3.3.2 ITU-T to IETF + + A Study Group may send texts of draft new Recommendations to the IETF + as contributions in the form of Internet Drafts. Internet Drafts are + IETF temporary documents that expire six months after being + published. The Study Group must decide that there is a benefit in + forwarding them to the IETF for review, comment and potential use. + Terms of reference for Rapporteur Group meetings may authorize + Rapporteur Groups to send working documents, in the form of Internet + + + +Brett, et. al. Informational [Page 6] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + Drafts, to the IETF. In both cases, the document editor would be + instructed to prepare the contribution in Internet Draft format (in + ASCII and optionally postscript format as per RFC 2223) and submit it + to the Internet Draft editor (email: internet-drafts@ietf.org). + Alternatively, the Study Group or Rapporteur Group could agree to + post the document on a web site and merely document its existence + with a short Internet Draft that contains a summary and the document + URL. + + Both the Rapporteur and the Document Editor should be identified as + contacts in the contribution. The contribution must also clearly + indicate that the Internet Draft is a working document of a + particular ITU-T Study Group. + +3.3.3 ITU-T & IETF + + It is envisaged that the processes of 3.3.1 & 3.3.2 will often be + used simultaneously by both an IETF Working Group and an ITU-T Study + Group to collaborate on a topic of mutual interest. It is also + envisaged that the outcome of the collaboration will be the + documentation in full by one body and its referencing by the other + (see section 3.4 for details). That is, common or joint text is + discouraged because of the current differences in approval, revision + and stability of approved documents for publication by each body. + +3.4 Simple cross referencing + + ITU-T Recommendation A.5, specifically its Annex A and the + application guidelines attached, describes the process for + referencing IETF RFCs in ITU-T Recommendations. IETF RFC 2026, + specifically section 7.1.1, describes the process for referencing + other open standards (like ITU-T Recommendations) in IETF RFCs. + +3.5 Additional items + + Several URLs to IETF procedures are provided here for information: + + RFC2223 - Instructions to RFC Authors, October 1997 + ftp://ftp.isi.edu/in-notes/rfc2223.txt + RFC2026 - The Internet Standards Process Revision 3, October 1996 + ftp://ftp.isi.edu/in-notes/rfc2026.txt + RFC2418 - IETF Working Group Guidelines and Procedures, September + 1998 ftp://ftp.isi.edu/in-notes/rfc2418.txt + Current list and status of all IETF RFCs ftp://ftp.isi.edu/in- + notes/rfc-index.txt + Current list and description of all IETF Internet Drafts: + ftp://ftp.ietf.org/internet-drafts/1id-abstracts.txt + + + + +Brett, et. al. Informational [Page 7] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + Current list of IETF Working Groups and their Charters: (includes + Area Directors and Chair contacts, Mailing list information, etc.) + http://www.ietf.org/html.charters/wg-dir.html + Current ITU-T information can be found on the ITU website: (includes + contacts, organization, Recommendations for purchase, mailing list + info, etc.) http://www.itu.int + +4. Acknowledgments + + The process was documented by ITU-T at its TSAG (Telecommunication + Standardization Advisory Group) meeting in September 1998. All + participants of this meeting (including Study Group chairmen and the + ISOC Vice President for Standards) assisted in the creation of this + document. Subsequently, it was sent to all ITU-T Study Groups and + ISOC/IETF to ensure that everyone was aware of the process. Feedback + is requested by the next meeting of TSAG in April 1999. + +5. Security Considerations + + This type of non-protocol document does not directly effect the + security of the Internet. + +6. Authors' Addresses + + ITU-T Contact: + R. F. Brett + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + + Phone: +1-613-828-0902 + Fax: +1-613-828-9408 + EMail: rfbrett@nortel.ca + + + ISOC Contact: + Scott O. Bradner + Harvard University + Holyoke Center, Room 876 + 1350 Mass. Ave. + Cambridge, MA 02138 + USA + + Phone: +1 617 495 3864 + EMail: sob@harvard.edu + + + + + +Brett, et. al. Informational [Page 8] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + Editor: + Glenn W. Parsons + Nortel Networks + P.O. Box 3511, Station C + Ottawa, ON K1Y 4H7 + Canada + + Phone: +1-613-763-7582 + Fax: +1-613-763-4461 + EMail: Glenn.Parsons@Nortel.ca + +7. References + + [A.4] ITU-T Recommendation A.4 - Communication process between + ITU-T and forums and consortia, October 1996. + + [A.5] ITU-T Recommendation A.5 - Generic procedures for including + references to documents to other organizations in ITU-T + Recommendations, January 1998. + + [A.6] ITU-T Recommendation A.6 - Cooperation and exchange of + information between ITU-T and national and regional + standards development organizations, September 1998. + + [RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", + BCP 9, RFC 2026, October 1996. + + [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", + RFC 2223, October 1997. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + +8. Full ITU Copyright Statement + + Copyright (C) ITU (1998). All Rights Reserved. + + No part of this publication may be reproduced or utilized in any form + or by any means, electronic or mechanical, including photocopying and + microfilm, without permission in writing from the ITU. + + + + + + + + + + + +Brett, et. al. Informational [Page 9] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + +9. Annex A + + APPLICATION GUIDELINES ON REFERENCING DOCUMENTS FROM OTHER + ORGANIZATIONS + +PART I - Developed by TSAG at its January 1998 Meeting + + The following guidelines should be used in conjunction with the + relevant provisions of Recommendations A.3, A.4, A.5 and A.23. + + 1. Ownership/Change Control + - When considering using material from other organizations it is + preferable to only include references to other standards, + rather than incorporate text from a standard in the body of a + Recommendation. Exceptionally, full text incorporation is + necessary rather than a reference where Recommendations having + regulatory connotations are concerned. + + - Reference should be made to the particular issue of a standard. + In this way the ITU-T is in control of what is actually + referenced even if the source organization updates the + standard. + - References to standards from other organizations should only be + made where those organizations continue to provide public + access to the version referenced even when updated versions are + issued. + - When a draft Recommendation is being prepared and the intention + is to reference a standard from another organization, that + organization should be advised by the TSB of the ITU-T's + intention and should be requested to notify the ITU-T of any + impending changes to the standard and of any reissues of the + standard. (This request may be part of the correspondence + described in Recommendation A.5, section 2.4.) It is however + the responsibility of the Study Group to regularly review its + Recommendations and check if the references are correct and if + necessary to reissue the Recommendation with revised references + (and where necessary make changes in the body of the + Recommendation where the reference is made.). + - Should an organization intend to remove completely an earlier + version of a standard the ITU-T should be advised so that it + can either incorporate the text in the Recommendation or change + the reference to a later version. + + 2. Access + - The objective is to have referenced standards freely available + via the Web so that people purchasing a Recommendation may get + access to the references. A warning should be given to + purchasers of ITU-T Recommendations that they may have to + + + +Brett, et. al. Informational [Page 10] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + additionally purchase the referenced standards. This could be + done by including a note to such effect in the introduction to + Recommendations where references are included. + - When developing a Recommendation where consideration is being + given to using references to other standards the Study Group + should investigate with the TSB whether the referenced text + will be available free of charge or if a payment will be + required. This should be taken into account by the Study Group + as it may influence the decision to use the reference. + + 3. IPR + - In principle, if the IPR policy of the organization owning a + referenced standard is more stringent than that of the ITU-T + then there should not be any IPR problems with including the + reference. However, this may not be the case with all + organizations. Further guidelines are being prepared by the + Director of the TSB. + + 4. Approval + - The approval procedures in Resolution 1 have to be followed for + Recommendations containing references (wholly or in part) to + standards from other bodies even in the case where the + Recommendation is just a reference to another standard. + +PART II - Developed by TSAG at its September 1998 Meeting + + The following guidelines should be used in conjunction with + Recommendation A.5. + + 1. Nested References + Issue: RFCs often contain references to related RFCs and ITU-T + Recommendations which, in turn, may contain references to other + RFCs and Recommendations. It is unclear how to handle these nested + references in the context of A.5. + + Guideline: Each time an RFC is referenced within an ITU-T + Recommendation, all references within that RFC should be listed in + the report documenting the decision of the Study Group. No further + treatment is necessary, although the Study Group may wish to + investigate those references further on a case-by-case basis. The + same guidelines apply when referencing the documents of other + organizations. + + 2. Subsequent Referencing of the Same Document + Issue: It is possible that the same RFC may be considered for + referencing in multiple Recommendations. It is unclear what + evaluation is required in subsequent references. + + + + +Brett, et. al. Informational [Page 11] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + Guideline: The justification for referencing the same document in + different Recommendations is likely to be different. Consequently, + it is important that separate evaluations be made each time the + document is referenced. However, only items 1 - 8 in Appendix I + (and Annex A) of Recommendation A.5 need to be completed if the + referenced organization has already been qualified per Section 3 + of A.5. Since items 9 and 10 are dependent on the organization and + not on the document, they need to be completed only the first time + a document from that organization is being considered for + referencing and only if such information has not been documented + already. + + 3. Availability of Referenced Document + Issue: Paragraph 2.2.10 of A.5 requires that the contributing + Study Group member provide a full copy of the existing document. + It is unclear whether paper copies are mandatory or whether + electronic availability, for example, on a Web site, is + sufficient. + + Guideline: The objective is to have referenced documents available + via the Web at no cost so that the Study Group members may proceed + with their evaluation. Accordingly, if a referenced document is + available in this manner, it is sufficient for the contributing + member to provide its exact location on the Web. On the other + hand, if the document is not available in this manner, a full copy + must be provided (in electronic format if permissible by the + referenced organization, otherwise in paper format). + + 4. Referencing of IETF Documents + Issue: It is unclear whether or not it is appropriate to reference + RFCs that are not on the standards track (the "Informational" and + "Experimental" RFCs) or those that are at the first level of + standardization (the "Proposed Standard" RFCs). + + Guideline: Some outputs of organizations may not be appropriate + for normative referencing, others may not be appropriate for any + referencing, normative or informative. In the case of the IETF, it + is not appropriate to make any references to "Internet Drafts" or + to "Historic" RFCs as noted in A.5. In addition, it is not + appropriate to make normative references to RFCs that are + considered "Informational" or "Experimental". References to RFCs + that have the status of "Proposed Standards" should be made with + caution and should be evaluated on a case-by-case basis because + such standards are considered immature in the sense that they may + change if problems are found in real implementations or if better + solutions are identified. + + + + + +Brett, et. al. Informational [Page 12] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + + 5. IETF Address Changes + The electronic address of the IETF archives has changed. + Accordingly the addresses in items 4 and 9.8 of Annex A should be + changed, respectively to: + http://www.ietf.org/ipr.html - for the IPR archive + http://www.rfc-editor.org/rfc.html - for the RFC archive + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Brett, et. al. Informational [Page 13] + +RFC 2436 ISOC/IETF - ITU-T Collaboration October 1998 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1998). 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. + + + + + + + + + + + + + + + + + + + + + + + + +Brett, et. al. Informational [Page 14] + -- cgit v1.2.3