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 October 13, 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.

Table of Contents

• 1. Introduction
• 1.1. Terminology
• 2. Overall Processing of Liaison Statements
• 2.1. Inbound Liaison Statements
• 2.2. Outbound Liaison Statements
• 2.3. Description of Liaison Statement Elements
• 3. Specific Tooling Requirements
• 4. Acknowledgments
• 5. Security Considerations
• 6. IANA Considerations
• 7. Normative References
• Appendix A. Changes
• Authors' Addresses

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

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

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

2.3. Description of Liaison Statement Elements

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.

4. Acknowledgments

The current tool can be accessed from the IETF web page. 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.

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.

6. IANA Considerations

This document contains no requests for actions by IANA.

7. Normative References

Appendix A. Changes

This section to be removed prior to publication.

• 00a Initial Draft from Eliot.
• 00b Revision by Spencer to include IANA Considerations, add text for Security Considerations, and generally clean up IDNITs errors.
• 00c Revision by Spencer to address comments from Adrian Farrell and Scott Bradner.

Authors' Addresses