| Internet-Draft | IAB Liaison Management | February 2025 |
| Krishnan, et al. | Expires 28 August 2025 | [Page] |
This document discusses the procedures used by the IAB to establish and maintain formal 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 the expectations of the IAB in establishing liaison relationships.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-krishnan-iab-rfc4052bis/.¶
Discussion of this document takes place on the Internet Architecture Board Internet Engineering Task Force mailing list (mailto:[email protected]), which is archived at https://mailarchive.ietf.org/arch/browse/iab/. Subscribe at https://www.ietf.org/mailman/listinfo/iab/.¶
Source for this draft and an issue tracker can be found at https://github.com/intarchboard/draft-tab-rfc4052bis.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 28 August 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
The IETF, as an organization, has the need to engage in direct communication or joint work with various other formal organizations. For example, the IETF is one of several Standards Development Organizations, or SDOs, and SDOs including the IETF find it increasingly necessary to communicate and coordinate their activities involving Internet-related technologies. This is useful in order to avoid overlap in work efforts, and to manage interactions between their groups. In cases where the mutual effort to communicate and coordinate activities is formalized, these relationships are generically referred to as "liaison relationships".¶
In such cases, a person is designated by the IAB to manage a given 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 establishment and maintenance of 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 liaison relationship, is outside the scope of this document.¶
The IETF has chartered the Internet Architecture Board to manage the formal liaison relationships. Consistent with its charter [BCP39], the IAB acts as representative of the interests of the IETF in technical liaison relationships with other organizations concerned with standards, and other technical and organizational issues relevant to the worldwide Internet. Liaison relationships are kept informal whenever possible, and must possess demonstrable value to the IETF's technical mandate. Individual participants from the IETF community are appointed as liaison managers to other organizations by the IAB.¶
In general, a liaison relationship is most valuable 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). Establishing a liaison relationship can provide the framework for ongoing communications to¶
prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate;¶
provide authoritative information of one organization's dependencies on the other's work.¶
It is important to note that participation in the IETF work is open to everyone, and all the working documents and RFCs are freely available to everyone without the need for a formal liaison relationship. Hence, in almost all cases the need for a formal relationship is mostly driven by other organizations rather than by the IETF.¶
This version of the document contains the following updates:¶
Notes in the Introduction and Section 2.1 on "Liaison Relationships" that the IETF process itself does not require a formal liaison relationship, e.g. for document access or meeting participation, and therefore the need for a formal liaison relationship is often driven by processes of the peer organization.¶
Statement that the "IAB acts as representative of the interests of [..] the Internet Society" has been removed.¶
Role of the Liaison Representative (Section 2.3) has been removed since this role is not used in pratice.¶
Clarifcation in section on "Liaison Communication" (now 2.3; was 2.4) that informal channels are preferred, with and without a formal liaison relationship, and further that liaison statements have no "special standing" in the IETF process.¶
Section 4 on "Approval and Transmission of Liaison Statements" has been moved to 4053bis.¶
A formal liaison relationship is established when it is mutually agreeable and required for some specific purposes, as viewed by the other organization, the IAB, and the IETF participants conducting the work. Some potential purposes include:¶
The other organization requires a formal liaison relationship in order to provide access to their working documents or standards.¶
A formal liaison relationship is required to provide input to ongoing work at other organizations.¶
Required to participate in meetings of other organizations¶
There is no set process or form for this; the IETF participants and the peer organization approach the IAB, and after discussion come to an agreement to form the relationship. In some cases, the intended scope and guidelines for the collaboration are documented specifically (e.g., see [RFC3113], [RFC3131], and [RFC3356]).¶
In setting up the 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 [BCP9]. The peer organization often has different organizational structure and procedures than the IETF, which will require some flexibility on the part of both organizations to accommodate. There is an expectation that both organizations will use the relationship carefully, allowing sufficient time for the requests they make on the other organization to be processed.¶
As described above, most work on mutually interesting topics will be carried out in the usual way within the IETF and the peer organization. Therefore, most communications will be informal in nature (for example, Working Group (WG) or mailing list discussions).¶
An important function of the liaison manager is to ensure that communication is maintained, productive, and timely. He or she may use any applicable businesslike approach, from private to public communications, and bring in other parties as needed. If a communication from a peer organization is addressed to an inappropriate party, such as being sent to the WG but not copying the Area Director (AD) or being sent to the wrong WG, the liaison manager will help redirect or otherwise augment the communication.¶
IETF liaison managers should also communicate and coordinate with other liaison managers where concerned technical activities overlap.¶
Since the IAB is ultimately responsible for liaison relationships, anyone who has a problem 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, the IAB itself.¶
Communications between organizations use a variety of formal and informal channels irrespective of established liaison 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 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 liaison relationship. In the case of formal communications, the established procedures of many organizations use a form known as a "liaison statement". Procedures for sending, managing, and responding to liaison statements are discussed in [RFC4053].¶
Note that communications between organizations have no difference to any other IETF contributions and should follow the same IETF process and polices and should be open to everyone for inputs and contributions, e.g., input discussion in specific working group in the IETF.¶
The main responsibility of the liaison manager is to ensure good and formally correct communication between the organizations. This often includes:¶
Ensure received LSs 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. formatting) and are delivered to the appropriate groups.¶
Provide additional communication on e.g. process or known consensus positions in the IETF. This may also require participation in relevant meetings of the peer organization and potentially report back to the appropriate IETF organization any material information that is intended to be shared by the peer organization.¶
Formal messages from the IETF to the peer organization are usually carried in liaison statements. In certain situations, the liaison manager may carry addional messages, when specifically instructed. However, if these communications aim to "represent the IETF", they must have consensus, e.g. by being based on an RFC or some other formal statement by a group within the IETF.¶
Optionally liaison manager may provide updates to the IAB on technical matters. Especially if a concern e.g. regarding technical overlap or incorrectness is detected this should be communicated to the IAB. However, given most organization are quite large, it is not expected that the liaison manager can have the full overview about everything that is going on.¶
The security of the Internet is not threatened by these procedures.¶
This document has no IANA actions.¶
[RFC4052] was authored by Leslie Daigle and developed as part of a conversation regarding the management of [RFC4053], and the authors of [RFC4053] contributed significantly to it as well.¶
This version of the document is based on [RFC4052] and brings it in line with currently followed procedures. Further updates to all parts of the text are expected in the process of gathering community feedback for this document.¶