One document matched: draft-iab-liaison-guidelines-01.txt
Differences from draft-iab-liaison-guidelines-00.txt
Network Working Group L. Andersson
Internet-Draft Acreo AB
Expires: July 27, 2006 January 23, 2006
Guidelines for Acting as an IETF Liaison to Another Organization
draft-iab-liaison-guidelines-01.txt
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-
Drafts.
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
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
managers.
Andersson Expires July 27, 2006 [Page 1]
Internet-Draft Liaison Guidelines January 2006
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IETF Liaison Relationships . . . . . . . . . . . . . . . . . . 4
2.1. Related documents . . . . . . . . . . . . . . . . . . . . 4
2.2. Written information . . . . . . . . . . . . . . . . . . . 4
2.3. A Person Acting As a Liaison Manager . . . . . . . . . . . 5
2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Liaison Guidelines . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Expectations . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Responsibilities . . . . . . . . . . . . . . . . . . . . . 7
3.3. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Mandate . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.1. Speaking for the IETF . . . . . . . . . . . . . . . . 9
3.5. Relationship management . . . . . . . . . . . . . . . . . 9
3.5.1. IETF consensus process on liaison statements . . . . . 9
3.5.2. Incoming Liaison Statements . . . . . . . . . . . . . 10
3.5.3. Ambigous incoming Liaison Statements . . . . . . . . . 10
3.5.4. Liaison managers representing other SDOs . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Normative References . . . . . . . . . . . . . . . . . . . 15
7.2. Informative References . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Andersson Expires July 27, 2006 [Page 2]
Internet-Draft Liaison Guidelines January 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, 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 Expires July 27, 2006 [Page 3]
Internet-Draft Liaison Guidelines January 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; RFC 3356 [RFC3356] describes the collaboration
between the IETF and ITU-T.
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/PP2 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
dependency list and conveys the request for expedited publication to
the appropriate AD.
Andersson Expires July 27, 2006 [Page 4]
Internet-Draft Liaison Guidelines January 2006
2.3. A Person Acting As a Liaison Manager
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
representatives.
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 a liaison representative to manage
one aspect of the liaison relationship between the IETF and the other
organization.
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
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 Expires July 27, 2006 [Page 5]
Internet-Draft Liaison Guidelines January 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 is accountable to 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.
Competence
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.
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.
Andersson Expires July 27, 2006 [Page 6]
Internet-Draft Liaison Guidelines January 2006
Distance
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.
Timeliness
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
liased 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 liased organization
differ substantially in their positions. In this situation the
liaison manager needs to facilitate prompt communication so that the
IETF the the liased organization can stay in close communication.
The liaison managers are responsible for clearly and correctly
communicating the IETF consensus position to the liased organization.
This includes, when specifically instructed, to carry any messages
from the IETF to the peer organization. Generally, these
Andersson Expires July 27, 2006 [Page 7]
Internet-Draft Liaison Guidelines January 2006
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 liased 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
sheparding 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 Expires July 27, 2006 [Page 8]
Internet-Draft Liaison Guidelines January 2006
8. Liaison mangers and liaison representatives shall 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 Section 3.2 and in Section Section 3.3, tasks and
responsibilities are listed which enable the IETF to obtain the
information to correctly interact with the liased 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, 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 Expires July 27, 2006 [Page 9]
Internet-Draft Liaison Guidelines January 2006
available.
How consensus is arrived at may vary according to the circumstnaces.
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 and in these cases the liaison statement can
be written and sent (such as by a working group chair), possibly
involving the liaison manager
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, 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. Ambigous incoming Liaison Statements
Sometimes the IETF, IETF areas or IETF working groups receives
liaison statements from a liaised organisation that is sent to the
wrong destination. At other times the liaision statement is sent to
working groups that is 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
Liased organizations may appoint a person to act as a liaison manager
for "their side" of the relationship. This is the person that will
speak for the other organization within the IETF. 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.
Andersson Expires July 27, 2006 [Page 10]
Internet-Draft Liaison Guidelines January 2006
The mandate 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.
IETF liaison managers should work to include the liaison manager from
the liaised organization within their contact network.
Andersson Expires July 27, 2006 [Page 11]
Internet-Draft Liaison Guidelines January 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
protocols.
Andersson Expires July 27, 2006 [Page 12]
Internet-Draft Liaison Guidelines January 2006
5. IANA considerations
There are no requests to the IANA herein. Note that the liaison
manager very often has to understand and bridge questions regarding
IETF namespace.
Andersson Expires July 27, 2006 [Page 13]
Internet-Draft Liaison Guidelines January 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
subjet matter, also have spent time on correcting language and
grammar.
Members of the IAB at the time of approval of this document were:
Bernard Aboba
Loa Andersson
Brian Carpenter
Leslie Daigle
Patrik Falstrom
Bob Hinden
Kurtis Lindqvist
David Meyer
Pekka Nikander
Eric Rescorla
Pete Resnick
Jonathan Rosenberg
Lixia Zhang
Andersson Expires July 27, 2006 [Page 14]
Internet-Draft Liaison Guidelines January 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
[I-D.andersson-rtg-gmpls-change]
Andersson, L., "MPLS and GMPLS Change Process",
draft-andersson-rtg-gmpls-change-02 (work in progress),
December 2005.
[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 Expires July 27, 2006 [Page 15]
Internet-Draft Liaison Guidelines January 2006
Author's Address
Loa Andersson
Acreo AB
Email: loa@pi.se
Andersson Expires July 27, 2006 [Page 16]
Internet-Draft Liaison Guidelines January 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
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andersson Expires July 27, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-24 09:54:47 |