Network Working Group                                      S. Trowbridge
Request for Comments: 4053                           Lucent Technologies
BCP: 103                                                      S. Bradner
Category: Best Current Practice                       Harvard University
                                                                F. Baker
                                                           Cisco Systems
                                                              April 2005
        
Network Working Group                                      S. Trowbridge
Request for Comments: 4053                           Lucent Technologies
BCP: 103                                                      S. Bradner
Category: Best Current Practice                       Harvard University
                                                                F. Baker
                                                           Cisco Systems
                                                              April 2005
        

Procedures for Handling Liaison Statements to and from the IETF

处理进出IETF的联络声明的程序

Status of This Memo

关于下段备忘

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

本文件规定了互联网社区的最佳现行做法,并要求进行讨论和提出改进建议。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(2005年)。

Abstract

摘要

This document describes the procedure for proper handling of incoming liaison statements from other standards development organizations (SDOs), consortia, and industry fora, and for generating liaison statements to be transmitted from IETF to other SDOs, consortia and industry fora. This procedure allows IETF to effectively collaborate with other organizations in the international standards community.

本文件描述了正确处理来自其他标准开发组织(SDO)、联盟和行业论坛的传入联络声明的程序,以及生成从IETF传输到其他SDO、联盟和行业论坛的联络声明的程序。该程序允许IETF与国际标准界的其他组织进行有效合作。

The IETF expects that liaison statements might come from a variety of organizations, and it may choose to respond to many of those. The IETF is only obligated to respond if there is an agreed liaison relationship, however.

IETF预计联络声明可能来自不同的组织,并且可能会选择对其中的许多组织作出回应。然而,IETF只有在存在商定的联络关系时才有义务作出响应。

Table of Contents

目录

   1. Introduction ....................................................3
   2. Liaison Statements and Their Handling ...........................3
      2.1. Definitions ................................................3
      2.2. Liaison Statements .........................................4
           2.2.1. Contents of a Liaison Statement .....................4
                  2.2.1.1. Envelope Information .......................4
                  2.2.1.2. Liaison Content ............................5
      2.3. Addressee Responsibilities .................................6
      2.4. Lifetime of a Liaison Statement ............................7
   3. Tools for Handling Liaison Statements ...........................7
      3.1. Liaison Statements from Other SDOs, Consortia, and
           Fora to IETF ...............................................7
           3.1.1. Liaison Statement Submission ........................8
           3.1.2. Mechanism for Displaying Liaison Statements .........9
      3.2. Communicating IETF Information to Other SDOs,
           Consortia, and Fora ........................................9
           3.2.1. Spontaneously Generating Liaison Statements
                  to Other ............................................9
                  3.2.1.1. Transmitting IETF Documents to
                           Other Organizations .......................10
                  3.2.1.2. Requests for Information ..................10
                  3.2.1.3. Requesting Comments on Work in Progress ...11
                  3.2.1.4. Requests for Other Actions
                           (Besides Comments on IETF Drafts) .........11
           3.2.2. Responding to Incoming Liaison Statements ..........11
                  3.2.2.1. Responding to Requests for Information ....11
                  3.2.2.2. Responding to Requests for Comments .......12
                  3.2.2.3. Responding to Request for Action ..........12
                  3.2.2.4. Generating Liaison Statements .............13
   4. Security Considerations ........................................13
   5. Acknowledgements ...............................................14
   A. Implementation Road map ........................................15
      A.1. Phase I: Initial Implementation ...........................15
           A.1.1.   Displays .........................................15
           A.1.2.   Actions on Submission ............................16
   B. Phase II: Additional Instrumentation and Responses to
      Usage Experience ...............................................17
   Normative References ..............................................17
        
   1. Introduction ....................................................3
   2. Liaison Statements and Their Handling ...........................3
      2.1. Definitions ................................................3
      2.2. Liaison Statements .........................................4
           2.2.1. Contents of a Liaison Statement .....................4
                  2.2.1.1. Envelope Information .......................4
                  2.2.1.2. Liaison Content ............................5
      2.3. Addressee Responsibilities .................................6
      2.4. Lifetime of a Liaison Statement ............................7
   3. Tools for Handling Liaison Statements ...........................7
      3.1. Liaison Statements from Other SDOs, Consortia, and
           Fora to IETF ...............................................7
           3.1.1. Liaison Statement Submission ........................8
           3.1.2. Mechanism for Displaying Liaison Statements .........9
      3.2. Communicating IETF Information to Other SDOs,
           Consortia, and Fora ........................................9
           3.2.1. Spontaneously Generating Liaison Statements
                  to Other ............................................9
                  3.2.1.1. Transmitting IETF Documents to
                           Other Organizations .......................10
                  3.2.1.2. Requests for Information ..................10
                  3.2.1.3. Requesting Comments on Work in Progress ...11
                  3.2.1.4. Requests for Other Actions
                           (Besides Comments on IETF Drafts) .........11
           3.2.2. Responding to Incoming Liaison Statements ..........11
                  3.2.2.1. Responding to Requests for Information ....11
                  3.2.2.2. Responding to Requests for Comments .......12
                  3.2.2.3. Responding to Request for Action ..........12
                  3.2.2.4. Generating Liaison Statements .............13
   4. Security Considerations ........................................13
   5. Acknowledgements ...............................................14
   A. Implementation Road map ........................................15
      A.1. Phase I: Initial Implementation ...........................15
           A.1.1.   Displays .........................................15
           A.1.2.   Actions on Submission ............................16
   B. Phase II: Additional Instrumentation and Responses to
      Usage Experience ...............................................17
   Normative References ..............................................17
        
1. Introduction
1. 介绍

This document describes the procedure for generating and handling liaison statements between the IETF and other SDOs, so that IETF can effectively collaborate with other organizations in the international standards community. These liaison statements are primarily exchanged between IETF and organizations with whom the IAB has created a liaison relationship (see [RFC4052]), although other organizations are not precluded. The procedures described in this document encompass all liaisons statements received from SDOs, whether or not a formal liaison arrangement is in place between the SDO and the IETF. The IETF is not obligated to respond to the liaison statement where there is no formal liaison arrangement.

本文件描述了生成和处理IETF与其他SDO之间的联络声明的程序,以便IETF能够与国际标准界的其他组织进行有效合作。这些联络声明主要在IETF和IAB与之建立联络关系的组织之间交换(见[RFC4052]),但不排除其他组织。本文件中描述的程序包括从SDO收到的所有联络声明,无论SDO和IETF之间是否有正式联络安排。如果没有正式的联络安排,IETF没有义务对联络声明作出回应。

The implementation of the procedure and supporting tools is occurring in a minimum of three phases. The initial phase has been the development of a prototype (in the best tradition of "rough consensus and running code"), by Sunny Lee of Foretec, in parallel with the development of this specification. The second phase is the conversion of that prototype to an operational tool. This operational tool lacks an automated tracking tool; rather, the liaison manager implements it in his or her own way. The third phase will include that tracking tool.

程序和支持工具的实施至少分三个阶段进行。最初阶段是由Foretec的Sunny Lee开发原型(按照“大致共识和运行代码”的最佳传统),同时开发本规范。第二阶段是将该原型转化为操作工具。该操作工具缺乏自动跟踪工具;相反,联络经理以自己的方式实施。第三阶段将包括该跟踪工具。

The specific supporting tools and their functionality described in this document are one possible way of providing automated support for the processes described in this document. Because specific tools and their functionality will change over time, the descriptions in this document are to be considered examples only and are not a normative part of this specification.

本文档中描述的特定支持工具及其功能是为本文档中描述的流程提供自动化支持的一种可能方式。由于特定工具及其功能会随着时间的推移而变化,因此本文件中的描述仅作为示例,而不是本规范的规范性部分。

2. Liaison Statements and Their Handling
2. 联络声明及其处理

Let us first define what a liaison statement is (and is not), and set reasonable expectations. The expectations in this section are normative for a liaison statement sent by any SDO to the IETF.

让我们首先定义什么是(和不是)联络声明,并设定合理的期望。本节中的要求是任何SDO向IETF发送联络声明的规范性要求。

2.1. Definitions
2.1. 定义

For purposes of clarity, we use the following definitions:

为清晰起见,我们使用以下定义:

Addressee: The Working Group(s) (WG) or other party(s) in the IETF to whom a liaison statement is addressed.

收件人:联络声明所针对的IETF工作组(WG)或其他方。

Assignee: The person responsible to act on a liaison statement, initially either the person to whom it was addressed or the chair of the group to which it was addressed. The task may be reassigned to another person in the same or a different group as appropriate.

受让人:负责对联络声明采取行动的人,最初是该声明的收件人或该声明所针对的小组的主席。该任务可根据需要重新分配给同一组或不同组中的其他人员。

Liaison manager: A person designated to act as a manager of the relationship between the IETF and a peer organization to ensure that communication is maintained, is productive, and is timely, as defined by sections 2.2 and 3 in [RFC4052].

联络经理:根据[RFC4052]第2.2节和第3节的定义,被指定为IETF和对等组织之间关系的经理,以确保保持沟通、高效和及时。

Liaison statement: A letter as described in this document, exchanged between organizations.

联络声明:如本文件所述,各组织之间交换的信函。

2.2. Liaison Statements
2.2. 联络声明

A Liaison Statement is a business letter sent by one standards organization to another. These organizations may be at any level (WG, Area, etc.) Generally, the sender and receiver are peer organizations. A liaison statement may have any purpose, but generally the purpose is to solicit information, make a comment or request an action.

联络声明是一个标准组织发送给另一个标准组织的商业信函。这些组织可以是任何级别(工作组、区域等)。通常,发送方和接收方是对等组织。联络声明可能有任何目的,但通常目的是征求信息、发表评论或要求采取行动。

2.2.1. Contents of a Liaison Statement
2.2.1. 联络声明的内容

Liaison statements may be very formal or informal, depending on the rules of the body generating them. Any liaison statement, however, will always contain certain information, much as an business letter does. This information will include the following:

联络声明可能非常正式,也可能非常非正式,这取决于产生联络声明的机构的规则。然而,任何联络声明都会包含某些信息,就像商务信函一样。这些信息将包括以下内容:

2.2.1.1. Envelope Information
2.2.1.1. 信封信息

The following fields detail properties of the liaison statement.

以下字段详细说明了联络声明的属性。

2.2.1.1.1. From:

2.2.1.1.1. 发件人:

The statement will indicate from what body it originates; for example, it may be from, an IETF WG or Area, an ITU-T Study Group, Working Party, or Question, etc. In this document, this body is the "sender".

该声明将指明其来源;例如,它可能来自IETF工作组或地区、ITU-T研究小组、工作组或问题等。在本文件中,该机构是“发送者”。

2.2.1.1.2. To:

2.2.1.1.2. 致:

The statement will indicate to which body it is. In this document, this body is the "addressee".

该语句将指明它是哪个主体。在本文件中,该机构是“收件人”。

2.2.1.1.3. Title:

2.2.1.1.3. 标题:

The statement will contain a short (usually single line) statement of its context and content.

该语句将包含其上下文和内容的简短(通常是单行)语句。

2.2.1.1.4. Response Contact:

2.2.1.1.4. 回应联络人:

The sender will indicate the electronic mail address to which any response should be sent.

发件人将指明任何回复应发送到的电子邮件地址。

2.2.1.1.5. Technical Contact:

2.2.1.1.5. 技术联系人:

The sender will indicate one or more electronic mail addresses (persons or lists) that may be contacted for clarification of the liaison statement.

发件人将指明一个或多个可联系以澄清联络声明的电子邮件地址(人员或名单)。

2.2.1.1.6. Purpose:

2.2.1.1.6. 目的:

A liaison statement generally has one of three purposes and will clearly state its purpose using one of the following labels:

联络声明通常有三个目的之一,并使用以下标签之一明确说明其目的:

For Information: The liaison statement is to inform the addressee of something, and expects no response.

仅供参考:联络声明旨在通知收件人某件事,不希望收到回复。

For Comment: The liaison statement requests commentary from the addressee, usually within a stated time frame.

评论:联络声明要求收件人在规定的时间范围内发表评论。

For Action: The liaison statement requests that the addressee do something on the sender's behalf, usually within a stated time frame.

行动:联络声明要求收件人代表发件人做一些事情,通常在规定的时间范围内。

In Response: The liaison statement includes a response to a liaison statement from the peer organization on one or more of its documents and expects no further response.

回应:联络声明包括对同行组织在其一份或多份文件上的联络声明的回应,预计不会有进一步的回应。

2.2.1.1.7. Deadline:

2.2.1.1.7. 截止日期:

Liaison statements that request comment or action will indicate when the comment or action is required. If the addressee cannot accomplish the request within the stated period, courtesy calls for a response offering a more doable deadline or an alternative course of action.

要求评论或行动的联络声明将说明何时需要评论或行动。如果收件人不能在规定的期限内完成请求,礼貌要求回复,提供更可行的截止日期或替代行动方案。

2.2.1.2. Liaison Content
2.2.1.2. 联络内容

The following fields are the substance of the liaison statement. IETF participants use a wide variety of systems, thus document formats that are not universally readable are problematic. As a

以下字段是联络声明的实质内容。IETF参与者使用各种各样的系统,因此不能普遍阅读的文档格式是有问题的。作为一个

result, documents enclosed with the body or attachments should be in PDF, W3C HTML (without proprietary extensions), or ASCII text format. If they were originally in a proprietary format such as Microsoft Word, the file may be sent, but should be accompanied by a generally readable file.

因此,随正文或附件附上的文档应为PDF、W3CHTML(无专有扩展)或ASCII文本格式。如果文件最初是以专有格式(如Microsoft Word)发送的,则可以发送该文件,但应附带一般可读的文件。

2.2.1.2.1. Body:

2.2.1.2.1. 正文:

As with any business letter, the liaison statement contains appropriate content explaining the issues or questions at hand.

与任何商业信函一样,联络声明包含适当的内容,解释手头的问题。

2.2.1.2.2. Attachments:

2.2.1.2.2. 附件:

Attachments, if enclosed, may be in the form of documents sent with the liaison statement or may be URLs to similar documents including Internet Drafts.

附件(如随附)可以是与联络声明一起发送的文件形式,也可以是类似文件(包括互联网草案)的URL。

2.3. Addressee Responsibilities
2.3. 收件人责任

The responsibilities of the addressee of a liaison statement are the same as the responsibilities of any business letter. A liaison statement calls for appropriate consideration of its contents, and if a reply is requested and an appropriate relationship exists, a courteous authoritative reply within the expected time frame. The reply may be that the information was useful or not useful, that the requested action has been accomplished, it will be accomplished by a specified date, it will not be done for a specific reason, an answer to a question posed, or any other appropriate reply.

联络声明收件人的责任与任何商业信函的责任相同。联络声明要求适当考虑其内容,如果要求答复且存在适当关系,则在预期时间范围内给予礼貌的权威答复。答复可以是信息有用或无用、请求的行动已经完成、将在指定日期完成、出于特定原因不会完成、对提出的问题的答复或任何其他适当答复。

A liaison statement, like any other temporary document, must be considered for its relevance, importance, and urgency.

与任何其他临时文件一样,必须考虑联络声明的相关性、重要性和紧迫性。

One hopes that a liaison statement will be sent to the right organization, but this cannot be assured. An SDO might send a liaison statement to a specific IETF Area whose Area Director (AD) deems it better handled by one of the WGs, or it might be sent to one WG when it should have gone to another. If a liaison statement arrives that appears misdirected, the assignee should promptly ask the liaison manager to redirect it appropriately. In some cases, a liaison statement may require consideration by multiple groups within the IETF; in such cases, one assignee takes the lead and responsibility for developing a response.

人们希望向正确的组织发送一份联络声明,但这不能保证。SDO可以向其区域主管(AD)认为由其中一个工作组更好地处理的特定IETF区域发送联络声明,也可以在本应发送给另一个工作组时发送给一个工作组。如果收到的联络声明有误,受让人应立即要求联络经理对其进行适当的重定向。在某些情况下,联络声明可能需要IETF内多个小组的考虑;在这种情况下,由一名受让人牵头并负责制定应对措施。

Liaison Statements are always important to the body that sent them. Having arrived at the appropriate body, the liaison statement may be more or less important to the addressee depending on its contents and the expertise of the sender. If the liaison statement seeks to influence the direction of a WG's development, it should receive the

联络声明对发出联络声明的机构来说总是很重要的。联络声明到达适当机构后,根据其内容和发件人的专业知识,对收件人可能或多或少重要。如果联络声明试图影响工作组的发展方向,则应收到

same consideration that any temporary document receives. The WG chair may request the sender's contacts to make their case to the IETF WG in the same manner that an author of an internet draft makes his or her case.

与任何临时文件收到的考虑相同。工作组主席可要求发送方联系人向IETF工作组陈述其观点,其方式与互联网草案作者陈述其观点的方式相同。

The urgency of a liaison statement is usually reflected in its deadline. A liaison statement for informational purposes may have no deadline; in such a case, a courteous "thank you" liaison statement is necessary to inform the sender that the liaison statement was received. The WG may then inform itself of the contents and close the document. A liaison statement specifying a deadline, however, gives the addressee a finite opportunity to influence the activity of another body; if it fails to react in a timely fashion, it may miss the opportunity.

联络声明的紧迫性通常反映在其截止日期上。用于提供信息的联络声明可能没有截止日期;在这种情况下,有必要发出礼貌的“谢谢”联络声明,告知发件人已收到联络声明。工作组随后可告知其内容并关闭文件。然而,一份指明最后期限的联络声明给收件人一个有限的机会来影响另一个机构的活动;如果它不能及时做出反应,它可能会错失良机。

2.4. Lifetime of a Liaison Statement
2.4. 联络声明的有效期

A liaison statement is a temporary document, much like an internet draft. If it affects IETF output, the normal expectation is that the resulting RFC will contain relevant information that remains pertinent. Retaining liaison statements that have been completely dealt with mostly serves to hide new ones and create the appearance of not dealing with them.

联络声明是一份临时文件,很像互联网上的草案。如果影响IETF输出,通常预期结果RFC将包含仍然相关的相关信息。保留已经完全处理过的联络声明主要是为了隐藏新的联络声明,并造成不处理这些声明的外观。

However, unlike an internet draft, liaison statements are often the only record the IETF has of the communication with the peer SDO. As such, some liaison statements are referred to for relatively long periods of time.

然而,与互联网草案不同,联络声明通常是IETF与对等SDO通信的唯一记录。因此,一些联络声明被提及的时间相对较长。

As a result, the IETF will archive liaison statements that have been fully dealt with, along with any attachments that may have been relevant, but do so in a manner obviously distinct from current liaison statements.

因此,IETF将归档已充分处理的联络声明以及可能相关的任何附件,但归档方式明显不同于当前的联络声明。

3. Tools for Handling Liaison Statements
3. 处理联络声明的工具

Some tools have been developed for the IETF. Development is expected to continue. This section describes the basic tool and its intended use.

已经为IETF开发了一些工具。预计发展将继续。本节介绍基本工具及其预期用途。

3.1. Liaison Statements from Other SDOs, Consortia, and Fora to IETF
3.1. 其他SDO、财团和论坛向IETF的联络声明

The process of handling a liaison statement is more weighty than handling a business letter because it is important to a relationship with another SDO established by the IAB. To manage liaison statements, the IETF will offer three electronically accessible facilities: a form for submission of liaison statements, a mechanism organizing their contents and making them accessible, and a tracking

处理联络声明的过程比处理商业信函更重要,因为这对于与IAB建立的另一SDO的关系很重要。为了管理联络声明,IETF将提供三种电子可访问设施:一种提交联络声明的表格,一种组织其内容并使其可访问的机制,以及一种跟踪机制

system. Initially, the tracking system will be a manual procedure used by the liaison manager; in the future, this should be automated.

系统最初,跟踪系统将是联络经理使用的手动程序;将来,这应该是自动化的。

3.1.1. Liaison Statement Submission
3.1.1. 提交联络声明

The IETF Secretariat will provide an electronic method for submission of liaison statements.

IETF秘书处将提供提交联络声明的电子方法。

The liaison statement submission mechanism is a form that requests the information listed in Section 2.2.1 from the user.

联络声明提交机制是要求用户提供第2.2.1节所列信息的表格。

Submission of that information results in the following actions:

提交该信息将导致以下行动:

o creation of a display mechanism containing the envelope data in Section 2.2.1.1 and URLs pointing to the items from Section 2.2.1.2, an indication whether the liaison statement has been replied to, and if so, on what date,

o 创建一个显示机制,其中包含第2.2.1.1节中的信封数据和指向第2.2.1.2节中项目的URL,指示是否已回复联络声明,如果已回复,日期是什么,

o the addition of a URL to the "outstanding liaison statements" summary mechanism,

o 在“未决联络声明”摘要机制中添加URL,

o when an automated tracking system has been implemented, a tickler/ status entry in the tracking system, assigned to the relevant chair or AD,

o 当实施了自动跟踪系统时,跟踪系统中分配给相关主席或广告的备忘录/状态条目,

o an email to the assignee copying

o 发送给受让人的电子邮件

* the liaison statement's technical contacts

* 联络声明的技术联系

* The supervisor of the assignee (if it is to a WG, the relevant ADs; if to an AD, the IETF Chair),

* 受让人的监督人(如果是工作组,则为相关ADs;如果是AD,则为IETF主席),

* The liaison manager for the sending SDO,

* 发送SDO的联络经理,

* an alias associated with the assignee (WG/BOF or other open mailing list, Area Directorate, IESG, IAB, etc.)

* 与受让人相关的别名(WG/BOF或其他公开邮件列表、地区董事会、IESG、IAB等)

This email should contain the URL to the liaison statement mechanism, text indicating that the liaison statement has arrived, requests appropriate consideration, and if a deadline is specified, a reply by the deadline.

此电子邮件应包含联络声明机制的URL、表明联络声明已送达的文本、要求适当考虑的文本,以及如果指定了截止日期,则在截止日期前回复。

The assignee has the capability of interacting with the liaison manager and the tracking system (once implemented), including replying, changing dates, reassignment, closing the liaison statement process, etc.

受让人具有与联络经理和跟踪系统(一旦实施)互动的能力,包括回复、更改日期、重新分配、结束联络声明流程等。

The liaison manager or tracking system's "tickle" function periodically reminds the assignee by email that the liaison statement has not yet been closed. This tickle email copies all of the above except the associated mailing alias.

联络经理或跟踪系统的“挠痒”功能通过电子邮件定期提醒受让人联络声明尚未结束。此电子邮件复制了除相关邮件别名之外的所有上述内容。

3.1.2. Mechanism for Displaying Liaison Statements
3.1.2. 显示联络声明的机制

The IETF site contains a section for current liaison statement activity. This consists of:

IETF网站包含当前联络声明活动部分。这包括:

o A submission mechanism,

o 提交机制,

o A status/management mechanism for each active or recently closed liaison statement, and zero or more associated files.

o 每个活动或最近结束的联络声明的状态/管理机制,以及零个或多个相关文件。

The status/management mechanism contains a simple frame, showing the title of the liaison statement, the URL for its mechanism, and the organizations it is from and to.

状态/管理机制包含一个简单的框架,其中显示了联络声明的标题、其机制的URL以及它来自和前往的组织。

The display for liaison statement itself contains:

联络声明本身的显示包括:

o the liaison statement envelope information (Section 2.2.1),

o 联络声明信封信息(第2.2.1节),

o direct content (Section 2.2.1),

o 直接内容(第2.2.1节),

o URLs for the various associated files

o 各种关联文件的URL

o current status of the liaison statement: to whom it is assigned, its due date, and its status,

o 联络声明的当前状态:被分配给谁、到期日期和状态,

o pointer to the liaison manager and tracking system entry for the liaison statement.

o 指向联络经理的指针,以及联络声明的跟踪系统条目。

o reply-generation mechanism (see Section 3.2.2.4)

o 回复生成机制(见第3.2.2.4节)

3.2. Communicating IETF Information to Other SDOs, Consortia, and Fora
3.2. 将IETF信息传达给其他SDO、联盟和论坛

This includes liaison statements sent in reply to liaison statements sent by other bodies, and liaison statements being originated by the IETF.

这包括回复其他机构发送的联络声明而发送的联络声明,以及IETF发起的联络声明。

3.2.1. Spontaneously Generating Liaison Statements to Other Organizations

3.2.1. 自动生成与其他组织的联络声明

Liaison Statements 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

联络声明可以在工作组、区域或IETF级别生成,并发送给其他组织。各(共同)主席负责判断发送特定文件的共识程度

liaison statement and deciding the content. The amount of consensus required to send a liaison statement varies greatly depending on its content. This section gives some rough guidance about how much consensus should be sought before sending a liaison statement to another organization.

联络声明并决定内容。发送联络声明所需的共识数量因其内容的不同而大不相同。本节提供了一些粗略的指导,说明在向另一个组织发送联络声明之前应寻求多少共识。

3.2.1.1. Transmitting IETF Documents to Other Organizations
3.2.1.1. 向其他组织传输IETF文件

The simplest case of approving sending of a liaison statement from IETF is when the information 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. Any Standards Track RFC (Draft Standard, Proposed Standard, Internet Standard, BCP), and any WG document expected to be placed on the standards track, may be transmitted without concern.

批准从IETF发送联络声明的最简单情况是,所传输的信息由IETF文件组成,该文件在IETF内具有一定程度的一致性。该文件为实现其目前地位已经经历的过程确保了必要的协商一致。任何标准跟踪RFC(标准草案、拟定标准、互联网标准、BCP)和任何预期将被置于标准跟踪的工作组文件均可在无需担心的情况下传输。

Informational documents may also be exchanged readily when they represent a WG position or consensus, such as a requirements or architecture document.

当信息性文件代表工作组的立场或共识时,如需求或架构(architecture)文件,也可以随时交换。

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

在所有情况下,必须适当记录文档状态。在工作组互联网草案的情况下,必须明确的是,草案的存在仅表明工作组已接受工作项,并且,正如标准免责声明所述,实际内容只能被视为正在进行的工作。

Individually submitted Internet Drafts, Experimental or Historical RFCs, and non-WG informational documents 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.

单独提交的互联网草案、实验性或历史性RFC以及非工作组信息性文件,在未在相关小组内形成进一步共识的情况下,不得传播,因为这些文件不能真实地表示为任何IETF立场。

3.2.1.2. Requests for Information
3.2.1.2. 索取资料

Another type of liaison statement 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 statement when they recognize, from the activities of the group, that some additional information is helpful, for example, to resolve an impasse (i.e., don't waste time arguing over what the real meaning or intent of another SDOs document is, just ask the other SDO and base further work on the "official" answer).

另一种不需要在电子邮件列表上建立广泛共识就可以生成的联络声明是信息请求。当(共同)主席从小组的活动中认识到一些额外的信息有助于解决僵局(即,不要浪费时间争论另一个SDO文件的真正含义或意图是什么,只需询问另一个SDO并根据该文件开展进一步工作)时,他们可以生成这样的联络声明“官方”回答)。

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

其他信息请求可能要求访问其他组织未公开的某些文件。

3.2.1.3. Requesting Comments on Work in Progress
3.2.1.3. 请求对正在进行的工作提出意见

There may be cases when one feels that a document under development in the IETF may benefit from the input of experts in another relevant 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 WG Internet Draft and some level of consensus should be reached on the WG or other open mailing list that it is appropriate to ask another organization for comments on an IETF draft.

在某些情况下,人们可能会认为IETF中正在开发的文件可能会从另一个相关SDO、联合体或论坛的专家投入中受益。一般来说,这是在文本“完全煮熟”之前完成的,以便在最终结果中包含来自另一个组织的专家的输入。通常会征求对标准跟踪工作组互联网草案的意见,并应就工作组或其他公开邮件列表达成某种程度的共识,以便向其他组织征求对IETF草案的意见。

3.2.1.4. Requests for Other Actions (Besides Comments on IETF Drafts)
3.2.1.4. 其他行动请求(除了对IETF草案的评论)

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

其他组织可能会合理地要求采取许多其他类型的行动:

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

o 如果在另一个组织中存在重叠或相关工作,可以请求另一个组织更改某些内容以与IETF工作保持一致。

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

o 可以请求另一个组织启动一个新的工作项(代表IETF)。

o 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).

o 可以请求其他组织停止某个工作项(可能是因为它与IETF中的其他工作重叠或冲突)。

These kinds of requests are quite serious. They can certainly be made when appropriate, but should only be made when there is the clearest possible consensus within the particular WG, Area, or within the IETF at large.

这类要求相当严重。它们当然可以在适当的时候做出,但只有在特定工作组、领域或整个IETF内达成最明确的共识时才能做出。

3.2.2. Responding to Incoming Liaison Statements
3.2.2. 对收到的联络声明作出答复

Any incoming liaison statement that indicates that it is for "Comment" or for "Action" requires a response by the deadline; other liaison statements may also be replied to, although a reply is generally optional. It is the responsibility of the (co)chair(s) of the addressed organization to ensure that a response is generated by the deadline.

任何表示“评论”或“行动”的新的联络声明都需要在截止日期前作出答复;也可以对其他联络声明作出答复,尽管答复通常是可选的。所述组织的(共同)主席有责任确保在截止日期前做出响应。

3.2.2.1. Responding to Requests for Information
3.2.2.1. 回应索取资料的要求

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

如果另一个组织要求提供第3.2.1.1节所述类型的IETF文件中的信息,则该信息可由所述小组的(共同)主席发送,表明相关文件的一致性水平。

3.2.2.2. Responding to Requests for Comments
3.2.2.2. 答复征求意见的请求

If an incoming liaison statement 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 statement back to the originating organization.

如果从对邮件列表的评论模式中可以明显看出有明确的共识,(共同)主席可以在回复联络声明中总结结论,并返回给发起组织。

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

如果从邮件列表上的评论模式中看不出明确的共识,或者如果没有进一步的讨论,则仍应向发起者作出答复。应创建电子邮件评论摘要,或对问题缺乏兴趣,并发送给发起人,并将其表示为“收集的评论”,而不是联络声明所针对的IETF小组的共识。即使某些评论相互矛盾,也可以发送此类回复。

3.2.2.3. Responding to Request for Action
3.2.2.3. 对行动请求的答复

A request for Action is a fairly serious thing. Examples of the kinds of actions that may be expected are:

请求采取行动是一件相当严肃的事情。可预期的行动类型示例如下:

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

o 如果在另一个组织中存在重叠或相关工作,另一个组织可要求IETF将其工作与另一个组织的工作相一致。

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

o 可以请求IETF承担新的工作项目。

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

o 可以请求IETF停止工作项(可能是因为它与发起组织中的其他工作重叠或冲突)。

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.

显然,IETF内接收小组的一致意见对于满足请求是必要的。完成请求可能需要大量时间和多个步骤,例如,如果启动或停止工作项需要更改章程。

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.

当然,没有要求IETF执行所请求的操作。但这一请求应始终得到认真对待,并需要作出回应。如果IETF决定响应请求做什么,则必须始终通知发起组织。如果IETF决定不履行该请求,或通过修改履行该请求,则响应应包括原因以及替代行动方案(如适用)。

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
3.2.2.4. 生成联络声明

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.

IETF参与者,通常是工作组主席、广告或其他官员,需要能够向其他SDO发送联络声明。第3.1.2节中描述的机制,列出了IAB与之建立联络关系的其他SDO中的适当联系人,提供了这种能力。

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

为方便起见,可使用第3.1.2节所述的联络声明页面生成回复。如果一个人(通常是工作组主席或广告)选择“回复”,则会从现有的联络声明页面生成一个新的联络声明页面,从而颠倒地址信息。IETF文档应通过URL引用,例如http://www.ietf.org/internet-drafts/>文件<或ftp://ftp.rfc-editor.org/in-notes/>文件<。

The process of generating and approving transmission of liaison statements is a matter of IETF process and is specified in [RFC4052].

联络声明的生成和批准传输过程属于IETF过程,并在[RFC4052]中规定。

4. Security Considerations
4. 安全考虑

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.

开发此过程的一个关键考虑因素是IETF及其过程可能遭受拒绝服务攻击。从历史上看,IETF并不总是有效地处理联络声明,导致在其他组织工作的人员对其感到沮丧。各组织还利用联络声明程序对IETF活动施加最后期限,这让所有相关方都感到沮丧——IETF因为不接受这样的最后期限,而其他组织因为感觉被忽视。

For this reason the submission process is automated. While the IETF cannot rate-limit the submitters, it can manage its internal pipelines.

因此,提交过程是自动化的。虽然IETF不能对提交者进行速率限制,但它可以管理其内部管道。

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.

由于提交者缺乏任何身份验证,这一问题更加严重。然而,IAB认为无论是否存在联络关系,都必须能够接受联络声明,因此,对提交人的认证不是一种有效的控制。

5. Acknowledgements
5. 致谢

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.

本文是由IETF和其他SDO和论坛中的许多个人讨论而产生的,包括Gary Fishman和Bert Wijnen。它是与[RFC4052]合作开发的,也就是说,与IAB主席Leslie Daigle明确合作。在协调ITU-T研究组15和IETF子IP领域的工作方面的个人经验和一些“失误”也推动了这项工作。一些解决个别问题的草案(例如,RFC 3427)明确指出,与外部组织打交道需要更通用、一致的解决方案。从这些文本中借用了某些观点。

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.

Barbara Fuller、Sunny Lee和Michael Lee开发了一个原型,并对文档进行了详细的评论。他们的投入直接导致了描述实施路线图的附录。

Appendix A. Implementation Road Map
附录A.实施路线图

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. 第一阶段:初步实施
A.1.1. Displays
A.1.1. 显示

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

第3.1.1节和第3.1.2节中对所需显示器的描述要求两套显示器:一套供公众使用(用于查看联络声明),另一套供提交人使用(用于管理联络声明)。

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 一个联络声明网页,列出所有传入和传出的联络声明(具体字段待定)。每份联络声明的标题是该联络声明详情页面的链接。

o A detail page for each liaison statement that contains:

o 每个联络声明的详细页,包括:

* All of the information specified in the subsections of Section 2.2.1.

* 第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:

o 提供以下机制的摘要页面:

* 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 用于创建和提交联络声明的模板。该模板允许用户输入第2.2.1节中规定的信息。用户可以随时访问模板(从用户先前创建和提交的联络声明列表中),并更新和重新提交信息。

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:

o 用于管理分配给用户的联络声明的详细页面。此页面类似于公众可用的详细信息页面。但是,它还包括:

* 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
A.1.2. 关于提交的行动

Submission of a liaison statement results in the following actions:

提交联络声明会导致以下行动:

o The information is uploaded to the database.

o 信息被上传到数据库。

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 将包含第3.1.1节规定内容的电子邮件发送给收件人,并将副本发送至第4.1节规定的地址和秘书处(如[RFC4052]中规定)。

o The liaison statement is added to the list on the Liaison Statements Web page.

o 联络声明将添加到联络声明网页上的列表中。

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

o 为联络声明创建了两个详细页面:一个供公众查看联络声明,另一个供发送方和受让方管理联络声明。

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

如第3.2.2.4节所述,当用户在联络声明的详细信息页面上选择“回复”时,将从现有的模板生成一个用于创建和提交新联络声明的模板,该模板将“从”复制到“到”,并将响应者指定为“来自”的个人。提交本回复联络声明将导致与提交任何新联络声明相同的行动。此外,在原始联络声明(即用户回复的联络声明)的详细页(公众和管理层)上的相关联络声明列表中添加了指向本联络声明详细页的链接。

Appendix B. Phase II: Additional Instrumentation and Responses to Usage Experience

附录B第二阶段:附加仪器和对使用经验的响应

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:

第3.1节讨论了未来联络声明跟踪系统的预期功能。这些机制包括:

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 指定受让人;受让人最初是与联络声明所针对的机构(IAB、IESG、Area、WG等)相关的人员,但随后可能会被IETF参与者变更。

o Indicating the status of the liaison statement (e.g., actions required, actions taken, etc. Specific options TBD).

o 说明联络声明的状态(例如,所需的行动、采取的行动等,具体选项待定)。

o Sending ticklers to the assignee when action is required (with copies to whomever is appropriate).

o 当需要采取行动时,向受让人发送备忘录(并将副本发送给任何合适的人)。

o Changing the status of the liaison statement, the deadline, or other attributes.

o 更改联络声明的状态、截止日期或其他属性。

o Reassigning responsibility.

o 重新分配责任。

o Closing the liaison statement.

o 结束联络声明。

Normative References

规范性引用文件

[RFC4052] Daigle, L., "IAB Processes for Management of Liaison Relationships", RFC 4052, April 2005.

[RFC4052]Daigle,L.,“IAB联络关系管理流程”,RFC 4052,2005年4月。

Authors' Addresses

作者地址

Stephen J. Trowbridge Lucent Technologies 1200 West 120th Avenue, Suite 232, Room 34Z07 Westminster, Colorado 80234-2795 USA

Stephen J.Trowbridge-Lucent Technologies美国科罗拉多州威斯敏斯特市西120大道1200号232室34Z07室80234-2795

   Phone: +1 303 920 6545
   Fax:   +1 303 920 6553
   EMail: sjtrowbridge@lucent.com
        
   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

斯科特·布拉德纳哈佛大学29牛津圣剑桥,马萨诸塞州02138

   Phone: +1 617 495 3864
   Fax:   +1 617 492 8835
   EMail: sob@harvard.edu
        
   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

Fred Baker Cisco Systems 1121 Via Del Rey Santa Barbara,加利福尼亚州93117

   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   EMail: fred@cisco.com
        
   Phone: +1-408-526-4257
   Fax:   +1-413-473-2403
   EMail: fred@cisco.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2005).

版权所有(C)互联网协会(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.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

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.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和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.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为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.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。