how to deal with liaison statements

[Scott Bradner <sob@harvard.edu>]

one of the topics that has come up on various lists over the
last few weeks (most strongly on some of the sub-ip lists) is the
issue of how the IETF deals (or actually does not deal) with
liaison statements from other organizations

Steven Trowbridge (an ITU guy that has been around the IETF for a
while - long enough to be serving on teh current nomcom) pu t together
an internet draft that says how he thinks this should work - he
sent a 1st draft to a few folks a week or so ago and revised it baised
on some comments - since teh IESG will be talking about the
issue on sunday and because this fits at some level in the IAB's
space I asked him if I could send it to teh IESG & IAB to get the
discussion going

note that I am not expressing an opinion one way or the other on
this specific proposal (I have not yet read the revised version) but 
I do think that this is an issue that the IETF does need to deal 
with, at least to the level of setting expectations in other SDOs.

Scott

-------------
	
Internet Draft	S. Trowbridge
<draft-trowbridge-general-liaison-00.doc	Bell Laboratories
Expires: September 2003	March 2003


Process for Sending/Receiving Liaison Statements between the IETF and other
Standards Development Organizations, Consortia, and Fora


Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [ ]. 

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that      other
groups may also distribute working documents as Internet-Drafts.

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

The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.


Abstract

It is common practice between many standards development organizations
(SDOs), consortia, and fora to coordinate related work and exchange
information of mutual interest via the transmission of liaison or
communication statements between the relevant organizations. 

This document describes the procedure for proper handling of incoming
liaison statements and for generating liaison statements to be transmitted
from IETF/ISOC so that IETF can effectively collaborate with other
organizations in the international standards community.

Internet Draft Background (Delete before becoming RFC):

It has been increasingly common that other standards development
organizations have generated and sent liaison statements to IETF/ISOC.
Recently, the IESG has developed a practice of posting these incoming
liaison statements on the web site, even though this practice is not part
of any documented process. What is still lacking are elements of proper
notification of these incoming liaison statements to the appropriate
Working Groups or Areas and a process for considering these liaison
statements and generating responses. It has also been extremely rare that
IETF/ISOC would spontaneously generate a liaison statement to another
organization. It is important that this capability be available so that,
where needed, IETF can have the appropriate level of impact on the work of
other standards organizations. It is not sufficient to trust that other
organizations will find the information they need on the IETF web site or
be watching the appropriate email lists. Liaison statements are needed to
insure that the appropriate information from IETF appears as valid input
documentation for other standards development organizations.


Table of Contents

1. Introduction							3
2. Why Liaison Statements?					3
2.1 Liaison Statement Fields and Components			3
2.1.1	From							4
2.1.2	To							4
2.1.3	Title							4
2.1.4	Contact							4
2.1.5	Purpose							4
2.1.6	Deadline						5
2.1.7	Body							5
2.1.8	Attachments						5
3. Liaison Statements from outside Standards Organizations, 
   	Consortia, and Fora to IETF				6
3.1 Web Page for displaying Liaison Statements			6
3.1.1	Attachments Stored on "From" organization Web 
	or FTP site						7
3.2 Notification of Incoming Liaison Statements			7
3.3 Consideration of an Incoming Liaison Statement		7
3.3.1	Weight of an Incoming Liaison Statement			8
4. Communicating IETF information to other SDOs, 
	consortia, and fora					9
4.1 Spontaneously generating Liaisons to other organizations	9
4.1.1	Transmitting IETF documents to other organizations	9
4.1.2	Requests for Information				10
4.1.3	Requesting comments on Work in Progress			10
4.1.4	Requests for Other Actions (besides comments 
	on IETF drafts)						11
4.2 Responding to Incoming Liaisons				11
4.2.1	Responding to Requests for Information			12
4.2.2	Responding to Requests for Comments			12
4.2.3	Responding to Request for Action			12
4.3 Approval and Transmission of Liaison Statements		14
4.4 Indication on Outgoing Liaison Statements about 
	how to Respond						14
5. Tracking of Liaison Responses				15
6. Security Considerations					16
7. References							17
8. Acknowledgments						17
9. Author's Addresses						17


1. Introduction

It is common practice between many standards development organizations
(SDOs), consortia, and fora to coordinate related work and exchange
information of mutual interest via the transmission of liaison or
communication statements between the relevant organizations. 

This document describes the procedure for proper handling of incoming
liaison statements and for generating liaison statements to be transmitted
from IETF/ISOC so that IETF can effectively collaborate with other
organizations in the international standards community.


2. Why Liaison Statements?

Liaison statements are the most common way that standards organizations
communicate with each other. They are used for many purposes: to coordinate
related work; to announce results; to request information or to ask a
question; etc. In general, liaison statements should be as clear as
possible as to what (if anything) the sending organization expects the
receiving organization to do as a result of the liaison statement and by
when.

2.1 Liaison Statement Fields and Components

Many liaison statements will have specific fields in the header of the
document that clarify important information about why the liaison is sent
and what is expected to be done with it. Some organizations are quite
meticulous about including this kind of information in a standard format on
every liaison statement. Others will sometimes use a "personal letter"
format and it is necessary to examine the text in more detail to infer what
value these liaison fields should have. If it cannot be determined what the
value of these fields are or should be based on the text, the default
assumption is that the liaison statement is for Information with no
deadline.

The following fields and components are normally part of a liaison
statement:

2.1.1 From

What organization sent the liaison statement, and to whom should replies be
addressed? This should normally be as specific as possible. For example, in
a liaison statement generated from IETF to another organization, it might
be a particular Working Group, Area, or the entire IETF depending on the
content. If a liaison statement is from ITU-T, it might indicate a
particular Study Group, Working Party, or Question.

2.1.2 To

What organization is this liaison statement being sent to. This should
normally be as specific as possible: for example, for a liaison sent to
IETF, it should indicate, if appropriate, the particular Working Group(s)
or Area(s) that should pay attention to this liaison statement. For a
liaison statement sent by IETF to ITU-T, for example, it should indicate
the appropriate Study Group(s), Working Party(ies), or Question(s) that
should consider the liaison statement. There is no need to generate "noise"
for parts of an organization that are not affected.

2.1.3 Title

A short description of the liaison statement.

2.1.4 Contact

One or more individuals in representing the "From:" organization who may be
contacted if there are any questions concerning the material sent in the
liaison statement.

2.1.5 Purpose

Indicates why the liaison is being sent. The most common are the following:

2.1.5.1 For Information

Liaisons generated for information do not normally expect or require a
reply.

They may be generated spontaneously from one organization to another to
convey information about a decision (e.g., to start, stop, or refocus work)
or to transmit a document that is considered by the sender to be of
relevance for the recipient.

They also may be generated as a response to an incoming liaison statement.
When another organization requests some action, asks for comments, or asks
a question, the reply could supply the answers, information, or comments
that were requested.

2.1.5.2 For Comment

Liaisons for Comment normally expect a reply. Generally, these are sent
when the "From:" organization has a draft document on a topic where the
"To:" organization has an interest or specific expertise, and they are
asking for input or concurrence. Liaisons for Comment will generally
indicate a deadline by which a response is required.

2.1.5.3 For Action

A Liaison Statement will be sent "For Action" when the "From:" organization
actually wants the "To:" organization to do something. For example: Answer
a Question, Align a Specification of the recipient organization with on of
the Sending organization, to start a new work activity, etc. A response is
always expected to a liaison For Action. The incoming liaison should always
indicate a deadline by which a response is required. The "From:"
organization may not always agree with the request and do what was asked,
but they must always respond and indicate what (if anything) they decided
to do as a result of the request. If the "From:" organization does not wish
to do what was requested, they at least owe the requesting organization a
response to explain why not.

2.1.6 Deadline

For a liaison that is sent "For Comment" or "For Action", the date by which
the "From:" organization requires a response if it is to be considered in
their further work.

2.1.7 Body

As with any business letter, a liaison statement has a body which explains
what is being sent. In the case of a liaison statement being sent for
Information, the body can explain what information is being transmitted and
why. In the case of a liaison statement for Comment, the body can explain
what the document is for which comments are being requested, the stage of
maturity, etc. In the case of a liaison statement for Action, the body can
explain what the "From:" organization would like the "To:" organization to
do and why.

2.1.8 Attachments

Frequently a liaison statement will have attachments. These may be draft or
approved documents or contributions that the "From:" organization believes
would be of relevance to the "To:" organization. In the case of a liaison
statement for Information, it may be a completed document that the "From:"
organization wishes to announce to the "To:" organization. In the case of a
liaison statement for Comment, it is generally the document(s) that the
"From:" organization would like for the "To:" organization to review and
respond with comments. In a liaison statement for Action, attachments could
include documents from the "From:" organization with which the "To:"
organization is asked to align their work.


3. Liaison Statements from outside Standards Organizations, Consortia, and
Fora to IETF

Internet Draft Note (delete from RFC): A practice has been developed for
dealing with incoming liaison statements which, as yet, is not captured in
any existing process document.

When an outside SDO, consortium, or forum wishes to send a liaison
statement to a Working Group, Area, or the IETF at large, they should send
the liaison statement, together with any attachments to
statements@ietf.org.

3.1 Web Page for displaying Liaison Statements

The actual liaison statements will be posted on the IESG web site under the
following URL: http://www.ietf.org/IESG/liaison.html. This web page
contains a list of all incoming and outgoing liaison statements. For
incoming liaison statements, the following information is displayed on the
web page:

- The date the liaison statement was received.

- The source (originating organization) of the liaison statement.

- The Working Group, Area, or entire IETF to which the liaison statement is
addressed. (Note: it may also be useful to designate a particular WG chair,
AD, or other individual who has the responsibility to generate the
response, similar to designating a shepherding AD for an Internet Draft.
But for now, as there are at most two WG co-chairs for a given WG or two
co-ADs for a given area, it is probably sufficient for now to indicate the
group or area to which the liaison statement is addressed, and consider the
(at most two) people to be jointly responsible for responding).

- The title of the liaison statement. The title is a hyperlink to the
actual text of the liaison statement.

- The purpose of the liaison statement (Information, Comment, Action).

- If the liaison statement is for Comment or for Action, the deadline
specified in the liaison statement.

The body of the liaison statement will be formatted as an HTML web page
which can be accessed by following the hyperlink for the title of the
liaison statement from http://www.ietf.org/IESG/liaison.html. Any
attachments are in turn formatted as web pages that can be accessed from
hyperlinks in the body of the liaison statement.

3.1.1 Attachments Stored on "From" organization Web or FTP site

In certain cases, the sending organization would prefer that attachments be
available through their own web or FTP site instead of posted on the IETF
site. There can be a variety of reasons for this, including making editable
source documents available in proprietary formats or copyright issues. In
this case, the body of the liaison statement posted on the IETF site will
contain a hyperlink back to the location on the "From" organization web or
FTP site where the "attached" information can be found.

Indication of the presence of the new incoming liaison will then be made to
the relevant WG, Area, or IETF mailing list depending on how the incoming
liaison statement is addressed.

3.2 Notification of Incoming Liaison Statements

Once a new incoming liaison statement has been placed onto the
http://www.ietf.org/IESG/liaison.html page, the arrival of that liaison
statement will be announced to the relevant Working Group, Area, or IETF
list depending on how the incoming liaison statement is addressed. As those
who will be responsible for generating any response (the WG chair(s), Area
Director(s), or IETF chair) are subscribed to these lists anyway, a
separate notification to those leaders is not required.

3.3 Consideration of an Incoming Liaison Statement

An incoming liaison statement will be discussed and considered on the email
list in the same way as an Internet Draft (although most liaison statements
do not contain text that will ultimately advance through the process to
become an RFC). Any consensus that develops regarding the material in the
liaison statement will help to formulate any reply that is sent (see
section 4.2).

3.3.1 Weight of an Incoming Liaison Statement

This is not something that normally appears in the procedures of other
organizations regarding handling of liaison statements, but as discussion
has revealed some concern in this area, it is worth a few words.

There are two aspects of Weight that will be discussed here: Importance and
Urgency.

3.3.1.1 Importance of an Incoming Liaison Statement

The question of importance is this: How much influence will an incoming
liaison statement have over the ongoing work of the (Working
Group/Area/IETF) to which the liaison statement is addressed?

The simple answer is that, as a matter of PROCESS, an incoming liaison
statement has no more and no less weight than an individual internet draft
that has been submitted for consideration.

As a practical matter, though, it is not even the case that all internet
drafts have the same importance:

- Internet Drafts from more credible sources tend to be considered more
important to discuss and work on than internet drafts from less respected
sources.

- Internet Drafts containing good ideas tend to be considered more
important than those containing bad ideas.

- Internet Drafts that propose solutions to problems that are important in
the marketplace are considered more important than those that address
problems nobody cares about.

Similar factors may be used as arguments about why certain liaison
statements may have more importance than others:

- Liaison statements from a Standards Development organization doing
closely related work may be considered more important than one from an
organization with entirely unrelated scope.

- It may be argued that the contents of a liaison statement represent the
results of consensus building in the other organization and therefore
represent the views of more than a single individual.

But to be clear, there is no requirement that any text or proposal be
accepted just because it arrived in a liaison statement. A bad idea does
not need to be accepted just because of its source.

3.3.1.2 Urgency of an Incoming Liaison statement

While there is no automatic difference in the importance (as defined in
section 3.3.1.1) of material that arrives in an incoming liaison statement
versus material that arrives in an individual internet draft, there is most
definitely a difference in urgency.

There is no set timetable about when (or if) proposals and material in an
individual internet draft need to be addressed by the group to which it is
submitted. The Working Group, Area, or IETF can determine its own timetable
(explicitly, or just by letting the work take as long as it takes) for
dealing with the material.

However, in the case of an incoming liaison statement that is for "Action"
or for "Comment", a deadline may be specified by the "From" organization
indicating when a response is needed. By failing to respond by the
indicated deadline, the IETF forfeits its opportunity to influence the work
of other SDOs, consortia and fora. Therefore, it is CRITICAL that every
effort be made to consider material from incoming liaison statements that
are for "Action" or for "Comment" and to generated a response before the
indicated deadline. This does not mean that IETF needs to accept or agree
with what was asked in the liaison statement: just that it needs to respond
by the indicated deadline (even if the response is only to say "We think
this is a bad idea because ...").


4. Communicating IETF information to other SDOs, consortia, and fora

4.1 Spontaneously generating Liaisons to other organizations

Liaisons can be generated at a WG, Area, or IETF level to another
organization. The respective (co)chair(s) are responsible for judging the
degree of consensus for sending the particular liaison and what the content
should be.

4.1.1 Transmitting IETF documents to other organizations

The simplest case of approving sending of a liaison from IETF is where the
information that is being transmitted consists of an IETF document that has
some level of agreement within the IETF. The process that the document has
already gone through to achieve its current status assures the necessary
level of consensus.

The types of documents that can be sent to another organization on the
decision of the (co)chair(s) alone without the need to seek further
consensus are as follows:

- Any Standards Track RFC (Draft Standard, Proposed Standard, Internet
Standard, BCP).

- Any standards track Working Group Internet Draft can be transmitted.

In all cases, the level of agreement must be appropriately noted. In the
case of a Working Group Internet Draft, it must be clear that the existence
of the draft only indicates that the Working Group has accepted the work
item and, as the standard disclaimer says, the actual content can be
treated as nothing more than Work in Progress.

Individual Internet Drafts and Informational or Historical RFCs should not
be transmitted without developing further consensus within the relevant
group, as these documents cannot be truthfully represented as any kind of
IETF position.

4.1.2 Requests for Information

Another type of liaison that can be generated without the need for
extensive consensus building on the email list is a request for
information. The (co)chairs(s) can generate such a liaison when they
recognize from the activities of the group that some additional information
would be helpful to resolve an impasse. For example, ccamp once engaged in
an extensive debate about what the T1X1/ITU-T standards actually said about
particular aspects of SONET/SDH. Rather than acting based on which IETF
participants had the most stamina to continue the debate, an appropriate
action would have been for the ccamp co-chairs to send a liaison to T1X1
and ITU-T asking which is the correct interpretation. Further work could
then have been based on an official answer.

Other requests for information may be to request access to certain
documents of other organizations that are not publicly available.

As more information will generally lead to better decisions, the threshold
to decide to ask for information can actually be quite low. It can be done
just because the (co)chair(s) think it is a good idea and that a particular
piece of information will help the activities underway.

4.1.3 Requesting comments on Work in Progress

There may be cases where people feel that a document under development in
the IETF would benefit from the input of experts in another SDO,
consortium, or forum. Generally, this is done before the text is "fully
cooked" so that input from experts in another organization can be included
in the final result. Comments would generally be solicited for a standards
track working group Internet Draft.

The earlier observation (that more information is generally better)
notwithstanding, the political reality is that it may not be appropriate to
send a draft to certain external organizations asking for comments. In some
cases, the appropriate expertise may not be there and it is a waste of
everyone's time. In other cases, the goals and perspective of the other
organization may be sufficiently different from those of the working group
or area within the IETF that any comments which would be received would not
be expected to be helpful. As a result, some level of consensus should be
reached on the mailing list that it is appropriate to ask another
organization for comments on an IETF draft.

4.1.4 Requests for Other Actions (besides comments on IETF drafts)

There are a number of other kinds of actions that might reasonably be
requested of another organization:

- In the case of overlapping or related work in another organization, a
request could be made that the other organization change something to align
with the IETF work.

- A request could be made for another organization to start a new work item
(on behalf of IETF).

- A request could be made for another organization to stop a work item
(presumably because it overlaps or conflicts with other work in the IETF).

These sorts of requests are, of course, quite serious. They can certainly
be made where appropriate, but these kinds of requests should only be made
where there is the clearest possible consensus within the particular
Working Group, Area, or within the IETF at large.


4.2 Responding to Incoming Liaisons

Any incoming liaison that indicates that it is for "Comment" or for
"Action" requires a response by the deadline. It is the responsibility of
the (co)chair(s) of the addressed organization to make sure that a response
is generated by the deadline:

- For liaison statements addressed to an IETF Working Group, the Working
Group (co)chair(s) is/are responsible for ensuring that a response is
generated.

- For liaison statements addressed to an IETF Area, the Area Director(s)
is/are responsible for ensuring that a response is generated.

- For liaison statements addressed to the IETF as a whole, the IETF
chairman is responsible for ensuring that a response is generated.

4.2.1 Responding to Requests for Information

If another organization requests information that can be found in an IETF
document of the types indicated in section 4.1.1, this can be transmitted
directly by the (co)chair(s) of the addressed group, indicating the level
of agreement for the relevant document.

4.2.2 Responding to Requests for Comments

If an incoming liaison requests comments on a document from another
organization, a discussion will occur on the mailing list where
participants can provide their comments.

If a clear consensus is evident from the pattern of comments made to the
mailing list, the (co)chair(s) can summarize the conclusions in a reply
liaison back to the originating organization.

If no clear consensus is evident from the pattern of comments on the
mailing list, a response is still due to the originator. A summary of the
email comments can be created and sent to the originator, and represented
as "collected comments" rather than as a consensus of the IETF group to
which the liaison was addressed. It is possible to send this kind of a
reply even if some of the comments are contradictory.

4.2.3 Responding to Request for Action

As discussed in sections 2.1.5.3 and 4.1.4, a request for Action is a
fairly serious thing. Examples of the kinds of actions that may be expected
are:

- In the case of overlapping or related work in another organization,
another organization may request that the IETF align its work with that of
the other organization.

- A request could be made for IETF to undertake a new work item.

- 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 be
able 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 this document proposes a requirement that IETF always
respond to such a request. The request should always be taken seriously.
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.

For tasks that require a great deal of time, it may be necessary that
several liaisons be sent back to the originating organization to report the
status of the work and the anticipated completion time. The first of these
liaisons must be generated by the deadline indicated in the incoming
liaison.

Some special remarks about starting or stopping work as a result of an
incoming liaison statement:

- In the case of starting or stopping minor work items (within the context
of the current Working Group charter), for example, as part of ongoing
management of the division of work between IETF and another standards
organization, consensus based decisions can be made as to what to do and a
response can be generated just as for a liaison statement on a technical
matter.

- In the case of starting or stopping a major work item that would require
a charter change, a decision first needs to be made as to whether this is a
good idea. If the consensus of the group is that it is not a good idea, or
if the WG chair(s) in consultation with the Area Director(s) agree that the
charter should not be changed to accommodate the request, a reply can be
generated indicating that the request is out of scope for this group. A
copy of the current charter can be attached to the response.

- In the case of starting or stopping a major work item that would require
a charter change, and the consensus of the group, together with the WG
chair(s) and Area Director(s) is that this is a good idea, it is necessary
to take the proposal for the charter change to the IESG. Depending on the
deadline, it may be necessary to generate more than one reply to the
liaison statement. The first reply might be to indicate an agreement in
principle, but explaining that accepting the new work item requires a
charter change which has been proposed but not yet approved. A subsequent
reply can be generated once the charter change is approved by the IESG.

4.3 Approval and Transmission of Liaison Statements

It is important that appropriate leadership review be made of proposed IETF
liaison statements and that those who write such statements who claim to be
speaking on behalf of IETF are truly representing IETF views.

All requests to send an outgoing liaison statement must go through IESG
secretariat by sending the request to send the liaison statement to
statements@ietf.org. The sender is responsible for supplying the IESG
secretariat with the email address(es) to which the liaison statement
should be sent to properly reach the intended organization. The IESG
secretariat is responsible for verifying that appropriate approval has been
obtained. Sending of liaisons through the secretariat will also facilitate
posting of the outgoing liaison statements as described in section 5.

For a liaison statement generated on behalf of an IETF working group, the
working group chair(s) must have generated, or must agree with the sending
of the liaison statement, and the Area Director(s) must know about the
liaison statement and must not object to its being sent.

For a liaison statement generated on behalf of an IETF Area, the Area
Director(s) must have generated or must agree with the sending of the
liaison statement.

For a liaison statement generated on behalf of the IETF as a whole, the
IETF chairman must have generated or must agree with the sending of the
liaison statement.

Usually these approvals will require only that the secretariat examine the
"chain" by which the email with the proposed liaison was sent: for example,
the liaison statement author sends to the WG chair(s), who forward with an
"OK" remark to the ADs, who forward with an OK remark to the secretariat at
statements@ietf.org. In normal cases, the secretariat should not have an
investigative task to do to determine whether appropriate approval has been
obtained to send a liaison statement.

4.4 Indication on Outgoing Liaison Statements about how to Respond

All outgoing liaison statements should indicate how to respond. This is
standard text which can be appended by the secretariat when the liaison
statement is sent. This text should read:

Please send any responses to this liaison statement via email to
statements@ietf.org,indicating
Attention: (xxx Working Group)|(xxx Area)|IETF


5. Tracking of Liaison Responses

As with other parts of the IETF process, mechanisms should be put in place
to make sure that this process is open and transparent, and that it is
always possible to determine whether the necessary responses have been
generated.

Tracking of liaisons is not complicated, and can be done through a largely
manual process using the web page that is currently used to post incoming
liaison statements:

        http://www.ietf.org/IESG/liaison.html

To be effective, the web page should contain the following information
about each incoming liaison statement:

- The date the liaison statement was received.

- The source (originating organization) of the liaison statement.

- The Working Group, Area, or entire IETF to which the liaison statement is
addressed. (Note: it may also be useful to designate a particular WG chair,
AD, or other individual who has the responsibility to generate the
response, similar to designating a shepherding AD for an Internet Draft.
But for now, as there are at most two WG co-chairs for a given WG or two
co-ADs for a given area, it is probably sufficient for now to indicate the
group or area to which the liaison statement is addressed, and consider the
(at most two) people to be jointly responsible for responding).

- The title of the liaison statement. As is currently the case, the title
can be a hyperlink to the actual text of the liaison statement.

- The purpose of the liaison statement (Information, Comment, Action).

- If the liaison statement is for Comment or for Action, the deadline
specified in the liaison statement.

In addition, the following information should be posted regarding each
outgoing liaison statement:

- The date the liaison statement was sent.

- The source (which Working Group, Area, or the entire IETF is the source
of the liaison statement).

- The organization to which the liaison statement is addressed.

- The title of the liaison statement. This title should be a hyperlink to
the actual text of the liaison statement.

- The purpose of the liaison statement (Information, Comment, Action).

- If the liaison statement is for Comment or for Action, the deadline by
which a response is expected.

In the case where the liaison statement is a response to an incoming
liaison statement, the outgoing liaison statement information should be
shown, indented, immediately below the incoming liaison statement to which
the liaison statement responds. A separate area of the web page will list
the liaison statements that were generated spontaneously by IETF.

In this way, it is obvious from looking at the web page which liaison
statements have been responded to and which are still awaiting a response.
Seeing a deadline that is previous to the current date without a reply
liaison is a bad thing. Since the website is public, it is obvious to both
those inside of IETF and to those who send liaison statements to IETF who
is responsible for responding (similar to how ID Tracker indicates who is
responsible for taking the next action by when in the context of the
standards process).

Standards activities are, by their nature, voluntary and it is not possible
to force people to take actions indicated as "required" in this or any
other standards process. However, the public display of this information,
together with the resulting peer pressure and public embarrassment for
those who fail to perform the necessary tasks should ensure that, in most
cases, the appropriate responses are generated.


6. Security Considerations

Documents that describe cooperation procedures, like this one does, have no
direct Internet security implications.


7. References
 
8. Acknowledgments

This text has been prompted by discussions with numerous individuals within
IETF and other Standards Development Organizations and Fora, including
Scott Bradner, Gary Fishman, and Bert Wijnen. 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. Seeing some drafts aimed at
addressing individual problems (e.g.,
draft-andersson-mpls-g-chng-proc-00.txt and 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.


9. Author's Addresses

Stephen J. Trowbridge
Lucent Technologies
11900 North Pecos Street, room 34W34
Denver, Colorado 80234 USA
Phone: +1 303 920 6545
Fax:   +1 303 920 6553
Email: sjtrowbridge@lucent.com