o A request could be made for IETF to undertake a new work item.
o A request could be made for IETF to stop a work item (presumably
because it overlaps or conflicts with other work in the
originating organization).
Consensus of the receiving group within IETF is clearly necessary to
fulfill the request. Fulfilling the request may require a great deal
of time and multiple steps, for example, if initiating or stopping a
work item requires a charter change.
There is, of course, no requirement that IETF perform the action that
was requested. But the request should always be taken seriously, and
a response is required. The originating organization must always be
informed of what, if anything, the IETF has decided to do in response
to the request. If the IETF decides not to honor the request, or to
honor it with modifications, the response should include the reasons
and, if applicable, the alternate course of action.
For tasks that require a great deal of time, it may be necessary that
several liaison statements be sent back to the originating
organization to report the status of the work and the anticipated
completion time. The first of these liaison statements must be
generated by the deadline indicated in the incoming liaison
statement.
3.2.2.4. Generating Liaison Statements
IETF participants, usually WG chairs, ADs, or other officials, need
to be able to send liaison statements to other SDOs. The mechanism
described in Section 3.1.2, listing appropriate contacts in other
SDOs with which the IAB has established liaison relationships,
provides that capability.
As a convenience, the liaison statement page described in
Section 3.1.2 may be used to generate a reply. If a person (usually
a WG chair or an AD) selects "reply", a new liaison statement page is
generated from the existing one, reversing the addressing
information. IETF documents should be referenced by URL, such as
http://www.ietf.org/internet-drafts/>file< or
ftp://ftp.rfc-editor.org/in-notes/>file<.
The process of generating and approving transmission of liaison
statements is a matter of IETF process and is specified in [RFC4052].
4. Security Considerations
One of the key considerations in developing this process has been the
possibility of a denial of service attack on the IETF and its
processes. Historically, the IETF has not always handled liaison
statements effectively, resulting in people working in other
organizations becoming frustrated with it. Various organizations
have also used the liaison statement process to impose deadlines on
IETF activities, which has been frustrating for all concerned - the
IETF because it does not accept such deadlines, and other
organizations because they feel ignored.
For this reason the submission process is automated. While the IETF
cannot rate-limit the submitters, it can manage its internal
pipelines.
This issue is exacerbated by the lack of any authentication on the
part of the submitter. However, the IAB considers it important to be
able to accept liaison statements whether or not a liaison
relationship exists, so authentication of submitters is not an
effective control.
5. Acknowledgements
This text has been prompted by discussions with numerous individuals
within IETF and other SDOs and fora, including Gary Fishman and Bert
Wijnen. It has been developed in cooperation with [RFC4052], which
is to say with the express cooperation of the chair of the IAB,
Leslie Daigle. Personal experiences and some "miscues" in
coordinating work across ITU-T Study Group 15 and the IETF Sub-IP
Area have also motivated this work. Some drafts addressing
individual problems (for example, RFC 3427) make it clear that a more
general, consistent solution is needed for dealing with outside
organizations. Certain ideas have been borrowed from these texts.
Barbara Fuller, Sunny Lee, and Michael Lee developed a prototype and
commented in detail on the document. Their inputs directly resulted
in the appendices describing the implementation road map.
Appendix A. Implementation Road Map
This section documents the development program as of the time of the
writing of this document. It is not normative.
A.1. Phase I: Initial Implementation
A.1.1. Displays
The descriptions of the required displays in Section 3.1.1 and
Section 3.1.2 call for two sets of displays: one for the public (for
viewing liaison statements), and one for submitters (for managing
liaison statements).
Displays for public view of liaison statements include:
o A Liaison Statements Web page that lists all incoming and outgoing
liaison statements (specific fields TBD). The title of each
liaison statement is a link to the details page for that liaison
statement.
o A detail page for each liaison statement that contains:
* All of the information specified in the subsections of
Section 2.2.1.
* Links to all attachments that accompanied the liaison statement
or to documents that are mentioned in the statement but were
not provided as part of the submission.
* Links to all related liaison statements (e.g., replies).
Displays for submitting and managing liaison statements include:
o A summary page that offers mechanisms for:
* Creating and submitting a new liaison statement.
* Editing a liaison statement that the user has previously
created and submitted.
* Acting on a liaison statement that has been assigned to the
user.
o A template for creating and submitting a liaison statement. This
template allows the user to enter the information specified in
Section 2.2.1. The user is able to access the template at any
time (from a list of liaison statements that the user has
previously created and submitted), and update and resubmit the
information.
o A detail page for managing a liaison statement assigned to the
user. This page is similar to the details page available to the
public. However, it also includes:
* A mechanism for replying to the liaison statement (initial
implementation)
* A link to a liaison statement tracking mechanism (future
implementation)
A.1.2. Actions on Submission
Submission of a liaison statement results in the following actions:
o The information is uploaded to the database.
o An e-mail message with the content specified in Section 3.1.1 is
sent to the addressee with copies to the addresses specified in
Section 4.1, and to the Secretariat (as specified in [RFC4052]).
o The liaison statement is added to the list on the Liaison
Statements Web page.
o Two detail pages are created for the liaison statement: one for
the public (to view the liaison statement), and one for the sender
and the assignee (to manage the liaison statement).
As specified in Section 3.2.2.4, when a user selects reply on the
details page of a liaison statement, a template for creating and
submitting a new liaison statement is generated from the existing one
that copies "From" to "To" and specifies the respondent as the
individual the response is coming "From". Submission of this reply
liaison statement results in the same set of actions as submission of
any new liaison statement. In addition, a link to the details page
of this liaison statement is added to the list of related liaison
statements on the details pages (both public and management) of the
original liaison statement (i.e., the one to which the user replied).
Appendix B. Phase II: Additional Instrumentation and Responses to Usage
Experience
This section is for information, and is not normative.
The intended features of the future liaison statement tracking system
are discussed in Section 3.1. They include mechanisms for:
o Designating an assignee; the assignee is initially a person
associated with the body (IAB, IESG, Area, WG, etc.) to which the
liaison statement is addressed, but may subsequently be changed by
an IETF participant.
o Indicating the status of the liaison statement (e.g., actions
required, actions taken, etc. Specific options TBD).
o Sending ticklers to the assignee when action is required (with
copies to whomever is appropriate).
o Changing the status of the liaison statement, the deadline, or
other attributes.
o Reassigning responsibility.
o Closing the liaison statement.
Normative References
[RFC4052] Daigle, L., "IAB Processes for Management of Liaison
Relationships", RFC 4052, April 2005.
Authors’ Addresses
Stephen J. Trowbridge
Lucent Technologies
1200 West 120th Avenue, Suite 232, Room 34Z07
Westminster, Colorado 80234-2795
USA
Phone: +1 303 920 6545
Fax: +1 303 920 6553
EMail: sjtrowbridge@lucent.com
Scott Bradner
Harvard University
29 Oxford St.
Cambridge, Massachusetts 02138
USA
Phone: +1 617 495 3864
Fax: +1 617 492 8835
EMail: sob@harvard.edu
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.