doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6293.txt b/doc/rfc/rfc6293.txt
new file mode 100644
index 0000000..52e6eaf
--- /dev/null
+++ b/doc/rfc/rfc6293.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2011 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+Hoffman                       Informational                     [Page 1]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+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
+
+
+
+
+
+Hoffman                       Informational                     [Page 2]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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
+
+1.  Introduction
+
+   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.)
+
+   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).
+
+   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.
+
+   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.
+
+1.1.  Usage Scenarios
+
+   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:
+
+
+
+Hoffman                       Informational                     [Page 3]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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  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  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  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  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.
+
+1.2.  Context for This Document
+
+   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.
+
+   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.
+
+   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  the ability to get notifications when particular I-Ds from a list
+      change state
+
+   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
+
+
+
+
+
+Hoffman                       Informational                     [Page 4]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   o  the ability to set the granularity of the changes (such as "every
+      change", "just approvals and publication", and so on)
+
+   o  the ability to organize views of a list in many fashions that
+      would be useful to different types of community members
+
+   o  the ability to share and merge lists with other community members
+
+   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.
+
+1.3.  Definitions Used in This Document
+
+   A "user" is an individual person who is a member of the IETF
+   community.
+
+   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.
+
+   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.
+
+   A "row" is a set of attributes about a single I-D or RFC that is
+   displayed in the Datatracker.
+
+   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:
+
+   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  IAB stream: "Active IAB Document", "Community Review", and "Sent
+      to the RFC Editor"
+
+   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"
+
+
+
+
+
+Hoffman                       Informational                     [Page 5]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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  All streams: in addition to the above, the disposition states
+      "Approved", "RFC Published", and "Dead" are also included
+
+   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.
+
+1.4.  Expected User Interactions
+
+   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:
+
+   o  By going to the Datatracker page for the list (see Section 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  By subscribing to the mail stream for the list (see Section 2.2.3)
+      and reading the mail stream in their mail reader
+
+2.  Requirements for Tools Features
+
+   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.
+
+2.1.  Lists
+
+2.1.1.  Requirement: Lists of I-Ds and RFCs can be large
+
+   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.
+
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 6]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+2.1.2.  Requirement: Every Datatracker user can create 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.
+
+   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.
+
+   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
+
+   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.
+
+2.1.4.  Requirement: The Datatracker must support optional publicly-
+        readable lists for WGs and Area Directors
+
+   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.
+
+   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.
+
+   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
+
+
+
+Hoffman                       Informational                     [Page 7]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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.
+
+2.1.5.  Requirement: Specifying the I-Ds and RFCs that are in a list
+        must be simple
+
+   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.
+
+2.1.6.  Requirement: Adding groups of I-Ds to a list by attribute must
+        be simple
+
+   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:
+
+   o  All I-Ds associated with an particular WG
+
+   o  All I-Ds associated with all WGs in an particular Area
+
+   o  All I-Ds with a particular responsible AD
+
+   o  All I-Ds with a particular author
+
+   o  All I-Ds with a particular document shepherd
+
+   o  All I-Ds that have a reference to a particular RFC
+
+   o  All I-Ds that have a reference to a particular I-D
+
+   o  All I-Ds that are referenced by a particular RFC
+
+   o  All I-Ds that are referenced by a particular I-D
+
+   o  All I-Ds that contain a particular text string
+
+
+
+
+
+
+Hoffman                       Informational                     [Page 8]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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.
+
+   Note that some of these attributes are based on heuristics derived by
+   programs that parse I-Ds, and are therefore inherently not completely
+   reliable.
+
+2.1.7.  Requirement: Private information must not be exposed in lists
+
+   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.
+
+2.2.  Notifications
+
+2.2.1.  Requirement: Users can be notified when an I-D changes status
+
+   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.
+
+   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.
+
+2.2.2.  Requirement: Every list has Atom feeds associated with it
+
+   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.
+
+   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.
+
+
+
+
+
+Hoffman                       Informational                     [Page 9]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+2.2.3.  Requirement: Every list has mail streams associated with it
+
+   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.
+
+2.2.4.  Requirement: Notifications need to specify which list caused the
+        notification
+
+   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.)
+
+2.3.  Display in the Datatracker
+
+2.3.1.  Requirement: Users can define their Datatracker document view
+
+   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.
+
+   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:
+
+   o  Alphabetical by I-D filename and RFC number
+
+   o  Alphabetical by document title
+
+   o  Alphabetical by associated WG
+
+   o  Date of publication of current version of the document
+
+   o  Date of most recent change of status of any type
+
+   o  Date of most recent significant change of status
+
+
+
+Hoffman                       Informational                    [Page 10]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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.
+
+   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".
+
+   The Datatracker should save the last-chosen sorting for display with
+   the definition of the list.
+
+2.3.2.  Requirement: Users can choose which attributes to display
+
+   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.
+
+   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.
+
+   The Datatracker should support display of the following attributes:
+
+   o  I-D filename
+
+   o  I-D title
+
+   o  Date of current I-D
+
+   o  Status in the IETF process
+
+   o  Associated WG or RG
+
+   o  Associated AD, if any
+
+   o  Changed within the last 1 day
+
+
+
+
+Hoffman                       Informational                    [Page 11]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   o  Changed within the last 2 days
+
+   o  Changed within the last 7 days
+
+   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.
+
+2.3.3.  Requirement: Users can flag I-Ds with dates in the future
+
+   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.
+
+   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.
+
+2.3.4.  Requirement: Users can specify highlighting of I-Ds and RFCs
+        with recent changes
+
+   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".
+
+2.4.  File Output
+
+2.4.1.  Requirement: Users can get their current list as a single file
+
+   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.
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 12]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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.
+
+   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.
+
+3.  Security Considerations
+
+   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.
+
+   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.
+
+4.  Acknowledgements
+
+   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.
+
+5.  Informative References
+
+   [ALTSTREAMS]  Hoffman, P., "Data Tracker States and Annotations for
+                 the IAB, IRTF, and Independent Submission Streams",
+                 Work in Progress, May 2011.
+
+   [RFC2026]     Bradner, S., "The Internet Standards Process --
+                 Revision 3", BCP 9, RFC 2026, October 1996.
+
+   [RFC4287]     Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
+                 Syndication Format", RFC 4287, December 2005.
+
+   [RFC6174]     Juskevicius, E., "Definition of IETF Working Group
+                 Document States", RFC 6174, March 2011.
+
+
+
+
+Hoffman                       Informational                    [Page 13]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   [RFC6175]     Juskevicius, E., "Requirements to Extend the
+                 Datatracker for IETF Working Group Chairs and Authors",
+                 RFC 6175, March 2011.
+
+   [RFC6292]     Hoffman, P., "Requirements for a Working Group Charter
+                 Tool", RFC 6292, June 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 14]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+Appendix A.  Possible Tracking of Other Data
+
+   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.
+
+A.1.  Tracking WG Charter Changes
+
+   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.
+
+A.2.  Tracking IANA Registry Changes
+
+   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.
+
+   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.
+
+A.3.  Tracking Changes in the Liason Statement Directory
+
+   Users might want to know when a new liaison statement is sent by the
+   IETF or when one is received by the IETF.
+
+A.4.  Tracking Changes in Documents Outside the IETF Sphere
+
+   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.
+
+
+
+Hoffman                       Informational                    [Page 15]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+A.5.  Tracking Additions to the IPR Statement Repository
+
+   Users might want to know when a new IPR statement is submitted.
+
+Appendix B.  Ideas that Might Be Implemented Later
+
+   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  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  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  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  The normal Datatracker display could have a button to add a
+      particular I-D to the user's personal list.
+
+   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  A list creator can add a list-level comment about who might be
+      interested in following the list.
+
+   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.
+
+
+
+
+Hoffman                       Informational                    [Page 16]
+
+RFC 6293           Datatracker Community Tracking Reqs         June 2011
+
+
+   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  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  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.
+
+Author's Address
+
+   Paul Hoffman
+   VPN Consortium
+
+   EMail: paul.hoffman@vpnc.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hoffman                       Informational                    [Page 17]
+