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] [2] 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]