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

Network Working Group                                   S. Krishnan, Ed.
Internet-Draft                                             M. Kuehlewind
Obsoletes: 4052, 4691 (if approved)                                Q. Wu
Intended status: Informational                                       IAB
Expires: 21 January 2027                                    20 July 2026

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

Abstract

   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

   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 21 January 2027.

Krishnan, et al.         Expires 21 January 2027                [Page 1]
Internet-Draft           IAB Liaison Management                July 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
     1.2.  IETF's Preference for Informal Collaboration  . . . . . .   5
   2.  Establishing Formal Liaison Relationships . . . . . . . . . .   5
     2.1.  Purposes and Expectations for Formal Liaison
           Relationships . . . . . . . . . . . . . . . . . . . . . .   6
     2.2.  Liaison Communications  . . . . . . . . . . . . . . . . .   6
   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

   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

Krishnan, et al.         Expires 21 January 2027                [Page 2]
Internet-Draft           IAB Liaison Management                July 2026

   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 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 IAB to manage technical liaison
   relationships, as stated in its charter [BCP39] 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."

Krishnan, et al.         Expires 21 January 2027                [Page 3]
Internet-Draft           IAB Liaison Management                July 2026

   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 [I-D.iab-rfc4053bis]).

   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.

1.1.  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 Section 3 in this document.

Krishnan, et al.         Expires 21 January 2027                [Page 4]
Internet-Draft           IAB Liaison Management                July 2026

   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 Section 1.2.

   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.

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

2.  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 [RFC3113], [RFC3563] , [RFC3718], [RFC4965], [RFC4965],
   [RFC6756], and [RFC7241]).

Krishnan, et al.         Expires 21 January 2027                [Page 5]
Internet-Draft           IAB Liaison Management                July 2026

2.1.  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 [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.

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

Krishnan, et al.         Expires 21 January 2027                [Page 6]
Internet-Draft           IAB Liaison Management                July 2026

   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 [I-D.iab-rfc4053bis].

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

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

Krishnan, et al.         Expires 21 January 2027                [Page 7]
Internet-Draft           IAB Liaison Management                July 2026

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

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

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 21 January 2027                [Page 8]
Internet-Draft           IAB Liaison Management                July 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

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

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

Krishnan, et al.         Expires 21 January 2027                [Page 9]
Internet-Draft           IAB Liaison Management                July 2026

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

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

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-04, 3 July
              2026, <https://datatracker.ietf.org/doc/html/draft-iab-
              rfc4053bis-04>.

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

   [RFC3563]  Zinin, A., "Cooperative Agreement Between the ISOC/IETF
              and ISO/IEC Joint Technical Committee 1/Sub Committee 6
              (JTC1/SC6) on IS-IS Routing Protocol Development",
              RFC 3563, DOI 10.17487/RFC3563, July 2003,
              <https://www.rfc-editor.org/rfc/rfc3563>.

   [RFC3718]  McGowan, R., "A Summary of Unicode Consortium Procedures,
              Policies, Stability, and Public Access", RFC 3718,
              DOI 10.17487/RFC3718, February 2004,
              <https://www.rfc-editor.org/rfc/rfc3718>.

Krishnan, et al.         Expires 21 January 2027               [Page 10]
Internet-Draft           IAB Liaison Management                July 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>.

   [RFC4965]  Mule, J. and W. Townsley, "CableLabs - IETF
              Standardization Collaboration", RFC 4965,
              DOI 10.17487/RFC4965, September 2007,
              <https://www.rfc-editor.org/rfc/rfc4965>.

   [RFC6756]  Trowbridge, S., Ed., Lear, E., Ed., Fishman, G., Ed., and
              S. Bradner, Ed., "Internet Engineering Task Force and
              International Telecommunication Union - Telecommunication
              Standardization Sector Collaboration Guidelines",
              RFC 6756, DOI 10.17487/RFC6756, September 2012,
              <https://www.rfc-editor.org/rfc/rfc6756>.

   [RFC7241]  Dawkins, S., Thaler, P., Romascanu, D., and B. Aboba, Ed.,
              "The IEEE 802/IETF Relationship", RFC 7241,
              DOI 10.17487/RFC7241, July 2014,
              <https://www.rfc-editor.org/rfc/rfc7241>.

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, Russ Housley 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

Krishnan, et al.         Expires 21 January 2027               [Page 11]
Internet-Draft           IAB Liaison Management                July 2026

   Email: ietf@kuehlewind.net

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

Krishnan, et al.         Expires 21 January 2027               [Page 12]