[要約] RFC 6293は、IETFコミュニティによるDatatrackerでのInternet-Draftの追跡に関する要件を定めたものです。その目的は、IETFプロセスの透明性と効率性を向上させることです。
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
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 DataTrackerを拡張して、IETFのリーダーシップ、インターネットドラフトの進捗状況を簡単に追跡するための簡単な方法、RFCの関心のあるRFCを含む個々のIETFコミュニティメンバーに提供するための一連の要件を提供します。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
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 DataTrackerは、多くのIETFコミュニティメンバーによって使用され、インターネットドラフト（I-DS）とRFCのステータスを見つけ、特定の基準を満たすI-DSおよびRFCを表示します。<https://datatracker.ietf.org/>にある現在のDataTrackerは、誰でもアクティブなI-DSとRFCを検索し、指定された基準に一致するリストを取得できます。（DataTrackerは期限切れのI-DSも許可していますが、これらはこの議論には関係ありません。）
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 Authorリスト、関連ワーキンググループ（WG）、IETFエリア、責任エリアディレクター（AD）、またはIESGステータスでDatAtrackerで検索できます。タイトルの数や単語でRFCを検索できます。I-DSおよび/またはRFCSの返されたリストには、ファイル名またはRFC番号、ドキュメントのタイトル、公開された日付、IETFまたはRFCプロセスでのステータス、IPRステートメント、および責任AD（存在の場合）の6列が含まれています。。
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.
DataTrackerの検索機能を使用して、関心のあるI-DSとRFCを手動で見つける代わりに、ユーザーは通常従うI-DSのリストを作成することをお勧めします。一部のユーザーは自分のリストを自分自身に保持したいと考えていますが、他のユーザーは他のユーザーが自分のリストを表示できるようにしたいと思うでしょう。
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の更新とステータスに関する情報を取得したいさまざまな方法があります。多くのユーザーは、原子フィード（[RFC4287]を参照）や自動化された電子メールなど、すぐに通知されたいと思うでしょう。多くのユーザーは、Webページにアクセスしたときにのみ更新について知りたいと思うでしょう。多くのユーザーは、他のツールへの入力としてリストのデータを取得したい場合があります。そして、もちろん、一部のユーザーは3つすべてを望んでいます。これらはすべて、ライフサイクルを通じてI-DSを追跡するのを支援します。
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: 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.
これらの提案されたDataTrackerの変更の主な動機は、さまざまな潜在的なユーザーがI-DSとRFCを追跡できるようにし、重要なイベントがいつ発生するかをよりよく確認できるようにすることです。いくつかの例には、o WG椅子は、自分のWGのアクティブなI-DSに関連する他のWGのすべてのI-DSのリストを保持したい場合があります。
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 その同じWG椅子は、WGメンバーが彼または彼女がフォローしているのと同じI-DSをフォローできるように支援したいと思うかもしれません。
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-DSに従い、DNS RFCのいずれかが後で更新されるか、および/またはそれらに対してserrataが投稿されているかどうかを認識することをお勧めします。。これには、DNS（DNSEXT、DNSOP、振る舞いなど）を直接変更している多くのWGSにあるI-DSだけでなく、個々の提出、IAB I-DS、IRTF I-DS、および独立した提出物も含まれます。。
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-DSに焦点を当てることにより、プロセスの一部に従うことをお勧めします。
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-DSの1つ以上の（おそらく大きな）リストを作成する機能
o the ability to get notifications when particular I-Ds from a list change state
o リスト状態を変更する特定のI-DSが通知を取得する機能
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-DSで発生したすべての州の変更を見る能力
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-DSが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-DS、およびI-DSのグループの順序付けられていないセットです。リストはユーザーによって指定されています。場合によっては、著者は、そのWGに関連付けられたリストの指定子であるWG椅子など、役割に基づいています。
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.
「属性」は、ファイル名またはRFC番号、IETFまたはRFCプロセスの現在の状態など、I-Dまたは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:
「ステータスの大幅な変化」は、すべてI-Dの承認と処分です。[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ストリーム：WGは、「WGで採用された」、「WG Last Callで採用された」、「WGコンセンサス：Waiting White whoting」、「Parked WG Document」、および「Dead WG Document」と述べています。IESGには、「公開要求が要求された」、「最後のコール」、「IESG評価」、および「RFCエディターに送信」と述べています。
o IAB stream: "Active IAB Document", "Community Review", and "Sent to the RFC Editor"
o IABストリーム：「Active IAB Document」、「Community Review」、および「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のステータスが歴史的に変更される、または投稿された正誤sの発表です。ベース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-DSおよび/またはRFCのグループをフォローしたい場合、DatAtrackerに行き、新しいリストを作成します。リストの要件は、セクション2.1に記載されています。リストが作成された後、ユーザーには、リスト内のI-DSおよび/またはRFCが更新されたときに表示される3つの方法があります。
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 アップデートを自動的に取得するフィードリーダーのリストの原子フィード（セクション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-DSおよび数十のRFCのステータスに従うことをお勧めします。たとえば、一部の広告には、その地域に100 IDがあります。さらに、彼らはまた、その地域の文書に影響を与える彼らの地域の外側のI-DSに従うことを望んでいるかもしれません。
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.
ユーザーがDataTrackerアカウントを取得すると、そのアカウントには空のリストが事前に定義されています。リストは通常、アカウントの所有者によってのみ変更できますが、事務局はDatAtrackerのサポートロールの一部としてリストを変更することもできます。各DataTrackerユーザーは、1つのリストを持つことに制限されています。
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.
プライベートリストの内容を編集できるのは、リストが関連付けられているアカウントのパスワードを知っている人だけです。
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は、他の人にリストを編集する能力を与えることなく共有できる必要があります。同様に、プライベートリストに関連付けられた原子フィードは、他の人にリストを編集する能力を与えずに共有できる必要があります。
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では、ユーザーがWG内の単一のI-DSとRFCだけでなく、WG全体の作業に従うことが一般的です。また、WGに関連する一部の作業は、他のWGSまたは個々の努力としてWGの外で発生することも非常に一般的です。多くのWG椅子は、さまざまな理由でこのWGの外部活動を監視しています。
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内で発生しますが、常にではありません。たとえば、セキュリティエリアに関連するいくつかのトピックは、アプリケーションエリアの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 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.
このため、コミュニティメンバーがWGSまたは関心のある領域に対応するリストを見つけることができるのは役に立ちます。WGリストは、WGチェアによって維持できます。エリアリストは、広告によって維持される可能性があります。そのようなリストは必須ではないことに注意してください。たとえば、WG椅子は、トピックが非常に広いWGのこのようなリストを維持することを選択しない場合があります。
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.
ワーキンググループの椅子とエリアディレクターの両方がすでにデータタッカーアカウントを持っているため、この要件を満たすには、これらのアカウントをリストを管理する役割と関連するだけです。
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-DSとRFCを簡単に追加できる必要があります。これは、DataTrackerの現在の検索機能を使用して行うことができ、検索されたI-DSの表示に「リストに追加」オプションを追加するだけです。さらに、既存のリストを編集する場合、追加のI-DSおよびRFCを簡単に追加できる必要があり、リストからI-DSとRFCを簡単に削除することができなければなりません。
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-DSには多くの属性があり、一部のユーザーは、特定の属性を持つすべてのI-DSをフォローしたい場合があります。すべてではありませんが、属性を指定する際に意味のある値があります。リストを追加または編集するときに、次の各属性を簡単に追加できます。
o All I-Ds associated with an particular WG
o 特定のWGに関連付けられているすべてのI-DS
o All I-Ds associated with all WGs in an particular Area
o 特定の領域のすべてのWGに関連付けられているすべてのI-DS
o All I-Ds with a particular responsible AD
o 特定の責任ある広告を持つすべてのI-DS
o All I-Ds with a particular author
o 特定の著者とのすべてのI-DS
o All I-Ds with a particular document shepherd
o 特定のドキュメントシェパードを使用したすべてのI-DS
o All I-Ds that have a reference to a particular RFC
o 特定のRFCへの参照があるすべてのI-DS
o All I-Ds that have a reference to a particular I-D
o 特定のI-Dへの参照を持つすべてのI-DS
o All I-Ds that are referenced by a particular RFC
o 特定のRFCによって参照されるすべてのI-DS
o All I-Ds that are referenced by a particular I-D
o 特定のI-Dによって参照されるすべてのI-DS
o All I-Ds that contain a particular text string 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.
o 特定のテキスト文字列を含むすべてのI-DSこれらの属性は動的であるため、ユーザーがリストにその属性を追加すると、特定の属性を持つI-DSのリストが変更されます。DataTrackerは、1時間以上など、サーバー環境にとって顕著なのと同じくらい頻繁に動的属性を持つリストを更新する必要があります。
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-DSを解析するプログラムによって導出されたヒューリスティックに基づいているため、本質的に完全に信頼性がないことに注意してください。
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.
一部のユーザーは、I-DまたはRFCがいつ更新されたかを確認するために、DatAtrackerの表示ページにアクセスしたくありません。代わりに、彼らは変更後すぐに通知されたいと考えています。DataTrackerは、このタイプの即時通知をサポートする必要があります。ここでは、「即時」は、リスト内のI-DまたはRFCの変更から1時間以内に意味があります。この要件は、次の2つのセクションで説明されているように、原子フィードとメールストリームで満たすことができます。
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は、原子フィードとメールストリームを生成するために使用できる一般的な「通知エンジン」を作成する場合があります。このエンジンを使用して、後でジャバーフィードなどの他の通知タイプを追加できます。
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.
リストには、リストの変更から生成される2つの原子フィードがあります。1つはステータスの変更ごとに、もう1つはステータスの大幅な変更です。各原子フィードには、フィードリーダーが使用できる安定した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ユーザーは、単一のI-DSのIETFツールチームによって作成されたAtom Feedsをすでに使用しています。ここで説明するリストに新しいフィードを使用すると、従う必要のあるフィードの数を減らすために、より良い選択機能を備えています。
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.
ユーザーは、リストの変更から生成される2つのメールストリームを購読できます。1つはステータスの変更ごとに、もう1つはステータスの大幅な変更についてです。
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.
メールストリームは変更ごとにあることに注意してください。それらはバッチされていません（1日に1つのメッセージなど）。頻繁ではあるがバッチされた通知が必要なユーザーは、メールストリームの代わりに原子フィードを使用する必要があります。
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 FeedまたはMail Stream内のメッセージの本文は、どのリストが通知を生成したかを言う必要があります。（理想的には、通知を希望するユーザーは複数のリストに基づいて1つのリストを作成しますが、複数のリストを購読する場合、この要件は少なくとも重複するサブスクリプションを制限したいことを示唆します。）
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番号によってアルファベット順に表示されるビューを必要とする場合がありますが、ユーザーが1週間ネットから外れた後、ステータスの変更の順にビューを表示したい場合があります。そのため、これらの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-DSをリストすることです。最後にRFCがあります。リストを表示する場合、DataTrackerは次の照合順序でI-DSの簡単な並べ替えを許可する必要があります。
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 関連するWGによるアルファベット順
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 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.
o ディスプレイの最新の重要なステータスの変更の日付、特定のI-DまたはRFCは1回しか含まれていません。たとえば、誰かが彼のリストにドラフト-ITeCrony-someTopicを手動で追加し、「CuteAcrony」WGのすべてのI-Dがリストに含まれていることを指定した場合、I-Dはディスプレイに1回しか表示されないことを指定します。リストが含まれているという列には、このI-Dが含まれているということは、この情報の損失を軽減するのに役立ちます。
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".
また、ユーザーは、「このWGのすべてのI-DS」や「タイトルにこの単語を含むすべてのI-DS」など、リストのグループを使用してI-DSをグループ化することもできます。
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 現在のi-dの日付
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 Changed within the last 2 days
o 過去1日以内に変更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-DSを追跡するとき、一部のユーザーは、I-Dが2週間の最後の呼び出しを開始したり、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ディスプレイは、マーカーの日付が通過したがステータスの変更が発生していない場合、視覚的な表示を提供します。ユーザーがこれらの更新予定マーカーを削除するのは非常に簡単でなければなりません。
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-DSおよび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が1回しか含まれていません。たとえば、誰かが彼のリストにドラフト-ITeCrony-someTopicを手動で追加し、「CuteAcrony」WGのすべてのI-Dがリストに含まれていることを指定した場合、I-Dは1回しか表示されません。
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.
この機能により、誰でも独自のマッシュアップを作成し、IETFデータに基づいて独自のWebサイトを作成できます。これは、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-DSと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、およびIndependent Submission Streamsのデータトラッカー状態と注釈」、2011年5月の進行中。
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[RFC4287]ノッティンガム、M。、編and R. Sayre、ed。、「The Atom Syndication Format」、RFC 4287、2005年12月。
[RFC6174] Juskevicius, E., "Definition of IETF Working Group Document States", RFC 6174, March 2011.
[RFC6174] Juskevicius、E。、「IETFワーキンググループドキュメント状態の定義」、RFC 6174、2011年3月。
[RFC6175] Juskevicius, E., "Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors", RFC 6175, March 2011.
[RFC6175] Juskevicius、E。、「IETFワーキンググループの椅子と著者のDatatrackerを拡張するための要件」、RFC 6175、2011年3月。
[RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011.
[RFC6292]ホフマン、P。、「ワーキンググループチャーターツールの要件」、RFC 6292、2011年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アイテムの1つ以上が要件になったとしても、I-DSの同じリストに含まれるかどうかは明らかではありません。つまり、IANAレジストリの変更が要件と見なされる場合、ユーザーがi-DSを含むリストにレジストリを含めるか、I-DS用の2つのリストを作成する必要があるかどうかは明らかではありません。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.
WGチャーターとマイルストーンの変更を追跡する方がまもなく簡単になります。詳細については、[RFC6292]を参照してください。WGのメールストリームを購読している人は、これらの各変更を見ることができます。予想される変更により、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の署名タグレジストリにはそうではなかったとしても、レジストリが変更されたことを示すメッセージをトリガーします。
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アクティビティに関連するが、W3C、IEEE、Unicodeコンソーシアム、ITUなどの他の標準開発組織（SDO）によって作成されるドキュメントを追跡したい場合があります。トラッカーがこれらのドキュメントを追跡するためには、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.
以下は、開発の第1ラウンドで現在考慮されていないが、将来の使用の可能性のために文書化されている新しいツールのアイデアです。このリストの項目は、開発の最初のラウンド中に統合されると予想される要件のリストに移動する場合があります。
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のWGページからWGチェアが維持されている公開されているリストへのリンクを持つことができます。
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-DSおよび/またはグループが追加される理由を理解できるのが役立つかもしれません。リストをまとめたユーザーがコメントフィールドを追加できるようにすると、他の誰かが動機を理解するのに役立ちます。
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ディスプレイには、特定のI-Dをユーザーの個人リストに追加するボタンがあります。
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 今後の会議のアジェンダがI-D名のために削られた場合、それが表示されるWGアジェンダをリストする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-DSのグループを追加する」のセクションで、「特定のリストの任意のI-Dが参照するすべてのI-DS」の属性を追加します。
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-DSをリストに追加することを可能にします（非自明のIANAの考慮事項、付録のASN.1モジュール、MIBS、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 Feedsは長年にわたって存在していましたが、多くのインターネットユーザーにとって新しいものであり、経験豊富なユーザーでさえ、限られた方法でそれらを使用する方法しか知っていません。DataTrackerには、専用のフィードリーダー、オンラインフィードディスプレイサービスなどのさまざまなツールで提供する原子フィードをどのように使用できるかを説明する少なくともいくつかの段落が必要です。
Author's Address
著者の連絡先
Paul Hoffman VPN Consortium
ポール・ホフマンVPNコンソーシアム
EMail: paul.hoffman@vpnc.org