[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc4691                                        
Network Working Group                                  L. Andersson (Ed)
Internet-Draft                                                       IAB
Expires: November 4, 2006                                    May 3, 2006

    Guidelines for Acting as an IETF Liaison to Another Organization

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

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

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on November 4, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   Whenever IETF decides to enter into a liaison relationship with
   another organization, such as a Standards Development Organization
   (SDO), a consortium, or an industrial forum, a liaison manager is
   appointed.  The procedures used by the IAB to establish and maintain
   liaison relationships between the IETF and other organizations are
   described in RFC 4052 [RFC4052].  This document gives guidelines on
   expectations, tasks, responsibilities and mandate of the liaison

Andersson (Ed)          Expires November 4, 2006                [Page 1]

Internet-Draft             Liaison Guidelines                   May 2006

   Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  IETF Liaison Relationships . . . . . . . . . . . . . . . . . .  4
     2.1.  Related documents  . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Written information  . . . . . . . . . . . . . . . . . . .  4
     2.3.  Liaison Managers and Liaison Representatives . . . . . . .  5
     2.4.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Liaison Guidelines . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Expectations . . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Responsibilities . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Tasks  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  Mandate  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.4.1.  Speaking for the IETF  . . . . . . . . . . . . . . . . 10
     3.5.  Relationship management  . . . . . . . . . . . . . . . . . 10
       3.5.1.  IETF consensus process on liaison statements . . . . . 10
       3.5.2.  Incoming Liaison Statements  . . . . . . . . . . . . . 11
       3.5.3.  Ambiguous incoming Liaison Statements  . . . . . . . . 11
       3.5.4.  Liaison managers representing other SDOs . . . . . . . 11
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   5.  IANA considerations  . . . . . . . . . . . . . . . . . . . . . 14
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
   Intellectual Property and Copyright Statements . . . . . . . . . . 18

Andersson (Ed)          Expires November 4, 2006                [Page 2]

Internet-Draft             Liaison Guidelines                   May 2006

1.  Introduction

   The IETF communicates extensively with other organizations on issues
   relating to the development of Internet standards.  Part of this
   communication occurs in written form, known as "liaison statements".
   In order to ensure the delivery of liaison statements, as well as to
   enable other forms of communication, the IETF appoints a liaison
   manager to be responsible for the relationship with the other
   organization.  We normally speak of such a person as "the liaison"
   from the IETF to the other organization.

   The organizations IETF establishes liaison relationships with include
   Standards Developing Organizations (SDOs) such as ITU-T or IEEE 802,
   consortia such as W3C, and industrial forums such as Global Grid
   Forum.  Usually IETF liaisons are concerned with groups that develop
   standards and technical specifications.

   Whenever the IETF decides to enter into a liaison relationship, a
   liaison manager is appointed.  The procedures used by the IAB to
   establish and maintain liaison relationships between the IETF and
   other organizations are described in RFC 4052 [RFC4052].

   The role of the liaison manager has grown in importance to the IETF.
   This document supplements [RFC4052] by providing guidelines for
   liaison managers and liaison representatives to other organizations.

Andersson (Ed)          Expires November 4, 2006                [Page 3]

Internet-Draft             Liaison Guidelines                   May 2006

2.  IETF Liaison Relationships

   A major goal of the IETF is to develop standards for the Internet,
   enabling the development of interoperable implementations.  In order
   to develop Internet standards, it is sometimes necessary for the IETF
   to communicate with other organizations which develop standards for
   other types of networks, for Internet applications or for
   technologies that the Internet uses.

   Sometimes the IETF and other organizations consider it mutually
   beneficial to have certain rules governing the relationship.  The
   organizations then enter into a "liaison relationship".  At a high
   level, both sides agree to undertake certain responsibilities with
   respect to each other.  The most basic liaison responsibility is to
   communicate information as necessary, and to respond to requests from
   liaison organizations.

2.1.  Related documents

   The IETF liaison process is specified in several documents.  RFC 4052
   [RFC4052] specifies how the IAB manages the IETF liaison
   relationship; RFC 4053 [RFC4053] specifies how liaison statements
   should be treated.  Organization-specific agreements and documents
   may also be generated in some cases, e.g., RFC 3356 [RFC3356]
   describes the collaboration between the IETF and ITU-T, RFC 3113
   [RFC3113] describes the relationship with 3GPP, and RFC 3131
   [RFC3131]describes the one with 3GPP2.

2.2.  Written information

   Extensive communication may occur between the IETF and the
   organizations it has liaison relationships with.  Much of this
   information is sent in liaison statements and typically contains
   plans, new developments and time schedules that one party believes
   that the other party should be aware of.

   For example, when a liaison organization needs to reference an IETF
   Internet-Draft within a specification that is under development, a
   liaison statement is often sent to the IETF requesting that an RFC
   number be assigned within the required timeframe.  In response, the
   IETF can provide the RFC number or explain why it is not possible to
   provide this within the timeframe requested.

   Requests for expedited action on RFCs by organizations other than
   ITU-T have not typically come in the form of liaison statements.  For
   example, 3GPP/3GPP2 and OMA provide the IETF with an updated list of
   dependencies on a monthly basis, indicating what documents are needed
   and the required timeframe.  The liaison manager tracks the

Andersson (Ed)          Expires November 4, 2006                [Page 4]

Internet-Draft             Liaison Guidelines                   May 2006

   dependency list and conveys the request for expedited publication to
   the appropriate AD.

2.3.  Liaison Managers and Liaison Representatives

   Whenever the IETF enters into a liaison relationship with another
   organization, a liaison manager (often referred to as "the IETF
   liaison") is appointed.  This document describes the expectations,
   tasks and responsibilities of the liaison manager.

   Decisions on IETF liaison relationships are the responsibility of the
   IAB.  This includes whether the IETF should have a liaison
   relationship with a particular organization or not.  The IAB is also
   responsible for appointing both liaison managers and liaison

   In some cases, it may be necessary to have more than one person
   handling the liaison relationship with a given organization.  For
   example, the time commitment required may be too substantial, or the
   technical scope of the liaison relationship may be too broad to be
   handled by a single individual.

   In such cases the IAB may appoint one or more liaison representatives
   to supplement the work of the liaison manager by managing different
   aspects of the liaison relationship between the IETF and the other

2.4.  Terminology

   Terminology relating to IETF liaison procedures is found in
   [RFC4052].  Terms defined below are valid for this document only.

   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 it is only the
   scale of the responsibilities, mandate and tasks that 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

Andersson (Ed)          Expires November 4, 2006                [Page 5]

Internet-Draft             Liaison Guidelines                   May 2006

   indicate either consensus of the IETF as an organization, an Area
   within IETF or a working group.  There the term "IETF consensus"
   needs to be interpreted in the context in which it is used.

Andersson (Ed)          Expires November 4, 2006                [Page 6]

Internet-Draft             Liaison Guidelines                   May 2006

3.  Liaison Guidelines

   Since liaison relationships are intended to be mutually beneficial,
   the IETF liaison to another organization must act as a bi-directional
   communication link between the IETF and the other organization.
   Since the liaison manager has been appointed by the IETF, the liaison
   manager needs to be responsive to the needs and aims of the IETF.

   RFC 4052 lists some of the tasks and expectations relating to liaison
   managers.  This document provides more detailed discussion and
   describes how the role is executed.

3.1.  Expectations

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


   A person appointed to act as a liaison manager on behalf of the IETF
   is expected to have a thorough technical understanding of the key
   issues in the subject area, as well as an understanding of the
   concerns important to stakeholders in both organizations.

   An IETF liaison manager needs to have knowledge of the IETF's
   consensus process in general, as well as the consensus process(es)
   applying to the key issues within the liaison relationship.

   The technical competence of the liaison manager is important, but the
   essence of the liaison manager role is management of the liaison
   process according to the rules that have been agreed upon.  In the
   liaison manager role, the liaison manager acts as a representative of
   the IETF and not an independent voice with respect to topics of
   discussion in the liaison relationship.  The liaison manager must
   therefore be careful to distinguish their own views from documented
   IETF consensus in his or her dealings with the liaison organization.


   Liaison relationships are designed for the mutual benefit of the
   organizations participating in the liaison.  As such, 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
   with respect to 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.

Andersson (Ed)          Expires November 4, 2006                [Page 7]

Internet-Draft             Liaison Guidelines                   May 2006


   When appointing an appropriate person to manage a liaison
   relationship, the IAB needs to take into account any conflicts of
   interest that the individual being considered might have.  Before a
   person is appointed to manage a liaison relationship he or she 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, an individual with an
   industry or organizational leadership position in an organization
   would typically not be suitable for appointment as an 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, it
   is necessary for the liaison be able to allocate sufficient time to
   the task.


   It is expected that a liaison manger will make the IETF aware of new
   developments in the subject area in a timely fashion.

3.2.  Responsibilities

   The liaison manager provides information to the IETF community in
   order to enable the IETF to make decisions based on the best possible
   information.  Information communicated by the IETF liaison to the
   liaised organization is based on IETF consensus.  The liaison manager
   works with the liaised organization to ensure that communication is
   clear.  As part of this, the liaison manager must clearly
   differentiate their own independent positions from those which
   represent IETF consensus.

   It is the responsibility of the liaison manager to ensure that the
   liaised organization provides its requirements to the IETF and that
   the IETF consensus is clearly understood.  This is particularly
   important in situations where the IETF and the liaised organization
   differ substantially in their positions.  In this situation the
   liaison manager needs to facilitate prompt communication so that the
   IETF and the liaised organization can stay in close communication.

   The liaison managers are responsible for clearly and correctly
   communicating the IETF consensus position to the liaised
   organization.  This includes, when specifically instructed, to carry
   any messages from the IETF to the peer organization.  Generally,

Andersson (Ed)          Expires November 4, 2006                [Page 8]

Internet-Draft             Liaison Guidelines                   May 2006

   these communications "represent the IETF", and therefore due care and
   consensus must be applied in their construction.

   The liaison managers are responsible for ensuring that relevant
   information originating from the liaised organization, or other
   information coming to the attention of the liaison manager, reaches
   the correct destination within the IETF, in a timely and correct way.

3.3.  Tasks

   Examples of tasks performed by the liaison manager are provided
   below.  Depending on the nature of liaised organization the task may
   vary in frequency and relative importance.

   1.  Attend relevant meetings and participate in conference calls and
       mailing lists within the liaised organization.  Report back to
       the IETF on the developments of interest.

   2.  A liaison manager is encouraged to communicate; sometimes this
       involves holding frequent update meetings with a team of IETFers
       involved in the liaised organization and other interested parties
       within the IETF, e.g. working group chairs and ADs.  A
       significant result of holding such meetings is an increased
       understanding, and eventually IETF support, for the other
       organizations goals.

   3.  Prepare updates as requested.  The target for these updates
       (e.g., the IAB, an AD, a WG) will typically be identified upon
       establishment of the liaison relationship and/or the appointment
       of the liaison manager.

   4.  Oversee delivery of liaison statements addressed to the IETF.
       This includes ensuring that liaison statements are delivered to
       the appropriate destination within the IETF, as well as
       shepherding the timely creation of responses by the IETF.

   5.  Work with the liaised organization to ensure that the IETF's
       liaison statements are appropriately directed and responded to in
       a timely fashion.  To accomplish this, the liaison needs to build
       a contact network.

   6.  Communicate and coordinate with other IETF liaison managers where
       the activities of two or more liaised organizations overlap.

   7.  Assist with the preparation of IETF liaison statements based on
       IETF consensus.

Andersson (Ed)          Expires November 4, 2006                [Page 9]

Internet-Draft             Liaison Guidelines                   May 2006

   8.  Liaison mangers and liaison representatives will have to report
       to the IETF on the status of the liaison relationship and keep
       track of outstanding issues on behalf of the IETF.  The frequency
       of the reports and the recipients of the reports within the IETF
       will be decided when the liaison relationship is set up and may
       be changed at any time by an IAB decision.  IAB or other parties
       within the IETF may probe for liaison reports as needed or at
       reegular intervals.

3.4.  Mandate

   In Section 3.2 and in Section 3.3, tasks and responsibilities are
   listed which enable the IETF to obtain the information to correctly
   interact with the liaised organizations and to develop and clearly
   communicate IETF consensus.

   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].  Liaison statements are only sent on
   the initiative of the IETF chair, the IAB chair, IETF Area Directors
   or IETF working group chairs.

3.4.1.  Speaking for the IETF

   The IETF functions based on rough consensus, which means that 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.5.  Relationship management

   Liaison managers will be involved in activities for which they are
   not directly responsible, but that might greatly 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 IETF or one of its working
   groups or areas.  Though the liaison manager is not responsible for
   determining consensus, it is important that the liaison manager
   participate in the process and makes his/her expertise and knowledge

Andersson (Ed)          Expires November 4, 2006               [Page 10]

Internet-Draft             Liaison Guidelines                   May 2006


   How consensus is arrived at may vary according to the circumstances.
   Some issues are new and in these cases an open discussion on a
   mailing list should be undertaken.  For some issues consensus has
   already been arrived at or the liaison statement is a mere statement
   of facts (e.g., to inform the liaised organization that an IETF Last
   Call had started on a document they had previously expressed interest
   in) and in these cases the liaison statement can be written and sent
   (such as by a working group chair), possibly involving the liaison

3.5.2.  Incoming Liaison Statements

   When the IETF receives a liaison statement or other communication
   from an organization with which it has an liaison relationship that
   includes a request for a response to the communication, the IETF is
   committed to providing a timely response.  This means that IETF will
   respond within the time requested, and provide information as
   accurately as possible.  This commitment has been one of the key
   discussion points in the past, such as within the (g)mpls change
   process [I-D.andersson-rtg-gmpls-change].

   This commitment does not mean that the IETF will uncritically accept
   the content in the incoming liaison statement.  To the extent the
   liaison contains requirements on IETF technology or protocols they
   will be taken into consideration based on their technical merit.

3.5.3.  Ambiguous incoming Liaison Statements

   Sometimes the IETF, an IETF area or an IETF working group receives
   liaison statements from a liaised organization that is sent to the
   wrong destination.  At other times the liaison statement is sent to
   working groups that are not chartered to do the work that the liaison
   statement addresses.  In some cases it might be the situation that no
   working group is chartered to do the work.

   In such cases the liaison manager should assist in finding the
   appropriate recipient within the IETF that might respond to the
   incoming liaison statement.  Sometimes this might require that the
   intended response is made available for review on one of the IETF
   mailing lists.

3.5.4.  Liaison managers representing other SDOs

   Liaised organizations may appoint a person to act as a liaison
   manager for "their side" of the relationship.  This is the person
   that will speak authoritatively, within the IETF, on the activities

Andersson (Ed)          Expires November 4, 2006               [Page 11]

Internet-Draft             Liaison Guidelines                   May 2006

   performed by the other organization.  The other organization needs to
   make this person known to the IETF.  This person might request a slot
   on a working group agenda to discuss developments and plans of the
   liaised organization.

   The mandates of liaison managers from other organizations are
   recognized by the IETF to the extent needed to understand the
   information received from the liaison manager.  In all other respects
   he/she participates in IETF activities under the same conditions and
   rules as any other IETF participant.

   Note that, according to IETF process [RFC3356], opinions expressed by
   any such liaison manager are given equal weight with opinions
   expressed by other working group participants.

   IETF liaison managers should work to include the liaison manager from
   the liaised organization within their contact network.

Andersson (Ed)          Expires November 4, 2006               [Page 12]

Internet-Draft             Liaison Guidelines                   May 2006

4.  Security Considerations

   This document does not specify any protocol or "bits on the wire".
   However, since interaction with other standards-making organizations
   often relates to security, the liaison manager can assist with
   security related issues, resulting in improved security for Internet

Andersson (Ed)          Expires November 4, 2006               [Page 13]

Internet-Draft             Liaison Guidelines                   May 2006

5.  IANA considerations

   There are no requests to the IANA herein.  Note that the liaison
   manager very often has to understand and convey questions regarding
   IETF namespaces managed by IANA.

Andersson (Ed)          Expires November 4, 2006               [Page 14]

Internet-Draft             Liaison Guidelines                   May 2006

6.  Acknowledgements

   This document was developed as part of a conversation regarding the
   requirements on IETF liaison managers and representatives.  Several
   IAB members have significantly contributed to the document.  Also,
   the document has been improved thanks to suggestions and review from
   Allison Mankin, Dave Meyer and Leslie Daigle.

   A special thanks to Bernard Aboba who apart from drawing on his
   experience as a liaison manager has made many useful comments on the
   subject matter, also has spent time on correcting language and

   Members of the IAB at the time of approval of this document 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

Andersson (Ed)          Expires November 4, 2006               [Page 15]

Internet-Draft             Liaison Guidelines                   May 2006

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

              Andersson, L., "MPLS and GMPLS Change Process",
              draft-andersson-rtg-gmpls-change-02 (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.

Andersson (Ed)          Expires November 4, 2006               [Page 16]

Internet-Draft             Liaison Guidelines                   May 2006

Author's Address

   Loa Andersson

   Email: loa@pi.se

Andersson (Ed)          Expires November 4, 2006               [Page 17]

Internet-Draft             Liaison Guidelines                   May 2006

Intellectual Property Statement

   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

   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

Disclaimer of Validity

   This document and the information contained herein are provided on an

Copyright Statement

   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.


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

Andersson (Ed)          Expires November 4, 2006               [Page 18]