Network Working Group P. Hoffman Internet-Draft VPN Consortium Intended status: Informational January 17, 2011 Expires: July 21, 2011 Requirements for Draft Tracking by the IETF Community in the Datatracker draft-ietf-genarea-datatracker-community-04 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 of interest to them. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 21, 2011. 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 Expires July 21, 2011 [Page 1] Internet-Draft Datatracker Community Tracking Reqs January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.2. Context for This Document . . . . . . . . . . . . . . . . 5 1.3. Definitions Used in This Document . . . . . . . . . . . . 6 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Requirement: Lists of drafts can be large . . . . . . 7 2.1.2. Requirement: Every Datatracker user can create a list . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.3. Requirement: Read-only views of private lists can be made visible to others . . . . . . . . . . . . . . 8 2.1.4. Requirement: The Datatracker must support optional publicly-readable lists for WGs and Area Directors . . 8 2.1.5. Requirement: Specifying the drafts that are in a list must be simple . . . . . . . . . . . . . . . . . 9 2.1.6. Requirement: Adding groups of drafts to a list by attribute must be simple . . . . . . . . . . . . . . . 9 2.1.7. Tombstone: lists dynamically including other lists . . 10 2.1.8. Later Requirement: Users can add comments to say why they added a draft or group . . . . . . . . . . . 10 2.1.9. Requirement: These extensions must not make the Datatracker take up too many resources . . . . . . . . 10 2.1.10. Requirement: Private information must not be exposed in lists . . . . . . . . . . . . . . . . . . . 11 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 2.2.1. Requirement: Users can be notified when a draft changes status . . . . . . . . . . . . . . . . . . . . 11 2.2.2. Requirement: Every list has Atom feeds associated with it . . . . . . . . . . . . . . . . . . . . . . . 11 2.2.3. Requirement: Every list has mail streams associated with it . . . . . . . . . . . . . . . . . . 11 2.2.4. Requirement: Notifications need to specify which list caused the notification . . . . . . . . . . . . . 12 2.2.5. Later Requirement: The tool must have instructions on how to use it Atom feeds . . . . . . . . . . . . . 12 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12 2.3.1. Requirement: Users can define how the rows are sorted in a display . . . . . . . . . . . . . . . . . 12 2.3.2. Requirement: Users can choose which attributes to display . . . . . . . . . . . . . . . . . . . . . . . 13 2.3.3. Requirement: Users can flag drafts with dates in the future . . . . . . . . . . . . . . . . . . . . . . 14 2.3.4. Requirement: Users can specify highlighting of drafts with recent changes . . . . . . . . . . . . . . 14 Hoffman Expires July 21, 2011 [Page 2] Internet-Draft Datatracker Community Tracking Reqs January 2011 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. Requirement: Users can get their current list as a single file . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 6. Informative References . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Possible Tracking of Non-draft Documents . . . . . . 16 A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 16 A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 17 A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 17 A.4. Tracking Changes in the Liason Statement Directory . . . . 17 A.5. Tracking Changes in Documents Outside the IETF Sphere . . 17 Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17 Appendix C. Ideas that Might Be Implemented Later . . . . . . . . 18 Appendix D. Differences Between -03 and -04 . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Hoffman Expires July 21, 2011 [Page 3] Internet-Draft Datatracker Community Tracking Reqs January 2011 1. Introduction The IETF Datatracker is used by many IETF community members to find the status of Internet Drafts (I-Ds) and view drafts that meet particular criteria. The current Datatracker, found at , allows anyone to search for active I-Ds and get a list of drafts matching the given criteria. (The Datatracker also allows for searching RFCs and expired I-Ds, but those are not relevant to this discussion.) Users can search in the Datatracker by the filename of the draft, words in the draft's title, author, associated Working Group (WG) or IETF area, the responsible Area Director (AD), or IESG status. The returned list of drafts includes five columns: draft filename (with an active link to an HTMLized version of the draft maintained by the IETF tools team), the draft's title, the date it was submitted, its status in the IETF process, and the responsible AD (if any). For example, the output of a search in the current Datatracker can be seen at . Instead of using the search capability of the Datatracker to manually find I-Ds of interest, users might want to create a list of drafts 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 draft 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 desires are related to the overall desire to track drafts 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 drafts 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 drafts from other WGs that relate to active drafts in his or her WG. o That same WG chair might want to help WG members be able to follow the same drafts that he or she is following. Hoffman Expires July 21, 2011 [Page 4] Internet-Draft Datatracker Community Tracking Reqs January 2011 o Someone who cares about an established topic such as the DNS may want to follow the various drafts that might make changes to the DNS. This would include not only drafts that are in the many WGs that directly are changing the DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual submissions, IAB drafts, and even IRTF research. o Developers who are not active in the IETF process might want to lightly follow drafts 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 drafts 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. This document was prepared at the request of the IAOC. Some of the requirements in this document are listed as "later requirements". This means that these requirements might not be part of the first RFP for adding these enhancements. The statement of work that led to this document says "The tools that will eventually be provided to individuals in the community include": o the ability to create one or more (possibly large) lists of I-Ds that they want to follow o the ability to get notifications when individual drafts from a list changes state o the ability to see all of the state changes that have occurred on all the drafts in a list over a specified range of dates 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 their 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 Internet Drafts go Hoffman Expires July 21, 2011 [Page 5] Internet-Draft Datatracker Community Tracking Reqs January 2011 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 individual drafts as they go through the process. During the early discussion of these requirements, some community members proposed that it would be very useful to track other types of documents, such as WG charters. Appendixes A through D list these proposals. It is not clear currently if those sections will be part of the initial deployment of the requirements in the main body of this document. 1.3. Definitions Used in This Document A "user" is an individual person who is member of the IETF community. A "list" is an unordered set of Internet Drafts and groups of Internet Drafts. 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 a draft, such as its filename, its current state in the IETF process, and so on. Attributes are usually displayed as columns in the Datatracker. A "row" is a set of attributes about a single draft that is displayed in the Datatracker. A "significant change in status" is all approvals and disposition of the draft. Assuming that the changes to the Datatracker specified in [WGSTATES] 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", and "IESG Evaluation" 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" o ISE stream: "Submission Received", "In ISE Review", "In IESG Review", "Sent to the RFC Editor", and "Document on Hold Based On IESG Request" Hoffman Expires July 21, 2011 [Page 6] Internet-Draft Datatracker Community Tracking Reqs January 2011 o All streams: in addition to the above, the disposition states "Approved", "RFC Published", and "Dead" are also included 1.4. Expected user interactions When a user wants to follow a group of drafts, 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 drafts 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 stream in their mail reader 1.5. Discussion of These Requirements This document is being discussed on the datatracker-rqmts@ietf.org mailing list. For more information, see . There will probably be virtual interim meetings to discuss this document in early 2011. 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 drafts can be large An active IETF participant might want to follow the status of hundreds of drafts. For example, some ADs have 100 drafts in their area, and they may also want to follow drafts outside their area that affect documents in their area. Hoffman Expires July 21, 2011 [Page 7] Internet-Draft Datatracker Community Tracking Reqs January 2011 2.1.2. Requirement: Every Datatracker user can create a list When a user gets a Datatracker account, that account comes with an empty list pre-defined. The list can nomrally 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. 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 (lots 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 safely shared with others. In this case, "safely" means "will not help others be able to edit the list". Similarly, the Atom feed associated with a private list should be able to be safely shared with others> 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 individual drafts 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 to 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 which 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 Expires July 21, 2011 [Page 8] Internet-Draft Datatracker Community Tracking Reqs January 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. Proposed later requirements include having the Datatracker list all of the publicly-readable lists (or certainly at least the ones associated with IETF activities), and having links from WG pages in Datatracker to the publicly-readable lists maintained by the WG chairs. 2.1.5. Requirement: Specifying the drafts that are in a list must be simple When a user creates a new list, it must be easy to add individual drafts to the list. This could be done using the Datatracker's current search facility, and simply adding a "add to list" option for Further, when editing an existing list, it must be easy to add additional drafts, and it must be easy to remove drafts from a list. 2.1.6. Requirement: Adding groups of drafts to a list by attribute must be simple Drafts have many attributes, and some users might want to follow all of the drafts 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 drafts associated with an individual WG o All drafts associated with all WGs in an individual Area o All drafts with a particular responsible AD o All drafts with a particular author o All drafts with a particular document shepherd o All drafts that have a reference to a particular RFC o All drafts that have a reference to a particular draft o All drafts that are referenced by a particular RFC Hoffman Expires July 21, 2011 [Page 9] Internet-Draft Datatracker Community Tracking Reqs January 2011 o All drafts that are referenced by a particular draft o All drafts that contain a particular text string These attributes are dynamic, and thus the list of drafts 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 derived by programs created by the IETF Tools Team that parse drafts and are therefore inherently not completely reliable. 2.1.7. Tombstone: lists dynamically including other lists Earlier versions of this draft had a requirement that lists needed 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. Later versions of the Datatracker might include this feature. 2.1.8. Later Requirement: Users can add comments to say why they added a draft or group In public lists, it might be useful for someone to be able to understand why particular drafts and/or groups are added. Allowing the user who put together the list to add a comment field would help someone else see the motivation. 2.1.9. Requirement: These extensions must not make the Datatracker take up too many resources Currently, the only state that the Datatracker keeps for its users is a very small set of attributes assigned to a username-password pair. The extensions described here will cause the Datatracker to need to keep more information, namely lists. Each list might have additional associated state as well. This could lead to the Datatracker needing a larger amount of storage and other resources. When this document is near completion, it would probably be good to list exactly which new state will be kept on the Datatracker server. In order to reduce the chance that these extensions would strain the Datatracker, some sort of denial-of-service prevention should be used when the extensions are added. A later requirement might be to cull 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. Hoffman Expires July 21, 2011 [Page 10] Internet-Draft Datatracker Community Tracking Reqs January 2011 Culling presents a problem, however, for user-based lists that are made public. The creator of a list might no longer be using it, but others might be. Thus, it is likely that the Datatracker needs to be be able to maintain lists long-term even if their creators are no longer using them. 2.1.10. 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 streams created in this document. This private information includes private notes in the IESG balloting for a draft, 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 a draft changes status Some users do not want to go to the Datatracker's display page to find out when a draft has been updated. Instead, they want to be notified immediately after the draft is changed. The Datatracker needs to support this type of immediate notification, where "immediate" means "within an hour of a change to any draft 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 individual drafts. 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. 2.2.3. Requirement: Every list has mail streams associated with it A user can subscribe to two email streams that are generated from the changes to the list: one for every change in status, and another for significant change of status. Hoffman Expires July 21, 2011 [Page 11] Internet-Draft Datatracker Community Tracking Reqs January 2011 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.2.5. Later Requirement: The tool must have instructions on how to use it Atom feeds 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. 2.3. Display in the Datatracker 2.3.1. Requirement: Users can define how the rows are sorted in a display 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 to normally see it in alphabetical order by the drafts' filenames, but after the user is of the net for a week, he or she might want to see the list in order of changes of status so that those drafts changed recently appear at the top of the list. The default is to first list the groups first in alphabetical order by group name, then individual drafts in alphabetical order by draft filename. When displaying a list, the Datatracker should allow easy sorting of the drafts with the following collation orders: o Alphabetical order by group name followed by individual drafts (default) o Alphabetical by draft filename Hoffman Expires July 21, 2011 [Page 12] Internet-Draft Datatracker Community Tracking Reqs January 2011 o Alphabetical by draft title o Alphabetical by associated WG o Date of publication of current version of the draft o Date of most recent change of status of any type o Date of most recent significant change of status In displays, a particular draft should only included once; for example, if someone manually adds draft-ietf-cuteacronym-sometopic to his list and also specifies that all drafts from the "cuteacronym" WG are included in the list, that draft should only appear once in the display. The column saying which included list(s) contain this draft helps alleviate this loss of information. The user might also want to group the files using the groupings in the list, such as "all drafts from this WG" and "all drafts 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 is draft filename, draft title, date of current draft, status in stream process, associated WG or RG, whether it was changed within the last 7 days, and included list(s) which contain this draft. The Datatracker should support display of the following attributes: o Draft filename o Draft title o Date of current draft Hoffman Expires July 21, 2011 [Page 13] Internet-Draft Datatracker Community Tracking Reqs January 2011 o Status in the IETF process o Associated WG or RG o Associated AD, if any o Changed within the last 1 day 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 drafts with dates in the future When tracking drafts, some users want to be able to say "tell me if this draft has not changes state by a particular date" such as when a draft is starting a two-week last call or a draft author has promised a new version by the end of the week. This feature gives the user a "dashboard" style capability. For each draft in a list, the user should be able to set one date- based deadline. When using the display version of the Datatracker, if that date has passed and no change in status happened between the time that the user set the deadline and the set date, the Datatracker will highlight the deadline in red. It must also be easy to remove these deadlines. 2.3.4. Requirement: Users can specify highlighting of drafts 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 drafts. To make this easier, users should be able to get a machine-parsable file that has a well-known format and Hoffman Expires July 21, 2011 [Page 14] Internet-Draft Datatracker Community Tracking Reqs January 2011 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 care about. When a list is marshaled into a data file, each record in the file format represents a single draft. In a file, a particular draft is only included once; for example, if someone manually adds draft-ietf-cuteacronym-sometopic to his list and also specifies that all drafts from the "cuteacronym" WG are included in the list, that draft 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 narrower audiences. The format of the file will be XML or JSON or tab-separated fields in a text file. The decision on which format is supported will be based on the desires of the community while discussing this document. (Imagine how much fun that will be!) Regardless of the format chosen, a syntax will need to be specified. 3. IANA Considerations None. 4. Security Considerations A tool for tracking the status of Internet Drafts can affect the privacy of its users. The requirements for privacy of the Datatracker views are discussed earlier in the document. 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. 5. 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 Hoffman Expires July 21, 2011 [Page 15] Internet-Draft Datatracker Community Tracking Reqs January 2011 Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad, Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner. 6. Informative References [ALTSTREAMS] Hoffman, P., "Data Tracker States and Annotations for the IAB, IRTF, and Independent Submission Streams", draft-hoffman-alt-streams-tracker (work in progress), September 2010. [CHARTERTOOL] Hoffman, P., "Requirements for a Working Group Charter Tool", draft-ietf-genarea-charter-tool (work in progress), October 2010. [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. [WGSTATES] Juskevicius, E., "Definition of IETF Working Group Document States", draft-ietf-proto-wgdocument-states (work in progress), October 2010. Appendix A. Possible Tracking of Non-draft Documents 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-draft items is made a requirement, it is not clear whether they will be included in the same lists with drafts. That is, if tracking RFC status changes are considered a requirement, it is not clear whether a user would include the RFCs in a list that also contains draft, or whether they would need to create two lists, one for drafts and one for RFCs. A.1. Tracking RFC Status Changes and Errata The contents of RFCs never change after they are published. However, that does not mean that nothing alters the meaning of the RFC. In specific, an RFC can be updated or obsoleted by another RFC; also, errata can be made against RFCs. A user who cares about the RFC might want to know when these changes are made. Hoffman Expires July 21, 2011 [Page 16] Internet-Draft Datatracker Community Tracking Reqs January 2011 Currently, the only way for the Datatracker to see these changes is by polling structured files on the RFC Editor site and parsing them. A.2. Tracking WG Charter Changes It will soon be easier to track changes in WG charters and milestones; see [CHARTERTOOL] for more information. Someone subscribing to the 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.3. 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 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.4. 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.5. 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. Appendix B. Some Known Open Issues This list is mostly meant to remind the author of topics that need to be updated in future versions of the document, and to spur readers to think of even more open issues. Hoffman Expires July 21, 2011 [Page 17] Internet-Draft Datatracker Community Tracking Reqs January 2011 o When an AD agrees to sponsor an individual submission, does the Datatracker consider that draft associated with the AD? If not, that needs to be dealt with here. Appendix C. 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 here might move between this list and the list of requirements that are expected to be in the first round. o The normal Datatracker display could have a button to add a particular draft 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 draft names, it would be possible to add an attribute to a draft that lists that WG agenda(s) on which it appears. o In the section on "Adding groups of drafts to a list by attribute", add an attribute for "all drafts that are referenced by any draft in a particular list". o Make it possible to add all drafts that have a certain section to a list (non-trivial IANA considerations, ASN.1 modules in appendicies, ...). Appendix D. Differences Between -03 and -04 Removed the "early" note from the intro. Added a requirement on private data not being exposed. Added an appendix of ideas that could possibly be added later. Removed the "legal issues for user data" open issue because no one listed any. Moved many open issues to the "possibly later" list. Hoffman Expires July 21, 2011 [Page 18] Internet-Draft Datatracker Community Tracking Reqs January 2011 Author's Address Paul Hoffman VPN Consortium Email: paul.hoffman@vpnc.org Hoffman Expires July 21, 2011 [Page 19]