Internet DRAFT - draft-andersson-iab-liaison-guidelines
draft-andersson-iab-liaison-guidelines
Network Working Group L. Andersson
Internet-Draft Acreo AB
Expires: January 2, 2006 July 2005
Guidelines for Acting as an IETF Liaison to Another Organization
draft-andersson-iab-liaison-guidelines-00.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 January 2, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
Whenever IETF decides to enter into a liaison relationhsip with
another organization, e.g. a Standards Development Organization, a
consortium, or an industrial forum, a liaison manger 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 give guidelines on
expectations, tasks, responsibilities and mandate of the liaisons
managers.
Andersson Expires January 2, 2006 [Page 1]
Internet-Draft Liaison July 2005
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 liaisons . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Related documents . . . . . . . . . . . . . . . . . . . . 4
2.2. Written information . . . . . . . . . . . . . . . . . . . 4
2.3. A person acting as liaison . . . . . . . . . . . . . . . . 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
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
Andersson Expires January 2, 2006 [Page 2]
Internet-Draft Liaison July 2005
1. Introduction
IETF has extensive communication with other organizations on issues
telating to the development of standards for the Internet. Part of
this is in written form, known as "liaison statements" sent between
the organizations. Part is done by appointing a person to be
responsible for the relationship with the other organization, a
liaison manager. We normally speak of such a person as "the liaison"
from the IETF to this other organization.
The organizations IETF establish liaison relationships with comes
from various categories, such as Standards Developing Organization
(SDO), e.g. the ITU-T or IEEE 802, consortium, and industrial forum.
Global Grid Forum is an example of the latter. Usually the IETF
liaisons are concerned with groups that develop standards and
technical specifications, and many types of groups do so.
Whenever 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 become more and important to the
IETF. This document therefore, in addition to what is specified in
RFC 4052, gives some guidelines for liaison managers and liaison
representatives to another organization.
Andersson Expires January 2, 2006 [Page 3]
Internet-Draft Liaison July 2005
2. IETF liaisons
A goal for IETF is to develop standards for the Internet. These
standards are intended to make interoperable implementations for the
Internet possible. Developing Internet standards is an actvity that
makes communication with and agreements between IETF and other
organizations necessary. Other organizations may develop standards
for other types of networks, applications running over the Internet
and/or technologies that the Internet uses.
Sometimes the IETF and other organizations consider it mutually
beneficial to have certain rules governing such a relationship. The
organizations then enter into a "liaison relationship". On a high
level it can be said that both sides agree to undertake certain
responsibilities towards each other. The most basic liaison
responsibility is to communicate information as necessary and to
respond to requests for information from organizations participating
in the liasion relationship.
2.1. Related documents
The IETF liaison process is specified in an number of documents, RFC
4052 specifies how the IAB mamage 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
A large amount of information may be exchanged between the IETF and
the organizations it has a liaison relationships with. This
information is sent in a liaison statement and typically contains
plans, new developments and time schedules that one of the parties
believe that the other should be aware of. A typical example is that
one of the organizations that the IETF has a liasion relationship
with needs to reference IETF documents as part of its document
publication activity. The liaison statement the IETF receive would
then ask us to have an RFC number ready in time. The response IETF
sent could either include that RFC number or explain why it is not
possible to have it available within the time requested.
The requests for quick action on RFCs by other organizations than ITU
have not typically come as liaison statements - e.g. from 3GPP/PP2
and OMA, they've come as a monthly-updated list of the document
dependencies and dates-required. The liaison manager is expected to
follow this and interact and convey the requests via the AD's
requests for expedited publication citing the table (or email when
needed).
Andersson Expires January 2, 2006 [Page 4]
Internet-Draft Liaison July 2005
2.3. A person acting as liaison
Whenever the IETF enteres in to a liaison relationship with another
organization a liaison manager is appointed. In day to day talk we
refer to this person "the IETF liaison" to this other organization.
This document gives guidelines on expecations, tasks and
responsibilities for such a person.
All decisions on IETF liaison relationships, e.g. whether we should
have a liaison realtionship with a certain organization or not, is
the responsibility of the IAB. This is also true for appointing
liaison managers or liaison representatives.
In some cases, it may be necessary to have more than one person
working with the liaison realtionship with a given organization. For
example, it may be the case that the technical scope of the liaison
relationship is to varied, or that the time committement is more than
would be reasonable for a single person.
In such cases we might appoint a liaison representative, a person
appointed to manage one certain aspect of the liaison relationship
between IETF and the other organization.
2.4. Terminology
A terminology for managing the IETF relationship procedures are found
in RFC 4052, definitons given here is intended to be the delta 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 tesks that is different
the rest of this document only explicitly mentioning the liaison
managers.
Andersson Expires January 2, 2006 [Page 5]
Internet-Draft Liaison July 2005
3. Liaison Guidelines
Since the liaison relationship is by definition intended to be mutual
beneficial, the IETF liaison to another organization must act as a
bi-directional communication link between the IETF and the other
organization. While this is self evident it, is also evident that
since the liasion manager has been appointed by the IETF that there
are certain expectations from the IETF.
RFC 4052 lists some tasks and expectations on liaison managers, the
intention in this document is discuss this in some more detail and at
the same time focus more on how to execute the role as liaison
manager.
3.1. Expectations
There are certain expectations placed on liaison managers appointed
by the IETF. Examples of these expectations are listed below.
Comptence
A person appointed to act as a liaison manager on behalf of the IETF
is expected to have a thorough technical knowledge and understanding
of the key issues in the subject area. That is, the liaison manager
is expected to have a thorough understanding of the stakeholder
issues from both organizations.
An IETF liaison manager needs to have knowledge of the IETF's
consensus process in general and on the consesus work on the key
issues for the specific liaison relationship in particular.
The technical comptence of the liaision manager is important, but it
should be understood the essence of the liaison manager role is
giving attention to managing the rules agreed upon. While the
liaison manager is managing the liaison relationship, the liasion
mananger is not an independent IETF technologist with respect to the
topics that are the focus of the liaision relationship. Rather, the
liaison manager must represent documented IETF consensus in his or
her dealings with the liasied organization.
Perspective
Liaison relationships are designed for the mutual benefit of the
organisations participating in the liasion. As such, swift
information flow in both directions is a firm requirement. It is
nevertheless expected that an IETF liaison manager in everthing that
relates to the subject matter of the liaison relationship promotes
the interests of the IETF. A liaison managers needs to approach the
Andersson Expires January 2, 2006 [Page 6]
Internet-Draft Liaison July 2005
tasks of the liaison relationship wearing an IETF hat. It is NOT the
tasks of a liaison manager to promote the interests of the liaised
organization within the IETF.
Distance
When appointing an appropriate person to manage a liasion
relationship the IAB needs to take into account any conflicts of
interest that the individual being considered might have. IAB will
not appoint a person to liaison manger if there is strong conflict of
interests. Examples of such conflict of interest includes industry
or organization leadership positions in the liaised organizations.
Before a person is appointed to manage a liaison relationship he or
she will be asked to explicitly state any conflicts of interest.
Commitment and opportunity
A liaison needs to be committed to and have the opportunity to solve
the issues for which the liaison relationship has been created. This
also includes having time allocated to spend on the task.
Timeliness
One key factor when acting as a liaison is to make the IETF aware of
the new development in the subject area in a timely fashion.
3.2. Responsibilities
The key responsibility of the liaison manager is to make sure that
the information flow between the IETF and the liaised organization is
as effective as possible.
Information brought to the IETF will be used so that the IETF may
take decisions and actions based on the best possible information.
Information from the IETF is based on IETF consensus. The liaison
manager does not develop independent positions different from the
IETF consensus, though the liaison manager works with the other
organization on ways to ensure that the communication is clear; that
the other organization gets it requirements to the IETF, that the
IETF consensus is clear. If differences are strong between the IETF
and the other organization, the relevant IETF and other organization
leadership need to be in touch; the liaison manager needs to
facilitate this communication quickly.
From a more formal point of view the liaison managers are responsible
for a clear and correct communication of the IETF consensus position
to the liaised organization. This includes, when specifically
Andersson Expires January 2, 2006 [Page 7]
Internet-Draft Liaison July 2005
instructed, to carry 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 managers are responsible that any relevant information
originating from the liaised organization, or other information and
comes to the attention of the liaison manager, reaches the correct
destination, in a timely and correct fashion, within the IETF.
3.3. Tasks
The list below are examples of tasks that a liaison manager could be
required to perform. Depending on the nature of liaised organization
the task may vary in frequence and relative importance,
1. Attend relevant meetings, mailing lists and conference calls of
the liaised organization as needed and report back to the
appropriate part of the IETF on any developments that is of
interest for the IETF.
2. A liaison manager is encouraged to work through delegation,
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 of holding such meetings is an
increased understanding, and eventually IETF support, for the
other organizations goals.
3. Prepare updates as this is requested by the IETF side. The
target of these updates (e.g., the IAB, an AD, a WG) will
generally 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,
ensuring that they reach the appropriate destination within the
IETF, and ensure that relevant responses from the IETF are
created and sent in a timely fashion.
5. Work with the liaised organization to ensure that the IETF's
liaison statements are appropriately directed and responded to in
a timely fashion. This could e.g. be accomplished by building an
informal contact network for exchanging relevant information.
6. Communicate and coordinate with other IETF liaison managers where
concerned technical activities of two or more organizations that
the IETF has a liaison relationship with overlap.
Andersson Expires January 2, 2006 [Page 8]
Internet-Draft Liaison July 2005
7. Based on the IETF consensus position be part of preparation of
IETF liaison statements.
8. Once the IETF has decided that a liaison statement should be sent
the liasion manager should be part of the preparation of the
liaison statement. The liaison manager should do this based on
the IETF consensus position and the information he or she has
about the liaised organisation.
9. Liaison mangers and liaison representaives shall report to the
IETF on 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
decide when the liaison relationship is set up and may be changed
at any time by an IAB decision. Status report and issue tracking
shall be done by means of the IETF liaison managment system."
3.4. Mandate
The mandate for IETF liaison managers is strictly limited, it
comprises only conveying IETF consensus to the liased organization.
In Section 3.3 and in Section 3.2 a number of tasks and
responsibilites is listed. There are at least two important aspects
of the tasks and responsibilities. Carried out carefully they will
supply the IETF with the information need to correctly interact with
other organizations. The other, equally important, aspect is that
the tasks and responsibilites will help the liaison manager
understand the IETF consensus and build a basis on which is possible
to execute the mandate.
The liaison manager MUST NOT on his or her 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 RFC 4052. 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
IETF does work on the rough consensus basis, which means that the
right to speak for the IETF is not in any way delegated. However,
the liaison manager has the task to speak for the IETF on the subject
matter of the liaison, but only after making sure that the IETF
consensus is understood. Some guidelines in understanding the IETF
consensus are given above, but the most important aspect is a close
and detailed coordination and consultation with the IETF side in the
liaison relationship.
Andersson Expires January 2, 2006 [Page 9]
Internet-Draft Liaison July 2005
4. Security Considerations
Because the interaction on protocols with other standards-making
organizations often concerns security aspects, though this document
does not specify any protocol or "bits on the wire", getting the
liaison manager role right does improve the development of secure
protocols for the Internet.
Andersson Expires January 2, 2006 [Page 10]
Internet-Draft Liaison July 2005
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 January 2, 2006 [Page 11]
Internet-Draft Liaison July 2005
6. Acknowledgements
This document was developed as part of a conversation regarding the
requirements on IETF liaison managers and representatives. Several
IAB memebers 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.
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 January 2, 2006 [Page 12]
Internet-Draft Liaison July 2005
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
[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 January 2, 2006 [Page 13]
Internet-Draft Liaison July 2005
Author's Address
Loa Andersson
Acreo AB
Email: loa@pi.se
Andersson Expires January 2, 2006 [Page 14]
Internet-Draft Liaison July 2005
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 (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Andersson Expires January 2, 2006 [Page 15]
