



Network Working Group                                   S. Krishnan, Ed.
Internet-Draft                                             M. Kuehlewind
Obsoletes: 4052, 4691 (if approved)                                Q. Wu
Intended status: Informational                                       IAB
Expires: 3 September 2026                                   2 March 2026


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

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





Krishnan, et al.        Expires 3 September 2026                [Page 1]

Internet-Draft           IAB Liaison Management               March 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 . . . . . . . . . .   6
     2.1.  IETF's Preference for Informal Collaboration  . . . . . .   6
     2.2.  Purposes and Expectations for Formal Liaison
           Relationships . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  Liaison Communications  . . . . . . . . . . . . . . . . .   7
   3.  Liaison Manager Responsibilities and Expectations . . . . . .   8
     3.1.  Speaking for the IETF . . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   6.  Appendix A: Document Process  . . . . . . . . . . . . . . . .   9
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12

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.  The IAB also
   serves as contact point for any matters regarding liaison management
   beyond the scope of this document.










Krishnan, et al.        Expires 3 September 2026                [Page 2]

Internet-Draft           IAB Liaison Management               March 2026


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















Krishnan, et al.        Expires 3 September 2026                [Page 3]

Internet-Draft           IAB Liaison Management               March 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 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 process restrictions or other
   requirements for collaboration within other organizations.

   If tighter coordination is needed, 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.
   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

   The text in this section is intended to be removed and replaced with
   a shorter, high-level summary before publication.

   This version of the document contains the following updates:









Krishnan, et al.        Expires 3 September 2026                [Page 4]

Internet-Draft           IAB Liaison Management               March 2026


   1.   Notes were added 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 was added 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 was
        reworked.

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

   7.   The description of both the aspects and requirements for
        establishing a formal relationship ws improved.

   8.   Text was addded to clarify 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 was made of the description of aspects for establishing a
        formal relationship and clarifications about informal
        collaborations

   10.  Liaison manager responsibilities sections was merged

   11.  One level in the dcoument structure was removed

   12.  Section on "Liaison Communication" was moved into a subsection
        of "Establishing a Liaison Relationship" and some redundant text
        was merged

   13.  Wording was aligned to consistently use “formal liaison
        relationship”




Krishnan, et al.        Expires 3 September 2026                [Page 5]

Internet-Draft           IAB Liaison Management               March 2026


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

   15.  The intro text was revised including a new initial paragraph to
        further clarify the scope that aligns with text in 4053bis

   16.  RFC4691 was added to the obsolete tag

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

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

   There is no specific procedure to enable informal collaboration.
   Such a 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



Krishnan, et al.        Expires 3 September 2026                [Page 6]

Internet-Draft           IAB Liaison Management               March 2026


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




Krishnan, et al.        Expires 3 September 2026                [Page 7]

Internet-Draft           IAB Liaison Management               March 2026


   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.

   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.





Krishnan, et al.        Expires 3 September 2026                [Page 8]

Internet-Draft           IAB Liaison Management               March 2026


   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, e.g. the outcome of a working group consensus
   call.

4.  Security Considerations

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

5.  IANA Considerations

   This document has no IANA actions.

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:



Krishnan, et al.        Expires 3 September 2026                [Page 9]

Internet-Draft           IAB Liaison Management               March 2026


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

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






Krishnan, et al.        Expires 3 September 2026               [Page 10]

Internet-Draft           IAB Liaison Management               March 2026


              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-01, 11
              February 2026, <https://datatracker.ietf.org/doc/html/
              draft-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>.

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

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








Krishnan, et al.        Expires 3 September 2026               [Page 11]

Internet-Draft           IAB Liaison Management               March 2026


   [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, 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 3 September 2026               [Page 12]
