diff options
Diffstat (limited to 'doc/rfc/rfc4691.txt')
| -rw-r--r-- | doc/rfc/rfc4691.txt | 787 |
1 files changed, 787 insertions, 0 deletions
diff --git a/doc/rfc/rfc4691.txt b/doc/rfc/rfc4691.txt new file mode 100644 index 0000000..26bf076 --- /dev/null +++ b/doc/rfc/rfc4691.txt @@ -0,0 +1,787 @@ + + + + + + +Network Working Group L. Andersson, Ed. +Request for Comments: 4691 IAB +Category: Informational October 2006 + + + Guidelines for Acting as an IETF Liaison to Another Organization + +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 + + Whenever the IETF decides to enter into a liaison relationship with + another organization, such as a Standards Development Organization + (SDO), a consortium, or an industrial forum, a liaison manager is + appointed. The procedures used by the IAB to establish and maintain + liaison relationships between the IETF and other organizations are + described in RFC 4052. This document expands on the role of liaison + managers and liaison representatives, giving guidelines on their + mandate and the expectations, tasks, and responsibilities placed on + them. + +Table of Contents + + 1. Introduction ....................................................2 + 2. IETF Liaison Relationships ......................................3 + 2.1. Related Documents ..........................................3 + 2.2. Liaison Managers and Liaison Representatives ...............3 + 2.3. Written Communications .....................................4 + 2.4. Terminology and Conventions ................................5 + 3. Guidelines for Liaison Managers and Representatives .............5 + 3.1. Mandate ....................................................6 + 3.1.1. Speaking for the IETF ...............................6 + 3.2. Expectations ...............................................6 + 3.3. Responsibilities ...........................................8 + 3.4. Tasks ......................................................9 + 3.5. Relationship Management ...................................10 + 3.5.1. IETF Consensus Process on Liaison Statements .......10 + 3.5.2. Incoming Liaison Statements ........................10 + 3.5.3. Ambiguous Incoming Liaison Statements ..............11 + 3.5.4. Liaison Managers Representing Peer Organizations ...11 + + + +Andersson Informational [Page 1] + +RFC 4691 Liaison Guidelines October 2006 + + + 4. Security Considerations ........................................12 + 5. IANA Considerations ............................................12 + 6. Acknowledgements ...............................................12 + 7. References .....................................................13 + 7.1. Normative References ......................................13 + 7.2. Informative References ....................................13 + +1. Introduction + + In the course of developing Internet standards, the IETF needs to + communicate extensively with various other peer organizations, + including the following: + + o Standards Development Organizations (SDOs) such as the + Telecommunication Standardization Sector of the International + Telecommunication Union (ITU-T) or standardization working groups + of the Institute of Electrical and Electronics Engineers (e.g., + IEEE 802) + + o Consortia such as the World Wide Web Consortium (W3C) + + o Industrial forums such as the Global Grid Forum (GGF) + + These organizations are usually concerned with developing related + standards and technical specifications, so that from time to time + issues of coordination and mutual interest may arise. To facilitate + communications, the IETF, through the Internet Architecture Board + (IAB), establishes permanent liaison relationships with appropriate + parts of these organizations according to the processes described in + RFC 4052 [RFC4052]. + + Whenever the IETF decides to enter into a liaison relationship, a + liaison manager and possibly some liaison representatives are + appointed by the IAB to act as a channel between the IETF and the + peer organization, typically in tandem with counterparts appointed by + the peer organization. + + Sections 2.2, 2.3, and 3 of RFC 4052 briefly set out the basic + functions of the tasks of liaison managers and representatives. Over + time, the number and importance of liaisons have grown, and the + importance of the personal role of IETF liaison managers and + representatives in maintaining effective relationships with peer + organizations has grown concomitantly. This document supplements + [RFC4052] by providing guidelines for liaison managers and liaison + representatives in maintaining communications to peer organizations. + + + + + + +Andersson Informational [Page 2] + +RFC 4691 Liaison Guidelines October 2006 + + +2. IETF Liaison Relationships + + A major goal of the IETF is to develop standards for the Internet, + enabling the development of interoperable implementations. In order + to develop Internet standards, it is frequently necessary for the + IETF to communicate with other organizations that develop standards + for other types of networks, for Internet applications, or for + technologies that the Internet uses. + + In some cases, the IETF and peer organizations consider it mutually + beneficial to have a permanent formal relationship with certain rules + governing the relationship. The organizations then enter into a + "liaison relationship". At a high level, both sides agree to + undertake certain responsibilities with respect to each other. The + most basic liaison responsibility is to communicate information as + necessary, and to respond to requests from peer organizations to + which liaisons are maintained. + + Decisions on IETF liaison relationships are the responsibility of the + IAB. This includes whether or not the IETF should have a liaison + relationship with a particular organization. + +2.1. Related Documents + + The IETF liaison process is specified in several documents. RFC 4052 + [RFC4052] specifies how the IAB manages the IETF liaison + relationship; RFC 4053 [RFC4053] specifies how liaison statements + should be treated. Organization-specific agreements and documents + may also be generated in some cases, e.g., RFC 3356 [RFC3356] + describes the collaboration between the IETF and ITU-T, RFC 3113 + [RFC3113] describes the relationship with the 3rd Generation + Partnership Project (3GPP), and RFC 3131 [RFC3131] describes the one + with the Third Generation Partnership Project 2 (3GPP2). + +2.2. Liaison Managers and Liaison Representatives + + Whenever the IETF enters into a liaison relationship with another + organization, a liaison manager (often referred to as "the IETF + liaison") is appointed by the IAB. This document expands on the + mandate of and the expectations, tasks, and responsibilities placed + on the liaison manager by Section 2.2 of RFC 4052. + + In some cases, it may be necessary to have more than one person + handling the liaison relationship with a given organization. For + example, the time commitment required may be too substantial, or the + technical scope of the liaison relationship may be too broad to be + handled by a single individual. + + + + +Andersson Informational [Page 3] + +RFC 4691 Liaison Guidelines October 2006 + + + In such cases, the IAB may appoint one or more liaison + representatives to supplement the work of the liaison manager by + managing different aspects of the liaison relationship between the + IETF and the other organization. + + The value of personal relationships between the IETF liaison manager + and representatives and members of the peer organization is central + to the roles. The IAB will be looking for people who have both a + good technical understanding of the work being carried out and + effective personal relationships within the peer organization. + Ongoing face-to-face interactions between the IETF liaisons and + members of the peer organization are seen as critical to the + effective functioning of the role. These interactions should allow + the liaisons to keep the IETF abreast, and preferably ahead, of + matters of mutual interest or potential conflict. When the liaison + is working effectively, it should facilitate the IETF and the peer + organization working synergistically and reduce the chance of + overlapping or conflicting standards being created. + +2.3. Written Communications + + Aside from the personal contacts between liaisons and the peer + organization, extensive communication may occur between the IETF and + the peer organizations through written materials. Much of this + communication is through liaison statements that typically contain + plans, new developments, and time schedules of which one party + believes that the other party should be aware. + + The liaison manager should be aware of these written communications + and assist both parties to see that appropriate action is taken in + relation to liaison statements passing in both directions. + + For example, when a liaison organization, such as ITU-T, needs to + reference material that is under development in the IETF: the final + reference in the peer organization's document needs the permanent + identifier (RFC number) that will be assigned to the Internet Draft + when it is approved and published. To meet the publication schedule + of the peer organization, a liaison statement is often sent to the + IETF requesting that an RFC number be assigned within the required + timeframe. In response, the IETF can provide the RFC number or + explain why it is not possible to provide this within the timeframe + requested. + + An alternative situation that involves more specific action by the + liaison manager also involves requests for this kind of expedited + action on RFCs. For example, 3GPP/3GPP2 and the Open Mobile Alliance + (OMA) provide the IETF with an updated list of dependencies between + their documents and IETF documents on a monthly basis, indicating + + + +Andersson Informational [Page 4] + +RFC 4691 Liaison Guidelines October 2006 + + + what documents are needed and the required timeframe. In this case, + the liaison manager tracks the dependency list and, when necessary, + conveys the request for expedited assignment to the appropriate IETF + Area Director (AD). + +2.4. Terminology and Conventions + + Terminology relating to IETF liaison procedures is found in + [RFC4052]. Terms defined below are valid for this document only. + + Liaison manager + + A person appointed to manage an IETF liaison relationship with + another organization. + + Liaison representative + + A person appointed to manage a certain (sub-)aspect of an IETF + liaison relationship with another organization. Since it is only the + scale of the responsibilities, mandate, and tasks that is different, + the rest of this document only explicitly mentions liaison managers. + + IETF consensus + + RFC 2026 [RFC2026] and RFC 2418 [RFC2418] discuss the IETF consensus + process. In this document, the term "IETF consensus" is used to + indicate either consensus of the IETF as an organization, an area + within IETF, or a working group. There the term "IETF consensus" + needs to be interpreted in the context in which it is used. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +3. Guidelines for Liaison Managers and Representatives + + Since liaison relationships are intended to be mutually beneficial, + the IETF liaison to another organization must act as a bi-directional + communication link between the IETF and the other organization. + Since the liaison manager has been appointed by the IETF, the liaison + manager needs to be responsive to the needs and aims of the IETF. + + RFC 4052 lists some of the tasks and expectations relating to liaison + managers and liaison representatives. This document expands on their + mandate, provides more detailed discussion, and describes how the + role is executed. + + + + + +Andersson Informational [Page 5] + +RFC 4691 Liaison Guidelines October 2006 + + +3.1. Mandate + + The mandate for IETF liaison managers is strictly limited to + conveying IETF consensus to the liaised organization. The liaison + manager MUST NOT on their own initiative send liaison statements to a + liaised organization on behalf of IETF, or any of its areas and + working groups. Liaison statements are only sent following the + process specified in [RFC4052]. Liaison statements are only sent on + the initiative of the IETF chair, the IAB chair, IETF Area Directors, + or IETF working group chairs. + + In Section 3.3 and Section 3.4, responsibilities and tasks are listed + that enable the IETF to obtain the information to correctly interact + with the liaised organizations and to develop and clearly communicate + IETF consensus. + +3.1.1. Speaking for the IETF + + The IETF functions based on rough consensus, which means that the + right to speak for the IETF cannot be delegated. The liaison manager + speaks on behalf of the IETF on the subject matter of the liaison, + but only after making sure that the IETF consensus is understood. + Some guidelines for understanding IETF consensus are provided above; + however, the most important requirement is close and detailed + coordination/consultation with the IETF community. + +3.2. Expectations + + There are certain expectations placed on liaison managers appointed + by the IETF. Examples of these expectations are listed below. + + Competences required + + The key competence needed in the liaison manager or representative + role is effective management of the liaison process according to + the rules that have been agreed upon. The liaison acts as a + representative of the IETF and not an independent voice with + respect to topics of discussion in the liaison relationship. The + liaison must therefore be careful to distinguish his or her own + views from documented IETF consensus in dealings with the peer + organization. + + To this end, the liaison manager or representative must be able to + communicate effectively with members of the peer organization, + especially in face-to-face situations. This is important both to + communicate the IETF's viewpoint and to gather information about + the issues in the peer organization that the IETF needs to + understand. + + + +Andersson Informational [Page 6] + +RFC 4691 Liaison Guidelines October 2006 + + + In support of the liaison process, a person appointed to act as a + liaison manager or representative on behalf of the IETF is + expected to have a good technical understanding of the key issues + in the subject area, as well as an understanding of the concerns + important to stakeholders in both organizations. + + An IETF liaison needs to have knowledge of the IETF's consensus + process in general, as well as the consensus process(es) applying + to the key issues within the liaison relationship. + + The liaison must also have a good understanding of the processes + used by the peer organization involved. + + Perspective + + Liaison relationships are designed for the mutual benefit of the + organizations participating in the liaison. As such, swift + information flow in both directions is a firm requirement. The + role of an IETF liaison manager is to promote the interests of the + IETF with respect to all topics within the scope of the liaison + relationship. Since the liaison manager "wears an IETF hat", it + is NOT the task of a liaison manager to promote the interests of + the liaised organization within the IETF. + + Distance + + A liaison may not be able to maintain the required perspective if + he or she is closely involved in the outcome of the work in the + peer organization. A conflict of interest might arise if the + liaison is involved in the management of the relevant part of the + peer organization, has a close technical involvement in the work + that is the subject of the liaison, or has a close interest in the + outcome of the work in the peer organization through his or her + employment. When appointing an appropriate person to manage a + liaison relationship, the IAB needs to take into account any + conflicts of interest that the individual being considered might + have. Before a person is appointed to manage a liaison + relationship, he or she will be asked to explicitly state any + conflicts of interest. The IAB will not appoint a person to a + liaison manager position if there is a strong conflict of + interest. For example, an individual with an industry or + organizational leadership position in an organization would + typically not be suitable for appointment as an IETF liaison to + that organization. + + + + + + + +Andersson Informational [Page 7] + +RFC 4691 Liaison Guidelines October 2006 + + + Commitment and opportunity + + A liaison manager needs to be committed to addressing the issues + relevant to the liaison relationship. To handle the job properly, + it is necessary that the liaison be able to allocate sufficient + time to the task. + + Timeliness + + It is expected that a liaison manger will make the IETF aware of + new developments in the subject area in a timely fashion. + +3.3. Responsibilities + + The liaison manager and representatives provide information to the + IETF community in order to enable the IETF to make decisions based on + the best possible information regarding the work in the peer + organization. In turn, information communicated by the IETF liaison + to the liaised organization MUST be based on the relevant IETF + consensus. The liaison manager works with the liaised organization + to ensure that communication is clear. As part of this, the liaison + must clearly differentiate his or her own independent positions from + those that represent IETF consensus. + + It is the responsibility of the liaison manager to ensure that the + liaised organization communicates its requirements to the IETF in a + timely fashion and that the IETF consensus is clearly understood. + This is particularly important in situations where the IETF and the + liaised organization differ substantially in their positions. In + this situation, the liaison manager needs to facilitate prompt + communication so that the IETF and the liaised organization can stay + in close communication and avoid misunderstandings. + + The liaison manager and representatives are responsible for clearly + and correctly communicating the IETF consensus position to the + liaised organization. This includes, when specifically instructed, + carrying any messages from the IETF to the peer organization. + Generally, these communications "represent the IETF", and therefore + due care and consensus must be applied in their construction. + + The liaison manager and representatives are responsible for ensuring + that relevant information originating from the liaised organization, + or other information coming to the attention of the liaison, reaches + the correct destination within the IETF, in a timely and effective + way. + + + + + + +Andersson Informational [Page 8] + +RFC 4691 Liaison Guidelines October 2006 + + +3.4. Tasks + + Examples of tasks performed by the liaison manager are provided + below. Depending on the nature of the liaised organization, the task + may vary in frequency and relative importance. + + 1. Attend relevant meetings and participate in conference calls and + mailing lists within the liaised organization to gather + information relevant to the liaison relationship. Note + developments of interest for onward communication to the IETF. + Communicate the point of view of the IETF consensus to the peer + organization. + + 2. Communicate information relevant to the liaison relationship to + the relevant part of the IETF either by written reports or + verbally; this may involve briefings with a team of IETFers + involved in the liaised organization and other interested parties + within the IETF, e.g., working group chairs and ADs. + + 3. Understand the concerns of both the IETF and the peer + organization, while ensuring that interests of the IETF are + maintained; where there appear to be problems to solve or + conflicts between approaches, work with both parties to encourage + engineers from both organizations to collaborate on solving the + problem and facilitate the development of engineering solutions + in the appropriate organization. + + 4. Prepare reports giving updates on developments in the peer + organization as requested by the IAB or other interested parties + in the IETF. The target for these updates (e.g., the IAB, an AD, + a WG) will typically be identified upon establishment of the + liaison relationship and/or the appointment of the liaison + manager. + + 5. Oversee delivery of liaison statements addressed to the IETF. + This includes ensuring that liaison statements are delivered to + the appropriate destination within the IETF, as well as + shepherding the timely creation of responses by the IETF. + + 6. Work with the liaised organization to ensure that the IETF's + liaison statements are appropriately directed and responded to in + a timely fashion. To accomplish this, the liaison needs to build + a contact network. + + 7. Communicate and coordinate with other IETF liaison managers where + the activities of two or more liaised organizations overlap. + + + + + +Andersson Informational [Page 9] + +RFC 4691 Liaison Guidelines October 2006 + + + 8. Assist with the preparation of IETF liaison statements based on + IETF consensus. + + 9. From time to time, liaison managers and liaison representatives + will have to report to the IETF on the status of the liaison + relationship. For this purpose, they will need to keep track of + outstanding issues on behalf of the IETF. The frequency of the + reports and the recipients of the reports within the IETF will be + decided when the liaison relationship is set up and may be + changed at any time by an IAB decision. IAB or other parties + within the IETF may probe for liaison reports as needed or at + regular intervals. + +3.5. Relationship Management + + Liaison managers will be involved in activities for which they are + not directly responsible, but that might greatly benefit from their + expertise. Some of these activities are outlined below. + +3.5.1. IETF Consensus Process on Liaison Statements + + Liaison statements and other messages sent to a liaised organization + should be based on rough consensus within the IETF or one of its + working groups or areas. Though the liaison manager is not + responsible for determining consensus, it is important that the + liaison manager participate in the process and makes his or her + expertise and knowledge available. + + How consensus is arrived at may vary according to the circumstances. + Some issues are new, and in these cases an open discussion on a + mailing list should be undertaken. For some issues, consensus has + already been arrived at or the liaison statement is a mere statement + of facts (e.g., to inform the liaised organization that an IETF Last + Call had started on a document it had previously expressed interest + in) and in these cases the liaison statement can be written and sent + (such as by a working group chair), possibly involving the liaison + manager. + +3.5.2. Incoming Liaison Statements + + When the IETF receives a liaison statement or other communication + from an organization with which it has a liaison relationship that + includes a request for a response to the communication, the IETF is + committed to providing a timely response. This means that the IETF + will respond within the time requested and provide information as + accurately as possible. This commitment has been one of the key + discussion points in the past, such as within the (g)mpls change + process [GMPLS]. + + + +Andersson Informational [Page 10] + +RFC 4691 Liaison Guidelines October 2006 + + + This commitment does not mean that the IETF will uncritically accept + the content in the incoming liaison statement. To the extent that + the liaison contains requirements on IETF technology or protocols, + they will be taken into consideration based on their technical merit. + +3.5.3. Ambiguous Incoming Liaison Statements + + Sometimes the IETF, an IETF area, or an IETF working group receives + liaison statements from a liaised organization that are sent to the + wrong destination. At other times, the liaison statement is sent to + working groups that are not chartered to do the work that the liaison + statement addresses. In some cases, it might be the situation that + no working group is chartered to do the work. + + In such cases, the liaison manager should assist in finding the + appropriate recipient within the IETF that might respond to the + incoming liaison statement. Sometimes this might require that the + intended response is made available for review on one of the IETF + mailing lists. + +3.5.4. Liaison Managers Representing Peer Organizations + + Liaised organizations may appoint a person to act as a liaison + manager for "their side" of the relationship. This is the person + that will speak authoritatively, within the IETF, on the activities + performed by the other organization. The other organization needs to + make this person known to the IETF. This person might request a slot + on a working group agenda to discuss developments and plans of the + liaised organization. + + Opinions expressed by a liaison mangers of other SDOs, other than + reports on work within the liaised organization, are given equal + weight with opinions expressed by other working group participants. + RFC 3356 [RFC3356] describes this in the context of the relationship + between the IETF and the ITU-T; however, the same model is applicable + to all other organizations with which the IETF has a liaison + relationship. + + The mandates of liaison managers from other organizations are + recognized by the IETF to the extent needed to understand the + information received from the liaison manager. In all other respects + he or she participates in IETF activities under the same conditions + and rules as any other IETF participant. It is important that the + IETF liaison manager understands the extent to which the peer liaison + manager is mandated or delegated to speak on behalf of the peer + organization, and to inform the relevant part of the IETF if the peer + liaison manager appears to be stepping outside the role or stance + given to him or her by the peer organization. + + + +Andersson Informational [Page 11] + +RFC 4691 Liaison Guidelines October 2006 + + + IETF liaison managers should work to include the liaison manager from + the liaised organization within their contact network, and to + understand the positions being communicated by the peer liaison + manager. + +4. Security Considerations + + This document does not specify any protocol or "bits on the wire". + However, since interaction with other standards-making organizations + often relates to security, the liaison manager can assist with + security-related issues, resulting in improved security for Internet + protocols. + +5. IANA Considerations + + There are no requests to the IANA herein. Note that the liaison + manager very often has to understand and convey questions regarding + IETF namespaces managed by IANA. + +6. Acknowledgements + + This document was developed as part of a conversation regarding the + requirements on IETF liaison managers and representatives. Several + IAB members have significantly contributed to the document. Also, + the document has been improved thanks to suggestions and review from + Allison Mankin, Dave Meyer, and Leslie Daigle. + + A special thanks to Bernard Aboba, who, based on his experience as a + liaison manager, has made many useful comments on the subject matter. + Elwyn Davies and Bernard Aboba have both spent time correcting + language and grammar. + + Members of the IAB at the time of approval of this document were the + following: + + Bernard Aboba + Loa Andersson + Brian Carpenter + Leslie Daigle + Elwyn Davies + Kevin Fall + Olaf Kolkman + Kurtis Lindqvist + David Meyer + Dave Oran + Eric Rescorla + Dave Thaler + Lixia Zhang + + + +Andersson Informational [Page 12] + +RFC 4691 Liaison Guidelines October 2006 + + +7. References + +7.1. Normative References + + [RFC2026] Bradner, S., "The Internet Standards Process -- Revision + 3", BCP 9, RFC 2026, October 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2418] Bradner, S., "IETF Working Group Guidelines and + Procedures", BCP 25, RFC 2418, September 1998. + + [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes + for Management of IETF Liaison Relationships", BCP 102, + RFC 4052, April 2005. + +7.2. Informative References + + [GMPLS] Andersson, L., "MPLS and GMPLS Change Process", Work in + Progress, December 2005. + + [RFC3113] Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin, + "3GPP-IETF Standardization Collaboration", RFC 3113, June + 2001. + + [RFC3131] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., + Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF + Standardization Collaboration", RFC 3131, June 2001. + + [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task + Force and International Telecommunication Union - + Telecommunications Standardization Sector Collaboration + Guidelines", RFC 3356, August 2002. + + [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for + Handling Liaison Statements to and from the IETF", BCP + 103, RFC 4053, April 2005. + +Editor's Address + + Loa Andersson + IAB + + EMail: loa@pi.se + + + + + + +Andersson Informational [Page 13] + +RFC 4691 Liaison Guidelines October 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). + + + + + + + +Andersson Informational [Page 14] + |