RFC 4052

IAB Processes for Management of IETF Liaison Relationships 🎀

okay bestie, this is RFC 4052, a Best Current Practice from the Internet Architecture Board (IAB), edited by L. Daigle, Ed. 💅 It was published in April 2005 as BCP 102, so the category is Best Current Practice 🌸 The title block doesn't list anything it obsoletes or updates, so it's a standalone doc ✨

Status of This Memo ✨

this doc specifies an Internet Best Current Practice for the Internet Community, and it's asking for discussion and suggestions for improvements 🫶 distribution is unlimited, so share it with everyone 💜

Copyright Notice 🌈

Copyright (C) The Internet Society (2005) 🔥

Abstract 🦋

this doc talks about the procedures the IAB uses to set up and keep up liaison relationships between the IETF and other Standards Development Organizations (SDOs), consortia and industry fora 🍓 it also covers how IETF liaison managers and representatives get appointed and what they're responsible for, plus what the IAB expects from organizations it has liaison relationships with 💖

Table of Contents 🧚

1. Liaison Relationships and Personnel .............................2
2. Aspects of Liaisons and Liaison Management ......................3
   2.1. Liaison Relationships ......................................3
   2.2. Liaison Manager ............................................3
   2.3. Liaison Representatives ....................................4
   2.4. Liaison Communications .....................................4
3. Summary of IETF Liaison Manager Responsibilities ................5
4. Approval and Transmission of Liaison Statements .................6
5. Security Considerations .........................................6
6. Acknowledgements ................................................7
7. References ......................................................8
   7.1. Normative References .......................................8
   7.2. Informative References .....................................8

1. Liaison Relationships and Personnel ✨

okay so the IETF is an organization, and sometimes it needs to talk directly or work jointly with other formal organizations 💅 the IETF is one of several SDOs, and every SDO (the IETF included) is finding it more and more necessary to communicate and coordinate on Internet-related technologies 🫶 this is useful for avoiding overlapping work and for managing how their groups interact 🎀 when that communication and coordination gets formalized, we call these relationships "liaison relationships" 🦋

so basically, a person from the IETF gets designated to manage a given liaison relationship, and that person is usually called the "IETF liaison manager" to the other organization 💖 if the relationship is supposed to cover a complicated or wide range of activities, more people can be designated to handle some parts of the communications, all coordinated by the liaison manager 🌸 the other organization often designates its own liaison manager to the IETF too 🧚

this doc is mainly about:

• the establishment and maintenance of liaison relationships, and
• the appointment and responsibilities of IETF liaison managers and representatives.

the management of other organizations' liaison managers to the IETF is out of scope here, whether or not it's part of a liaison relationship 🙈

the IETF chartered the Internet Architecture Board to manage liaison relationships 👑 consistent with its charter [2], the IAB acts as a representative of the interests of the IETF and the Internet Society in technical liaison relationships with other organizations that care about standards and other technical and organizational issues relevant to the worldwide Internet 🌈 liaison relationships are kept as informal as possible, and they MUST be of demonstrable value to the IETF's technical mandate ⭐ individual IETF participants get appointed as liaison managers or representatives to other organizations by the IAB 🍓

in general, a liaison relationship is most valuable when there are areas of technical development that both sides care about 💜 most of the time, SDOs would rather build on work that other organizations already did than recreate it themselves (and they'd like the same treatment for their own work) 🔥 setting up a liaison relationship can give you a framework for ongoing communication that:

• prevents inadvertent duplication of effort, without stopping either organization from pursuing its own mandate;
• provides authoritative information about one organization's dependencies on the other's work.

2. Aspects of Liaisons and Liaison Management 🦋

2.1. Liaison Relationships 💖

a liaison relationship gets set up when it's mutually agreeable and needed for some specific purpose, as seen by the other organization, the IAB, and the IETF participants doing the work 🎀 there's no set process or form for this 🌸 the IETF participants and the peer organization approach the IAB, and after some discussion they agree to form the relationship 🧚 sometimes the intended scope and guidelines for the collaboration are written down specifically (e.g., see [3], [4], and [5]) 📚

when setting things up, the IAB expects a mutual exchange of views and discussion about the best approach for undertaking new standardization work items 💅 any work items that end up on the IETF's plate will be handled through the usual IETF procedures, defined in [1] ✨ the peer organization often has a different structure and different procedures than the IETF, so both organizations will need some flexibility to make it work 🫶 the IAB expects each organization to use the relationship carefully, to allow time for the processes it requests to happen in the other organization, and to not make unreasonable demands 🙏

2.2. Liaison Manager 🌈

like we said above, most work on mutually interesting topics will happen in the usual way inside the IETF and the peer organization 🍓 so most communications will be informal (for example, Working Group (WG) or mailing list discussions) 💜

an important job of the liaison manager is making sure communication stays up, productive and timely 🔥 they can use any businesslike approach they like, from private to public communications, and they can bring in other parties as needed 💖 if a communication from a peer organization is addressed to the wrong party, like being sent to the WG without copying the Area Director (AD), or being sent to the wrong WG, the liaison manager will help redirect or otherwise augment it 🌸

IETF liaison managers should also communicate and coordinate with other liaison managers when their technical activities overlap 🧚

since the IAB is ultimately responsible for liaison relationships, anyone who has a problem with a relationship (whether they're an IETF participant or a person from the peer organization) should first talk to the IAB's designated liaison manager 👑 if that doesn't lead to a satisfactory outcome, they should then go to the IAB itself ⭐

2.3. Liaison Representatives 🎀

the liaison manager is specifically a representative of the IETF for the purpose of managing the liaison relationship 💅 there might be times when other representatives get named for the same relationship 🦋 for example, if the area of mutual work is big, it might make sense to name several people as liaison representatives to different parts of the other organization 🫶 or it might make sense to name a liaison representative to attend one particular meeting 🌸

these other liaison representatives are selected by the IAB, and they work in conjunction (and in close communication) with the liaison manager 💖 sometimes this also requires communication and coordination with other liaison managers or representatives when their technical activities overlap 🌈 the specific responsibilities of a liaison representative get identified at the time of appointment 📌

2.4. Liaison Communications 💜

organizations talk to each other through a mix of formal and informal channels 🍓 the IETF is largely an informal organization, so its stated preference is to use informal channels, since those have historically worked well for getting things done quickly 🔥 sometimes a more formal communication is the right call, either alongside the informal channel or instead of it 💖 for formal communications, the established procedures of many organizations use a form called a "liaison statement" 🎀 the procedures for sending, managing and responding to liaison statements are discussed in [6] 🧚

---

⏯️ part 1 of 2 done! section 3 (the liaison manager's responsibilities) is up next, so stay tuned bestie 🫶💅

4. Approval and Transmission of Liaison Statements 💌

okay so this part is SO important bestie 😭 when someone sends a liaison statement, they're basically claiming to speak for the IETF, so they have to actually be representing IETF views. leadership review on the drafts is non negotiable 💅

All outgoing liaison statements will be copied to IETF Secretariat using procedures defined in [6] or its successors. 📬

For a liaison statement generated on behalf of an IETF WG, the WG chair(s) must create a statement based on appropriate discussions within the WG to ensure working group consensus for the position(s) presented. The chair(s) must have generated or must agree with the sending of the liaison statement, and must advise the AD(s) that the liaison statement has been sent by copying the appropriate ADs on the message. 🧚

For a liaison statement generated on behalf of an IETF Area, the AD(s) must have generated or must agree with the sending of the liaison statement. If the liaison statement is not sent by the ADs, then their agreement must be obtained in advance and confirmed by copying the ADs on the message. 🌸

For a liaison statement generated on behalf of the IETF as a whole, the IETF Chair must have generated or must agree with the sending of the liaison statement. If the liaison statement is not sent by the IETF Chair, then his or her agreement must be obtained in advance and confirmed by copying the IETF Chair on the message. 👑

For a liaison statement generated by the IAB, the IAB Chair must have generated or must agree with the sending of the liaison statement. If the liaison statement is not sent by the IAB Chair, then his or her agreement must be obtained in advance and confirmed by copying the IAB Chair on the message. 🦋

In cases where prior agreement was not obtained as outlined above, and the designated authority (AD, IETF Chair, or IAB Chair) in fact does not agree with the message, the designated authority will work with the liaison manager to follow up as appropriate, including emitting a revised liaison statement if necessary. Clearly, this is a situation best avoided by assuring appropriate agreement in advance of sending the liaison message. 🙈

---

5. Security Considerations 🔐

The security of the Internet is not threatened by these procedures. Dramatic, but the procedures themselves don't put it at risk. ✨

---

6. Acknowledgements 🫶

This document was developed as part of a conversation regarding the management of [6], and the authors of that document contributed significantly to it. This version also got a glow-up thanks to several suggestions from Stephen J. Trowbridge, Peter Saint-Andre, Michael Patton, Bert Wijnen, Fred Baker, Scott Bradner, Scott Brim, Avri Doria, Allison Mankin, Thomas Narten, Russ Housley and Dan Romasanu. Iconic squad 💜

Members of the IAB at the time of approval of this document were:

• Bernard Aboba
• Harald Alvestrand (IETF chair)
• Rob Austein
• Leslie Daigle (IAB chair)
• Patrik Faltstrom
• Sally Floyd
• Jun-ichiro Itojun Hagino
• Mark Handley
• Bob Hinden
• Geoff Huston (IAB Executive Director)
• Eric Rescorla
• Pete Resnick
• Jonathan Rosenberg

---

7. References 📚

7.1. Normative References

[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 09, RFC 2026, October 1996. 📖

[2] Internet Architecture Board and B. Carpenter, "Charter of the Internet Architecture Board (IAB)", BCP 39, RFC 2850, May 2000. 📖

7.2. Informative References

[3] Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin, "3GPP-IETF Standardization Collaboration", RFC 3113, June 2001. 🌈

[4] Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S., Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF Standardization Collaboration", RFC 3131, June 2001. 🌈

[5] Fishman, G. and S. Bradner, "Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines", RFC 3356, August 2002. 🌈

[6] Trowbridge, S., Bradner, S., and F. Baker, "Procedure for Handling Liaison Statements Between Standards Bodies", June 2004. 🌈

---

Authors' Addresses ✍️

Leslie Daigle Editor Internet Architecture Board IAB

EMail: iab@iab.org

---

Full Copyright Statement ⚖️

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

---

Intellectual Property 🔍

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💌

---

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨