<pre>Network Working Group                                  L. Andersson, Ed.
Request for Comments: 4691                                           IAB
Category: Informational                                     October 2006


    <span class="h1">Guidelines for Acting as an IETF Liaison to Another Organization</span>

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 Notice

   Copyright (C) The Internet Society (2006).

Abstract

   Whenever the 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 <a href="./rfc4052">RFC 4052</a>.  This document expands on the role of liaison
   managers and liaison representatives, giving guidelines on their
   mandate and the expectations, tasks, and responsibilities placed on
   them.

Table of Contents

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



<span class="grey">Andersson                    Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


   <a href="#section-4">4</a>. Security Considerations ........................................<a href="#page-12">12</a>
   <a href="#section-5">5</a>. IANA Considerations ............................................<a href="#page-12">12</a>
   <a href="#section-6">6</a>. Acknowledgements ...............................................<a href="#page-12">12</a>
   <a href="#section-7">7</a>. References .....................................................<a href="#page-13">13</a>
      <a href="#section-7.1">7.1</a>. Normative References ......................................<a href="#page-13">13</a>
      <a href="#section-7.2">7.2</a>. Informative References ....................................<a href="#page-13">13</a>

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   In the course of developing Internet standards, the IETF needs to
   communicate extensively with various other peer organizations,
   including the following:

   o  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)

   o  Consortia such as the World Wide Web Consortium (W3C)

   o  Industrial forums such as the Global Grid Forum (GGF)

   These organizations are usually concerned with developing related
   standards and technical specifications, so that from time to time
   issues of coordination and mutual interest may arise.  To facilitate
   communications, the IETF, through the Internet Architecture Board
   (IAB), establishes permanent liaison relationships with appropriate
   parts of these organizations according to the processes described in
   <a href="./rfc4052">RFC 4052</a> [<a href="./rfc4052" title="&quot;IAB Processes for Management of IETF Liaison Relationships&quot;">RFC4052</a>].

   Whenever the IETF decides to enter into a liaison relationship, a
   liaison manager and possibly some liaison representatives are
   appointed by the IAB to act as a channel between the IETF and the
   peer organization, typically in tandem with counterparts appointed by
   the peer organization.

   Sections <a href="#section-2.2">2.2</a>, <a href="#section-2.3">2.3</a>, and <a href="#section-3">3</a> of <a href="./rfc4052">RFC 4052</a> briefly set out the basic
   functions of the tasks of liaison managers and representatives.  Over
   time, the number and importance of liaisons have grown, and the
   importance of the personal role of IETF liaison managers and
   representatives in maintaining effective relationships with peer
   organizations has grown concomitantly.  This document supplements
   [<a href="./rfc4052" title="&quot;IAB Processes for Management of IETF Liaison Relationships&quot;">RFC4052</a>] by providing guidelines for liaison managers and liaison
   representatives in maintaining communications to peer organizations.






<span class="grey">Andersson                    Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  IETF Liaison Relationships</span>

   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 frequently necessary for the
   IETF to communicate with other organizations that develop standards
   for other types of networks, for Internet applications, or for
   technologies that the Internet uses.

   In some cases, the IETF and peer organizations consider it mutually
   beneficial to have a permanent formal relationship with 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 peer organizations to
   which liaisons are maintained.

   Decisions on IETF liaison relationships are the responsibility of the
   IAB.  This includes whether or not the IETF should have a liaison
   relationship with a particular organization.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Related Documents</span>

   The IETF liaison process is specified in several documents.  <a href="./rfc4052">RFC 4052</a>
   [<a href="./rfc4052" title="&quot;IAB Processes for Management of IETF Liaison Relationships&quot;">RFC4052</a>] specifies how the IAB manages the IETF liaison
   relationship; <a href="./rfc4053">RFC 4053</a> [<a href="./rfc4053" title="&quot;Procedures for Handling Liaison Statements to and from the IETF&quot;">RFC4053</a>] specifies how liaison statements
   should be treated.  Organization-specific agreements and documents
   may also be generated in some cases, e.g., <a href="./rfc3356">RFC 3356</a> [<a href="./rfc3356" title="&quot;Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines&quot;">RFC3356</a>]
   describes the collaboration between the IETF and ITU-T, <a href="./rfc3113">RFC 3113</a>
   [<a href="./rfc3113" title="&quot;3GPP-IETF Standardization Collaboration&quot;">RFC3113</a>] describes the relationship with the 3rd Generation
   Partnership Project (3GPP), and <a href="./rfc3131">RFC 3131</a> [<a href="./rfc3131" title="&quot;3GPP2-IETF Standardization Collaboration&quot;">RFC3131</a>] describes the one
   with the Third Generation Partnership Project 2 (3GPP2).

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Liaison Managers and Liaison Representatives</span>

   Whenever the IETF enters into a liaison relationship with another
   organization, a liaison manager (often referred to as "the IETF
   liaison") is appointed by the IAB.  This document expands on the
   mandate of and the expectations, tasks, and responsibilities placed
   on the liaison manager by <a href="./rfc4052#section-2.2">Section&nbsp;2.2 of RFC 4052</a>.

   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.




<span class="grey">Andersson                    Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


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

   The value of personal relationships between the IETF liaison manager
   and representatives and members of the peer organization is central
   to the roles.  The IAB will be looking for people who have both a
   good technical understanding of the work being carried out and
   effective personal relationships within the peer organization.
   Ongoing face-to-face interactions between the IETF liaisons and
   members of the peer organization are seen as critical to the
   effective functioning of the role.  These interactions should allow
   the liaisons to keep the IETF abreast, and preferably ahead, of
   matters of mutual interest or potential conflict.  When the liaison
   is working effectively, it should facilitate the IETF and the peer
   organization working synergistically and reduce the chance of
   overlapping or conflicting standards being created.

<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Written Communications</span>

   Aside from the personal contacts between liaisons and the peer
   organization, extensive communication may occur between the IETF and
   the peer organizations through written materials.  Much of this
   communication is through liaison statements that typically contain
   plans, new developments, and time schedules of which one party
   believes that the other party should be aware.

   The liaison manager should be aware of these written communications
   and assist both parties to see that appropriate action is taken in
   relation to liaison statements passing in both directions.

   For example, when a liaison organization, such as ITU-T, needs to
   reference material that is under development in the IETF: the final
   reference in the peer organization's document needs the permanent
   identifier (RFC number) that will be assigned to the Internet Draft
   when it is approved and published.  To meet the publication schedule
   of the peer organization, 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.

   An alternative situation that involves more specific action by the
   liaison manager also involves requests for this kind of expedited
   action on RFCs.  For example, 3GPP/3GPP2 and the Open Mobile Alliance
   (OMA) provide the IETF with an updated list of dependencies between
   their documents and IETF documents on a monthly basis, indicating



<span class="grey">Andersson                    Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


   what documents are needed and the required timeframe.  In this case,
   the liaison manager tracks the dependency list and, when necessary,
   conveys the request for expedited assignment to the appropriate IETF
   Area Director (AD).

<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>.  Terminology and Conventions</span>

   Terminology relating to IETF liaison procedures is found in
   [<a href="./rfc4052" title="&quot;IAB Processes for Management of IETF Liaison Relationships&quot;">RFC4052</a>].  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

   <a href="./rfc2026">RFC 2026</a> [<a href="./rfc2026" title="&quot;The Internet Standards Process -- Revision 3&quot;">RFC2026</a>] and <a href="./rfc2418">RFC 2418</a> [<a href="./rfc2418" title="&quot;IETF Working Group Guidelines and Procedures&quot;">RFC2418</a>] discuss the IETF consensus
   process.  In this document, the term "IETF consensus" is used to
   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.

   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 <a href="./rfc2119">RFC 2119</a> [<a href="./rfc2119" title="&quot;Key words for use in RFCs to Indicate Requirement Levels&quot;">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Guidelines for Liaison Managers and Representatives</span>

   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.

   <a href="./rfc4052">RFC 4052</a> lists some of the tasks and expectations relating to liaison
   managers and liaison representatives.  This document expands on their
   mandate, provides more detailed discussion, and describes how the
   role is executed.





<span class="grey">Andersson                    Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>.  Mandate</span>

   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 [<a href="./rfc4052" title="&quot;IAB Processes for Management of IETF Liaison Relationships&quot;">RFC4052</a>].  Liaison statements are only sent on
   the initiative of the IETF chair, the IAB chair, IETF Area Directors,
   or IETF working group chairs.

   In <a href="#section-3.3">Section 3.3</a> and <a href="#section-3.4">Section 3.4</a>, responsibilities and tasks are listed
   that enable the IETF to obtain the information to correctly interact
   with the liaised organizations and to develop and clearly communicate
   IETF consensus.

<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>.  Speaking for the IETF</span>

   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.

<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>.  Expectations</span>

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

   Competences required

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

      To this end, the liaison manager or representative must be able to
      communicate effectively with members of the peer organization,
      especially in face-to-face situations.  This is important both to
      communicate the IETF's viewpoint and to gather information about
      the issues in the peer organization that the IETF needs to
      understand.



<span class="grey">Andersson                    Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


      In support of the liaison process, a person appointed to act as a
      liaison manager or representative on behalf of the IETF is
      expected to have a good 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 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 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 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.

   Distance

      A liaison may not be able to maintain the required perspective if
      he or she is closely involved in the outcome of the work in the
      peer organization.  A conflict of interest might arise if the
      liaison is involved in the management of the relevant part of the
      peer organization, has a close technical involvement in the work
      that is the subject of the liaison, or has a close interest in the
      outcome of the work in the peer organization through his or her
      employment.  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.







<span class="grey">Andersson                    Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


   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 that the liaison be able to allocate sufficient
      time to the task.

   Timeliness

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

<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>.  Responsibilities</span>

   The liaison manager and representatives provide information to the
   IETF community in order to enable the IETF to make decisions based on
   the best possible information regarding the work in the peer
   organization.  In turn, information communicated by the IETF liaison
   to the liaised organization MUST be based on the relevant IETF
   consensus.  The liaison manager works with the liaised organization
   to ensure that communication is clear.  As part of this, the liaison
   must clearly differentiate his or her own independent positions from
   those that represent IETF consensus.

   It is the responsibility of the liaison manager to ensure that the
   liaised organization communicates its requirements to the IETF in a
   timely fashion 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 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, when specifically instructed,
   carrying any messages from the IETF to the peer organization.
   Generally, these communications "represent the IETF", and therefore
   due care and consensus must be applied in their construction.

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






<span class="grey">Andersson                    Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>.  Tasks</span>

   Examples of tasks performed by the liaison manager are provided
   below.  Depending on the nature of the 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 to gather
       information relevant to the liaison relationship.  Note
       developments of interest for onward communication to the IETF.
       Communicate the point of view of the IETF consensus to the peer
       organization.

   2.  Communicate information relevant to the liaison relationship to
       the relevant part of the IETF either by 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 ensuring that 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 facilitate 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 upon establishment of the
       liaison relationship and/or the appointment of the liaison
       manager.

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

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

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





<span class="grey">Andersson                    Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


   8.  Assist with the preparation of 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 purpose, they will need to 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
       regular intervals.

<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>.  Relationship Management</span>

   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.

<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>.  IETF Consensus Process on Liaison Statements</span>

   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.  Though the liaison manager is not
   responsible for determining consensus, it is important that the
   liaison manager participate in the process and makes his or her
   expertise and knowledge available.

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

<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>.  Incoming Liaison Statements</span>

   When the IETF receives a liaison statement or other communication
   from an organization with which it has a liaison relationship that
   includes a request for a response to the communication, the IETF is
   committed to providing a timely response.  This means that the 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 [<a href="#ref-GMPLS" title="&quot;MPLS and GMPLS Change Process&quot;">GMPLS</a>].



<span class="grey">Andersson                    Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


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

<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>.  Ambiguous Incoming Liaison Statements</span>

   Sometimes the IETF, an IETF area, or an IETF working group receives
   liaison statements from a liaised organization that are 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.

<span class="h4"><a class="selflink" id="section-3.5.4" href="#section-3.5.4">3.5.4</a>.  Liaison Managers Representing Peer Organizations</span>

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

   Opinions expressed by a liaison mangers of other SDOs, other than
   reports on work within the liaised organization, are given equal
   weight with opinions expressed by other working group participants.
   <a href="./rfc3356">RFC 3356</a> [<a href="./rfc3356" title="&quot;Internet Engineering Task Force and International Telecommunication Union - Telecommunications Standardization Sector Collaboration Guidelines&quot;">RFC3356</a>] describes this in the context of the relationship
   between the IETF and the ITU-T; however, the same model is applicable
   to all other organizations with which the IETF has a liaison
   relationship.

   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 or she participates in IETF activities under the same conditions
   and rules as any other IETF participant.  It is important that the
   IETF liaison manager understands the extent to which the peer liaison
   manager is mandated or delegated to speak on behalf of the peer
   organization, and to inform the relevant part of the IETF if the peer
   liaison manager appears to be stepping outside the role or stance
   given to him or her by the peer organization.



<span class="grey">Andersson                    Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


   IETF liaison managers should work to include the liaison manager from
   the liaised organization within their contact network, and to
   understand the positions being communicated by the peer liaison
   manager.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Security Considerations</span>

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

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  IANA Considerations</span>

   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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Acknowledgements</span>

   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, based on his experience as a
   liaison manager, has made many useful comments on the subject matter.
   Elwyn Davies and Bernard Aboba have both spent time correcting
   language and grammar.

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

   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



<span class="grey">Andersson                    Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  References</span>

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>.  Normative References</span>

   [<a id="ref-RFC2026">RFC2026</a>]  Bradner, S., "The Internet Standards Process -- Revision
              3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>, <a href="./rfc2026">RFC 2026</a>, October 1996.

   [<a id="ref-RFC2119">RFC2119</a>]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.

   [<a id="ref-RFC2418">RFC2418</a>]  Bradner, S., "IETF Working Group Guidelines and
              Procedures", <a href="https://www.rfc-editor.org/bcp/bcp25">BCP 25</a>, <a href="./rfc2418">RFC 2418</a>, September 1998.

   [<a id="ref-RFC4052">RFC4052</a>]  Daigle, L. and Internet Architecture Board, "IAB Processes
              for Management of IETF Liaison Relationships", <a href="https://www.rfc-editor.org/bcp/bcp102">BCP 102</a>,
              <a href="./rfc4052">RFC 4052</a>, April 2005.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>.  Informative References</span>

   [<a id="ref-GMPLS">GMPLS</a>]    Andersson, L., <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&amp;q=inurl:draft-+%22MPLS+and+GMPLS+Change+Process%22'>"MPLS and GMPLS Change Process"</a>, Work in
              Progress, December 2005.

   [<a id="ref-RFC3113">RFC3113</a>]  Rosenbrock, K., Sanmugam, R., Bradner, S., and J. Klensin,
              "3GPP-IETF Standardization Collaboration", <a href="./rfc3113">RFC 3113</a>, June
              2001.

   [<a id="ref-RFC3131">RFC3131</a>]  Bradner, S., Calhoun, P., Cuschieri, H., Dennett, S.,
              Flynn, G., Lipford, M., and M. McPheters, "3GPP2-IETF
              Standardization Collaboration", <a href="./rfc3131">RFC 3131</a>, June 2001.

   [<a id="ref-RFC3356">RFC3356</a>]  Fishman, G. and S. Bradner, "Internet Engineering Task
              Force and International Telecommunication Union -
              Telecommunications Standardization Sector Collaboration
              Guidelines", <a href="./rfc3356">RFC 3356</a>, August 2002.

   [<a id="ref-RFC4053">RFC4053</a>]  Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
              Handling Liaison Statements to and from the IETF", <a href="https://www.rfc-editor.org/bcp/bcp103">BCP</a>
              <a href="https://www.rfc-editor.org/bcp/bcp103">103</a>, <a href="./rfc4053">RFC 4053</a>, April 2005.

Editor's Address

   Loa Andersson
   IAB

   EMail: loa@pi.se






<span class="grey">Andersson                    Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc4691">RFC 4691</a>                   Liaison Guidelines               October 2006</span>


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, 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 <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.

   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
   <a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.

   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 provided by the IETF
   Administrative Support Activity (IASA).







Andersson                    Informational                     [Page 14]
</pre>