RFC 4052 BEST CURRENT PRACTICE IETF PROCESS · GOVERNANCE · BEST CURRENT PRACTICE

IAB Liaison Processes: IAB Processes for Management of IETF Liaison Relationships

How the IETF's governing board opens, runs and approves working relationships with other standards bodies.

On rfc-editor.org ↗
PUBLISHED
April 2005
AUTHORS
L. Daigle, Internet Architecture Board
STREAM
IAB
BCP NUMBER
102
CATEGORY
Best Current Practice
BODY THAT MANAGES LIAISON RELATIONSHIPS
The Internet Architecture Board (IAB)
OUT OF SCOPE
Managing other organizations' liaison managers to the IETF
DOI
10.17487/RFC4052
ERRATA
Reported errata

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
Network Working Group                                     L. Daigle, Ed.
Request for Comments: 4052                   Internet Architecture Board
BCP: 102                                                      April 2005
Category: Best Current Practice


       IAB Processes for Management of IETF Liaison Relationships

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document discusses the procedures used by the IAB to establish
   and maintain 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 representatives, and
   the expectations of the IAB for organizations with whom liaison
   relationships are established.

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

   The IETF, as an organization, has the need to engage in direct
   communication or joint endeavors with various other formal
   organizations.  For example, the IETF is one of several Standards
   Development Organizations, or SDOs, and all 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 from the IETF is designated to manage a given
   liaison relationship; that person is generally called the "IETF
   liaison manager" to the other organization.  When the liaison
   relationship is expected to encompass a complex or broad range of
   activities, more people may be designated to undertake some portions
   of the communications, coordinated by the liaison manager.  Often,
   the other organization will similarly designate their own liaison
   manager to the IETF.

   This document is chiefly concerned with:

   o  the establishment and maintenance of liaison relationships, and

   o  the appointment and responsibilities of IETF liaison managers and
      representatives.

   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 chartered the Internet Architecture Board to manage
   liaison relationships.  Consistent with its charter [2], the IAB acts
   as representative of the interests of the IETF and the Internet
   Society in technical liaison relationships with other organizations
   concerned with standards and other technical and organizational
   issues relevant to the worldwide Internet.  Liaison relationships are
   kept as informal as possible and must be of demonstrable value to the
   IETF's technical mandate.  Individual participants of the IETF are
   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 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

   o  prevent inadvertent duplication of effort, without obstructing
      either organization from pursuing its own mandate;

   o  provide authoritative information of one organization's
      dependencies on the other's work.

2.  Aspects of Liaisons and Liaison Management

2.1.  Liaison Relationships

   A liaison relationship is set up when it is mutually agreeable and
   needed for some specific purpose, in the view of the other
   organization, the IAB, and the IETF participants conducting the work.
   There is no set process or form for this; the IETF participants and
   the peer organization approach the IAB, and after discussion 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 [3], [4], and [5]).

   In setting up the 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 in the usual IETF procedures, defined
   in [1].  The peer organization often has different organizational
   structure and procedures than the IETF, which will require some
   flexibility on the part of both organizations to accommodate.  The
   IAB expects that each organization will use the relationship
   carefully, allowing time for the processes it requests to occur in
   the other organization, and will not make unreasonable demands.

2.2.  Liaison Manager

   As described above, most work on mutually interesting topics will be
   carried out in the usual way within the IETF and the peer
   organization.  Therefore, most communications will be informal in
   nature (for example, Working Group (WG) or mailing list discussions).

   An important function of the liaison manager is to ensure that
   communication is maintained, productive, and timely.  He or she may
   use any applicable businesslike approach, from private to public
   communications, and bring in other parties as needed.  If a
   communication from a peer organization is addressed to an
   inappropriate party, such as being sent to the WG but not copying the
   Area Director (AD) or being sent to the wrong WG, the liaison manager
   will help redirect or otherwise augment the communication.

   IETF liaison managers should also communicate and coordinate with
   other liaison managers where concerned technical activities overlap.

   Since the IAB is ultimately responsible for liaison relationships,
   anyone who has a problem 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, 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 may be
   occasion to identify other representatives for the same relationship.
   For example, if the area of mutual work is extensive, it might be
   appropriate to name several people as liaison representatives to
   different parts of the other organization.  Or, it might be
   appropriate to name a liaison representative to attend a particular
   meeting.

   These other liaison representatives are selected by the IAB and work
   in conjunction (and close communication) with the liaison manager.
   In some cases, this may also require communication and coordination
   with other liaison managers or representatives where concerned
   technical activities overlap.  The specific responsibilities of the
   liaison representative will be identified at the time of appointment.

2.4.  Liaison Communications

   Communications between organizations use a variety of formal and
   informal channels.  The stated preference of the IETF, which is
   largely an informal organization, is to use informal channels, as
   these have 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 place.  In the case of
   formal communications, the established procedures of many
   organizations use a form known as a "liaison statement".  Procedures
   for sending, managing, and responding to liaison statements are
   discussed in [6].

3.  Summary of IETF Liaison Manager Responsibilities

   While the requirements will certainly vary depending on the nature of
   the peer organization and the type of joint work being undertaken,
   the general expectations of a liaison manager appointed by the IAB
   are as follows:

   o  Attend relevant meetings of the peer organization as needed and
      report back to the appropriate IETF organization any material
      updates.

   o  Carry any messages from the IETF to the peer organization, when
      specifically instructed.  Generally, these communications
      "represent the IETF", and therefore due care and consensus must be
      applied in their construction.

   o  Prepare occasional updates.  The target of these updates (e.g.,
      the IAB, an AD, a WG) will generally be identified upon
      appointment.

   o  Oversee delivery of liaison statements addressed to the IETF,
      ensuring that they reach the appropriate destination within the
      IETF, and ensure that relevant responses from the IETF are created
      and sent in a timely fashion.

   o  Work with the other organization to ensure that the IETF's liaison
      statements are appropriately directed and responded to in a timely
      fashion.

   o  Communicate and coordinate with other IETF liaison managers and
      representatives where concerned technical activities overlap.

4.  Approval and Transmission of Liaison Statements

   It is important that appropriate leadership review be made of
   proposed IETF liaison statements and that those writing such
   statements, who claim to be speaking on behalf of IETF, are truly
   representing IETF views.

   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.

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.  Also, this version of the document has been
   improved over its predecessor by 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.

   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.

ISO Plain Language

On this page
PROBLEMThe IETF is one of several standards development organizations, and it needs formal working relationships with the others so that work is not duplicated and dependencies are known.
MECHANISMThe IAB appoints an IETF liaison manager for each relationship, keeps the relationship informal where possible, and requires an explicit approval from the relevant IETF body before any liaison statement is sent.
WHY IT MATTERSThe result is a Best Current Practice, BCP 102, that tells both sides who speaks for the IETF and who signs off on a message leaving the community.

§1Liaison Relationships and Personnel

The IETF, as an organization, needs to engage in direct communication or joint endeavours with various other formal organizations. The IETF is one of several Standards Development Organizations, or SDOs, and all SDOs find it increasingly necessary to communicate and coordinate activities involving Internet-related technologies. That is useful in order to avoid overlap in work efforts and to manage interactions between their groups. Where mutual effort to communicate and coordinate is formalised, these relationships are generically referred to as liaison relationships.

For each relationship a person from the IETF is designated to manage it, and that person is generally called the IETF liaison manager to the other organization. When the relationship is expected to encompass a complex or broad range of activities, more people may be designated to undertake some portions of the communications, coordinated by the liaison manager. Often the other organization designates its own liaison manager to the IETF in return.

The document is chiefly concerned with the establishment and maintenance of liaison relationships and with the appointment and responsibilities of IETF liaison managers and representatives. The management of other organizations' liaison managers to the IETF is outside its scope. The IETF has chartered the Internet Architecture Board (IAB) to manage liaison relationships, and consistent with its charter the IAB acts as representative of the interests of the IETF and the Internet Society in technical liaison relationships. Liaison relationships are kept as informal as possible and must be of demonstrable value to the IETF's technical mandate.

A liaison relationship is most valuable when there are areas of technical development of mutual interest, because SDOs would rather leverage existing work done by other organizations than recreate it themselves. Establishing one can prevent inadvertent duplication of effort, without obstructing either organization from pursuing its own mandate, and can provide authoritative information of one organization's dependencies on the other's work.

A liaison relationship is a formal way for the IETF and another standards body to work together without repeating each other's work. The IAB keeps these relationships, and each one has an IETF liaison manager who looks after day-to-day communication.

THE IETF BODIES NAMED IN RFC 4052
  • IETF
    • Working Group Chairs create statements on behalf of the group.
    • Area Area Directors agree to statements on behalf of the area.
    • IETF Chair Agrees to statements on behalf of the IETF as a whole.
    • IAB Manages liaison relationships; the IAB Chair agrees to statements the IAB generates.

§2.1Setting Up a Liaison Relationship

A liaison relationship is set up when it is mutually agreeable and needed for some specific purpose, in the view of the other organization, the IAB, and the IETF participants conducting the work. There is no set process or form for this. The IETF participants and the peer organization approach the IAB, and after discussion come to an agreement to form the relationship. In some cases the intended scope and guidelines for the collaboration are documented specifically.

In setting up the relationship, the IAB expects 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 in the usual IETF procedures. The peer organization often has a different organizational structure and procedures from the IETF, which will require some flexibility on the part of both organizations to accommodate. The IAB expects that each organization will use the relationship carefully, allowing time for the processes it requests to occur in the other organization, and will not make unreasonable demands.

There is no form to fill in. The people doing the work and the peer body approach the IAB, talk it over, and agree a relationship. From then on the IETF still does its own work by its own rules, and each side gives the other time to work in its own way.

§2.2The Liaison Manager

Most work on mutually interesting topics will be carried out in the usual way within the IETF and the peer organization, so most communications will be informal in nature, for example Working Group or mailing list discussions. An important function of the liaison manager is to ensure that communication is maintained, productive, and timely. The liaison manager may use any applicable businesslike approach, from private to public communications, and bring in other parties as needed.

If a communication from a peer organization is addressed to an inappropriate party, such as being sent to the Working Group but not copying the Area Director, or being sent to the wrong Working Group, the liaison manager will help redirect or otherwise augment the communication. Liaison managers should also communicate and coordinate with other liaison managers where concerned technical activities overlap.

Since the IAB is ultimately responsible for liaison relationships, anyone who has a problem 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, the IAB itself.

The liaison manager keeps the conversation going and on time. If a message from the other body arrives at the wrong group, the liaison manager puts it right. Anyone unhappy with how a relationship is working goes to the liaison manager first and to the IAB if that does not settle it.

§2.3Liaison Representatives

The liaison manager is, specifically, a representative of the IETF for the purpose of managing the liaison relationship. There may be occasion to identify other representatives for the same relationship. For example, if the area of mutual work is extensive it might be appropriate to name several people as liaison representatives to different parts of the other organization. Or it might be appropriate to name a liaison representative to attend a particular meeting.

These other liaison representatives are selected by the IAB and work in conjunction, and close communication, with the liaison manager. In some cases this may also require communication and coordination with other liaison managers or representatives where concerned technical activities overlap. The specific responsibilities of the liaison representative will be identified at the time of appointment.

A relationship that covers a lot of ground may need more than one person. The IAB can name extra liaison representatives for parts of the other organization or for a single meeting. They are appointed for a stated job and work closely with the liaison manager.

§2.4Liaison Communications

Communications between organizations use a variety of formal and informal channels. The stated preference of the IETF, which is largely an informal organization, is to use informal channels, as these have 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 place. In the case of formal communications, the established procedures of many organizations use a form known as a liaison statement. Procedures for sending, managing, and responding to liaison statements are discussed in a separate document.

The IETF prefers informal channels such as working group discussions, because they get things done quickly. When a formal note is needed, the usual form is a liaison statement, which is a document one standards body sends to another.

§3Liaison Manager Responsibilities

The requirements vary with the nature of the peer organization and the type of joint work being undertaken, but the general expectations of a liaison manager appointed by the IAB are as follows.

  • Attend relevant meetings of the peer organization as needed and report back to the appropriate IETF organization any material updates.
  • Carry any messages from the IETF to the peer organization when specifically instructed. Generally these communications represent the IETF, so due care and consensus must be applied in their construction.
  • Prepare occasional updates. The target of these updates, for example the IAB, an Area Director or a Working Group, will generally be identified upon appointment.
  • Oversee delivery of liaison statements addressed to the IETF, ensuring that they reach the appropriate destination within the IETF, and ensure that relevant responses from the IETF are created and sent in a timely fashion.
  • Work with the other organization to ensure that the IETF's liaison statements are appropriately directed and responded to in a timely fashion.
  • Communicate and coordinate with other IETF liaison managers and representatives where concerned technical activities overlap.

The liaison manager attends the other body's meetings and reports back, carries messages when told to, writes occasional updates, makes sure statements arriving for the IETF reach the right group and get an answer, and keeps other liaison managers in step where the work overlaps.

WHAT THE IAB EXPECTS OF A LIAISON MANAGER
  • Attend and reportGo to the peer organization's meetings when needed and report material updates back to the IETF.
  • Carry messagesPass messages from the IETF to the peer organization when instructed, with care and consensus.
  • Prepare updatesWrite occasional updates for the target named at appointment, such as the IAB, an Area Director or a Working Group.
  • Receive statementsMake sure incoming statements reach the right IETF destination and get a timely response.
  • Send statementsWork with the other organization so that IETF statements are directed properly and answered in time.
  • CoordinateCoordinate with other IETF liaison managers and representatives where the technical work overlaps.

§4Approving and Sending Liaison Statements

It is important that appropriate leadership review be made of proposed IETF liaison statements, and that those writing such statements, who claim to be speaking on behalf of the IETF, are truly representing IETF views. All outgoing liaison statements will be copied to the IETF Secretariat using the procedures defined in the separate liaison statement document or its successors.

For a liaison statement generated on behalf of an IETF Working Group, the Working Group chairs must create a statement based on appropriate discussions within the group to ensure working group consensus for the positions presented. The chairs must have generated or must agree with the sending of the statement, and must advise the Area Directors that it has been sent by copying them on the message.

For a statement generated on behalf of an IETF Area, the Area Directors must have generated or must agree with the sending. If it is not sent by the Area Directors, their agreement must be obtained in advance and confirmed by copying them on the message. For a statement generated on behalf of the IETF as a whole, the IETF Chair must have generated or must agree with the sending, with the same rule for prior agreement. For a statement generated by the IAB, the IAB Chair must have generated or must agree with the sending, again with the same rule.

In cases where prior agreement was not obtained, and the designated authority in fact does not agree with the message, that authority will work with the liaison manager to follow up as appropriate, including emitting a revised liaison statement if necessary. The RFC calls this a situation best avoided by assuring appropriate agreement in advance of sending the liaison message.

A statement only speaks for the IETF if the right IETF leader agrees to it. Working group statements need the group chairs, area statements need the Area Directors, statements for the whole IETF need the IETF Chair, and statements from the IAB need the IAB Chair.

WHO MUST AGREE TO AN OUTGOING LIAISON STATEMENT
Statement made on behalf ofWho must generate or agree to it
An IETF Working GroupThe Working Group chairs
An IETF AreaThe Area Directors
The IETF as a wholeThe IETF Chair
The IABThe IAB Chair

§5Security Considerations

The RFC states the position in one line: the security of the Internet is not threatened by these procedures. The document governs how people talk to each other across standards bodies, not how packets are built or sent, so it introduces no protocol behaviour that could weaken the Internet's security.

These procedures do not affect the security of the Internet. They are about how people talk to each other, not about how data is sent.

§9References