IETF Liaisoning
draft-bradner-ietf-liaisoning-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Scott O. Bradner , Dr. Thomas Narten | ||
| Last updated | 2014-10-22 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bradner-ietf-liaisoning-00
Network Working Group Scott Bradner
Internet-Draft Harvard University
Intended status: BCP
Obsoletes: TBD T. Narten
Updates: TBD IBM
Expires: April 22, 2015 October 22, 2014
IETF Liaisoning
draft-bradner-ietf-liaisoning-00.txt
Abstract This document details the processes by which the IETF interacts
with peer organizations. In some cases this involves establishing
long lasting formal liaison relationships and in other cases the
processes are less formal and of shorter duration. The document is
designed to be useful to both IETF participants and to the
participants in the other organizations with which the IETF
interacts. The document also includes information and pointers to
information about the IETF and its operation that may be of use to
participants in such peer organizations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on December xx, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
Bradner & Narten [Page 1]
Internet-Draft IETF Liaisoning October 2014
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
TBD
1. Introduction
Standards development organizations (SDOs), including the IETF, often
find it useful to engage in direct, and often formal, communication
with each other convey information relevant to a standards
development effort in a SDO or to coordinate related standards
development efforts.
For example, as a standards development organization (SDO) working in
the Internet area, the IETF finds it increasingly necessary to
communicate and coordinate their activities involving Internet-
related technologies with other SDOs working in the same area. This
is useful in order to avoid accidental overlap in work efforts and to
manage interactions between their groups. In cases where the mutual
effort to communicate and coordinate activities is formalized, these
relationships are generically referred to as "liaison relationships".
In addition, the IETF interacts with Internet-related organizations
that are not directly involved in standards development, such as
Internet Corporation for Assigned Names and Numbers (ICANN), the
regional Internet registries (RIRs), and the Internet Governance
Forum (IGF). These interactions sometimes require that the IETF
provide formal communications on a topic but do not require the
ongoing coordination that a liaison relationship implies.
This document addresses both situations.
2. IETF Background
This section provides a very quick overview of the IETF for the
benefit of people in other organizations who may not be familiar with
the IETF. Some of this information is from the Tao of the IETF [Tao],
where a fuller picture of the IETF and how it works can be found.
2.1. IETF Scope
The IETF is concerned with all protocols, procedures, and conventions
that are used in or by the Internet, whether or not they are part of
the TCP/IP protocol suite. [RFC2026]
2.2. IETF History
The Internet Engineering Task Force (IETF) was formed in 1986 as an
Bradner & Narten [Page 2]
Internet-Draft IETF Liaisoning October 2014
expansion of US government sponsored activities aimed at the
development of Internet related technology. Although the IETF
received US Government support until 1997, the IETF became a self-
directed activity before 1990. Since then, support for the IETF has
come from meeting fees and, since the late 1990s, from the Internet
Society.
The IETF holds face-to-face three times a year but most of the work
of the IETF takes place on mailing lists. Attendance at the face-to-
face meetings grew from 21 at the first meeting to over 28 hundred at
the height of the Internet boom in 2010. Meeting attendance has been
between 1,000 and 1,500 for most of the last decade.
2.3. Internet Research Task Force
The Internet Research Task Force (IRTF) includes research groups that
work on topics that are not yet ready for standardization. As with
IETF working groups, the main work of IRTF research groups is done
over mailing lists, but IETF research groups occasionally meet during
an IETF face-to-face meeting.
2.4. Internet Society
The IETF has no separate legal existence, it has been operating as an
organized activity of the Internet Society since 1966.
The mission of the Internet Society (www.internetsociety.org/) is "to
promote the open development, evolution, and use of the Internet for
the benefit of all people throughout the world". The Internet Society
sees support for the IETF as a part of fulfilling its mission.
2.5. IETF Participants
The IETF does not have any members or membership agreements.
Individuals participate in the activities of the IETF on their own
behalf and are judged by the quality of their ideas not on what
company they might work for. Participation can be in person at face-
to-face meetings, by remote participation at such meetings, via email
discussion lists or by publishing IETF documents.
2.6. IETF Structure
The work of the IETF is done in working groups. The scope and goals
of each working group is defined in a charter. Working groups have
one or more chairs, who are responsible for the proper functioning of
the working group and for judging consensus on topics discussed
within the working group.
IETF working groups are grouped together into Areas for managerial
efficiency. Each IETF Area has two Area Directors (ADs) who are
responsible for the proper functioning of the Area, for the creation
Bradner & Narten [Page 3]
Internet-Draft IETF Liaisoning October 2014
and termination of working groups within the area and for serving on
the Internet Engineering Steering Group (IESG).
The IESG is the standards approval body of the IETF and is
responsible for approving the creation of working groups and for the
technical management of IETF activities and for the Internet
standards process. The IESG gets advice on the creation of working
groups from the Internet Architecture Board (IAB).
In addition to providing advice to the IESG on creation of working
groups, the IAB is responsible for all IETF relationships with other
groups (the subject of this memo) and for providing general
architectural guidance to the IETF and its working groups.
2.7. The IETF Trust
The IETF Trust (trustee.ietf.org/) is a legal entity set up in 2005
to hold whatever intellectual property rights the IETF accumulates
during its work.
2.8. IETF Documents
IETF documents and mailing lists are publically available, other than
a few internal mailing lists and parts of some contracts.
2.8.1. Internet Drafts
IETF Internet Drafts are IETF working documents. Most Internet
Drafts are submitted by individuals and represent the opinions of the
people listed on the face of the Internet Draft. The publishing
process for Internet Drafts is automated. As long as the document is
formatted correctly and includes the proper boilerplate it will get
published. The mere publication of an Internet Draft should not be
taken as an indication that anyone participating in the IETF, other
than the authors, have knowledge of or support the document. Some
other Internet Drafts are working group documents and are assumed to
represent the consensus of the working group, at least to some level.
The Internet Draft's filename can be used to determine its status.
Internet Drafts whose filename starts with draft-ietf- are working
group documents. Internet Drafts whose filename begin with draft-
iab- or draft-iesg- are IAB or IESG working Documents. Other
Internet drafts are the work of their authors. Internet Draft
filenames include a version number at the end.
2.8.2. RFCs
RFCs are the archival publications of the IETF. Once published, the
contents of an RFC is not changed. There are many types of RFCs.
Some RFCs are standards track, some informational, some historic and
some are jokes. The type and current status of a RFC can be found in
the RFC index.
Bradner & Narten [Page 4]
Internet-Draft IETF Liaisoning October 2014
2.9. IETF Standards Process
As mentioned above, most of the work of the IETF is done in working
groups. The normal development process for a RFC, standards track or
informational, involves one or more people developing an Internet
draft. The Internet Draft can be offered to a working group as long
as the topic is covered by the working group's charter. Internet
Drafts can also be created at the direction of a working group. The
working group will then discuss the Internet Draft and, in response
to the discussions, the authors will create a succession of versions
if the Internet Draft until the working group is satisfied with it.
The working group then sends a request to publish the Internet Draft
as a RFC to their AD. The AD does a careful technical and editorial
review of the document. If the AD is satisfied he or she then
forwards the publication request to the IESG. The IESG issues an
IETF-wide "last-call" asking that anyone interested to review the
Internet Draft and send their comments, if any, to the IESG. Then
each of the IESG members has the opportunity to review the document.
If the ADs, as a body, support the publication a request is sent to
the RFC Editor to publish the document as a RFC. The document can be
sent back to the working group at any time in the review process if
it is not deemed reedy for publication.
There is a similar process involving a longer last-call period that
can be used to publish a RFC without the requirement of a working
group.
In addition there is an independent submissions process that can be
used to publish non standards-track RFCs.
2.10. IETF Process Documents.
Te IETF standards process is documented in BCP (Best Current
Practice) 9 (currently RFC 2026 [RFC2026] and updates). The IETF
copyright rules are documented in BCP 78 (currently RFC 5378
[RFC5378]) and the IETF patent-related rules are documented in BCP 79
(currently RFC 3979 [RFC3979]).
3. Liaison Relationships
3.1 General
In general, formal liaison relationships are justified for the IETF
when there are areas of technical development of mutual interest in
the IETF and in another SDO. For the most part, SDOs would rather
leverage existing work done by peer organizations than recreate it
themselves (and would like the same done with respect to their own
work). Establishing a liaison relationship can provide the framework
for ongoing communications to prevent inadvertent duplication of
effort, without obstructing either organization from pursuing its own
mandate and to provide authoritative information concerning the
Bradner & Narten [Page 5]
Internet-Draft IETF Liaisoning October 2014
status of work within a SDO or concerning one organization's
dependencies on work being done in a different SDO.
3.2. Establishing a Liaison Relationship with the IETF
Within the IETF, the Internet Architecture Board (IAB) has been
chartered to establish and manage liaison relationships. Consistent
with its charter [IABCharter], the IAB acts as the representative of
the interests of the IETF and of the Internet Society in technical
liaison relationships with other organizations concerned with
standards as well as technical and organizational issues relevant to
the worldwide Internet. Liaison relationships are kept as informal
as possible and must be of demonstrable value to the IETF's technical
mandate.
A liaison relationship is set up when it is mutually agreeable and
needed for some specific purpose, in the view of the peer
organization, the IAB, and the IETF participants conducting the work.
In setting up the relationship, the IAB expects that the setup
process will include a mutual exchange of views and discussion of the
best approach for undertaking new standardization work items. Any
IETF work items will be undertaken in the usual IETF procedures,
defined in [BCB 9]. Other SDOs often have organizational structure
and procedures that are different than the IETF. Cooperation in the
face of often quite different structures and procedures often
requires some flexibility on the part of both organizations. The IAB
expects that each organization will use the relationship carefully,
allowing time for the processes it requests to occur in the peer
organization, and will not make unreasonable demands.
3.2.1. Requesting a Liaison Relationship
Contact the IAB if you believe that the IETF should establish a
Liaison Relationship with another organization. Include in your
request the reasons you believe that such a relationship would be
beneficial to the IETF and to the other organization.
There is no set form or process for this; the IETF participants
and/or the peer organization representatives approach the IAB,
generally by contacting the IAB Chair or by sending email to the IAB
mailing list (iab@ietf.org).
3.2.2. Appointment of a Liaison Manager
Once the liaison relationship is established, the IAB appoints a
Liaison Manager to act as the IETF-side point of contact. (See
section xx.) For this role, 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 IETF and the peer
organization.
Bradner & Narten [Page 6]
Internet-Draft IETF Liaisoning October 2014
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
unrealistic expectations about the work of the two organizations and
the chance of overlapping or conflicting standards being created.
3.2.3. Terminating a Liaison Relationship
Liaison Relationships are terminated when they no longer provide
useful functions in the collective opinion of the IAB and
representatives of the peer organization.
3.3. Listing Existing Relationships
The IAB maintains a list of existing liaison relationships and the
Liaison Managers responsible for each one on the IAB web site at
http://www.ietf.org/liaison/managers.html.
4. Liaison Statements
Standards Development Organizations (SDOs) frequently use liaison
statements to communicate with each other. Liaison statements (or
liaisons for short) are simply documents that have been prepared by
one organization for consumption by another and that carry the
authority of having been formally approved by the sending
organization. That is, a liaison reflects the formal and official
views of the sending organization and will have gone through an
internal approval process in the sending organization. Liaisons can
cover almost any topic, but typically ask questions about specific
technology being worked on by the target of a liaison, bring
attention to work the sending organization is working on that may be
of interest to the target organization or to ask for help in
extending technology developed by the target organization that is
being considered for use by sending organization.
A liaison is a business letter sent by one standards organization to
another. These organizations may be at any level (WG, Area, etc.)
Generally, the sender and receiver are peer organizations. A liaison
may have any purpose, but generally the purpose is to solicit
information, make a comment or request an action.
The IETF regularly sends liaisons to other SDOs, either in response
to a received liaison, or to initiate a dialog. In most cases,
communication is very specific to technology under discussion and
thus originates from a specific (or small number of) IETF Working
Groups.
Bradner & Narten [Page 7]
Internet-Draft IETF Liaisoning October 2014
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, references to documents or documents
themselves and time schedules of which one party believes that the
other party should be aware. Frequently the liaison will include
specific questions that the sending organization would like answered.
Frequently liaisons include documents as attachments for information
or for comment. It should be noted that all liaison statements
received by the IETF are publically posted
(https://datatracker.ietf.org/liaison/),along with any attachments
the statement may include.
See Appendix A for information about the format of liaisons.
5. New-Work email list
The IETF maintains a mailing list for the distribution of proposed
new work items among standards development organizations. (new-
work@ietf.org) On the IETF side, many such items can be identified in
proposed Birds-of-a-Feather (BOF) sessions, as well as in the draft
charters for proposed working groups. The intent of the list is to
enable SDOs to monitor the new work items for possible overlap or
interest to their organization. This mailing list receives a few
messages per month.
Each group with which the IETF has a liaison relationship should
ensure that at least one person is subscribed to the new work list
and has been tasked with the responsibility to distribute relevant
information from the list within the organization and to post
information on new or proposed work that might be of interest to
other SDOs.
6. - Liaison Relationship to IETF
This section provides information to the IETF on how to deal with
liaisons from groups that have an existing liaison relationship with
the IETF and information for groups that desire or have a liaison
relationship to IETF. It is designed to provide information on how
the IETF deals with such relationships and the messages that are
exchanged within such a relationship, with the people from such
groups when they are participating in IETF activities and with
messages addressed to the IETF or its working groups received from
such groups.
6.1 How liaisons are treated in the IETF
One topic that deserves special consideration is how the IETF handles
liaisons (both people serving as a liaison and liaison messages) from
Bradner & Narten [Page 8]
Internet-Draft IETF Liaisoning October 2014
other organizations. The IETF has a long tradition of considering
itself a meritocracy, where everyone participates as an individual
and a person's position or affiliation does not automatically bestow
special weight to his or her views. From that perspective, giving a
liaison statement special weight, just because it is a liaison from
another organization, is potentially problematical. Indeed, IETF
processes on liaison handling specify that liaisons must be treated
exactly the same as submissions (e.g. an Internet draft) from anyone
else. From that perspective, in theory, liaison statements do not
require special consideration by the IETF. In practice, however,
they of course should and do. While a liaison may not by itself carry
any special weight, it is in the IETF's own best interest to handle
liaisons with special care, giving liaisons proper and careful
consideration, and above all being respectful in all interactions
with other organizations and the handling of liaisons.
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 peer organization needs to reference material
that is under development in the IETF: the final reference in the
peer organization's documents needs the permanent identifier (RFC
number) that will be assigned to an 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, when justified and when the
IETF document is sufficiently mature that the RFC publication is
imminent, 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 lists of their
dependencies between their documents and IETF documents on a regular
basis, indicating 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) or working
group.
6.2. Liaison Tool
See Appendix B for information about the IETF Liaison Tool used to
send liaisons to the IETF.
Bradner & Narten [Page 9]
Internet-Draft IETF Liaisoning October 2014
6.3. IETF processing incoming liaison statements
In practice, when handling liaison statements, the following
considerations apply:
o Listen carefully to what is being asked, take extra steps to
understand what is being asked (and why), and be aware that if the
IETF doesn't respond helpfully and constructively, the other SDO
may not get the relevant input it needs from the IETF and
inadvertently take steps that are not in the IETF's own best
interest. How the IETF responds can make the difference between a
positive collaboration and a situation where poorly informed
decisions are made that require active follow up actions later by
the IETF to repair the damage.
o A liaison represents an official/consensus view of the
sending organization (or a particular portion of the organization,
such as a working group). Ignoring it or otherwise not responding
constructively could be interpreted as a slap in the face, making
it harder to work together on any future issue.
o The sending organization may not understand the IETF culture
well (and vice versa). Poorly chosen words or language can easily
be misinterpreted as much more negative or condescending than is
helpful. Often there is a longer story behind a liaison
statement, and it is advisable to understand the bigger story in
order to have a full context in which to respond to a liaison
statement.
o Giving liaisons special consideration does not mean that the
contents of a liaison carry more weight than input from other
IETFers, but it does mean the IETF needs to exercise extra due
diligence in evaluating and responding to input and carefully
considering how a response will be received and what the possible
next steps would be.
6.4. Liaison Managers Representing Peer Organizations
Liaised organizations may appoint a person to act as a liaison
manager for "their side" of the relationship. This is the person hat
will speak authoritatively, within the IETF, on the activities within
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 manger of other SDOs, other than
reports on work within the liaised organization, are given equal
weight with opinions expressed by other working group participants.
Bradner & Narten [Page 10]
Internet-Draft IETF Liaisoning October 2014
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.
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.
6.5. Informing the IETF of proposed & new work in other SDOs
The new-work mailing can also be used to inform the IETF, and the
other SDOs subscribed to the list, about proposed and new work in
other SDOs.
Each group with which the IETF has a liaison relationship is
requested to send information relating to new work within that group
to the new-work lists as soon as the distribution of such information
is possible within their process.
7. Liaison Relationship from IETF
This section is for the information to IETF participants. It is
designed to provide information on the IETF procedures for dealing
with such relationships including how people from the IETF should act
when participating in the activities of a group with which the IETF
has a Liaison Relationship as a IETF liaison and how liaison messages
should be developed, approved and transmitted.
7.1. IETF Liaison Manager
When the IAB establishes a liaison relationship with peer
organization it designates a person from the IETF to manage that
liaison relationship; the person is generally called the "IETF
Liaison Manager" to the peer organization. When the liaison
relationship is expected to encompass a complex or broad range of
activities, more people may be designated to undertake some portions
of the communications, coordinated by the liaison manager. Often,
the peer organization will similarly designate their own liaison
manager to the IETF.
7.2. IETF Liaison Representative
A Liaison Manager is, specifically, a representative of the IETF for
the purpose of managing the liaison relationship. There may be
Bradner & Narten [Page 11]
Internet-Draft IETF Liaisoning October 2014
occasion to identify other representatives for the same relationship.
For example, if the area of mutual work is extensive, it might be
appropriate to name several people as Liaison Representatives to
different parts of the other organization. Or, it might be
appropriate to name a Liaison Representative to attend a particular
meeting.
Liaison Representatives are selected by the IAB and work in
conjunction (and close communication) with the Liaison Manager. In
some cases, this may also require communication and coordination with
other Liaison Managers or representatives where concerned technical
activities overlap. The specific responsibilities of the Liaison
Representative will be identified at the time of appointment.
The Liaison Manager and Liaison 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.
7.3. Authority, Responsibilities and Duties of an IETF Liaison Manager
Most work on topics of mutual interest will be carried out in the
usual way within the IETF and the peer organizations. Specifically,
by participants in each organization directly participating in the
work of the other organization. Therefore, most communications will
be informal in nature (for example, Working Group (WG) or mailing
list discussions). Liaison Managers generally deal with the cases
where more than normal participation is required.
An important function of the Liaison Manager is to ensure that
communication is maintained, productive, and timely. He or she may
use any applicable businesslike approach, from private to public
communications, and bring in other parties as needed. If a
communication from a peer organization is addressed to an
inappropriate party, such as being sent to the WG but not copying the
Area Director (AD) or being sent to the wrong WG, the Liaison Manager
will help redirect or otherwise augment the communication.
IETF Liaison Managers should also communicate and coordinate with
other Liaison Managers where concerned technical activities overlap.
Since the IAB is ultimately responsible for liaison relationships,
anyone who has a problem with a relationship (whether an IETF
participant or a person from the peer organization) should first
consult the IAB's designated Liaison Manager, and if that does not
result in a satisfactory outcome, the IAB itself.
7.4. IETF Liaison Manager Communications
In communications directed to peer organization, the mandate for IETF
Liaison Managers is strictly limited to conveying factual information
Bradner & Narten [Page 12]
Internet-Draft IETF Liaisoning October 2014
or conveying IETF consensus to the other organization. The Liaison
Manager must not on their own initiative send liaison statements to
another organization on behalf of IETF, any of its areas, or any of
its working groups. Liaison statements are only sent following the
process specified in [RFC4052]. Liaison statements are only sent
with the agreement of the IETF chair, the IAB chair, IETF Area
Directors, or IETF working group chairs. As part of this, the
liaison must clearly differentiate his or her own independent
positions from those that represent IETF consensus.
7.5. Liaison Tool
See Appendix B for information on the IETF Liaison Tool used to send
liaisons to other organizations.
7.6. Compensation for IETF Liaison Managers and representatives
IETF Liaison Managers and representatives must not be compensated by
the organization with which they liaise other than for reasonable
travel expenses.
7.7. IETF Liaison Manager Responsibilities
Examples of tasks performed by the liaison manager are provided
below. Depending on the nature of the liaised organization, the
tasks may vary in frequency and relative importance.
o Attend relevant meetings and participate in conference calls or
mailing list discussions within the other organization. Note
developments of interest for onward communication to the IETF.
When required, communicate IETF consensus to the other
organization.
o Communicate information relevant to the liaison relationship to the
relevant parts of the IETF; this may involve email messages or
discussions with IETFers involved in the other organization and
other interested parties within the IETF, e.g., working group
chairs and ADs.
o Understand the concerns of both the IETF and the other
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
the development of engineering solutions within the appropriate
organization.
o It is the responsibility of the liaison manager to ensure that the
peer 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.
Bradner & Narten [Page 13]
Internet-Draft IETF Liaisoning October 2014
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.
o Oversee the proper handling of liaison statements addressed to the
IETF. This includes ensuring that liaison statements are
delivered to the appropriate destinations within the IETF, as well
as shepherding the timely creation of responses by the IETF.
o Work with the other organization to ensure that the IETF's liaison
statements are clear and are appropriately directed and responded
to in a timely fashion.
o Communicate and coordinate with other IETF Liaison Managers where
the activities or interests of two or more liaised organizations
overlap.
o Assist with the preparation and delivery of IETF liaison statements
based on IETF consensus.
o Prepare reports giving updates on developments in the other
organization as requested by the IAB or other interested parties
in the IETF.
o From time to time, Liaison Managers 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 work and issues.
7.8. Consensus Requirements
Liaison statements and other messages sent to a peer organization
must 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.
7.9. Incoming Liaison Statements
When the IETF receives a liaison statement or other communication
Bradner & Narten [Page 14]
Internet-Draft IETF Liaisoning October 2014
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 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.
7.9.1. Ambiguous Incoming Liaison Statements
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.
7.10. Informing others of new or revised IETF work
The IETF forwards all draft charters for all new and revised working
groups and BOF session announcements to the IETF new-work mailing
list.
Organizational representatives may provide comments on proposed IETF
working group charters and BOF descriptions by responding to the IESG
mailing list at iesg@ietf.org clearly indicating their organization's
position and the nature of their concern. Plain-text email is
preferred on the IESG mailing list.
Organizational representatives may provide comments on proposed IETF
working group charters and BOF descriptions by responding to the IESG
mailing list at iesg@ietf.org clearly indicating their organization's
position and the nature of their concern. Plain-text email is
preferred on the IESG mailing list.
7.11. Speaking for IETF (in messages & in person)
The IETF operates 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 he or she understands the IETF
consensus on the topic.
Bradner & Narten [Page 15]
Internet-Draft IETF Liaisoning October 2014
7.12. What Hat to Wear When Acting as a Liaison
*******we need a discussion here - when should someone have "IETF" or
"ISOC" "on their badge" when communication to a peer organization or
attending a meeting vs having a company or national delegation
badge*****
8. Intellectual property rights
The IETF's copyright-related rules for are detailed in BCP 78. The
IETF's patent-related rules are detailed in BCP 79. All people
submitting material to the IETF should be aware of these rules. Any
organization with which the IETF enters a liaison relationship should
take care to ensure that they have informed the IETF of any of their
intellectual property rights (IPR) rules that could impact any
messages the IETF sends or submissions the IETF makes.
8.1 Copyright
The IETF rules on copyright in submitted documents are documented in
BCP 78. By submitting an Internet Draft for publication the authors
of the Internet Draft are agreeing to those rules. Please see BCP 78
for the detailed rules but the following is a brief summary.
The IETF copyright-related rules are quite simple. The IETF Trust
obtains the non-exclusive perpetual right to publish Internet Drafts
and RFCs from the authors of those documents. Unless a specific
notice is included in the submission, the IETF Trust also obtains the
right to publish the Internet Draft as a RFC and the right to produce
derivative works based on the material in the submission. The IETF
Trust has licensed the content of all such submissions to IETF
participants to produce derivative works within the IETF processes.
The IETF Trust, in theory, can license others to produce derivative
works outside the IETF standards process (e.g., in books, educational
materials, other standards groups, etc.) but this is a rare
occurrence, and only done in consultation with the IETF community.
Document authors retain all other rights. Document authors are free
to do anything else they wish to with their material.
8.2 Patent and patent applications
The IETF rules relating to non-copyright intellectual property rights
(within the IETF processes are documented in BCP 79. By submitting
an Internet Draft for publication the authors of the Internet Draft
are agreeing to those rules. Please see BCP 79 for the detailed
rules but the following is a brief summary.
The work of the IETF and its working groups frequently involves
making choices about which technology to use in a particular
situation. Understanding all aspects of a technology, including any
Bradner & Narten [Page 16]
Internet-Draft IETF Liaisoning October 2014
intellectual property rights related impacts on the use of a
technology, is an important part of deciding what technologies to
support. Thus, it is important for the IETF and its working groups
to be informed of any intellectual property rights claimed in regards
to technologies under consideration. Thus, participants in the IETF
process are required to disclose any of their own IPR they personally
know about in any contribution to the IETF.
In this context, a participant is someone who makes a contribution to
the IETF (this includes submitting an Internet Draft, sending email
to an IETF mailing list, and speaking during a discussion in an IETF
working group) or otherwise doing something designed to effect the
discussion about a technology.
Also, in this context, "their own IPR" means any patent or patent
application that they, their employer or their sponsor could
potentially assert against the technology under discussion.
9. Limitation of Liability
The IETF makes no representations with respect to and does not
warrant the accuracy of any information or any document. Without
limiting the foregoing, each party of liaison relationship a agrees
to accept the terms of and reproduce any warranty disclaimers or
limitations of liability that are included in any reproduction of
published material made available to it under this cooperation
framework.
10. IANA Considerations
This document makes no requests of the IANA. [this section to be
removed before publication]
11. Security Considerations This type of process document does not have
any direct effect on the security of the Internet.
12. References
12.1. Normative references
12.2. Informative References
RFCs consulted
RFC 3113 - 3GPP-IETF Standardization Collaboration.
RFC 3131 - 3GPP2-IETF Standardization Collaboration
Bradner & Narten [Page 17]
Internet-Draft IETF Liaisoning October 2014
RFC 3975 - OMA-IETF Standardization Collaboration
RFC 4052 - IAB Processes for Management of IETF Liaison Relationships
RFC 4053 - Procedures for Handling Liaison Statements to and from the
IET
RFC 4441 - The IEEE 802/IETF Relationship
RFC 4691 - Guidelines for Acting as an IETF Liaison to Another
Organization
RFC 4965 - CableLabs - IETF Standardization Collaboration
RFC 6756 - Internet Engineering Task Force and International
Telecommunication Union - Telecommunication Standardization Sector
Collaboration Guidelines
Other documents
[Tau] The Tau of the IETF, https://www.ietf.org/tao.html
13. Author's addresses
Scott Bradner
Harvard University
8 Story St.
Cambridge MA 02138
USA
email: sob@harvard.edu
phone: +1 617 495 3864
Thomas Narten
IBM
email: narten@us.ibm.com
Appendix A - Format of a liaison
A. Contents of a Liaison Statement
Liaison statements may be very formal or informal, depending on the
rules of the body generating them. Any liaison statement, however,
will always contain certain information, much as an business letter
does. This information will include the following:
A.1. Envelope Information
The following fields detail properties of the liaison statement.
A.1.1. From:
The statement will indicate from what body it originates; for
example, it may be from, an IETF WG or Area, an ITU-T Study Group,
Working Party, or Question, etc. In this document, this body is the
"sender".
Bradner & Narten [Page 18]
Internet-Draft IETF Liaisoning October 2014
A.1.2. To:
The statement will indicate to which body it is. In this document,
his body is the "addressee".
A.1.3. Title:
The statement will contain a short (usually single line) statement of
its context and content.
A.1.4. Response Contact:
The sender will indicate the electronic mail address to which any
response should be sent.
A.1.5. Technical Contact:
The sender will indicate one or more electronic mail addresses
(persons or lists) that may be contacted for clarification of the
liaison statement.
A.1.6. Purpose:
A liaison statement generally has one of three purposes and will
clearly state its purpose using one of the following labels:
For Information: The liaison statement is to inform the addressee of
something, and expects no response.
For Comment: The liaison statement requests commentary from the
addressee, usually within a stated time frame.
For Action: The liaison statement requests that the addressee do
something on the sender's behalf, usually within a stated time frame.
In Response: The liaison statement includes a response to a liaison
statement from the peer organization on one or more of its documents
and expects no further response.
A.1.7. Deadline:
Liaison statements that request comment or action will indicate when
he comment or action is required. If the addressee cannot accomplish
the request within the stated period, courtesy calls for a response
offering a more doable deadline or an alternative course of action.
A.2. Liaison Content
The following fields are the substance of the liaison statement.
IETF participants use a wide variety of systems, thus document
formats that are not universally readable are problematic. As a
result, documents enclosed with the body or attachments should be in
PDF, W3C HTML (without proprietary extensions), or ASCII text format.
If they were originally in a proprietary format such as Microsoft
Word, the file may be sent, but should be accompanied by a generally
Bradner & Narten [Page 19]
Internet-Draft IETF Liaisoning October 2014
readable file.
A.2.1. Body:
As with any business letter, the liaison statement contains
appropriate content explaining the issues or questions at hand.
A.2.2. Attachments:
Attachments, if enclosed, may be in the form of documents sent with
he liaison statement or may be URLs to similar documents including
Internet Drafts.
Appendix B - The IETF Liaison Tool
B. Tools for Handling Liaison Statements
Some tools have been developed for the IETF. Development is expected
to continue. This section describes the basic tool and its intended
use.
B.1. Liaison Statements from Other SDOs, Consortia, and Fora to IETF
The process of handling a liaison statement is more weighty than
handling a business letter because it is important to a relationship
with another SDO established by the IAB. To manage liaison
statements, the IETF will offer three electronically accessible
facilities: a form for submission of liaison statements, a mechanism
organizing their contents and making them accessible, and a tracking
system. Initially, the tracking system will be a manual procedure
used by the liaison manager; in the future, this should be automated.
B.1.1. Liaison Statement Submission
The IETF Secretariat will provide an electronic method for submission
of liaison statements.
The liaison statement submission mechanism is a form that requests
the information listed in Section 2.2.1 from the user.
Submission of that information results in the following actions:
o creation of a display mechanism containing the envelope data in
Section 2.2.1.1 and URLs pointing to the items from Section
2.2.1.2, an indication whether the liaison statement has been
replied to, and if so, on what date,
o the addition of a URL to the "outstanding liaison statements"
summary mechanism,
o when an automated tracking system has been implemented, a tickler/
status entry in the tracking system, assigned to the relevant
chair or AD,
Bradner & Narten [Page 20]
Internet-Draft IETF Liaisoning October 2014
o an email to the assignee copying
* the liaison statement's technical contacts
* The supervisor of the assignee (if it is to a WG, the relevant
ADs; if to an AD, the IETF Chair),
* The liaison manager for the sending SDO,
* an alias associated with the assignee (WG/BOF or other open
mailing list, Area Directorate, IESG, IAB, etc.)
This email should contain the URL to the liaison statement mechanism,
text indicating that the liaison statement has arrived, requests
appropriate consideration, and if a deadline is specified, a reply by
the deadline.
The assignee has the capability of interacting with the liaison
manager and the tracking system (once implemented), including
replying, changing dates, reassignment, closing the liaison statement
process, etc.
The liaison manager or tracking system's "tickle" function
periodically reminds the assignee by email that the liaison statement
has not yet been closed. This tickle email copies all of the above
except the associated mailing alias.
B.1.2. Mechanism for Displaying Liaison Statements
The IETF site contains a section for current liaison statement
activity. This consists of:
o A submission mechanism,
o A status/management mechanism for each active or recently closed
liaison statement, and zero or more associated files.
The status/management mechanism contains a simple frame, showing the
title of the liaison statement, the URL for its mechanism, and the
organizations it is from and to.
The display for liaison statement itself contains:
o the liaison statement envelope information (Section 2.2.1),
o direct content (Section 2.2.1),
o URLs for the various associated files
Bradner & Narten [Page 21]
Internet-Draft IETF Liaisoning October 2014
o current status of the liaison statement: to whom it is assigned,
its due date, and its status,
o pointer to the liaison manager and tracking system entry for the
liaison statement.
o reply-generation mechanism (see Section 3.2.2.4)
Bradner & Narten [Page 22]