]> IAB

suresh.krishnan@gmail.com

IAB

ietf@kuehlewind.net

IAB

bill.wu@huawei.com

This document describes the procedures used by the Internet Architecture Board (IAB) to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also outlines the expectations of the IAB in establishing formal liaison relationships and describes the responsibilities of IAB-appointed IETF liaison managers. About This Document Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction This document describes the procedures to establish and maintain formal liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This process is managed by the Internet Architecture Board (IAB) and designed such that the IETF can effectively collaborate with other organizations in the international standards community when a formal relationship is required. The IAB also serves as contact point for any matters regarding liaison management beyond the scope of this document. The IETF, as an organization, has the need to engage in direct communication to coordinate joint activities with various other SDOs or similar formal organizations involving Internet-related technologies. This is useful in order to, e.g., avoid overlap in work efforts, and to manage interactions between their groups. The IETF process does not require any formal handling for such a communication and coordination to happen, however, sometimes a formal process is required by the other organization or seen as beneficial to support the needed level of collaboration. In cases where the mutual effort to communicate and coordinate activities is formalized, these relationships are generically referred to as "formal liaison relationships". In such cases, a person is designated by the IAB to manage a given formal liaison relationship; that person is generally called the "IETF liaison manager" to the other organization. Often, the other organization will similarly designate their own liaison manager to the IETF. This document is chiefly concerned with:

• the expectations in and establishment of formal liaison relationships , and
• the appointment and responsibilities of IETF liaison managers .

The management of other organizations' liaison managers to the IETF, whether or not in the context of a formal liaison relationship, is outside the scope of this document. The IETF has tasked the IAB to manage technical liaison relationships, as stated in its charter 2.(f), "The IAB acts as representative of the interests of the IETF and the Internet Society in technical liaison relationships with other organizations concerned with standards and other technical and organizational issues relevant to the world-wide Internet. Liaisons are kept as informal as possible and must be of demonstrable value in improving the quality of IETF specifications. Individual members of the IETF are appointed as liaisons to other organizations by the IAB or IESG as appropriate." In general, collaboration between SDOs is needed when there are areas of technical development of mutual interest. For the most part, SDOs would rather leverage existing work done by other organizations than recreate it themselves (and would like the same done with respect to their own work). Collaboration and coordination of efforts between the IETF and other organizations can help to prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate. While technical overlap and the respective desire for collaboration can be handled without establishing a formal liaison relationship, the formalization of the relationship can provide a framework to communicate authoritative information of one organization's dependencies on the other's work, if desired or required. It is important to note that participation in the IETF work is open to everyone, and all working documents and RFCs are freely available to everyone without the need for a formal liaison relationship. Hence, in many cases the need for a formal relationship is mostly driven by process restrictions or other requirements for collaboration within other organizations. Also, in many other cases where no formal relationship with a dedicated liaison manager is required and established, the IETF still closely collaborates with other organizations, using informal or formal communication in form of liaison statements (see also ). If even tighter coordination is needed, independent of the existence of an established formal liaison relationship, the IAB might consider additional activities such as meetings or calls with the relevant people (e.g. chairs, ADs, and authors). Such activities could be one-time events or organized in a standing groups. If a formal liaison relationship exists, the liaison manager should be involved in the organization and the running of these activities. Such activities can e.g. make sense in cases where there are a large number of document dependencies; this often happens when specifications are developed in parallel. Since the IAB is ultimately responsible for liaison management, anyone who has an issue with a relationship (whether an IETF participant or a person from the peer organization) should first consult the IAB's designated liaison manager, and if that does not result in a satisfactory outcome, then consult the IAB itself.

Changes compared to RFC4052 This document revises RFC4052 and obsoletes RFC4691. RFC4691 builds on RFC4052 and already had a lot of overlap; especially the guidance for liaison managers including the explicit part of "speaking for the IETF" has been merged into in this document. The revision of RFC4052 aligns the defined process with current practices and specifically clarifies the purposes and exceptions for establishing liaison relationships. Particularly, it emphasis that there are no formal requirements in the IETF process that require a formal liaison relationship for participating in the IETF and it clearly explains the role of and preference for informal collaborations (see . Further, the role of the Liaison Representative in RFC4052 was removed since this role is not used in practice. The Liaison Manager Responsibilities were clarified and re-focused on good, productive, and timely (formal and informal) communication. And the section "Approval and Transmission of Liaison Statements" in RFC4052 was moved to 4053bis.

IETF's Preference for Informal Collaboration Generally informal collaboration between the IETF and peer organizations is preferred whenever direct working relationships between the members of both organizations is possible. Specifically, there are no processes in the IETF that require a formal liaison relationship as our work is conducted in open public meetings and on mailing lists where anyone can contribute. Inputs to the IETF, regardless of the type of relationship, are given equal weight and standing. When a similar structure exists in the peer organization and all participants have access to open working documents and communication mechanisms, there may not be a need for a more formal structure. A de facto working relationship exists when members of both organizations cross-collaborate and participate in the groups with overlapping interest. No further structure or procedures are required in this case.

Establishing Formal Liaison Relationships There is no set process or form for establishing a formal liaison relationship with the IETF; the IETF participants and the peer organization can initiate a conversation with the IAB, and after discussion may come to an agreement to form a formal liaison relationship. Once the IAB and the other organization mutually agree that a formal liaison relationship is beneficial, the IAB appoints a liaison manager to establish it. In some cases, the intended scope and guidelines for the collaboration are documented specifically (e.g., see , , , , , , and ).

Purposes and Expectations for Formal Liaison Relationships From the IETF's perspective a formal liaison relationship is needed only when required for specific purposes, such as:

1. There is an overlap in work between one or more groups in each organization that requires close collaboration that would not be possible without a formal liaison relationship. This might include situations where one group in one organization has a dependency on a document produced in the other organization and is requesting in-depth support or would like feedback on internal documents. However note that the agreed need for close collaboration is a pre-condition for establishing a formal liaison relationship but is not alone sufficient for the IETF to require the establishment of a formal liaison relationship.
2. The peer organization of the IETF may require a more formal communication structure in order to allow the IETF to work directly within the peer organization's processes. Some potential formal requirements from the peer organizations include:
   • Access restrictions for accessing the peer organization's working documents or standards.
   • Ability to participate and contribute directly to the ongoing work in the peer organization's groups and forums.

In setting up a formal liaison relationship, the IAB expects that there will be a mutual exchange of views and discussion of the best approach for undertaking new standardization work items. Any work items resulting for the IETF will be undertaken using the usual IETF procedures, defined in . The peer organization often has different organizational structures and procedures than the IETF, and these differences will require some flexibility on the part of both organizations to accommodate. There is an expectation that both organizations will use the formal liaison relationship appropriately, allowing sufficient time for the requests they make on the other organization to be processed.

Liaison Communications Communications between organizations use a variety of formal and informal channels irrespective of established relationships. The stated preference of the IETF, which is largely an informal organization, is to use informal channels (e.g., discussion on expert level in a specific working group meeting or mailing list), as these have integrated better into IETF process and historically worked well to expedite matters. In some cases, however, a more formal communication is appropriate, either as an adjunct to the informal channel or in its own place with or without a formal liaison relationship. In the case of formal communications, the established procedures of many organizations produce a "liaison statement" (LS). Procedures for sending, managing, and responding to liaison statements are discussed in . Liaison statements can be sent and received without establishing a formal liaison relationship, if formal communication is desired. In this case, since a formal liaison manager does not exist, the IAB itself will be responsible for ensuring liaison statements are handled appropriately, as also further explained in . Note that communications between organizations have no impact on any other IETF contributions, and should follow the same IETF process and policies and should be open to everyone for inputs and contributions, e.g., input discussion in a specific working group in the IETF.

Liaison Manager Responsibilities and Expectations The main responsibility of the liaison manager is to ensure good, productive, and timely (formal and informal) communication between the organizations. This often includes:

• Ensure received liaison statements are recorded and delivered to the relevant groups.
• Ensure replies are sent in time or it is appropriately communicated why a reply is delayed or not sent.
• Ensure liaison statements from the IETF adhere to the formal requirements of the peer organization (e.g. structure/formatting) and are delivered to the appropriate groups. If a communication from a peer organization is addressed to an inappropriate party, such as being sent directly to the WG but not recorded otherwise or being sent to the wrong WG, the liaison manager will help redirect or otherwise augment the communication.
• Provide additional communication regarding e.g. process matters or known consensus positions in the IETF. This may also require participation in relevant meetings of the peer organization and potentially reporting back to the appropriate IETF organization any material information that is intended to be shared by the peer organization.
• Provide advice to the IETF community and leadership on processes and formal requirements of the other organization as needed.

Formal messages from the IETF to the peer organization are usually carried in liaison statements. The liaison manager must not send liaison statements on their own initiative to a liaised organization on behalf of IETF, or any of its areas and working groups. IETF liaison managers should also communicate and coordinate with other liaison managers where concerned technical activities overlap. Liaison managers also provide updates to the IAB on technical matters, especially if concerns regarding technical overlap or incorrectness are detected. However, given that most organizations are quite large, it is not expected that the liaison manager needs to have a complete overview of everything that is going on there.

Speaking for the IETF In certain situations, the liaison manager may carry additional messages for providing further context. For such additional communication, liaison managers may use any applicable businesslike approach, from private to public communications, and bring in other parties as needed. IETF liaison managers should limit their communication to factual statements or established consensus positions and the level at which that consensus exists (e.g., WG, IESG or IETF). A liaison relationship is not a means to circumvent IETF consensus processes. The liaison manager can speak on behalf of the IETF on the subject matter of the liaison and therefore "represents the IETF", but only after making sure that the IETF consensus is understood.

Security Considerations The security of the Internet is enhanced by robust coordination between SDOs.

IANA Considerations This document has no IANA actions.

Appendix A: Document Process RFC 4052 was published as a BCP. Since the IAB cannot publish BCPs, this document will follow a two step process. The current draft is marked as Informational until the IAB completes its process and formally approves it. After IAB approval, a member of the IESG needs to sponsor the document, and the document will enter the IETF process to update its intended status to BCP. This appendix should be removed at the time of publication.

References Normative References Internet Architecture Board This memo documents the composition, selection, roles, and organization of the Internet Architecture Board. It replaces RFC 1601. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the IAB Charter (RFC 2850) to be consistent with version 3 of the RFC Editor Model (RFC 9280). This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Advancing a protocol to Draft Standard requires documentation of the interoperation and implementation of the protocol. Historic reports have varied widely in form and level of content and there is little guidance available to new report preparers. This document updates the existing processes and provides more detail on what is appropriate in an interoperability and implementation report. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document updates the Internet Engineering Task Force (IETF) Standards Process defined in RFC 2026. Primarily, it reduces the Standards Process from three Standards Track maturity levels to two. This memo documents an Internet Best Current Practice. This document updates RFC 2026 to no longer use STD 1 as a summary of "Internet Official Protocol Standards". It obsoletes RFC 5000 and requests the IESG to move RFC 5000 (and therefore STD 1) to Historic status. RFC 2026 describes the review performed by the Internet Engineering Steering Group (IESG) on IETF Proposed Standard RFCs and characterizes the maturity level of those documents. This document updates RFC 2026 by providing a current and more accurate characterization of Proposed Standards. This document removes a limit on the number of Area Directors who manage an Area in the definition of "IETF Area". This document updates RFC 2026 (BCP 9) and RFC 2418 (BCP 25). This document requires that the IETF never publish any IETF Stream RFCs without IETF rough consensus. This updates RFC 2026. In RFC 9280, responsibility for the RFC Series moved to the RFC Series Working Group and the RFC Series Approval Board. It is no longer the responsibility of the RFC Editor, and the role of the IAB in the RFC Series is altered. Accordingly, in Section 2.1 of RFC 2026, the sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB" is deleted. Informative References IAB IAB IAB This document describes the procedures for generating and handling liaison statements between the IETF and other Standards Development Organizations (SDOs), so that the IETF can effectively collaborate with other organizations in the international standards community. This document describes the standardization collaboration between 3GPP and IETF. This memo provides information for the Internet community. This document contains the text of the agreement signed between ISOC/IETF and ISO/IEC JTC1/SC6 regarding cooperative development of the IS-IS routing protocol. The agreement includes definitions of the related work scopes for the two organizations, request for creation and maintenance of an IS-IS registry by IANA, as well as collaboration guidelines. This memo provides information for the Internet community. <p>This memo describes various internal workings of the Unicode Consortium for the benefit of participants in the IETF. It is intended solely for informational purposes. Included are discussions of how the decision-making bodies of the Consortium work and their procedures, as well as information on public access to the character encoding & standardization processes.</p> This document describes the collaboration and liaison relationship between the Internet Engineering Task Force (IETF) and the Cable Television Laboratories, Inc. (CableLabs). This memo provides information for the Internet community. This document provides guidance to aid in the understanding of collaboration on standards development between the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) and the Internet Engineering Task Force (IETF) of the Internet Society (ISOC). It is an update of and obsoletes RFC 3356. The updates reflect changes in the IETF and ITU-T since RFC 3356 was written. The bulk of this document is common text with ITU-T A Series Supplement 3 (07/2012). Note: This was approved by TSAG on 4 July 2012 as Supplement 3 to the ITU-T A-Series of Recommendations. This document is not an Internet Standards Track specification; it is published for informational purposes. This document describes the standardization cooperation between Project 802 of the Institute of Electrical and Electronics Engineers (IEEE) and the Internet Engineering Task Force (IETF). This document obsoletes RFC 4441. Note: This document was collaboratively developed by authors from both the IEEE 802 and IETF leadership and was reviewed and approved by the IEEE 802 Executive Committee prior to publication. Internet Architecture Board This document discusses the procedures used by the IAB to establish and maintain liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora. This document also discusses the appointment and responsibilities of IETF liaison managers and representatives, and the expectations of the IAB for organizations with whom liaison relationships are established. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community. The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgments was authored by Leslie Daigle and developed as part of a conversation regarding the management of , and the authors of contributed significantly to it as well. This version of the document is based on and brings it in line with currently followed procedures. The authors would like to thank Leslie Daigle, Roman Danyliw, Dhruv Dhody, Joel Halpern, Wes Hardaker, Russ Housley and Warren Kumari for their valuable comments and suggestions to improve this document.