Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6293 VPN Consortium
Category: Informational June 2011
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6293 VPN Consortium
Category: Informational June 2011
ISSN: 2070-1721
Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker
数据跟踪器中IETF社区对互联网草案跟踪的要求
Abstract
摘要
The document gives a set of requirements for extending the IETF Datatracker to give individual IETF community members, including the IETF leadership, easy methods for tracking the progress of the Internet-Drafts and RFCs of interest to them.
本文件给出了一系列扩展IETF数据跟踪器的要求，以向各个IETF社区成员（包括IETF领导层）提供跟踪互联网草案进度的简便方法以及他们感兴趣的RFC。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6293.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6293.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context for This Document . . . . . . . . . . . . . . . . 4
1.3. Definitions Used in This Document . . . . . . . . . . . . 5
1.4. Expected User Interactions . . . . . . . . . . . . . . . . 6
2. Requirements for Tools Features . . . . . . . . . . . . . . . 6
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 6
2.1.2. Requirement: Every Datatracker user can create one
list . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Requirement: Read-only views of private lists can
be made visible to others . . . . . . . . . . . . . . 7
2.1.4. Requirement: The Datatracker must support optional
publicly-readable lists for WGs and Area Directors . . 7
2.1.5. Requirement: Specifying the I-Ds and RFCs that are
in a list must be simple . . . . . . . . . . . . . . . 8
2.1.6. Requirement: Adding groups of I-Ds to a list by
attribute must be simple . . . . . . . . . . . . . . . 8
2.1.7. Requirement: Private information must not be
exposed in lists . . . . . . . . . . . . . . . . . . . 9
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Requirement: Users can be notified when an I-D
changes status . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 10
2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 10
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 10
2.3.1. Requirement: Users can define their Datatracker
document view . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Requirement: Users can flag I-Ds with dates in the
future . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Requirement: Users can specify highlighting of
I-Ds and RFCs with recent changes . . . . . . . . . . 12
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Requirement: Users can get their current list as a
single file . . . . . . . . . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. Informative References . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context for This Document . . . . . . . . . . . . . . . . 4
1.3. Definitions Used in This Document . . . . . . . . . . . . 5
1.4. Expected User Interactions . . . . . . . . . . . . . . . . 6
2. Requirements for Tools Features . . . . . . . . . . . . . . . 6
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 6
2.1.2. Requirement: Every Datatracker user can create one
list . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Requirement: Read-only views of private lists can
be made visible to others . . . . . . . . . . . . . . 7
2.1.4. Requirement: The Datatracker must support optional
publicly-readable lists for WGs and Area Directors . . 7
2.1.5. Requirement: Specifying the I-Ds and RFCs that are
in a list must be simple . . . . . . . . . . . . . . . 8
2.1.6. Requirement: Adding groups of I-Ds to a list by
attribute must be simple . . . . . . . . . . . . . . . 8
2.1.7. Requirement: Private information must not be
exposed in lists . . . . . . . . . . . . . . . . . . . 9
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Requirement: Users can be notified when an I-D
changes status . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 10
2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 10
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 10
2.3.1. Requirement: Users can define their Datatracker
document view . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Requirement: Users can flag I-Ds with dates in the
future . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Requirement: Users can specify highlighting of
I-Ds and RFCs with recent changes . . . . . . . . . . 12
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.1. Requirement: Users can get their current list as a
single file . . . . . . . . . . . . . . . . . . . . . 12
3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A. Possible Tracking of Other Data . . . . . . . . . . . 15
A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15
A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
A.3. Tracking Changes in the Liason Statement Directory . . . . 15
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 15
A.5. Tracking Additions to the IPR Statement Repository . . . . 16
Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16
Appendix A. Possible Tracking of Other Data . . . . . . . . . . . 15
A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15
A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
A.3. Tracking Changes in the Liason Statement Directory . . . . 15
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 15
A.5. Tracking Additions to the IPR Statement Repository . . . . 16
Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16
The IETF Datatracker is used by many IETF community members to find the status of Internet-Drafts (I-Ds) and RFCs, and view I-Ds and RFCs that meet particular criteria. The current Datatracker, found at <https://datatracker.ietf.org/>, allows anyone to search for active I-Ds and RFCs, and get a list matching the given criteria. (The Datatracker also allows for expired I-Ds, but those are not relevant to this discussion.)
许多IETF社区成员使用IETF数据跟踪器查找Internet草稿（I-D）和RFC的状态，并查看符合特定标准的I-D和RFC。当前数据跟踪器，位于<https://datatracker.ietf.org/>，允许任何人搜索活动的ID和RFC，并获得与给定条件匹配的列表。（Datatracker还允许过期的I-D，但与本讨论无关。）
Users can search in the Datatracker by the filename of the I-D, words in the I-D title, I-D author list, associated Working Group (WG), IETF area, the responsible Area Director (AD), or IESG status. They can search for RFCs by number or words in the title. The returned list of I-Ds and/or RFCs includes six columns: filename or RFC number, the document's title, the date it was published, its status in the IETF or RFC process, IPR statements, and the responsible AD (if any).
用户可以通过I-D文件名、I-D标题中的单词、I-D作者列表、相关工作组（WG）、IETF区域、负责区域主管（AD）或IESG状态在Datatracker中搜索。他们可以通过标题中的数字或单词搜索RFC。返回的I-D和/或RFC列表包括六列：文件名或RFC编号、文件标题、发布日期、在IETF或RFC过程中的状态、IPR声明和责任广告（如有）。
Instead of using the search capability of the Datatracker to manually find I-Ds and RFCs of interest, users might want to create a list of I-Ds that they normally follow. Some users will want to keep their list to themselves, but others will want to allow others to view their list.
用户可能希望创建一个他们通常遵循的I-D列表，而不是使用Datatracker的搜索功能手动查找感兴趣的I-D和RFC。有些用户希望自己保存自己的列表，但其他用户希望允许他人查看自己的列表。
Different users in the IETF community will have different ways that they want to get information on I-D and RFC updates and status. Many users will want to be notified immediately, such as through an Atom feed (see [RFC4287]) or automatically-generated email. Many users will want to only find out about updates when they go to a Web page. Many users might want to get the data for a list as input to other tools. And, of course, some users will want all three. All of these assist users in tracking I-Ds through their lifecycle.
IETF社区中的不同用户将以不同的方式获取有关I-D和RFC更新和状态的信息。许多用户希望立即收到通知，例如通过Atom提要（请参见[RFC4287]）或自动生成的电子邮件。许多用户只想在访问网页时了解有关更新的信息。许多用户可能希望获取列表的数据作为其他工具的输入。当然，有些用户会想要这三个。所有这些都有助于用户在其生命周期中跟踪I-D。
The main motivation for these proposed changes to the Datatracker is to allow a variety of potential users to be able to track I-Ds and RFCs, and thus be better able to see when important events happen. A few examples include:
对Datatracker进行这些拟议更改的主要动机是允许各种潜在用户能够跟踪I-D和RFC，从而更好地看到重要事件何时发生。一些例子包括：
o A WG chair might want to keep a list of all the I-Ds from other WGs that relate to active I-Ds in his or her WG.
o 工作组主席可能希望保留一份与他或她的工作组中的活动I-D相关的其他工作组所有I-D的列表。
o That same WG chair might want to help WG members be able to follow the same I-Ds that he or she is following.
o 同一个工作组主席可能希望帮助工作组成员能够遵循他或她正在遵循的相同ID。
o Someone who cares about an established topic such as the DNS may want to follow the various I-Ds that might make changes to the DNS, as well as be aware if any of the DNS RFCs are later updated and/or have errata posted against them. This would include not only I-Ds that are in the many WGs that directly are changing the DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual submissions, IAB I-Ds, IRTF I-Ds, and Independent submissions.
o 关心已建立的主题（如DNS）的人可能希望了解可能对DNS进行更改的各种I-D，并了解是否有任何DNS RFC稍后更新和/或发布了针对它们的勘误表。这不仅包括直接更改DNS的许多工作组中的I-D（DNSEXT、DNSOP、BEFORM等），还包括个人提交、IAB I-D、IRTF I-D和独立提交。
o Developers who are not active in the IETF process might want to lightly follow I-Ds and RFCs on a particular topic to watch for things that might affect their implementations.
o 在IETF过程中不活跃的开发人员可能希望在特定主题上轻松地遵循I-Ds和RFC，以观察可能影响其实现的事情。
o An IETF "regular" might want to follow parts of the process by focusing on all the I-Ds that are being shepherded by a particular Area Director.
o IETF“常客”可能希望通过关注由特定区域主管指导的所有I-D来遵循部分流程。
This document describes the requirements for extending the Datatracker for such capabilities. When complete, this document may be used to issue an RFP for the design and development of these enhancements to the Datatracker.
本文档描述了扩展Datatracker以实现此类功能的要求。完成后，本文件可用于发布设计和开发Datatracker增强功能的RFP。
Some of the requirements in this document are listed as "later requirements". It is expected that items listed in this document would be part of the initial RFP because they provide the highest benefit to the community; the later requirements might be part of a later RFP.
本文件中的一些要求被列为“后续要求”。预计本文件中列出的项目将成为初始RFP的一部分，因为它们为社区提供了最高的利益；后续要求可能是后续RFP的一部分。
The initial general requirements that led to the specific requirements this document described tools that include:
导致本文件所述特定要求的初始一般要求包括：
o the ability to create one or more (possibly large) lists of I-Ds that community members want to follow
o 能够创建一个或多个社区成员希望遵循的I-D列表（可能较大）
o the ability to get notifications when particular I-Ds from a list change state
o 当列表中的特定I-D更改状态时获取通知的能力
o the ability to see all of the state changes that have occurred on all the I-Ds in a list over a specified range of dates
o 能够查看在指定日期范围内列表中所有I-D上发生的所有状态更改
o the ability to set the granularity of the changes (such as "every change", "just approvals and publication", and so on)
o 设置更改粒度的能力（例如“每次更改”、“仅批准和发布”等）
o the ability to organize views of a list in many fashions that would be useful to different types of community members
o 能够以多种方式组织列表视图，这对不同类型的社区成员很有用
o the ability to share and merge lists with other community members
o 与其他社区成员共享和合并列表的功能
Note that [RFC2026] describes the process that I-Ds go through before they either become RFCs or are abandoned. The Datatracker does not control this process: instead, it simply reports on the current state of each I-D as it goes through the process.
请注意，[RFC2026]描述了I-D在成为RFC或被放弃之前所经历的过程。Datatracker不控制这个过程：相反，它只是在每个I-D通过该过程时报告其当前状态。
A "user" is an individual person who is a member of the IETF community.
“用户”是指作为IETF社区成员的个人。
A "list" is an unordered set of RFCs, I-Ds, and groups of I-Ds. Lists are specified by users. In some cases, the authors are role-based, such as a WG chair being the specifier of the list associated with that WG.
“列表”是一组无序的RFC、I-D和I-D组。列表由用户指定。在某些情况下，作者是基于角色的，例如工作组主席是与该工作组相关的列表的指定人。
An "attribute" is a feature of an I-D or RFC, such as its filename or RFC number, its current state in the IETF or RFC process, and so on. Attributes are usually displayed as columns in the Datatracker.
“属性”是I-D或RFC的特征，例如其文件名或RFC编号、其在IETF或RFC过程中的当前状态，等等。属性通常在Datatracker中显示为列。
A "row" is a set of attributes about a single I-D or RFC that is displayed in the Datatracker.
“行”是关于在Datatracker中显示的单个I-D或RFC的一组属性。
A "significant change in status" is all approvals and disposition of an I-D. Assuming that the changes to the Datatracker specified in [RFC6174], [RFC6175] and [ALTSTREAMS] are made, "all approvals" means the following:
“状态的重大变化”是指身份证的所有批准和处置。假设[RFC6174]、[RFC6175]和[ALTSTREAMS]中规定的数据跟踪器发生了变化，“所有批准”是指：
o IETF stream: the WG states "Adopted by a WG", "In WG Last Call", "WG Consensus: Waiting for Write-up", "Parked WG document", and "Dead WG document"; the IESG states "Publication Requested", "In Last Call", "IESG Evaluation", and "Sent to the RFC Editor"
o IETF流：工作组声明“工作组通过”、“工作组最后一次通话中”、“工作组共识：等待编写”、“暂停工作组文件”和“死工作组文件”；IESG声明“已请求发布”、“在上次通话中”、“IESG评估”和“发送给RFC编辑”
o IAB stream: "Active IAB Document", "Community Review", and "Sent to the RFC Editor"
o IAB流：“活动IAB文档”、“社区评论”和“发送到RFC编辑器”
o IRTF stream: "Active RG Document", "In RG Last Call", "Awaiting IRSG Reviews", "In IESG Review", "Sent to the RFC Editor", and "Document on Hold Based On IESG Request"
o IRTF流：“活动RG文档”、“在RG最后一次呼叫中”、“等待IRSG审核”、“在IESG审核中”、“发送给RFC编辑器”和“基于IESG请求的待决文档”
o ISE stream: "Submission Received", "In ISE Review", "In IESG Review", "Sent to the RFC Editor", and "Document on Hold Based On IESG Request"
o ISE流：“收到的提交”、“ISE评审中”、“IESG评审中”、“发送给RFC编辑”和“基于IESG请求的搁置文件”
o All streams: in addition to the above, the disposition states "Approved", "RFC Published", and "Dead" are also included
o 所有流：除上述内容外，还包括处置状态“已批准”、“已发布RFC”和“已终止”
An "update to an RFC" is the announcement of a newer RFC that updates or obsoletes the base RFC, an in-place change to the RFC's maturity level, the RFC's status being changed to historic, or an announcement of an errata posted for the base RFC.
“RFC更新”是指更新或淘汰基本RFC的更新RFC的公告、RFC成熟度级别的就地更改、RFC状态更改为历史状态或发布基本RFC的勘误表。
When a user wants to follow a group of I-Ds and/or RFCs, he or she goes to the Datatracker and creates a new list. The requirements for lists are given in Section 2.1. After a list is created, the user has three ways that he or she might see when I-Ds and/or RFCs in the list are updated:
当用户想要跟踪一组I-D和/或RFC时，他或她会转到Datatracker并创建一个新列表。清单要求见第2.1节。创建列表后，当更新列表中的I-D和/或RFC时，用户可能会看到三种方式：
o By going to the Datatracker page for the list (see Section 2.3)
o 通过转到Datatracker页面获取列表（参见第2.3节）
o By subscribing to the Atom feed for the list (see Section 2.2.2) in a feed reader that automatically fetches updates
o 通过订阅自动获取更新的提要阅读器中列表的Atom提要（参见第2.2.2节）
o By subscribing to the mail stream for the list (see Section 2.2.3) and reading the mail stream in their mail reader
o 通过订阅列表的邮件流（参见第2.2.3节）并在邮件阅读器中读取邮件流
This section defines the requirements for the tool described earlier in this document. The eventual tool, if implemented, may have more features than are listed here; however, before this document is finished, it should contain as many requirements as possible upon which the IETF community can agree.
本节定义了本文件前面所述工具的要求。如果实现，最终的工具可能比这里列出的功能更多；然而，在本文件完成之前，它应该包含IETF社区能够同意的尽可能多的要求。
An active IETF participant might want to follow the status of hundreds of I-Ds and dozens of RFCs; for example, some ADs have 100 I-Ds in their area. Additionally, they may also want to follow I-Ds outside their area that affect documents in their area.
活跃的IETF参与者可能希望跟踪数百个I-D和数十个RFC的状态；例如，一些广告在其区域内有100个ID。此外，他们还可能希望跟踪其区域外影响其区域内文档的I-D。
When a user gets a Datatracker account, that account comes with an empty list pre-defined. The list can normally be modified only by the owner of the account, although the Secretariat can also modify the list as part of its support role for the Datatracker. Each Datatracker user is restricted to having one list.
When a user gets a Datatracker account, that account comes with an empty list pre-defined. The list can normally be modified only by the owner of the account, although the Secretariat can also modify the list as part of its support role for the Datatracker. Each Datatracker user is restricted to having one list.translate error, please retry
In order for this requirement to be met, it must be easy for any community member to get a Datatracker account. Account setup must not involve any direct action on the part of the Secretariat. However, the Secretariat will be responsible for support of Datatracker accounts (lost passwords, odd interactions, and so on), so this addition of more Datatracker accounts will potentially increase the amount of work the Secretariat must do.
为了满足这一要求，任何社区成员都必须很容易获得Datatracker帐户。账户设置不得涉及秘书处的任何直接行动。但是，秘书处将负责支持Datatracker帐户（密码丢失、奇怪的交互等），因此，增加更多Datatracker帐户可能会增加秘书处必须做的工作。
The only person who can edit the contents of a private list is the person who knows the password to the account with which the list is associated.
唯一可以编辑私人列表内容的人是知道与列表关联的帐户密码的人。
2.1.3. Requirement: Read-only views of private lists can be made visible to others
2.1.3. 要求：私人列表的只读视图可以对其他人可见
Some users will want to make available a read-only view of their list. Each private list will have a URL that leads to the Datatracker view of the list; that URL must be able to be shared without giving others the ability to edit the list. Similarly, the Atom feed associated with a private list must be able to be shared without giving others the ability to edit the list.
有些用户希望提供其列表的只读视图。每个私有列表都有一个URL，该URL指向列表的Datatracker视图；该URL必须能够共享，而不允许其他人编辑列表。类似地，与私有列表关联的Atom提要必须能够共享，而不允许其他人编辑列表。
2.1.4. Requirement: The Datatracker must support optional publicly-readable lists for WGs and Area Directors
2.1.4. 要求：Datatracker必须支持WGs和区域控制器的可选公共可读列表
It is common in the IETF for users to follow the work of an entire WG, not just single I-Ds and RFCs within a WG. It is also very common that some work that is related to a WG happens outside the WG, either in other WGs or as individual efforts. Many WG chairs monitor this outside-the-WG activity for various reasons.
在IETF中，用户通常关注整个工作组的工作，而不仅仅是工作组中的单个I-D和RFC。与工作组相关的一些工作发生在工作组之外，或者在其他工作组中，或者作为个人努力，这也是很常见的。许多工作组主席出于各种原因在工作组活动之外监督这一点。
A smaller number of community members follow an entire Area's worth of topics. Again, these topics often happen within the WGs of an area, but not always; for example, some topics related to the Security Area happen in WGs in the Applications Area.
少数社区成员关注整个区域的主题。同样，这些主题经常发生在某个地区的工作组内，但并不总是如此；例如，一些与安全领域相关的主题出现在WGs中的应用程序领域。
Because of this, it would be useful for community members to be able to find a list that corresponds to the WGs or Areas in which they are interested. The WG lists could be maintained by the WG chairs; the Area lists would likely be maintained by the ADs. Note that such
因此，社区成员能够找到一份与其感兴趣的工作组或领域相对应的清单将是有益的。工作组名单可由工作组主席保存；区域列表可能由ADs维护。请注意
lists are not mandatory; for example, a WG chair might not choose to maintain such a list for a WG whose topic is extremely broad.
清单不是强制性的；例如，工作组主席可能不会选择为主题极其广泛的工作组保留这样一份清单。
Both Working Group chairs and Area Directors currently already have Datatracker accounts, so fulfilling this requirement only involves associating those accounts with the role that controls the list.
工作组主席和区域主管目前都已经拥有Datatracker帐户，因此满足此要求只需要将这些帐户与控制列表的角色关联。
2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list must be simple
2.1.5. 要求：指定列表中的I-D和RFC必须简单
When a user creates a new list, it must be easy to add single I-Ds and RFCs to the list. This could be done using the Datatracker's current search facility, and simply adding an "add to list" option to the display of searched-for I-Ds. Further, when editing an existing list, it must be easy to add additional I-Ds and RFCs, and it must be easy to remove I-Ds and RFCs from a list.
当用户创建一个新列表时，向列表中添加单个I-D和RFC必须很容易。这可以使用Datatracker当前的搜索功能来完成，只需在搜索到的I-D显示中添加一个“添加到列表”选项。此外，在编辑现有列表时，必须易于添加其他I-D和RFC，并且必须易于从列表中删除I-D和RFC。
2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must be simple
2.1.6. 要求：按属性向列表中添加I-D组必须很简单
I-Ds have many attributes, and some users might want to follow all of the I-Ds that have a particular attribute. Some, but not all, attributes have values that make sense in specifying lists. It should be easy to add each of the following attributes when adding to or editing a list:
I-D有许多属性，有些用户可能希望遵循所有具有特定属性的I-D。某些（但不是全部）属性的值在指定列表时有意义。在添加或编辑列表时，应易于添加以下每个属性：
o All I-Ds associated with an particular WG
o 与特定工作组相关的所有I-D
o All I-Ds associated with all WGs in an particular Area
o 与特定区域内所有工作组相关的所有I-D
o All I-Ds with a particular responsible AD
o 所有具有特定责任广告的I-D
o All I-Ds with a particular author
o 与特定作者的所有ID
o All I-Ds with a particular document shepherd
o 具有特定文档的所有I-D
o All I-Ds that have a reference to a particular RFC
o 引用特定RFC的所有I-D
o All I-Ds that have a reference to a particular I-D
o 引用特定I-D的所有I-D
o All I-Ds that are referenced by a particular RFC
o 特定RFC引用的所有I-D
o All I-Ds that are referenced by a particular I-D
o 由特定I-D引用的所有I-D
o All I-Ds that contain a particular text string
o 包含特定文本字符串的所有I-D
These attributes are dynamic, and thus the list of I-Ds that have a particular attribute will change after the user adds that attribute to a list. The Datatracker should update lists with dynamic attributes as often as is sensible for the server environment, such as once an hour or more.
这些属性是动态的，因此具有特定属性的I-D列表将在用户将该属性添加到列表中后更改。Datatracker应该在服务器环境中尽可能频繁地使用动态属性更新列表，例如每小时更新一次或更多。
Note that some of these attributes are based on heuristics derived by programs that parse I-Ds, and are therefore inherently not completely reliable.
请注意，其中一些属性基于解析I-D的程序派生的启发式，因此本质上并不完全可靠。
Any private information in the Datatracker must be excluded from any displays of the lists or mail streams. This private information includes private notes in the IESG balloting for an I-D, and probably other data that currently is restricted to being seen by certain members of the IETF leadership.
必须从列表或邮件流的任何显示中排除Datatracker中的任何私人信息。这些私人信息包括IESG I-D投票中的私人记录，以及目前仅限IETF领导层某些成员查看的其他数据。
Some users do not want to go to the Datatracker's display page to find out when an I-D or RFC has been updated. Instead, they want to be notified immediately after the change. The Datatracker needs to support this type of immediate notification, where "immediate" means within an hour of a change to any I-D or RFC in the list. This requirement can be met with Atom feeds and mail streams, as described in the next two sections.
一些用户不希望转到Datatracker的显示页面以了解I-D或RFC何时已更新。相反，他们希望在变更后立即得到通知。Datatracker需要支持这种类型的即时通知，“即时”是指列表中任何I-D或RFC更改后一小时内。Atom提要和邮件流可以满足这一要求，如下面两节所述。
The Datatracker might create a generic "notifications engine" that can be used to generate the Atom feeds and mail streams. This engine can then be used to later add other notification types, such as a Jabber feed.
Datatracker可能会创建一个通用的“通知引擎”，用于生成Atom提要和邮件流。该引擎随后可用于添加其他通知类型，如Jabber提要。
The list will have two Atom feeds that are generated from the changes to the list: one for every change in status and another for significant change of status. Each Atom feed will have a stable URL that can be used by feed readers.
列表将有两个Atom提要，它们是从列表的更改生成的：一个用于状态的每次更改，另一个用于状态的重大更改。每个Atom提要都有一个稳定的URL，供提要阅读器使用。
Many IETF users are already using Atom feeds created by the IETF Tools Team for single I-Ds. Using the new feeds for lists described here will allow them to have better selection capabilities to reduce the number of feeds they need to follow.
许多IETF用户已经在使用IETF工具团队为单个I-D创建的Atom提要。使用这里描述的列表的新提要将允许他们具有更好的选择功能，以减少他们需要遵循的提要数量。
A user can subscribe to two mail streams that are generated from the changes to the list: one for every change in status, and another for significant change of status.
用户可以订阅列表更改生成的两个邮件流：一个用于状态的每次更改，另一个用于状态的重大更改。
Note that the mail streams are for each change; they are not batched (such as one message per day). Users who want less frequent but batched notifications need to use the Atom feeds instead of the mail streams.
请注意，邮件流用于每个更改；它们不是批处理的（例如每天一条消息）。想要不太频繁但批量通知的用户需要使用Atom提要而不是邮件流。
2.2.4. Requirement: Notifications need to specify which list caused the notification
2.2.4. 要求：通知需要指定导致通知的列表
Users might have feeds and/or subscriptions to multiple lists. In order to disambiguate duplicate notifications from multiple lists, the body of the message in the Atom feed or mail stream needs to say which list generated the notification. (Ideally, a user who wants notifications will make one list based on multiple lists, but if they subscribe to multiple lists, this requirement will at least suggest to them that they want to limit their overlapping subscriptions.)
用户可能有多个列表的提要和/或订阅。为了消除多个列表中重复通知的歧义，Atom提要或邮件流中的消息体需要说明哪个列表生成了通知。（理想情况下，需要通知的用户将基于多个列表创建一个列表，但如果他们订阅多个列表，此要求至少会向他们建议，他们希望限制其重叠订阅。）
There are many ways that a user might want to see the Datatracker's HTML view of a list. For example, a user might want the view displayed in alphabetical order by the I-Ds' filenames and RFC numbers, but after the user is off the net for a week, he or she might want the view displayed in order of changes of status so that those I-Ds and RFCs changed recently appear at the top.
用户可能希望通过多种方式查看Datatracker的列表HTML视图。例如，用户可能希望视图按I-Ds文件名和RFC编号的字母顺序显示，但在用户离开网络一周后，他或她可能希望视图按状态更改的顺序显示，以便最近更改的I-Ds和RFC显示在顶部。
The default is to list I-Ds in alphabetical order by I-D filename, with RFCs at the end. When displaying a list, the Datatracker should allow easy sorting of the I-Ds with the following collation orders:
默认情况下，按I-D文件名的字母顺序列出I-D，最后是RFC。显示列表时，Datatracker应允许使用以下排序顺序轻松排序I-D：
o Alphabetical by I-D filename and RFC number
o 按I-D文件名和RFC编号按字母顺序排列
o Alphabetical by document title
o 按文件标题字母顺序排列
o Alphabetical by associated WG
o 按字母顺序排列
o Date of publication of current version of the document
o 文件当前版本的发布日期
o Date of most recent change of status of any type
o 任何类型的状态最近更改的日期
o Date of most recent significant change of status
o 最近状态发生重大变化的日期
In displays, a particular I-D or RFC should only be included once; for example, if someone manually adds draft-ietf-cuteacronym-sometopic to his list and also specifies that all I-Ds from the "cuteacronym" WG are included in the list, that I-D should only appear once in the display. The column saying which included list(s) contain this I-D helps alleviate this loss of information.
在显示器中，特定的I-D或RFC只应包括一次；例如，如果有人手动将草案ietf CuteAronym sometopic添加到他的列表中，并指定“CuteAronym”工作组中的所有I-D都包含在列表中，则该I-D只应在显示中出现一次。说明哪些包含列表包含此ID的列有助于减少信息丢失。
The user might also want to group the I-Ds using the groupings in the list, such as "all I-Ds from this WG" and "all I-Ds that contain this word in the title".
用户可能还希望使用列表中的分组对I-D进行分组，例如“来自此WG的所有I-D”和“标题中包含此单词的所有I-D”。
The Datatracker should save the last-chosen sorting for display with the definition of the list.
Datatracker应保存最后选择的排序，以便与列表的定义一起显示。
There are many attributes that might be displayed, and different users will have different information that they want to see. Also, users will have different display technologies: someone might normally use a Web browser on a large screen, but at other times use the browser on their phone.
可能会显示许多属性，不同的用户将拥有不同的信息。此外，用户将拥有不同的显示技术：有些人通常在大屏幕上使用Web浏览器，但有时在手机上使用浏览器。
Choosing which attributes should be displayed should be simple for the user. The Datatracker should save the last-chosen set of attributes for display with the definition of the list. The default is to display the I-D filename or RFC number, document title, date of current I-D or RFC publication date, status in the RFC queue or RFC process, the associated stream (IETF WG, IRTF RG, IAB, or ISE), whether it was changed within the last 7 days, and included list(s) that contain this I-D.
选择应该显示哪些属性对于用户来说应该很简单。Datatracker应保存最后选择的属性集，以便与列表的定义一起显示。默认情况下，显示I-D文件名或RFC编号、文档标题、当前I-D日期或RFC发布日期、RFC队列或RFC流程中的状态、关联流（IETF WG、IRTF RG、IAB或ISE）、是否在过去7天内更改，以及包含此I-D的包含列表。
The Datatracker should support display of the following attributes:
Datatracker应支持显示以下属性：
o I-D filename
o I-D文件名
o I-D title
o I-D标题
o Date of current I-D
o 当前身份证日期
o Status in the IETF process
o IETF过程中的状态
o Associated WG or RG
o 关联WG或RG
o Associated AD, if any
o 相关广告（如有）
o Changed within the last 1 day
o 在过去1天内更改
o Changed within the last 2 days
o 在过去2天内更改
o Changed within the last 7 days
o 在过去7天内更改
There is some leeway for how the Datatracker might display these attributes. For example, the "changed within" attributes might be shown with a check mark or a colored box.
对于Datatracker如何显示这些属性，还有一些余地。例如，“内部更改”属性可能显示为复选标记或彩色框。
When tracking I-Ds, some users want to be able to say "tell me if this I-D has not changed state by a particular date" such as when an I-D is starting a two-week last call or an I-D author has promised a new version by the end of the week. This feature gives the user a "dashboard" style capability.
在跟踪I-D时，一些用户希望能够说“告诉我该I-D是否在某个特定日期之前没有改变状态”，例如，当I-D开始进行为期两周的最后一次通话，或者I-D作者承诺在本周末之前发布新版本。此功能为用户提供了“仪表板”样式的功能。
For each I-D, the user should be able to set a marker date by which an update is expected. The Datatracker display will provide a visual indication if the marker date has passed but no change in status has occurred. It must be very easy for the user to remove these update-expected markers.
对于每个I-D，用户应该能够设置预期更新的标记日期。如果标记日期已过，但状态未发生变化，Datatracker显示屏将提供视觉指示。用户必须非常容易地删除这些更新预期标记。
2.3.4. Requirement: Users can specify highlighting of I-Ds and RFCs with recent changes
2.3.4. 要求：用户可以通过最近的更改指定I-D和RFC的突出显示
The Datatracker cannot easily keep track of when a user last looked at the page for a particular list. Thus, it instead needs to let a user say which range of dates they are most interested in. To that end, the user needs to be able to easily specify the amount of time they consider recent, either as "the past nnn hours", "the past nnn days", or "since this particular date".
Datatracker无法轻松跟踪用户上次查看页面的特定列表的时间。因此，它需要让用户说出他们最感兴趣的日期范围。为此，用户需要能够很容易地指定他们最近考虑的时间量，如“过去NNN小时”、“过去NNN天”或“自这个特定日期”。
Some users have their own tools for displaying and otherwise processing lists of I-Ds and RFCs. To make this easier, users should be able to get a machine-parsable file that has a well-known format and syntax that contains all the data that was used to create the current display. The order of the records in the file is not important because it is assumed that the user's program will sort the results themselves. All attributes will be included because it is assumed that the user's programs will only deal with the ones the user cares about.
一些用户有自己的工具来显示和处理I-D和RFC列表。为了简化此操作，用户应该能够获得一个机器可解析文件，该文件具有众所周知的格式和语法，其中包含用于创建当前显示的所有数据。文件中记录的顺序并不重要，因为假定用户的程序将自己对结果进行排序。所有属性都将包括在内，因为假定用户的程序只处理用户关心的那些。
When a list is marshaled into a data file, each record in the file format represents a single I-D or RFC. In a file, a particular I-D or RFC is only included once; for example, if someone manually adds draft-ietf-cuteacronym-sometopic to his list and also specifies that all I-Ds from the "cuteacronym" WG are included in the list, that I-D only appears once.
将列表封送到数据文件中时，文件格式中的每条记录都表示一个I-D或RFC。在一个文件中，特定的I-D或RFC只包含一次；例如，如果有人手动将草案ietf CuteAronym sometopic添加到他的列表中，并指定“CuteAronym”工作组中的所有I-D都包含在列表中，则该I-D只显示一次。
This feature will allow anyone to create mash-ups of their own and create their own Web sites based on the IETF data. This is significantly easier than adding features to the Datatracker, and is able to cater to narrow audiences. The format of this file has yet to be determined.
此功能允许任何人创建自己的mashup，并基于IETF数据创建自己的网站。这比向Datatracker中添加功能要容易得多，并且能够满足有限的受众。该文件的格式尚未确定。
A tool for tracking the status of I-Ds and RFCs can affect the privacy of its users. Someone could possibly determine relevant information about a user if they knew what that user was tracking.
用于跟踪I-D和RFC状态的工具可能会影响其用户的隐私。如果有人知道某个用户正在跟踪什么，他们可能会确定该用户的相关信息。
Web applications, particularly those that store data on a Web server, are a common source of security issues such as cross-site scripting attacks. The tool described in this document might also use access control for lists, and access control and authentication also cause security issues if not implemented properly.
Web应用程序，特别是那些在Web服务器上存储数据的应用程序，是安全问题（如跨站点脚本攻击）的常见来源。本文档中描述的工具还可能对列表使用访问控制，如果未正确实现，访问控制和身份验证也会导致安全问题。
Ideas used in this document were contributed by Scott Bradner, Leslie Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen, Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad, Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner.
本文件中使用的想法由斯科特·布拉德纳、莱斯利·戴格尔、斯宾塞·道金斯、亚伦·福克、罗斯·霍斯利、泰罗·基维宁、巴里·莱巴、约翰·莱文、亨里克·列夫科维茨、库尔蒂斯·林克维斯特、安迪·马利斯、雷·佩莱蒂埃、布莱克·拉姆斯代尔、朱利安·雷什克、吉姆·沙阿德、亚伦·谢弗、罗伯特·斯帕克斯、安德鲁·沙利文和肖恩·特纳提供。
[ALTSTREAMS] Hoffman, P., "Data Tracker States and Annotations for the IAB, IRTF, and Independent Submission Streams", Work in Progress, May 2011.
[ALTSTREAMS]Hoffman，P.，“IAB、IRTF和独立提交流的数据跟踪器状态和注释”，正在进行的工作，2011年5月。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.translate error, please retry
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，RFC 4287，2005年12月。
[RFC6174] Juskevicius, E., "Definition of IETF Working Group Document States", RFC 6174, March 2011.
[RFC6174]Juskevicius，E.“IETF工作组文件状态的定义”，RFC 61742011年3月。
[RFC6175] Juskevicius, E., "Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors", RFC 6175, March 2011.
[RFC6175]Juskevicius，E.“IETF工作组主席和作者扩展数据跟踪器的要求”，RFC 61752011年3月。
[RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011.
[RFC6292]Hoffman，P.“工作组章程工具的要求”，RFC 62922011年6月。
It is not at all clear if any of these will be a requirement, a later requirement, or a non-requirement. Further, even if one or more of these non-I-D items is made a requirement, it is not clear whether they will be included in the same lists with I-Ds. That is, if tracking IANA registry changes are considered a requirement, it is not clear whether a user would include the registries in a list that also contains I-Ds, or whether they would need to create two lists, one for I-Ds and one for IANA registries.
目前还不清楚这些要求中的任何一项是要求、后续要求还是非要求。此外，即使对其中一个或多个非I-D项目提出要求，也不清楚它们是否会与I-D一起包含在相同的列表中。也就是说，如果跟踪IANA注册表更改被视为一项要求，则不清楚用户是否会将注册表包括在一个也包含I-D的列表中，或者他们是否需要创建两个列表，一个用于I-D，一个用于IANA注册表。
It will soon be easier to track changes in WG charters and milestones; see [RFC6292] for more information. Someone subscribing to the mail stream for a WG would be able to see each of these changes. With the expected changes, the Datatracker would be able to update WGs in a list without any polling.
跟踪工作组章程和里程碑的变化将很快变得更容易；有关更多信息，请参阅[RFC6292]。订阅工作组邮件流的人将能够看到这些更改。有了预期的更改，Datatracker将能够在不进行任何轮询的情况下更新列表中的WGs。
Developers may need to get values from IANA registries for their software/hardware implementations. They might want to know when the registry changes, such as additional entries or updates to current entries. Thus, being able to be notified when a registry changes would be valuable to them.
开发人员可能需要从IANA注册中心获取用于其软件/硬件实现的值。他们可能想知道注册表何时更改，例如其他条目或当前条目的更新。因此，能够在注册表更改时收到通知对他们来说是很有价值的。
Adding this functionality may be tricky for some registries. For example, if a developer cared about DKIM signature tags, they would have to subscribe to <http://www.iana.org/assignments/dkim-parameters/> which (currently) covers a handful of registries, all related to DKIM. Thus, a change to the DKIM hash algorithms would trigger a message showing that the registry had changed, even though the DKIM signature tags registry had not.
对于某些注册中心来说，添加此功能可能很棘手。例如，如果开发人员关心DKIM签名标签，他们就必须订阅<http://www.iana.org/assignments/dkim-parameters/>它（目前）覆盖了少数几个注册中心，都与DKIM有关。因此，对DKIM哈希算法的更改将触发一条消息，显示注册表已更改，即使DKIM签名标记注册表未更改。
Users might want to know when a new liaison statement is sent by the IETF or when one is received by the IETF.
用户可能想知道IETF何时发送新的联络声明，或IETF何时收到新的联络声明。
Users might want to track documents that relate to IETF activities but are produced by other standards development organizations (SDOs) such as the W3C, the IEEE, the Unicode Consortium, the ITU, and others. In order for the tracker to track these documents, it would need to poll occasionally and possibly scrape listings from HTML.
用户可能希望跟踪与IETF活动相关但由其他标准开发组织（SDO）生成的文档，如W3C、IEEE、Unicode联盟、ITU等。为了让跟踪器跟踪这些文档，它需要偶尔进行轮询，并可能从HTML中获取列表。
Users might want to know when a new IPR statement is submitted.
用户可能想知道何时提交新的IPR语句。
The following are ideas for the new tool that are not currently being considered for the first round of development, but are being documented for possible future use. Items from this list may move to the list of requirements that are expected to be integrated during the first round of development.
以下是新工具的想法，目前尚未在第一轮开发中考虑，但正在记录以备将来可能使用。此列表中的项目可能会移动到预计将在第一轮开发期间集成的需求列表中。
o The Datatracker could list all of the publicly-readable lists (or certainly at least the ones associated with IETF activities), and have links from WG pages in the Datatracker to the publicly-readable lists maintained by the WG chairs.
o Datatracker可以列出所有公开可读的列表（或者至少肯定是与IETF活动相关的列表），并具有从Datatracker中的工作组页面到工作组主席维护的公开可读列表的链接。
o Draft versions of this RFC included a requirement to be able to include other lists. While this may still be desired, it was decided that implementing this in a safe and understandable way would be too difficult. In particular, there was a concern about detecting and handling loops. Later versions of the Datatracker might include this feature.
o 该RFC的草案版本包括一项要求，即能够包括其他列表。虽然这可能仍然是需要的，但决定以安全和可理解的方式实施这一点太困难了。特别是，有一个关于检测和处理循环的问题。Datatracker的更高版本可能包含此功能。
o In public lists, it might be useful for someone to be able to understand why particular I-Ds and/or groups are added. Allowing the user who put together the list to add a comment field would help someone else understand the motivation.
o 在公共列表中，如果有人能够理解为什么要添加特定的I-D和/或组，这可能会很有用。允许整理列表的用户添加注释字段将有助于其他人理解动机。
o The Datatracker might remove lists if it seems that storing them on the Datatracker is taking too many resources. The Datatracker can periodically send mail to the user reminding them to delete lists that are no longer needed.
o 如果将列表存储在Datatracker上似乎占用了太多资源，Datatracker可能会删除这些列表。Datatracker可以定期向用户发送邮件，提醒他们删除不再需要的列表。
o The normal Datatracker display could have a button to add a particular I-D to the user's personal list.
o 正常的Datatracker显示器可能有一个按钮，用于将特定的ID添加到用户的个人列表中。
o Allow each user to determine what "significant change in status" is for the list they create. This could be done by a series of check boxes for every possible status change.
o 允许每个用户确定他们创建的列表的“状态重大变化”。这可以通过为每个可能的状态更改设置一系列复选框来完成。
o A list creator can add a list-level comment about who might be interested in following the list.
o 列表创建者可以添加列表级别的注释，说明哪些人可能对列表感兴趣。
o If the agendas for an upcoming meeting are scraped for I-D names, it would be possible to add an attribute to an I-D that lists that WG agenda(s) on which it appears.
o 如果为即将召开的会议的议程刮取了ID名称，则可以在I-D中添加一个属性，该属性列出了该会议的工作组议程。
o In the section on "Adding groups of I-Ds to a list by attribute", add an attribute for "all I-Ds that are referenced by any I-D in a particular list".
o 在“按属性将I-D组添加到列表”一节中，为“特定列表中任何I-D引用的所有I-D”添加属性。
o Make it possible to add all I-Ds that have a certain section to a list (non-trivial IANA considerations, ASN.1 modules in appendices, MIBs, ABNF, XML modules, ...).
o 可以将具有特定部分的所有I-D添加到列表中（非琐碎的IANA注意事项、附录中的ASN.1模块、MIB、ABNF、XML模块等）。
o Even though Atom feeds have been around for years, they are new to many Internet users, and even experienced users only know how to use them in limited ways. The Datatracker should have at least a few paragraphs explaining how the Atom feeds that it provides can be used in different tools such as dedicated feed readers, online feed-display services, and so on.
o 尽管Atom提要已经存在多年了，但对于许多互联网用户来说，它们还是新的，即使是有经验的用户也只知道如何以有限的方式使用它们。Datatracker应该至少有几个段落解释它提供的Atom提要如何在不同的工具中使用，如专用提要阅读器、在线提要显示服务等。
Author's Address
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org