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]