draft-ietf-genarea-datatracker-community-02.txt   draft-ietf-genarea-datatracker-community-03.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational November 21, 2010 Intended status: Informational December 20, 2010
Expires: May 25, 2011 Expires: June 23, 2011
Requirements for Draft Tracking by the IETF Community in the Datatracker Requirements for Draft Tracking by the IETF Community in the Datatracker
draft-ietf-genarea-datatracker-community-02 draft-ietf-genarea-datatracker-community-03
Abstract Abstract
The document gives a set of requirements for extending the IETF The document gives a set of requirements for extending the IETF
Datatracker to give individual IETF community members, including the Datatracker to give individual IETF community members, including the
IETF leadership, easy methods for tracking the progress of the IETF leadership, easy methods for tracking the progress of the
Internet Drafts of interest to them. Internet Drafts of interest to them.
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 25, 2011. This Internet-Draft will expire on June 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 11 skipping to change at page 2, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
1.2. Context for This Document . . . . . . . . . . . . . . . . 5 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
1.3. Definitions Used in This Document . . . . . . . . . . . . 6 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
1.4. Expected user interactions . . . . . . . . . . . . . . . . 6 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7
1.5. Discussion of These Requirements . . . . . . . . . . . . . 7 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
2. Requirements for Tools Features . . . . . . . . . . . . . . . 7 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Requirement: Lists of drafts can be large . . . . . . 7 2.1.1. Requirement: Lists of drafts can be large . . . . . . 7
2.1.2. Requirement: A user can create multiple lists . . . . 7 2.1.2. Requirement: Every Datatracker user can create a
2.1.3. Requirement: Some lists must be able to be private list . . . . . . . . . . . . . . . . . . . . . . . . . 7
or anonymous . . . . . . . . . . . . . . . . . . . . . 7 2.1.3. Requirement: Read-only views of private lists can
2.1.4. Requirement: It must be easy for IETF leadership be made visible to others . . . . . . . . . . . . . . 8
and individuals to make lists they create 2.1.4. Requirement: The Datatracker must support optional
publicly-readable . . . . . . . . . . . . . . . . . . 8 publicly-readable lists for WGs and Area Directors . . 8
2.1.5. Requirement: Specifying the drafts that are in a 2.1.5. Requirement: Specifying the drafts that are in a
list must be simple . . . . . . . . . . . . . . . . . 9 list must be simple . . . . . . . . . . . . . . . . . 9
2.1.6. Requirement: Adding groups of drafts to a list by 2.1.6. Requirement: Adding groups of drafts to a list by
attribute must be simple . . . . . . . . . . . . . . . 9 attribute must be simple . . . . . . . . . . . . . . . 9
2.1.7. Requirement: Lists can dynamically include other 2.1.7. Tombstone: lists dynamically including other lists . . 9
lists . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.8. Later Requirement: Users can add comments to say 2.1.8. Later Requirement: Users can add comments to say
why they added a draft or group . . . . . . . . . . . 10 why they added a draft or group . . . . . . . . . . . 10
2.1.9. Requirement: These extensions must not make the 2.1.9. Requirement: These extensions must not make the
Datatracker take up too many resources . . . . . . . . 10 Datatracker take up too many resources . . . . . . . . 10
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
2.2.1. Requirement: Users can be notified when a draft 2.2.1. Requirement: Users can be notified when a draft
changes status . . . . . . . . . . . . . . . . . . . . 11 changes status . . . . . . . . . . . . . . . . . . . . 10
2.2.2. Requirement: Every list has Atom feeds associated 2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 11 with it . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Requirement: Every list has mail streams 2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 12 associated with it . . . . . . . . . . . . . . . . . . 11
2.2.4. Requirement: Notifications need to specify which 2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 12 list caused the notification . . . . . . . . . . . . . 11
2.2.5. Later Requirement: The tool must have instructions 2.2.5. Later Requirement: The tool must have instructions
on how to use it Atom feeds . . . . . . . . . . . . . 12 on how to use it Atom feeds . . . . . . . . . . . . . 11
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12
2.3.1. Requirement: Users can define how the rows are 2.3.1. Requirement: Users can define how the rows are
sorted in a display . . . . . . . . . . . . . . . . . 12 sorted in a display . . . . . . . . . . . . . . . . . 12
2.3.2. Requirement: Users can choose which attributes to 2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 13 display . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.3. Requirement: Users can flag drafts with dates in 2.3.3. Requirement: Users can flag drafts with dates in
the future . . . . . . . . . . . . . . . . . . . . . . 14 the future . . . . . . . . . . . . . . . . . . . . . . 13
2.3.4. Requirement: Users can specify highlighting of 2.3.4. Requirement: Users can specify highlighting of
drafts with recent changes . . . . . . . . . . . . . . 14 drafts with recent changes . . . . . . . . . . . . . . 13
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Requirement: Users can get their current list as a 2.4.1. Requirement: Users can get their current list as a
single file . . . . . . . . . . . . . . . . . . . . . 15 single file . . . . . . . . . . . . . . . . . . . . . 14
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . . 16 6. Informative References . . . . . . . . . . . . . . . . . . . . 15
Appendix A. Possible Tracking of Non-draft Documents . . . . . . 16 Appendix A. Possible Tracking of Non-draft Documents . . . . . . 15
A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 17 A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 16
A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 17 A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 16
A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 17 A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 16
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 17 A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16
Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17 Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 16
Appendix C. Differences Between -00 and -01 . . . . . . . . . . . 18 Appendix C. Differences Between -02 and -03 . . . . . . . . . . . 17
Appendix D. Differences Between -01 and -02 . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
IMPORTANT NOTE: This is an early draft of a set of requirements. It IMPORTANT NOTE: This is an early draft of a set of requirements. It
has gone through one round of community review at IETF 79 in Beijing, has gone through one round of community review at IETF 79 in Beijing,
and thus probably is missing things that should be included, and some and thus probably is missing things that should be included, and some
of the things in this draft are wrong and will be changed in future of the things in this draft are wrong and will be changed in future
drafts. Nothing in this draft should be considered solid. drafts. Nothing in this draft should be considered solid.
The IETF Datatracker is used by many IETF community members to find The IETF Datatracker is used by many IETF community members to find
skipping to change at page 4, line 32 skipping to change at page 4, line 32
words in the draft's title, author, associated Working Group (WG) or words in the draft's title, author, associated Working Group (WG) or
IETF area, the responsible Area Director (AD), or IESG status. The IETF area, the responsible Area Director (AD), or IESG status. The
returned list of drafts includes five columns: draft filename (with returned list of drafts includes five columns: draft filename (with
an active link to an HTMLized version of the draft maintained by the 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 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 status in the IETF process, and the responsible AD (if any). For
example, the output of a search in the current Datatracker can be example, the output of a search in the current Datatracker can be
seen at <http://imgur.com/snfyl.png>. seen at <http://imgur.com/snfyl.png>.
Instead of using the search capability of the Datatracker to manually Instead of using the search capability of the Datatracker to manually
find I-Ds of interest, users might want to create lists of drafts 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 lists that they normally follow. Some users will want to keep their list
to themselves, but others will want to allow others to view their to themselves, but others will want to allow others to view their
lists. list.
Different users in the IETF community will have different ways that Different users in the IETF community will have different ways that
they want to get information on draft updates and status. Many users they want to get information on draft updates and status. Many users
will want to be notified immediately, such as through an Atom feed will want to be notified immediately, such as through an Atom feed
(see [RFC4287]) or automatically-generated email. Many users will (see [RFC4287]) or automatically-generated email. Many users will
want to only find out about updates when they go to a web page. Many 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. 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 And, of course, some users will want all three. All of these desires
are related to the overall desire to track drafts through their are related to the overall desire to track drafts through their
lifecycle. lifecycle.
skipping to change at page 6, line 18 skipping to change at page 6, line 18
documents, such as WG charters. Appendixes A through D list these documents, such as WG charters. Appendixes A through D list these
proposals. It is not clear currently if those sections will be part proposals. It is not clear currently if those sections will be part
of the initial deployment of the requirements in the main body of of the initial deployment of the requirements in the main body of
this document. this document.
1.3. Definitions Used in This Document 1.3. Definitions Used in This Document
A "user" is an individual person who is member of the IETF community. 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 A "list" is an unordered set of Internet Drafts and groups of
Internet Drafts. Lists are specified by users. 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 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 current state in the IETF process, and so on. Attributes are usually
displayed as columns in the Datatracker. displayed as columns in the Datatracker.
A "row" is a set of attributes about a single draft that is displayed A "row" is a set of attributes about a single draft that is displayed
in the Datatracker. in the Datatracker.
A "significant change in status" is all approvals and disposition of A "significant change in status" is all approvals and disposition of
the draft. Assuming that the changes to the Datatracker specified in the draft. Assuming that the changes to the Datatracker specified in
skipping to change at page 7, line 19 skipping to change at page 7, line 25
o By subscribing to the mail stream for the list (see Section 2.2.3) o By subscribing to the mail stream for the list (see Section 2.2.3)
and reading the stream in their mail reader and reading the stream in their mail reader
1.5. Discussion of These Requirements 1.5. Discussion of These Requirements
This document is being discussed on the datatracker-rqmts@ietf.org This document is being discussed on the datatracker-rqmts@ietf.org
mailing list. For more information, see mailing list. For more information, see
<https://www.ietf.org/mailman/listinfo/datatracker-rqmts>. <https://www.ietf.org/mailman/listinfo/datatracker-rqmts>.
There will probably be virtual interim meetings to discuss this There will probably be virtual interim meetings to discuss this
document in late 2010 and early 2011. document in early 2011.
2. Requirements for Tools Features 2. Requirements for Tools Features
This section defines the requirements for the tool described earlier This section defines the requirements for the tool described earlier
in this document. The eventual tool, if implemented, may have more in this document. The eventual tool, if implemented, may have more
features than are listed here; however, before this document is features than are listed here; however, before this document is
finished, it should contain as many requirements as possible upon finished, it should contain as many requirements as possible upon
which the IETF community can agree. which the IETF community can agree.
2.1. Lists 2.1. Lists
2.1.1. Requirement: Lists of drafts can be large 2.1.1. Requirement: Lists of drafts can be large
An active IETF participant might want to follow the status of An active IETF participant might want to follow the status of
hundreds of drafts. For example, some ADs have 100 drafts in their 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 area, and they may also want to follow drafts outside their area that
affect documents in their area. affect documents in their area.
2.1.2. Requirement: A user can create multiple lists 2.1.2. Requirement: Every Datatracker user can create a list
A user might have multiple areas of interest and would want to track
each area on a different web page. Another example would be a WG
chair who wants to track the drafts in his or her WG separately from
the drafts in a different area of interest. An IETF participant
might want to have a list of drafts that they are following closely,
and another list of drafts written by work colleagues.
2.1.3. Requirement: Some lists must be able to be private or anonymous 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.
Seeing a list of drafts that covers multiple areas of interest can In order for this requirement to be met, it must be easy for any
tell you something about the person who created the list. For community member to get a Datatracker account. Account setup must
example, you might be able to guess that they might be looking for a not involve any direct action on the part of the Secretariat.
job in a different field by looking at their list of drafts of However, the Secretariat will be responsible for support of
interest. Of course, anyone can follow individual drafts today Datatracker accounts (lots passwords, odd interactions, and so on),
without having that be exposed; however, following a particular group so this addition of more Datatracker accounts will potentially
of drafts can reveal information about a person. increase the amount of work the Secretariat must do.
There is a open issue about whether lists should be default be The only person who can edit the contents of a private list is the
private/anonymous or public, and how that default should be manifest person who knows the password to the account with which the list is
in the eventual UI for creating lists. associated.
The first proposed methods that might keep lists private/anonymous 2.1.3. Requirement: Read-only views of private lists can be made
are: visible to others
o Private lists might only be available using passwords or some Some users will want to make available a read-only view of their
other common authentication mechanism. This would require that list. Each private list will have a URL that leads to the
the Datatracker have a subscription process for users that could Datatracker view of the list; that URL must be able to be safely
assign passwords, and a per-user process for adding lists to a shared with others. In this case, "safely" means "will not help
user account. (If the current Datatracker username and login others be able to edit the list". Similarly, the Atom feed
scheme is used, the interface needs to be improved so that getting associated with a private list should be able to be safely shared
a new login, and changing one's password, are significantly with others>
easier.)
o Anonymous lists might be assigned random URLs from a very large
(2^128) namespace, and the user who creates a list does not tell
others the assigned URL. This method makes it impossible for
someone to search the entire set of assigned lists. Given that
the URLs for lists are most likely going to be copy-and-pasted
anyway, having long random strings in the list's URL is not an
impediment.
2.1.4. Requirement: It must be easy for IETF leadership and individuals 2.1.4. Requirement: The Datatracker must support optional publicly-
to make lists they create publicly-readable readable lists for WGs and Area Directors
Private or anonymous lists are fine for individuals, but publicly- It is common in the IETF for users to follow the work of an entire
readable lists can magnify the value to the whole community. In WG, not just individual drafts within a WG. It is also very common
fact, some early commenters on this document emphasized that that some work that is related to a WG happens outside the WG, either
publicly-readable lists will be more valuable to the IETF than in other WGs or as individual efforts. Many WG chairs monitor this
helping individuals track documents that are only of interest to outside-the-WG activity for various reasons.
them.
Probably the easiest method to implement publicly-readable lists is A smaller number of community members to follow an entire Area's
to make them read-only aliases for private or anonymous lists. This worth of topics. Again, these topics often happen within the WGs of
would allow the list originators to control the contents of the list an area, but not always; for example, some topics related to the
as normal, but also allow anyone to view the results in the Security Area happen in WGs in the Applications Area.
Datatracker and/or subscribe to notifications. There may be other
methods that would also make sense, and this section might change in
the future.
Publicly-readable lists should have short URLs that can be Because of this, it would be useful for community members to be able
transcribed without relying on copy-and-paste. The names in the URLs to find a list which corresponds to the WGs or Areas in which they
for lists that are associated with IETF activities (initially, the are interested. The WG lists could be maintained by the WG chairs;
lists created by WG chairs and ADs) can be mnemonic, but other public the Area lists would likely be maintained by the ADs. Note that such
lists should have names that are not mnemonic in order to prevent lists are not mandatory; for example, a WG chair might not choose to
name-squatting. maintain such a list for a WG whose topic is extremely broad.
It is important to note that publicly-readable lists can only be Both Working Group chairs and Area Directors currently already have
changed by the owners. Allowing many people to change the contents Datatracker accounts, so fulfilling this requirement only involves
of a list would probably lead to lists that are not very useful to associating those accounts with the role that controls the list.
typical users.
Proposed later requirements include having the Datatracker list all Proposed later requirements include having the Datatracker list all
of the publicly-readable lists (or certainly at least the ones of the publicly-readable lists (or certainly at least the ones
associated with IETF activities), and having links from WG pages in associated with IETF activities), and having links from WG pages in
Datatracker to the publicly-readable lists maintained by the WG Datatracker to the publicly-readable lists maintained by the WG
chairs. chairs.
2.1.5. Requirement: Specifying the drafts that are in a list must be 2.1.5. Requirement: Specifying the drafts that are in a list must be
simple simple
skipping to change at page 9, line 35 skipping to change at page 9, line 23
drafts to the list. This could be done using the Datatracker's drafts to the list. This could be done using the Datatracker's
current search facility, and simply adding a "add to list" option for current search facility, and simply adding a "add to list" option for
Further, when editing an existing list, it must be easy to add 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. 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 2.1.6. Requirement: Adding groups of drafts to a list by attribute must
be simple be simple
Drafts have many attributes, and some users might want to follow all Drafts have many attributes, and some users might want to follow all
of the drafts that have a particular attribute. Some, but not all, of the drafts that have a particular attribute. Some, but not all,
attributes have values that make sense for creating lists. It should attributes have values that make sense in specifying lists. It
be easy to add each of the following attributes when adding to or should be easy to add each of the following attributes when adding to
editing a list: or editing a list:
o All drafts associated with an individual WG o All drafts associated with an individual WG
o All drafts associated with all WGs in an individual Area 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 responsible AD
o All drafts with a particular author o All drafts with a particular author
o All drafts with a particular document shepherd 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 RFC
o All drafts that have a reference to a particular draft o All drafts that have a reference to a particular draft
o All drafts that are referenced by a particular RFC o All drafts that are referenced by a particular RFC
o All drafts that are referenced by a particular draft o All drafts that are referenced by a particular draft
skipping to change at page 10, line 12 skipping to change at page 9, line 48
These attributes are dynamic, and thus the list of drafts that have a These attributes are dynamic, and thus the list of drafts that have a
particular attribute will change after the user adds that attribute particular attribute will change after the user adds that attribute
to a list. The Datatracker should update lists with dynamic to a list. The Datatracker should update lists with dynamic
attributes as often as is sensible for the server environment, such attributes as often as is sensible for the server environment, such
as once an hour or more. as once an hour or more.
Note that some of these attributes are derived by programs created by Note that some of these attributes are derived by programs created by
the IETF Tools Team that parse drafts and are therefore inherently the IETF Tools Team that parse drafts and are therefore inherently
not completely reliable. not completely reliable.
2.1.7. Requirement: Lists can dynamically include other lists 2.1.7. Tombstone: lists dynamically including other lists
If a user is authorized to see the contents of a list, he or she can
include that other list in a different list. When the referenced
list changes, those changes are also reflected in the referring-to
list; that is, if list A includes list B, and the set of drafts in
list B changes, the set of drafts in list A is automatically changed.
This feature is expected to be useful for experts (particularly WG
chairs) who create lists on topics that others might consider
interesting. For example, if Alice creates a list that contains all
the drafts that she thinks relate to TLS, and Bob has access to that
list, Bob can add that list to his personal list of things for which
he is interested. Bob might also create a list-of-lists about TLS
that includes references to Alice's list as well as to a similar list
that Eric put together.
There needs to be some way to prevent circular references in lists Earlier versions of this draft had a requirement that lists needed to
that refer to other lists. 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 2.1.8. Later Requirement: Users can add comments to say why they added
a draft or group a draft or group
In public lists, it might be useful for someone to be able to In public lists, it might be useful for someone to be able to
understand why particular drafts and/or groups are added. Allowing understand why particular drafts and/or groups are added. Allowing
the user who put together the list to add a comment field would help the user who put together the list to add a comment field would help
someone else see the motivation. someone else see the motivation.
2.1.9. Requirement: These extensions must not make the Datatracker take 2.1.9. Requirement: These extensions must not make the Datatracker take
up too many resources up too many resources
Currently, the only state that the Datatracker keeps for its users is Currently, the only state that the Datatracker keeps for its users is
a very small set of attributes assigned to a username-password pair. a very small set of attributes assigned to a username-password pair.
The extensions described here will cause the Datatracker to need to The extensions described here will cause the Datatracker to need to
keep more information, namely lists. Each list might have additional keep more information, namely lists. Each list might have additional
associated state as well. Depending on the method for keeping lists associated state as well. This could lead to the Datatracker needing
private or anonymous, this could lead to the Datatracker needing a a larger amount of storage and other resources. When this document
larger amount of storage and other resources. When this document is is near completion, it would probably be good to list exactly which
near completion, it would probably be good to list exactly which new new state will be kept on the Datatracker server.
state will be kept on the Datatracker server.
In order to reduce the chance that these extensions would strain the In order to reduce the chance that these extensions would strain the
Datatracker, some sort of denial-of-service prevention should be used Datatracker, some sort of denial-of-service prevention should be used
when the extensions are added. For example, if the lists are user- when the extensions are added. A later requirement might be to cull
based, a user might be limited to having only a certain number of lists if it seems that storing them on the Datatracker is taking too
lists; if they are anonymous, the Datatracker might have test to many resources. The Datatracker can periodically send mail to the
prove that the person creating the list actually exists, such as a user reminding them to delete lists that are no longer needed.
CAPTCHA test or a requirement that the user has a reachable mail
address.
A later requirement might be to cull lists if it seems that storing
them on the Datatracker is taking too many resources. If lists are
user-based, the Datatracker can periodically send mail to the user
reminding them to delete lists that are no longer needed; if the
lists are anonymous, the Datatracker can maybe check whether or not a
list is viewed or the Atom feed retrieved.
Culling presents a problem, however, for lists that are public. The Culling presents a problem, however, for user-based lists that are
creator of a list might no longer be using it, but others might be. made public. The creator of a list might no longer be using it, but
Thus, it is likely that the Datatracker needs to be be able to others might be. Thus, it is likely that the Datatracker needs to be
maintain lists long-term even if their creators are no longer using be able to maintain lists long-term even if their creators are no
them. longer using them.
2.2. Notifications 2.2. Notifications
2.2.1. Requirement: Users can be notified when a draft changes status 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 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 find out when a draft has been updated. Instead, they want to be
notified immediately after the draft is changed. The Datatracker notified immediately after the draft is changed. The Datatracker
needs to support this type of immediate notification, where needs to support this type of immediate notification, where
"immediate" means "within an hour of a change to any draft in the "immediate" means "within an hour of a change to any draft in the
skipping to change at page 12, line 18 skipping to change at page 11, line 33
A user can subscribe to two email streams that are generated from the 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 changes to the list: one for every change in status, and another for
significant change of status. significant change of status.
Note that the mail streams are for each change; they are not batched 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 (such as one message per day). Users who want less frequent but
batched notifications need to use the Atom feeds instead of the mail batched notifications need to use the Atom feeds instead of the mail
streams. streams.
Because lists can incorporate other lists, and those other lists
might be very large or grow very large, a user might suddenly get a
flood of email. The Datatracker needs to warn a user when the list
to which he or she is subscribed has more than 100 drafts.
2.2.4. Requirement: Notifications need to specify which list caused the 2.2.4. Requirement: Notifications need to specify which list caused the
notification notification
Users might have feeds and/or subscriptions to multiple lists. In Users might have feeds and/or subscriptions to multiple lists. In
order to disambiguate duplicate notifications from multiple lists, order to disambiguate duplicate notifications from multiple lists,
the body of the message in the Atom feed or mail stream needs to say 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 which list generated the notification. (Ideally, a user who wants
notifications will make one list based on multiple lists, but if they notifications will make one list based on multiple lists, but if they
subscribe to multiple lists, this requirement will at least suggest subscribe to multiple lists, this requirement will at least suggest
to them that they want to limit their overlapping subscriptions.) to them that they want to limit their overlapping subscriptions.)
skipping to change at page 14, line 16 skipping to change at page 13, line 24
o Draft filename o Draft filename
o Draft title o Draft title
o Date of current draft o Date of current draft
o Status in the IETF process o Status in the IETF process
o Associated WG or RG o Associated WG or RG
o Associated AD, if any o Associated AD, if any
o Changed within the last 1 day o Changed within the last 1 day
o Changed within the last 2 days o Changed within the last 2 days
o Changed within the last 7 days o Changed within the last 7 days
o Included list(s) which contain this draft
There is some leeway for how the Datatracker might display these There is some leeway for how the Datatracker might display these
attributes. For example, the "changed within" attributes might be attributes. For example, the "changed within" attributes might be
shown with a check mark or a colored box. The "included lists" shown with a check mark or a colored box.
attribute might show a pop-up with the names of the lists, given that
list names might be long.
2.3.3. Requirement: Users can flag drafts with dates in the future 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 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 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 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 a new version by the end of the week. This feature gives the user a
"dashboard" style capability. "dashboard" style capability.
For each draft in a list, the user should be able to set one date- For each draft in a list, the user should be able to set one date-
skipping to change at page 16, line 49 skipping to change at page 15, line 49
NOTE: This is the first draft to include the functionality listed in NOTE: This is the first draft to include the functionality listed in
the next four subsections. Thus, it is not at all clear if any of the next four subsections. Thus, it is not at all clear if any of
these will be a requirement, a later requirement, or a non- these will be a requirement, a later requirement, or a non-
requirement. requirement.
Further, even if one or more of these non-draft items is made a 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 requirement, it is not clear whether they will be included in the
same lists with drafts. That is, if tracking RFC status changes are same lists with drafts. That is, if tracking RFC status changes are
considered a requirement, it is not clear whether a user would considered a requirement, it is not clear whether a user would
include the RFCs in a list that also contains draft, or whether they include the RFCs in a list that also contains draft, or whether they
would need to create two lists. would need to create two lists, one for drafts and one for RFCs.
A.1. Tracking RFC Status Changes and Errata A.1. Tracking RFC Status Changes and Errata
The contents of RFCs never change after they are published. However, The contents of RFCs never change after they are published. However,
that does not mean that nothing alters the meaning of the RFC. In 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, 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 errata can be made against RFCs. A user who cares about the RFC
might want to know when these changes are made. might want to know when these changes are made.
Currently, the only way for the Datatracker to see these changes is Currently, the only way for the Datatracker to see these changes is
skipping to change at page 18, line 16 skipping to change at page 17, line 16
versions of the document, and to spur readers to think of even more versions of the document, and to spur readers to think of even more
open issues. open issues.
o There may be legal issues with keeping user data private if we use o There may be legal issues with keeping user data private if we use
login accounts. login accounts.
o When an AD agrees to sponsor an individual submission, does the o When an AD agrees to sponsor an individual submission, does the
Datatracker consider that draft associated with the AD? If not, Datatracker consider that draft associated with the AD? If not,
that needs to be dealt with here. that needs to be dealt with here.
o Thought: add a button in the normal Datatracker output to add a o Thought: add a button in the normal Datatracker output to add a
particular draft to a particular list. particular draft to a particular list.
New open issues added in -02:
o Maybe need a way to let a user delete lists that are no longer
used.
o Maybe want to remind users monthly that they created a list.
o If the Datatracker contains private information (that is still to o If the Datatracker contains private information (that is still to
be seen), that private information needs to be invisible in lists be seen), that private information needs to be invisible in lists
so that it is not accidentally exposed. so that it is not accidentally exposed.
o Should "significant change in status" be judged by the list o Should "significant change in status" be judged by the list
creator, such as by a series of check boxes for every possible creator, such as by a series of check boxes for every possible
status change? status change?
o Idea for a later requirement: A list creator can add comments o Idea for a later requirement: A list creator can add comments
about who might be interested in following the list. about who might be interested in following the list.
o If the design goes towards anonymous pages under a common root
URI, there should be a robots.txt page telling spiders not to look
beneath it.
o It should be easy to remove items from list in the Datatracker o It should be easy to remove items from list in the Datatracker
display. display.
o If the agendas for an upcoming meeting are scraped for draft 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 names, it would be possible to add an attribute to a draft that
lists that WG agenda(s) on which it appears. lists that WG agenda(s) on which it appears.
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, ...).
o In 2.1.6, add "All drafts that are referenced by any draft on list
XXXX"
o Another possible stream: liaison statements.
Appendix C. Differences Between -00 and -01 Appendix C. Differences Between -02 and -03
Added info for the mailing list.
Appendix D. Differences Between -01 and -02
Note that this is a *huge* modification based on the large number of
suggestions given during the meeting at IETF 79 in Beijing.
Changed the intro to indicate that there was input from IETF 79.
Added a new section 1.1 on usage scenarios.
Added the statement of work to the new "Context for this Document"
section 1.2. Added a brief introduction to the ideas in Appendix A
through D to section 1.2. Discussed "later requirements".
In old 1.1 (now 1.3), updated the definitions of "user" and "list".
Also made the definition of "significant change in status" much
fuller.
In 2.1.3, opened the issue of whether public or private should be the
default. Also clarified that the two proposals are just the first
two proposals. Also added the note about the Datatracker's GUI for
new usernames and changing passwords.
Added new 2.1.4 on publicly-readable lists.
In old 2.1.4 (now 2.1.5), changed the second sentence to make it
clear that the Datatracker's current search facility is fine as-is.
Clarified old 2.1.5 (now 2.1.6) to be "best effort" instead of
exactly one hour.
In old 2.1.6 (now 2.1.7), added the need for prevention of circular
references.
Added 2.1.8, a later requirement for adding comments.
Added 2.1.9, requirement that the Datatracker not take up too many
resources.
In 2.2, added idea of a notifications stream.
In 2.2.1, clarified that this requirement can be met with the
following requirements.
In 2.2.3, added a note about not having batched mail streams, and
added a requirement for warnings on long lists.
Added section 2.2.5, the requirement that the tool must have
instructions on how to use it Atom feeds.
In 2.3, removed the intro text.
In 2.3.1, added the default display.
In 2.3.2, added the default display. Also removed "Also, the user
should also be able to specify the order in which the attributes are
displayed."
Added 2.3.3, the requirement for dashboard-style specification of
date timers on drafts.
Added 2.3.4, the requirement that users can specify highlighting of
drafts with recent changes.
Added Scott Bradner, Leslie Daigle, Spencer Dawkins, Aaron Falk, Tero
Kivinen, Barry Leiba, Henrik Levkowetz, Kurtis Lindqvist, Andy Malis,
Jim Schaad, Robert Sparks, and Sean Turner, to the acknowledgements.
Made the reference to RFC 2026 to be informative. Added references
for the two active drafts.
Previous Appendix A, "Some Known Open Issues", and previous Appendix
B, "Differences Between -00 and -01", became Appendixes C and D,
respectively, due to the addition of the new appendix for non-draft
items that might be tracked.
Removed the open issue about dashboards because it is now 2.3.3.
Removed the open issue about non-IETF streams because the information
is now included in the document.
Removed the open issue about changing public lists because the Made the number of lists per person from "many" to "one". This was
document is now clear that they are read-only. done throughout the document, but is particularly apparent in 2.1.2.
Removed the open issue "Is there a formal definition for 'drafts Resolved the "private or anonymous" question by making lists private,
associated with a particular WG'?" based on a response from Henrik based on ownership of a Datatracker account. This primarily affects
Levkowetz on the mailing list. 2.1.3, which now also covers the requirement that private lists also
have a public read-only component. This change assumes that private
lists are a requirement.
Removed some open issues that could be incorporated later: "Should Talked more about role-based lists, particularly in 2.1.4, making all
paging be supported for long lists in the HTML display?" "Should the those lists publicly-readable.
file output be in all the interesting formats (XML and JSON and tab-
separated text) or just one?"
Removed open issue "How prescriptive do we want to be? Should this Got rid of the requirement that lists can dynamically include other
say things like "JavaScript pop-up" and "CSS" and such?" because lists, making 2.1.7 a tombstone. Also modifed 2.2.3 and 2.3.2
there is no need to go to that level. because of this change.
Added some more open issues. Added two new open issues ("all drafts referenced by another list"
and "liaison statements stream").
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 49 change blocks. 
260 lines changed or deleted 129 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/