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

Network Working Group                                   S. Krishnan, Ed.
Internet-Draft                                             M. Kuehlewind
Obsoletes: 4052 (if approved)                                      Q. Wu
Intended status: Informational                                       IAB
Expires: 23 April 2026                                   20 October 2025

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

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 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 23 April 2026.

Krishnan, et al.          Expires 23 April 2026                 [Page 1]
Internet-Draft           IAB Liaison Management             October 2025

Copyright Notice

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Changes compared to RFC4052 . . . . . . . . . . . . . . .   4
   2.  Establishing Formal Liaison Relationships . . . . . . . . . .   5
   3.  Liaison Communications  . . . . . . . . . . . . . . . . . . .   6
   4.  Liaison Manager Responsibilities  . . . . . . . . . . . . . .   7
     4.1.  Speaking for the IETF . . . . . . . . . . . . . . . . . .   8
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  Appendix A: Document Process  . . . . . . . . . . . . . . . .   8
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

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 "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:

Krishnan, et al.          Expires 23 April 2026                 [Page 2]
Internet-Draft           IAB Liaison Management             October 2025

   *  the establishment and maintenance of liaison relationships
      Section 2, and

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

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

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

Krishnan, et al.          Expires 23 April 2026                 [Page 3]
Internet-Draft           IAB Liaison Management             October 2025

   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 relationships,
   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.  Description of formal and informal relationships.

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

   9.  Clarified there are no specific establishment procedures for
       informal relationships and described handling of liaison
       communications that don't have a formal relationship.

Krishnan, et al.          Expires 23 April 2026                 [Page 4]
Internet-Draft           IAB Liaison Management             October 2025

2.  Establishing Formal Liaison Relationships

   A formal liaison relationship is established between the IETF and
   another organization when it is mutually agreeable and beneficial to
   do so.

   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.

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

   Note that 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 further explained in
   [I-D.kuehlewind-iab-rfc4053bis].

   From the IETF's perspective a formal relationship is needed only when
   required for specific purposes, such as:

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

   b) 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:

Krishnan, et al.          Expires 23 April 2026                 [Page 5]
Internet-Draft           IAB Liaison Management             October 2025

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

   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 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 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 relationship appropriately, allowing
   sufficient time for the requests they make on the other organization
   to be processed.

3.  Liaison Communications

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

   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.

Krishnan, et al.          Expires 23 April 2026                 [Page 6]
Internet-Draft           IAB Liaison Management             October 2025

4.  Liaison Manager Responsibilities

   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 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 additional messages for providing further context.
   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.  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 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.

Krishnan, et al.          Expires 23 April 2026                 [Page 7]
Internet-Draft           IAB Liaison Management             October 2025

4.1.  Speaking for the IETF

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

5.  Security Considerations

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

6.  IANA Considerations

   This document has no IANA actions.

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

8.  References

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

Krishnan, et al.          Expires 23 April 2026                 [Page 8]
Internet-Draft           IAB Liaison Management             October 2025

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

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

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

Krishnan, et al.          Expires 23 April 2026                 [Page 9]
Internet-Draft           IAB Liaison Management             October 2025

   [I-D.kuehlewind-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-kuehlewind-iab-rfc4053bis-
              01, 13 June 2025, <https://datatracker.ietf.org/doc/html/
              draft-kuehlewind-iab-rfc4053bis-01>.

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

   [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

Krishnan, et al.          Expires 23 April 2026                [Page 10]
Internet-Draft           IAB Liaison Management             October 2025

   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 23 April 2026                [Page 11]