One document matched: draft-lear-liaison-tool-rqts-00.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC2850 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2850.xml'>
<!ENTITY RFC4052 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4052.xml'>
<!ENTITY RFC4053 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4053.xml'>
<!ENTITY RFC4691 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4691.xml'>
<!ENTITY RFC5322 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5322.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no" ?>
<?rfc sortrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc linkmailto="yes" ?>
<rfc ipr="trust200902" docName="draft-lear-liaison-tool-rqts-00" category="info">
<front>
<title abbrev="Liaison Statement Tool Requirements">
Requirements for the IETF Liaison Statement Tool
</title>
<author fullname="Eliot Lear" initials="E." surname="Lear">
<organization>Cisco Systems GmbH</organization>
<address>
<postal>
<street>Richtistrasse 7</street>
<city>Wallisellen</city>
<code>CH-8304</code>
<region>ZH</region>
<country>Switzerland</country>
</postal>
<phone>+41 44 878 9200</phone>
<email>lear@cisco.com</email>
</address>
</author>
<author initials="S." surname="Dawkins" fullname="Spencer Dawkins" role="editor">
<organization abbrev="Huawei">Huawei Technologies</organization>
<address>
<postal>
<street> 1547 Rivercrest Blvd.</street>
<city> Allen</city>
<region>TX </region>
<code>75002 </code>
<country>USA</country>
</postal>
<email>spencer@wonderhamster.org</email>
</address>
</author>
<date />
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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 <xref target="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 <xref target="RFC4052" />.</t>
<t>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.</t>
<t>The IETF process for sending and receiving liaison statements is defined in <xref target="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.
</t>
<t>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 <xref target="RFC4053" /> for the
purposes of further elaborating the data elements of a liaison
statement.</t>
<t>The IAB's guidance to liaison managers is
available in <xref target="RFC4691" />.</t>
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
</section>
</section>
<section title="Overall Processing of Liaison Statements">
<t>
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 <xref target="RFC4053" />.
</t>
<t>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.
</t>
<t>EDITOR'S NOTE: Scott Bradner asked if we track response deadlines on all liaison statements, or only on inbound liaison statements. Thoughts?
</t>
<t>The format of a liaison statement is described in Section 2.2.1
of <xref target="RFC4053" />. The following data elements are
further elaborated for purposes of understanding when they are
used.
</t>
<section title="Inbound Liaison Statements">
<t>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.
</t>
<t>Representatives from external organizations sending an inbound
liaison statement must be known in advance, and must request an
IETF tools system password from <eref target="http://trac.tools.ietf.org/newlogin">
the IETF Tools Password web page</eref>.
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.
</t>
<t> 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.
</t>
<t>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.
</t>
</section>
<section title="Outbound Liaison Statements">
<t>Outbound liaison statements may only be sent by those
specified in Section 4 of <xref target="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 <xref target="RFC4053" />, in addition to anyone else the person sending
the liaison statement deems appropriate.
</t>
</section>
<section title="Description of Liaison Statement Elements">
<texttable title="Liaison Statement Elements">
<ttcol align="center">Field</ttcol>
<ttcol align="center">Format</ttcol>
<ttcol align="center">When required</ttcol>
<ttcol align="center">Purpose</ttcol>
<c>Liaison-Id
</c>
<c>A short identifier uniquely identifying this liaison statement
</c>
<c>Always
</c>
<c>Identifies the liaison statement that is to be tracked. Is prefixed with "In" or "Out".
</c>
<c>Pointer to the liaison statement
</c>
<c>URL pointing to the liaison statement in the IETF liaison statement repository.
</c>
<c>Always
</c>
<c>Locates the liaison statement that is to be tracked. Includes the Liaison-ID as part of the URL.
</c>
<c>Source or From:</c><c>UTF-8</c><c>Always</c><c>See RFC
4053 Section 2.2.1.</c>
<c>To or Addresse</c><c>UTF-8</c><c>Always</c><c>See RFC
4053 Section 2.2.1.</c>
<c>Response Contact</c><c>One or more name-addr from
RFC-5322</c><c>Always</c><c>See RFC 4053 Section 2.2.1.</c>
<c>Date</c><c>date from RFC-5322</c><c>Always</c>
<c>See RFC 4053 Section 2.2.1.</c>
<c>Purpose
</c>
<c>"For action" / "For Information" / "In Response" / "For Comment"
</c>
<c>Always
</c>
<c>See RFC 4053 Section 2.2.1.
</c>
<c>Title
</c>
<c>UTF-8
</c>
<c>Always
</c>
<c>RFC 4053 Section 2.2.1.
</c>
<c>Deadline</c><c>date from RFC-5322</c>
<c>When Purpose is "For Action" or "For Comment"</c>
<c>RFC 4053 Section 2.2.1.
</c>
<c>Liaison Content</c><c>From RFC-5322 definition of
"body"</c><c>Always</c><c>See RFC 4053 Section 2.2.1.</c>
<c>Attachments</c><c>MIME</c><c>Optional</c><c></c>
<c>Cc List</c><c>One or more name-addr from
RFC-5322</c><c>optional</c><c>A list of addresses to CC the
liaison when it is transmitted.</c>
<c>Owner
</c>
<c>name-addr from RFC-5322
</c>
<c>For inbound liaison statements when they are "For Action" or "For Comment".
</c>
<c>Someone who will manage the liaison statement.
</c>
<c>Response liaison statement
</c>
<c>URL pointing to the response in the IETF liaison statement repository.
</c>
<c>When a reply has been generated
</c>
<c>This is the outbound liaison statement that is in
response to the inbound liaison statement. Note that more than one outbound liaison
statement may be associated with an inbound liaison statement.
</c>
<c>Status
</c>
<c>"awaiting response" / "no response required" / "responded to" / "no action will be taken" / "overdue"
</c>
<c>Always</c>
<c>Generated based on type of
liaison, date, whether a response has been generated, and
input from the owner as to whether action will be taken
</c>
</texttable>
</section>
</section>
<section title="Specific Tooling Requirements">
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
<t>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.
</t>
</section>
<section title="Acknowledgments">
<t>The current tool can be accessed from
the <eref target="https://datatracker.ietf.org/liaison/">IETF web
page</eref>. 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.
</t>
</section>
<section title="Security Considerations">
<t>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.
</t>
</section>
<section title="IANA Considerations">
<t>This document contains no requests for actions by IANA.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC2850;
&RFC4052;
&RFC4053;
&RFC4691;
&RFC5322;
</references>
<section title="Changes">
<t>This section to be removed prior to publication.</t>
<t>
<list style="symbols">
<t>00a Initial Draft from Eliot. </t>
<t>00b Revision by Spencer to include IANA Considerations, add text for Security Considerations, and generally clean up IDNITs errors. </t>
<t>00c Revision by Spencer to address comments from Adrian Farrell and Scott Bradner. </t>
</list>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:30:44 |