Internet DRAFT - draft-lear-liaison-tool-rqts
draft-lear-liaison-tool-rqts
Network Working Group E. Lear
Internet-Draft Cisco Systems GmbH
Intended status: Informational S. Dawkins, Ed.
Expires: August 22, 2013 Huawei
February 18, 2013
Requirements for the IETF Liaison Statement Tool
draft-lear-liaison-tool-rqts-00
Abstract
This memo specifies requirements for the liaison statement tool used
by IETF working group chairs, IESG members, and the IAB, as well as
representatives of organizations that liaise to these IETF entities.
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 August 22, 2013.
Copyright Notice
Copyright (c) 2013 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
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.
Lear & Dawkins Expires August 22, 2013 [Page 1]
Internet-Draft Liaison Statement Tool Requirements February 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overall Processing of Liaison Statements . . . . . . . . . . . 5
2.1. Inbound Liaison Statements . . . . . . . . . . . . . . . . 5
2.2. Outbound Liaison Statements . . . . . . . . . . . . . . . 6
2.3. Description of Liaison Statement Elements . . . . . . . . 7
3. Specific Tooling Requirements . . . . . . . . . . . . . . . . 10
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
7. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Lear & Dawkins Expires August 22, 2013 [Page 2]
Internet-Draft Liaison Statement Tool Requirements February 2013
1. Introduction
The Internet Architecture Board (IAB) acts as representative of the
interests of the IETF and the Internet Society in technical liaison
relationships with other organizations concerned with standards and
other technical and organizational issues relevant to the world-wide
Internet, as part of its chartered responsibilities [RFC2850]. As
part of that responsibility, the IAB approves requests for IETF
liaison relationships with these organizations, and the IAB appoints
individual IETF participants as liaison managers using the process
described in [RFC4052].
From time to time the IETF and IAB exchange liaison statements with
other organizations. These official statements must be preserved as
part of the historical record of the IETF, and often require that
responses to such statements must be tracked. It is the job of the
liaison manager to track those actions. A tool exists to help that
process, and to direct messages to the correct set of recipients.
This memo specifies a detailed set of requirements for the evolution
of that tool.
The IETF process for sending and receiving liaison statements is
defined in [RFC4053], which describes the basic flow of a liaison
statement. To briefly summarize, there are inbound and outbound
liaison statements. Inbound statements are issued by organizations
wishing to communicate with the IETF or to respond to liaison
statements sent to them by the IETF. Outbound statements are issued
by people within the IETF wishing to officially communicate with
another organization or wishing to respond to a liaison statement
received from another organization. Different groups of people are
authorized to issue such statements. When liaison statements are
issued, certain groups of people are meant to be informed of the
statement.
Upon receipt of an inbound liaison statement, certain response
actions may be desired by a particular date. Therefore, a liaison
statement management system has aspects of issue tracking, a role-
based statement distribution system, and a web service where people
can access liaison statements. The remainder of this document will
delve into the flow in detail, and describe data elements required to
process liaison statements. This memo expands on descriptions in
[RFC4053] for the purposes of further elaborating the data elements
of a liaison statement.
The IAB's guidance to liaison managers is available in [RFC4691].
Lear & Dawkins Expires August 22, 2013 [Page 3]
Internet-Draft Liaison Statement Tool Requirements February 2013
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT",ccccc "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
Lear & Dawkins Expires August 22, 2013 [Page 4]
Internet-Draft Liaison Statement Tool Requirements February 2013
2. Overall Processing of Liaison Statements
ALL liaison statements that are received by the liaison tool, whether
inbound or outbound, MUST be posted to a web site for public
inspection. A liaison statement MUST be kept in perpetuity, as
mentioned in Section 2.4 of [RFC4053].
Liaison statements may be for information, comment, action, or a
reply to an earlier statement. Liaison statements that are for
comment or action will have a response deadline associated with them.
EDITOR'S NOTE: Scott Bradner asked if we track response deadlines on
all liaison statements, or only on inbound liaison statements.
Thoughts?
The format of a liaison statement is described in Section 2.2.1 of
[RFC4053]. The following data elements are further elaborated for
purposes of understanding when they are used.
2.1. Inbound Liaison Statements
An inbound liaison statement comes from an external organization. It
is destined to either the IETF, the IAB, one or more Area Directors,
one or more IETF working groups, or exceptionally other groups, such
as the IESG or the IRTF. Upon receipt the liaison system MUST
transmit the liaison statement to the correct destination group, if
identified, to relevant responsible Area Directors for the working
groups, as applicable, and to the relevant liaison managers, based on
the source of the liaison statement. The liaison management system
MUST transmit inbound liaisons to those individuals and email lists
associated with the IETF and IAB, and working groups. It is not
required that inbound liaison statements be transmitted to every
destination listed in the "To" or "Cc" fields of a liaison statement.
Representatives from external organizations sending an inbound
liaison statement must be known in advance, and must request an IETF
tools system password from the IETF Tools Password web page [1].
Each representative must be associated with an external organization,
and the IETF liaison manager for this external organization requests
that the external representative's e-mail address be associated with
the external organization.
If an inbound liaison statement is marked "for action" or "for
comment", then one individual SHALL be assigned as having
responsibility for ensuring that the liaison statement is addressed.
This assignment SHALL be made automatically by the tool using a list
of individuals maintained by the IETF Secretariat for this purpose.
If there is no individual listed for the named IETF destination of
Lear & Dawkins Expires August 22, 2013 [Page 5]
Internet-Draft Liaison Statement Tool Requirements February 2013
the liaison statement, or if there are multiple IETF destinations
involved, the responsibility shall be assigned to the IETF's liaison
manager responsible for the liaison relationship with the
organization originating the liaison.
An open action awaiting response may be closed in one of two ways:
administratively by the action owner, or through the action of a
posting a response liaison statement. Periodically the liaison
management system SHALL remind individuals who are responsible for
tracking liaison statements for action when they have open actions.
Liaison managers for the organization MUST also receive such
reminders, even if they are not the assigned owner. There may be
more than one liaison manager for an organization.
2.2. Outbound Liaison Statements
Outbound liaison statements may only be sent by those specified in
Section 4 of [RFC4052]. Any tool MUST impose appropriate access
control for this purpose. Furthermore, when a liaison statement is
transmitted, the tool SHALL send appropriate copies in accordance
with Section 3.1.1 of [RFC4053], in addition to anyone else the
person sending the liaison statement deems appropriate.
Lear & Dawkins Expires August 22, 2013 [Page 6]
Internet-Draft Liaison Statement Tool Requirements February 2013
2.3. Description of Liaison Statement Elements
+-------------+--------------+------------+-------------------------+
| Field | Format | When | Purpose |
| | | required | |
+-------------+--------------+------------+-------------------------+
| Liaison-Id | A short | Always | Identifies the liaison |
| | identifier | | statement that is to be |
| | uniquely | | tracked. Is prefixed |
| | identifying | | with "In" or "Out". |
| | this liaison | | |
| | statement | | |
| | | | |
| Pointer to | URL pointing | Always | Locates the liaison |
| the liaison | to the | | statement that is to be |
| statement | liaison | | tracked. Includes the |
| | statement in | | Liaison-ID as part of |
| | the IETF | | the URL. |
| | liaison | | |
| | statement | | |
| | repository. | | |
| | | | |
| Source or | UTF-8 | Always | See RFC 4053 Section |
| From: | | | 2.2.1. |
| | | | |
| To or | UTF-8 | Always | See RFC 4053 Section |
| Addresse | | | 2.2.1. |
| | | | |
| Response | One or more | Always | See RFC 4053 Section |
| Contact | name-addr | | 2.2.1. |
| | from | | |
| | RFC-5322 | | |
| | | | |
| Date | date from | Always | See RFC 4053 Section |
| | RFC-5322 | | 2.2.1. |
| | | | |
| Purpose | "For action" | Always | See RFC 4053 Section |
| | / "For | | 2.2.1. |
| | Information" | | |
| | / "In | | |
| | Response" / | | |
| | "For | | |
| | Comment" | | |
| | | | |
| Title | UTF-8 | Always | RFC 4053 Section 2.2.1. |
| | | | |
Lear & Dawkins Expires August 22, 2013 [Page 7]
Internet-Draft Liaison Statement Tool Requirements February 2013
| Deadline | date from | When | RFC 4053 Section 2.2.1. |
| | RFC-5322 | Purpose is | |
| | | "For | |
| | | Action" or | |
| | | "For | |
| | | Comment" | |
| | | | |
| Liaison | From | Always | See RFC 4053 Section |
| Content | RFC-5322 | | 2.2.1. |
| | definition | | |
| | of "body" | | |
| | | | |
| Attachments | MIME | Optional | |
| | | | |
| Cc List | One or more | optional | A list of addresses to |
| | name-addr | | CC the liaison when it |
| | from | | is transmitted. |
| | RFC-5322 | | |
| | | | |
| Owner | name-addr | For | Someone who will manage |
| | from | inbound | the liaison statement. |
| | RFC-5322 | liaison | |
| | | statements | |
| | | when they | |
| | | are "For | |
| | | Action" or | |
| | | "For | |
| | | Comment". | |
| | | | |
| Response | URL pointing | When a | This is the outbound |
| liaison | to the | reply has | liaison statement that |
| statement | response in | been | is in response to the |
| | the IETF | generated | inbound liaison |
| | liaison | | statement. Note that |
| | statement | | more than one outbound |
| | repository. | | liaison statement may |
| | | | be associated with an |
| | | | inbound liaison |
| | | | statement. |
| | | | |
Lear & Dawkins Expires August 22, 2013 [Page 8]
Internet-Draft Liaison Statement Tool Requirements February 2013
| Status | "awaiting | Always | Generated based on type |
| | response" / | | of liaison, date, |
| | "no response | | whether a response has |
| | required" / | | been generated, and |
| | "responded | | input from the owner as |
| | to" / "no | | to whether action will |
| | action will | | be taken |
| | be taken" / | | |
| | "overdue" | | |
+-------------+--------------+------------+-------------------------+
Liaison Statement Elements
Lear & Dawkins Expires August 22, 2013 [Page 9]
Internet-Draft Liaison Statement Tool Requirements February 2013
3. Specific Tooling Requirements
The IETF entities who may send a liaison statement to an external
organization have a hierarchy. The tool must allow entities higher
in the hierarchy to send liaison statements on behalf of an entity
lower in the hierarchy (for example, a routing Area Director might
send a liaison statement on behalf of a working group chair). These
liaison statements should include both the actual sender and the
person who will be responsible for further interaction with the
external organization.
Many peer standards organizations have a hierarchy to them. The tool
MUST support that hierarchy. It should be possible to direct a
liaison statement to specific subgroups. It should equally be
possible for a liaison manager to facilitate processing of inbound
statements for a specific subgroup within a standards organization.
Web tools should be able to input all information required for both
inbound and outbound liaison statements. As liaison statements can
sometimes be complex, information should be checkpointed. That is,
work should not be lost even if a session is lost.
For any field that takes more than one email address as an input,
separation of those addresses SHALL be either by commas or semi-
colons.
EDITOR'S NOTE: Scott Bradner asked - "how do we deal with a series of
interleaved inbound and outbound messages? - they send something to
us, we respond, they respond to the response, we respond to that
response etc - it would be good to keep this as a thread rather than
as a series of individual exchanges". I agree, but would appreciate
confirmation from others.
The tool should include a maintenance interface enabling the
secretariat to maintain the list of authorized external
organizations, the authorized representatives from those external
organizations, the IETF Liaison Managers for each external
organization, the list of IETF working groups, the area for each
working group, the e-mail list for each working group, etc.
Lear & Dawkins Expires August 22, 2013 [Page 10]
Internet-Draft Liaison Statement Tool Requirements February 2013
4. Acknowledgments
The current tool can be accessed from the IETF web page [2]. These
requirements are based on experience with that tool, and the author
would like to acknowledge the efforts put into that tool by Henrik
Levkowitz, and others.
Lear & Dawkins Expires August 22, 2013 [Page 11]
Internet-Draft Liaison Statement Tool Requirements February 2013
5. Security Considerations
Representatives from external organizations request an IETF Tools-
level password, and the IETF Liaison Manager responsible for each
organization requests that the representative's e-mail address be
associated with the appropriate external organization in the tool.
This requires the IETF Liasison Manager to be familiar with the
people in the external organization who will be sending liaison
statements, to prevent the possibility of impersonation attacks, and
requires the representatives to handle their passwords in a secure
way.
Lear & Dawkins Expires August 22, 2013 [Page 12]
Internet-Draft Liaison Statement Tool Requirements February 2013
6. IANA Considerations
This document contains no requests for actions by IANA.
Lear & Dawkins Expires August 22, 2013 [Page 13]
Internet-Draft Liaison Statement Tool Requirements February 2013
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2850] Internet Architecture Board and B. Carpenter, "Charter of
the Internet Architecture Board (IAB)", BCP 39, RFC 2850,
May 2000.
[RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes
for Management of IETF Liaison Relationships", BCP 102,
RFC 4052, April 2005.
[RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for
Handling Liaison Statements to and from the IETF",
BCP 103, RFC 4053, April 2005.
[RFC4691] Andersson, L., "Guidelines for Acting as an IETF Liaison
to Another Organization", RFC 4691, October 2006.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
[1] <http://trac.tools.ietf.org/newlogin>
[2] <https://datatracker.ietf.org/liaison/>
Lear & Dawkins Expires August 22, 2013 [Page 14]
Internet-Draft Liaison Statement Tool Requirements February 2013
Appendix A. Changes
This section to be removed prior to publication.
o 00a Initial Draft from Eliot.
o 00b Revision by Spencer to include IANA Considerations, add text
for Security Considerations, and generally clean up IDNITs errors.
o 00c Revision by Spencer to address comments from Adrian Farrell
and Scott Bradner.
Lear & Dawkins Expires August 22, 2013 [Page 15]
Internet-Draft Liaison Statement Tool Requirements February 2013
Authors' Addresses
Eliot Lear
Cisco Systems GmbH
Richtistrasse 7
Wallisellen, ZH CH-8304
Switzerland
Phone: +41 44 878 9200
Email: lear@cisco.com
Spencer Dawkins (editor)
Huawei Technologies
1547 Rivercrest Blvd.
Allen, TX 75002
USA
Email: spencer@wonderhamster.org
Lear & Dawkins Expires August 22, 2013 [Page 16]