



Network Working Group                                   S. Krishnan, Ed.
Internet-Draft                                             M. Kuehlewind
Obsoletes: 4052 (if approved)                                      Q. Wu
Intended status: Informational                                       IAB
Expires: 15 August 2026                                 11 February 2026


       IAB Processes for Management of IETF Liaison Relationships
                        draft-iab-rfc4052bis-02

Abstract

   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 formal liaison relationships.

About This Document

   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-iab-rfc4052bis/.

   Source for this draft and an issue tracker can be found at
   https://github.com/intarchboard/draft-iab-rfc4052bis.

Status of This Memo

   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 15 August 2026.






Krishnan, et al.         Expires 15 August 2026                 [Page 1]

Internet-Draft           IAB Liaison Management            February 2026


Copyright Notice

   Copyright (c) 2026 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Changes compared to RFC4052 . . . . . . . . . . . . . . .   4
   2.  Establishing Formal Liaison Relationships . . . . . . . . . .   5
     2.1.  IETF's Preference for Informal Collaboration  . . . . . .   5
     2.2.  Purposes and Expectations for Formal Liaison
           Relationships . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Liaison Communications  . . . . . . . . . . . . . . . . .   7
   3.  Liaison Manager Responsibilities and Expectations . . . . . .   7
     3.1.  Speaking for the IETF . . . . . . . . . . . . . . . . . .   8
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Appendix A: Document Process  . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   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 "formal liaison relationships".








Krishnan, et al.         Expires 15 August 2026                 [Page 2]

Internet-Draft           IAB Liaison Management            February 2026


   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 establishment and maintenance of formal liaison relationships
      Section 2, and

   *  the appointment and responsibilities of IETF liaison managers
      Section 3.

   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 Internet Architecture Board to manage formal
   liaison relationships.  As stated in its charter [BCP39] 2.(f), "The
   IAB acts as a 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 formal 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 formal 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;

   *  allow for the collaboration and coordination of efforts between
      the IETF and other organizations.

   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



Krishnan, et al.         Expires 15 August 2026                 [Page 3]

Internet-Draft           IAB Liaison Management            February 2026


   relationship.  Hence, in almost all cases the need for a formal
   relationship is mostly driven by other organizations rather than by
   the IETF.

   If tighter coordination is needed, e.g. in cases where there are a
   large number of document dependencies when specifications are
   developed in parallel, 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.  The liaison manager should be involved in the
   organization and the running of these activities.

   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.

1.1.  Changes compared to RFC4052

   This version of the document contains the following updates:

   1.   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.

   2.   Statement that the "IAB acts as representative of the interests
        of [..] the Internet Society" has been removed.

   3.   Role of the Liaison Representative (Section 2.3) has been
        removed since this role is not used in practice.

   4.   Clarification 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.

   5.   Section on Summary of IETF Liaison Manager Responsibilities
        reworked.

   6.   Section 4 on "Approval and Transmission of Liaison Statements"
        has been moved to 4053bis.

   7.   Better description of both the aspects and requirements for
        establishing a formal relationship



Krishnan, et al.         Expires 15 August 2026                 [Page 4]

Internet-Draft           IAB Liaison Management            February 2026


   8.   Clarified there are no specific establishment procedures for
        informal collaboration and formal liaison communications in form
        of liaison statement don't require a formal liaison relationship

   9.   Update of description of aspects for establishing a formal
        relationship and clarifications about informal collaborations

   10.  Merged liaison manager responsibilities sections

   11.  Removal of one level in the dcoument structure

   12.  Move "Liaison Communication" into a subsection of "Establishing
        a Liaison Relationship" and merge some redundant text

   13.  Align wording to consistently use “formal liaison relationship”

   14.  Small clarification that the appointment of a liaison manager
        establishes the formal relationship

2.  Establishing Formal Liaison Relationships

   There is no set process or form for establishing a formal liaison
   relationship; the IETF participants and the peer organization can
   initiate a conversation with the IAB, and after discussion may come
   to an agreement to form the 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 [RFC3113],
   [RFC3131], and [RFC3356]).

2.1.  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 from all
   participants in 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.







Krishnan, et al.         Expires 15 August 2026                 [Page 5]

Internet-Draft           IAB Liaison Management            February 2026


   There is no specific procedure to enable informal collaboration.
   Such an working relationship simply exists by defacto when members of
   both organizations cross-collaborate and participate in the groups
   with overlapping interest.

2.2.  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 in the peer
          organization's groups and forums.

       *  Ability to participate in and contribute to the ongoing work
          of the peer organization.

   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 [BCP9].  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.




Krishnan, et al.         Expires 15 August 2026                 [Page 6]

Internet-Draft           IAB Liaison Management            February 2026


2.3.  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 use a form known as a "liaison
   statement" (LS).  Procedures for sending, managing, and responding to
   liaison statements are discussed in [I-D.iab-rfc4053bis].

   Formal communications in the form of liaison statements, if needed,
   can be used without establishing a formal liaison relationship.  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
   [I-D.iab-rfc4053bis].

   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.

3.  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.




Krishnan, et al.         Expires 15 August 2026                 [Page 7]

Internet-Draft           IAB Liaison Management            February 2026


   *  Provide additional communication regarding 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.  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.

3.1.  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.  However, the mandate for IETF liaison managers is
   strictly limited to conveying IETF consensus to the liaised
   organization.  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.  Specifically, 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.

4.  Security Considerations

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

5.  IANA Considerations

   This document has no IANA actions.







Krishnan, et al.         Expires 15 August 2026                 [Page 8]

Internet-Draft           IAB Liaison Management            February 2026


6.  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.

7.  References

7.1.  Normative References

   [BCP39]    Best Current Practice 39,
              <https://www.rfc-editor.org/info/bcp39>.
              At the time of writing, this BCP comprises the following:

              IAB and B. Carpenter, Ed., "Charter of the Internet
              Architecture Board (IAB)", BCP 39, RFC 2850,
              DOI 10.17487/RFC2850, May 2000,
              <https://www.rfc-editor.org/info/rfc2850>.

              Carpenter, B., Ed., "IAB Charter Update for RFC Editor
              Model", BCP 39, RFC 9283, DOI 10.17487/RFC9283, June 2022,
              <https://www.rfc-editor.org/info/rfc9283>.

   [BCP9]     Best Current Practice 9,
              <https://www.rfc-editor.org/info/bcp9>.
              At the time of writing, this BCP comprises the following:

              Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,
              <https://www.rfc-editor.org/info/rfc2026>.

              Dusseault, L. and R. Sparks, "Guidance on Interoperation
              and Implementation Reports for Advancement to Draft
              Standard", BCP 9, RFC 5657, DOI 10.17487/RFC5657,
              September 2009, <https://www.rfc-editor.org/info/rfc5657>.

              Housley, R., Crocker, D., and E. Burger, "Reducing the
              Standards Track to Two Maturity Levels", BCP 9, RFC 6410,
              DOI 10.17487/RFC6410, October 2011,
              <https://www.rfc-editor.org/info/rfc6410>.







Krishnan, et al.         Expires 15 August 2026                 [Page 9]

Internet-Draft           IAB Liaison Management            February 2026


              Resnick, P., "Retirement of the "Internet Official
              Protocol Standards" Summary Document", BCP 9, RFC 7100,
              DOI 10.17487/RFC7100, December 2013,
              <https://www.rfc-editor.org/info/rfc7100>.

              Kolkman, O., Bradner, S., and S. Turner, "Characterization
              of Proposed Standards", BCP 9, RFC 7127,
              DOI 10.17487/RFC7127, January 2014,
              <https://www.rfc-editor.org/info/rfc7127>.

              Dawkins, S., "Increasing the Number of Area Directors in
              an IETF Area", BCP 9, RFC 7475, DOI 10.17487/RFC7475,
              March 2015, <https://www.rfc-editor.org/info/rfc7475>.

              Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
              Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
              DOI 10.17487/RFC8789, June 2020,
              <https://www.rfc-editor.org/info/rfc8789>.

              Rosen, B., "Responsibility Change for the RFC Series",
              BCP 9, RFC 9282, DOI 10.17487/RFC9282, June 2022,
              <https://www.rfc-editor.org/info/rfc9282>.

7.2.  Informative References

   [I-D.iab-rfc4053bis]
              Kühlewind, M., Krishnan, S., and Q. Wu, "Procedures for
              Handling Liaison Statements to and from the IETF", Work in
              Progress, Internet-Draft, draft-iab-rfc4053bis-00, 17
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-iab-rfc4053bis-00>.

   [RFC3113]  Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin,
              "3GPP-IETF Standardization Collaboration", RFC 3113,
              DOI 10.17487/RFC3113, June 2001,
              <https://www.rfc-editor.org/rfc/rfc3113>.

   [RFC3131]  Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S.,
              Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF
              Standardization Collaboration", RFC 3131,
              DOI 10.17487/RFC3131, June 2001,
              <https://www.rfc-editor.org/rfc/rfc3131>.

   [RFC3356]  Fishman, G. and S. Bradner, "Internet Engineering Task
              Force and International Telecommunication Union -
              Telecommunications Standardization Sector Collaboration
              Guidelines", RFC 3356, DOI 10.17487/RFC3356, August 2002,
              <https://www.rfc-editor.org/rfc/rfc3356>.



Krishnan, et al.         Expires 15 August 2026                [Page 10]

Internet-Draft           IAB Liaison Management            February 2026


   [RFC4052]  Daigle, L., Ed. and IAB, "IAB Processes for Management of
              IETF Liaison Relationships", BCP 102, RFC 4052,
              DOI 10.17487/RFC4052, April 2005,
              <https://www.rfc-editor.org/rfc/rfc4052>.

   [RFC4053]  Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
              Handling Liaison Statements to and from the IETF",
              BCP 103, RFC 4053, DOI 10.17487/RFC4053, April 2005,
              <https://www.rfc-editor.org/rfc/rfc4053>.

Acknowledgments

   [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.  The authors would like to
   thank Leslie Daigle, Roman Danyliw, Dhruv Dhody, Joel Halpern, Wes
   Hardaker, and Warren Kumari for their valuable comments and
   suggestions to improve this document.

Authors' Addresses

   Suresh Krishnan (editor)
   IAB
   Email: suresh.krishnan@gmail.com


   Mirja Kuehlewind
   IAB
   Email: ietf@kuehlewind.net


   Qin Wu
   IAB
   Email: bill.wu@huawei.com














Krishnan, et al.         Expires 15 August 2026                [Page 11]
