RFC 4691

Guidelines for Acting as an IETF Liaison to Another Organization

📅 published October 2006, from ietf

RFC 4691 💖 Guidelines for Acting as an IETF Liaison to Another Organization

Okay so this one is from the Network Working Group 🎀, written by L. Andersson, Ed. from the IAB 🦋, filed as Informational and dated October 2006 🌸. It's info for the Internet community, not a standard, so it doesn't specify an Internet standard of any kind. The title block doesn't list anything it obsoletes or updates ✨.

Status of This Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 🌈

Whenever the IETF decides to enter into a liaison relationship with another organization, like a Standards Development Organization (SDO), a consortium, or an industrial forum, a liaison manager gets appointed 💅. The procedures the IAB uses to set up and keep up these liaison relationships are described in RFC 4052. This doc expands on the role of liaison managers and liaison representatives, with guidelines on their mandate and the expectations, tasks, and responsibilities placed on them 🫶.

Table of Contents 🗂️

1. Introduction ....................................................2
2. IETF Liaison Relationships ......................................3
   2.1. Related Documents ..........................................3
   2.2. Liaison Managers and Liaison Representatives ...............3
   2.3. Written Communications .....................................4
   2.4. Terminology and Conventions ................................5
3. Guidelines for Liaison Managers and Representatives .............5
   3.1. Mandate ....................................................6
        3.1.1. Speaking for the IETF ...............................6
   3.2. Expectations ...............................................6
   3.3. Responsibilities ...........................................8
   3.4. Tasks ......................................................9
   3.5. Relationship Management ...................................10
        3.5.1. IETF Consensus Process on Liaison Statements .......10
        3.5.2. Incoming Liaison Statements ........................10
        3.5.3. Ambiguous Incoming Liaison Statements ..............11
        3.5.4. Liaison Managers Representing Peer Organizations ...11

4. Security Considerations ........................................12
5. IANA Considerations ............................................12
6. Acknowledgements ...............................................12
7. References .....................................................13
   7.1. Normative References ......................................13
   7.2. Informative References ....................................13

1. Introduction ✨

In the course of developing Internet standards, the IETF needs to talk a LOT with other peer organizations 🗣️, including:

  • Standards Development Organizations (SDOs) such as the Telecommunication Standardization Sector of the International Telecommunication Union (ITU-T) or standardization working groups of the Institute of Electrical and Electronics Engineers (e.g., IEEE 802)
  • Consortia such as the World Wide Web Consortium (W3C)
  • Industrial forums such as the Global Grid Forum (GGF)

These orgs are usually working on related standards and technical specs, so every so often issues of coordination and mutual interest pop up 👀. To make communication easier, the IETF, through the Internet Architecture Board (IAB), sets up permanent liaison relationships with the right parts of these orgs, following the processes in RFC 4052 [RFC4052] 💜.

Whenever the IETF decides to enter a liaison relationship, the IAB appoints a liaison manager and possibly some liaison representatives 🧚. They act as the channel between the IETF and the peer org, usually working in tandem with counterparts the peer org appoints too 🫶.

Sections 2.2, 2.3, and 3 of RFC 4052 quickly lay out the basic functions of liaison managers and representatives 📋. Over time there are more liaisons and they've gotten way more important 📈, and so has the personal role of IETF liaison managers and representatives in keeping good relationships with peer orgs 💖. This doc builds on [RFC4052] by giving guidelines for liaison managers and liaison representatives on keeping up communications with peer orgs 🌸.

2. IETF Liaison Relationships 🎀

A big goal of the IETF is developing standards for the Internet so interoperable implementations can happen 🔥. To do that, the IETF often has to talk with other orgs that develop standards for other types of networks, for Internet applications, or for technologies the Internet uses 🌐.

Sometimes the IETF and a peer org think it's mutually beneficial to have a permanent formal relationship with certain rules for it 🦋. Then they enter into a "liaison relationship" 💅. Basically, both sides agree to take on certain responsibilities toward each other. The most basic one is communicating information as needed and responding to requests from the peer orgs the liaisons are maintained with 🫶.

Decisions on IETF liaison relationships are the IAB's call 👑. That includes whether the IETF should have a liaison relationship with a particular org at all 🙈.

The IETF liaison process is spelled out in several docs. RFC 4052 [RFC4052] covers how the IAB manages the IETF liaison relationship, and RFC 4053 [RFC4053] covers how liaison statements should be treated 💖. Some orgs also get their own agreements and docs. For example, RFC 3356 [RFC3356] describes the collaboration between the IETF and ITU-T, RFC 3113 [RFC3113] describes the relationship with the 3rd Generation Partnership Project (3GPP), and RFC 3131 [RFC3131] describes the one with the Third Generation Partnership Project 2 (3GPP2) ✨.

2.2. Liaison Managers and Liaison Representatives 🧚‍♀️

Whenever the IETF enters a liaison relationship with another org, the IAB appoints a liaison manager (often called "the IETF liaison") 🎀. This doc expands on the mandate, expectations, tasks, and responsibilities that Section 2.2 of RFC 4052 places on the liaison manager 💅.

Sometimes one person isn't enough for a given org's liaison relationship 🙃. For example, the time commitment might be too big, or the technical scope might be too broad for one individual 🌈.

In those cases, the IAB can appoint one or more liaison representatives to back up the liaison manager by handling different aspects of the relationship between the IETF and the other org 🦋.

The personal relationships are the heart of these roles 💜. The IAB is looking for people who really get the technical work being done and who have effective personal relationships inside the peer org 🫶. Ongoing face-to-face interactions between the IETF liaisons and members of the peer org are seen as critical to the role working well 🔥. Those interactions should keep the liaisons on top of things, and ideally ahead of them, on matters of mutual interest or potential conflict 👀. When the liaison is working well, it should help the IETF and the peer org work synergistically and cut down the chance of overlapping or conflicting standards getting created ✨.

2.3. Written Communications 📝

Besides personal contact between liaisons and the peer org, there's lots of written communication between the IETF and peer orgs too 💌. A lot of it happens through liaison statements, which usually contain plans, new developments, and time schedules that one party thinks the other should know about 🗓️.

The liaison manager should keep track of these written communications and help both parties make sure appropriate action gets taken on liaison statements going in both directions 💅.

For example, say a liaison org like ITU-T needs to reference material that's still in development at the IETF 🤔. The final reference in the peer org's doc needs the permanent identifier (RFC number) that the Internet Draft will get once it's approved and published 🎀. To hit the peer org's publication schedule, a liaison statement often gets sent to the IETF asking for an RFC number to be assigned within the timeframe needed 🏃‍♀️. In response, the IETF can provide the RFC number or explain why it can't do that within the requested timeframe 🙏.

There's also a situation where the liaison manager has to take more specific action, and it also involves requests for this kind of expedited action on RFCs 🔥. For example, 3GPP/3GPP2 and the Open Mobile Alliance (OMA) send the IETF an updated list of dependencies between their docs and IETF docs every month 📅. The list shows what docs are needed and the timeframe needed for them. In this case the liaison manager tracks the dependency list and, when necessary, passes the request for expedited assignment along to the appropriate IETF Area Director (AD) 👑.

2.4. Terminology and Conventions 🔤

Terminology for IETF liaison procedures is found in [RFC4052] 📖. The terms defined below only count for this document 💅.

Liaison manager

A person appointed to manage an IETF liaison relationship with another organization 🧚.

Liaison representative

A person appointed to manage a certain (sub-)aspect of an IETF liaison relationship with another organization 🦋. Since only the scale of the responsibilities, mandate, and tasks is different, the rest of this document only explicitly mentions liaison managers 💖.

IETF consensus

RFC 2026 [RFC2026] and RFC 2418 [RFC2418] discuss the IETF consensus process 🗳️. In this document, the term "IETF consensus" is used to mean consensus of the IETF as an organization, an area within the IETF, or a working group 🌈. The term "IETF consensus" needs to be interpreted in the context where it's used 🫶.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💜.

3. Guidelines for Liaison Managers and Representatives 💅

Since liaison relationships are meant to be mutually beneficial, the IETF liaison to another org has to act as a two-way communication link between the IETF and that org 🔁. Because the IETF appointed the liaison manager, the liaison manager needs to be responsive to the IETF's needs and aims 🎯.

RFC 4052 lists some of the tasks and expectations for liaison managers and liaison representatives 📋. This document expands on their mandate, gives more detailed discussion, and describes how the role is carried out 🌸.

3.1. Mandate ✨

Okay bestie, the mandate for IETF liaison managers is strictly limited to conveying IETF consensus to the liaised organization 💅. The liaison manager MUST NOT on their own initiative send liaison statements to a liaised organization on behalf of IETF, or any of its areas and working groups 🙅. Liaison statements are only sent following the process specified in [RFC4052]. They're only sent on the initiative of the IETF chair, the IAB chair, IETF Area Directors, or IETF working group chairs 🫶.

In Section 3.3 and Section 3.4, the responsibilities and tasks are listed. They help the IETF get the info it needs to interact correctly with the liaised organizations, and to develop and clearly communicate IETF consensus ✨.

3.1.1. Speaking for the IETF

The IETF runs on rough consensus, which means the right to speak for the IETF cannot be delegated 🌸. 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. Some guidelines for understanding IETF consensus are provided above. However, the most important requirement is close and detailed coordination/consultation with the IETF community 🧚.

3.2. Expectations

There are certain expectations placed on liaison managers appointed by the IETF. Some examples of these are listed below 💜.

Competences required

The key competence for a liaison manager or representative is managing the liaison process well, following the rules that have been agreed upon. The liaison is a representative of the IETF, not an independent voice on the topics being discussed in the liaison relationship. So they have to be careful to separate their own views from documented IETF consensus when dealing with the peer organization 🎀.

The liaison manager or representative also has to communicate effectively with members of the peer organization, especially face to face. This matters both for getting the IETF's viewpoint across and for gathering information about the issues in the peer organization that the IETF needs to understand 🗣️.

A person appointed as a liaison manager or representative for the IETF is also expected to have a good technical understanding of the key issues in the subject area. They should understand the concerns that matter to stakeholders in both organizations too 🤓.

An IETF liaison needs to know the IETF's consensus process in general, and the consensus process(es) that apply to the key issues within the liaison relationship 📚.

The liaison must also have a good understanding of the processes used by the peer organization involved 🌈.

Perspective

Liaison relationships are designed for the mutual benefit of the organizations taking part, so swift information flow in both directions is a firm requirement ⚡. The role of an IETF liaison manager is to promote the interests of the IETF on all topics within the scope of the liaison relationship. Since the liaison manager "wears an IETF hat", it is NOT the task of a liaison manager to promote the interests of the liaised organization within the IETF 🎩.

Distance

A liaison may not be able to keep the required perspective if they're closely involved in the outcome of the work in the peer organization 👀. A conflict of interest might come up if the liaison is involved in managing the relevant part of the peer organization, has close technical involvement in the work that is the subject of the liaison, or has a close interest in the outcome of that work through their employment 😬. When the IAB appoints someone to manage a liaison relationship, it needs to take into account any conflicts of interest that the individual might have. Before anyone is appointed, they will be asked to explicitly state any conflicts of interest. The IAB will not appoint a person to a liaison manager position if there is a strong conflict of interest. For example, someone with an industry or organizational leadership position in an organization would typically not be suitable to be the IETF liaison to that organization 🚫.

Commitment and opportunity

A liaison manager needs to be committed to addressing the issues relevant to the liaison relationship. To handle the job properly, the liaison needs to be able to set aside enough time for it ⏰.

Timeliness

A liaison manger is expected to make the IETF aware of new developments in the subject area in a timely fashion 🚀.

3.3. Responsibilities

The liaison manager and representatives provide information to the IETF community so the IETF can make decisions based on the best possible information about the work in the peer organization 🧠. In turn, information the IETF liaison communicates to the liaised organization MUST be based on the relevant IETF consensus. The liaison manager works with the liaised organization to make sure communication is clear. As part of this, the liaison must clearly tell apart their own independent positions from those that represent IETF consensus 💖.

It is the liaison manager's responsibility to make sure the liaised organization communicates its requirements to the IETF in a timely fashion, and that the IETF consensus is clearly understood 📣. This matters most when the IETF and the liaised organization differ a lot in their positions. In that situation, the liaison manager needs to help make communication prompt, so the two can stay in close contact and avoid misunderstandings 🫧.

The liaison manager and representatives are responsible for clearly and correctly communicating the IETF consensus position to the liaised organization. This includes carrying messages from the IETF to the peer organization when they're specifically instructed to do so. These communications "represent the IETF", so due care and consensus must go into how they're written 💅.

The liaison manager and representatives are responsible for making sure relevant information from the liaised organization, or other information that comes to the liaison's attention, reaches the correct destination within the IETF, in a timely and effective way 📬.

3.4. Tasks

Here are some examples of tasks the liaison manager performs. Depending on the nature of the liaised organization, the frequency and relative importance of each task may vary 📋.

  1. Attend relevant meetings and take part in conference calls and mailing lists within the liaised organization to gather information relevant to the liaison relationship. Note developments of interest for passing on to the IETF. Communicate the IETF consensus point of view to the peer organization 👂.
  2. Communicate information relevant to the liaison relationship to the relevant part of the IETF, either in written reports or verbally. This may involve briefings with a team of IETFers involved in the liaised organization and other interested parties within the IETF, e.g., working group chairs and ADs 🗂️.
  3. Understand the concerns of both the IETF and the peer organization, while making sure the interests of the IETF are maintained. Where there appear to be problems to solve or conflicts between approaches, work with both parties to encourage engineers from both organizations to collaborate on solving the problem, and help the development of engineering solutions in the appropriate organization 🤝.
  4. Prepare reports giving updates on developments in the peer organization, as requested by the IAB or other interested parties in the IETF. The target for these updates (e.g., the IAB, an AD, a WG) will typically be identified when the liaison relationship is established and/or the liaison manager is appointed 📊.
  5. Oversee delivery of liaison statements addressed to the IETF. This includes making sure liaison statements reach the appropriate destination within the IETF, as well as shepherding the timely creation of responses by the IETF 🏃‍♀️.
  6. Work with the liaised organization to make sure the IETF's liaison statements are appropriately directed and responded to in a timely fashion. To do this, the liaison needs to build a contact network 🕸️.
  7. Communicate and coordinate with other IETF liaison managers where the activities of two or more liaised organizations overlap 🤝.
  8. Help prepare IETF liaison statements based on IETF consensus ✍️.
  9. From time to time, liaison managers and liaison representatives will have to report to the IETF on the status of the liaison relationship. For this, they need to keep track of outstanding issues on behalf of the IETF. The frequency of the reports and who within the IETF receives them is decided when the liaison relationship is set up, and may be changed at any time by an IAB decision. The IAB or other parties within the IETF may ask for liaison reports as needed or at regular intervals 📅.

3.5. Relationship Management

Liaison managers will get involved in activities they aren't directly responsible for, but that could really benefit from their expertise 🌟. Some of these activities are outlined below.

3.5.1. IETF Consensus Process on Liaison Statements

Liaison statements and other messages sent to a liaised organization should be based on rough consensus within the IETF or one of its working groups or areas. The liaison manager isn't responsible for deciding consensus, but it's important that they take part in the process and share their expertise and knowledge 🗳️.

How consensus is reached can vary depending on the circumstances. Some issues are new, and for those an open discussion on a mailing list should happen. For other issues, consensus has already been reached, or the liaison statement is just a statement of facts (for example, to tell the liaised organization that an IETF Last Call has started on a document it had shown interest in). In these cases the liaison statement can be written and sent, such as by a working group chair, possibly with the involvement of the liaison manager 💫.

3.5.2. Incoming Liaison Statements ✨

okay so when the IETF gets a liaison statement or other message from an org it has a liaison relationship with, and that message asks for a reply, the IETF is committed to answering on time 💅 That means responding within the time requested and giving information that's as accurate as possible. This commitment has been a big talking point before, like in the (g)mpls change process [GMPLS] 🦋

But being committed to replying doesn't mean the IETF just nods along to everything in the incoming liaison statement 🙈 If the liaison includes requirements on IETF technology or protocols, those get considered based on their technical merit ⭐

3.5.3. Ambiguous Incoming Liaison Statements 🧩

sometimes the IETF, an IETF area, or an IETF working group gets a liaison statement from a liaised org that was sent to the wrong place 💀 other times it lands with working groups that aren't chartered to handle the topic. and in some cases, honestly, no working group is chartered to do the work at all 😭

in those situations, the liaison manager should help find the right person or group inside the IETF who might respond to the incoming liaison statement 🫶 sometimes that means the intended response has to be posted for review on one of the IETF mailing lists 💌

3.5.4. Liaison Managers Representing Peer Organizations 👯

liaised orgs can appoint someone to be the liaison manager for their side of the relationship 💜 this is the person who speaks with authority inside the IETF about what the other organization is doing. the other organization has to make sure the IETF knows who this person is 📣 and this person might ask for a slot on a working group agenda to talk through the liaised org's developments and plans 🗓️

opinions shared by liaison managers from other SDOs get equal weight with opinions from any other working group participant, except when they're reporting on work happening inside the liaised org 🌸 RFC 3356 [RFC3356] explains this for the relationship between the IETF and the ITU-T, but the same model applies to every other org the IETF has a liaison relationship with 🧚

the IETF recognizes a peer liaison manager's mandate only as far as it's needed to make sense of the information they send over 💅 for everything else, they take part in IETF activities under the same conditions and rules as any other IETF participant. it's really important that the IETF liaison manager understands how much authority the peer liaison manager has to speak for the peer organization 👑 and if the peer liaison manager seems to be stepping outside the role or position their own organization gave them, the IETF liaison manager needs to tell the relevant part of the IETF 🚨

IETF liaison managers should also work to bring the liaised organization's liaison manager into their contact network, and make an effort to understand the positions that peer liaison manager is communicating 🤝✨

4. Security Considerations 🔐

okay this one is serious bestie 🥺 this document doesn't specify any protocol or "bits on the wire". BUT 😤 interaction with other standards-making orgs is so often tied up with security, so the liaison manager can help with security-related issues, which leads to better security for Internet protocols 🛡️💖

5. IANA Considerations 🗂️

no requests to the IANA in this doc 🎀 still, the liaison manager very often has to understand and pass along questions about IETF namespaces that IANA manages, so it's not like IANA is totally off the radar 👀

6. Acknowledgements 🙏

this document was developed as part of a conversation about the requirements on IETF liaison managers and representatives 💬 several IAB members contributed a lot to it, and it got better thanks to suggestions and reviews from Allison Mankin, Dave Meyer, and Leslie Daigle 💕

a huge special thanks to Bernard Aboba 🏆 who, drawing on his own experience as a liaison manager, left a bunch of super useful comments on the subject matter. Elwyn Davies and Bernard Aboba also both spent time fixing the language and grammar ✍️

members of the IAB at the time this document was approved were:

  • Bernard Aboba
  • Loa Andersson
  • Brian Carpenter
  • Leslie Daigle
  • Elwyn Davies
  • Kevin Fall
  • Olaf Kolkman
  • Kurtis Lindqvist
  • David Meyer
  • Dave Oran
  • Eric Rescorla
  • Dave Thaler
  • Lixia Zhang

7. References 📚

7.1. Normative References

[RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
           3", BCP 9, RFC 2026, October 1996.

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2418]  Bradner, S., "IETF Working Group Guidelines and
           Procedures", BCP 25, RFC 2418, September 1998.

[RFC4052]  Daigle, L. and Internet Architecture Board, "IAB Processes
           for Management of IETF Liaison Relationships", BCP 102,
           RFC 4052, April 2005.

7.2. Informative References 🌷

[GMPLS]    Andersson, L., "MPLS and GMPLS Change Process", Work in
           Progress, December 2005.

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

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

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

[RFC4053]  Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
           Handling Liaison Statements to and from the IETF", BCP
           103, RFC 4053, April 2005.

Editor's Address 📬

  • Loa Andersson
  • IAB
  • EMail: loa@pi.se

Copyright (C) The Internet Society (2006).

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 on 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 on whether any license under such rights might or might not be available, and it doesn't claim to have made any independent effort to identify any such rights 🤷‍♀️ info on procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission to use such proprietary rights by implementers or users of this specification can be obtained from the IETF online 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 required to implement this standard 💌 please send that info to the IETF at ietf-ipr@ietf.org 📨

Acknowledgement 🌈

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 💖

📦 where this page comes from