draft-ietf-genarea-datatracker-community-01.txt   draft-ietf-genarea-datatracker-community-02.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational October 21, 2010 Intended status: Informational November 21, 2010
Expires: April 24, 2011 Expires: May 25, 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-01 draft-ietf-genarea-datatracker-community-02
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 April 24, 2011. This Internet-Draft will expire on May 25, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Definitions Used in This Document . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
1.2. Discussion of These Requirements . . . . . . . . . . . . . 4 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
2. Requirements for Tools Features . . . . . . . . . . . . . . . 5 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.4. Expected user interactions . . . . . . . . . . . . . . . . 6
2.1.1. Requirement: Lists of drafts can be large . . . . . . 5 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
2.1.2. Requirement: A user can create multiple lists . . . . 5 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
2.1.3. Requirement: Some lists must be able to be private . . 5 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.4. Requirement: Specifying the drafts that are in a 2.1.1. Requirement: Lists of drafts can be large . . . . . . 7
list must be simple . . . . . . . . . . . . . . . . . 6 2.1.2. Requirement: A user can create multiple lists . . . . 7
2.1.5. Requirement: Adding groups of drafts to a list by 2.1.3. Requirement: Some lists must be able to be private
attribute must be simple . . . . . . . . . . . . . . . 6 or anonymous . . . . . . . . . . . . . . . . . . . . . 7
2.1.6. Requirement: Lists can dynamically include other 2.1.4. Requirement: It must be easy for IETF leadership
lists . . . . . . . . . . . . . . . . . . . . . . . . 7 and individuals to make lists they create
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 7 publicly-readable . . . . . . . . . . . . . . . . . . 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. Requirement: Lists can dynamically include 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.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Requirement: Users can be notified when a draft 2.2.1. Requirement: Users can be notified when a draft
changes status . . . . . . . . . . . . . . . . . . . . 7 changes status . . . . . . . . . . . . . . . . . . . . 11
2.2.2. Requirement: Every list has Atom feeds associated 2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 7 with it . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Requirement: Every list has mail streams 2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 8 associated with it . . . . . . . . . . . . . . . . . . 12
2.2.4. Requirement: Notifications need to specify which 2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 8 list caused the notification . . . . . . . . . . . . . 12
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 8 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 2.3.1. Requirement: Users can define how the rows are
sorted in a display . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 9 display . . . . . . . . . . . . . . . . . . . . . . . 13
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 10 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
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 . . . . . . . . . . . . . . . . . . . . . 10 single file . . . . . . . . . . . . . . . . . . . . . 15
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Informative References . . . . . . . . . . . . . . . . . . . . 16
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11 Appendix A. Possible Tracking of Non-draft Documents . . . . . . 16
6.2. Informative References . . . . . . . . . . . . . . . . . . 11 A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 17
Appendix A. Some Known Open Issues . . . . . . . . . . . . . . . 11 A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 17
Appendix B. Differences between -00 and -01 . . . . . . . . . . . 12 A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 A.4. Tracking Changes in Documents Outside the IETF Sphere . . 17
Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17
Appendix C. Differences Between -00 and -01 . . . . . . . . . . . 18
Appendix D. Differences Between -01 and -02 . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
IMPORTANT NOTE: This is a very early draft of a set of requirements. IMPORTANT NOTE: This is an early draft of a set of requirements. It
It has gone through no general community review, and thus probably is has gone through one round of community review at IETF 79 in Beijing,
missing many things that should be included, and some of the things and thus probably is missing things that should be included, and some
in this draft are wrong and will be changed in future drafts. of the things in this draft are wrong and will be changed in future
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
the status of Internet Drafts (I-Ds) and view drafts that meet the status of Internet Drafts (I-Ds) and view drafts that meet
particular criteria. The current Datatracker, found at particular criteria. The current Datatracker, found at
<https://datatracker.ietf.org/>, allows anyone to search for active <https://datatracker.ietf.org/>, allows anyone to search for active
I-Ds and get a list of drafts matching the given criteria. (The I-Ds and get a list of drafts matching the given criteria. (The
Datatracker also allows for searching RFCs and expired I-Ds, but Datatracker also allows for searching RFCs and expired I-Ds, but
those are not relevant to this discussion.) those are not relevant to this discussion.)
Users can search in the Datatracker by the filename of the draft, Users can search in the Datatracker by the filename of the draft,
skipping to change at page 3, line 33 skipping to change at page 4, line 33
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 lists of drafts
that they normally follow. Different users in the IETF community that they normally follow. Some users will want to keep their lists
will have different ways that they want to get information on draft to themselves, but others will want to allow others to view their
updates and status. Many users will want to be notified immediately, lists.
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.
For example, a WG chair might want to keep a list of all the drafts Different users in the IETF community will have different ways that
from other WGs that relate to active drafts in his or her WG. they want to get information on draft updates and status. Many users
Someone who cares about the DNS probably also wants to follow the will want to be notified immediately, such as through an Atom feed
various drafts in different areas that affect the DNS. Developers (see [RFC4287]) or automatically-generated email. Many users will
who are not active in the IETF process might want to follow drafts on want to only find out about updates when they go to a web page. Many
a particular topic to watch for things that might affect their users might want to get the data for a list as input to other tools.
implementations. 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.
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 This document describes the requirements for extending the
Datatracker for such capabilities. When complete, this document may Datatracker for such capabilities. When complete, this document may
be used to issue an RFP for the design and development of these be used to issue an RFP for the design and development of these
enhancements to the Datatracker. This document was prepared at the enhancements to the Datatracker. This document was prepared at the
request of the IAOC. 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 Note that [RFC2026] describes the process that Internet Drafts go
through before they either become RFCs or are abandoned. The through before they either become RFCs or are abandoned. The
Datatracker does not control this process: instead, it simply reports Datatracker does not control this process: instead, it simply reports
on the current state of individual drafts as they go through the on the current state of individual drafts as they go through the
process. process.
1.1. Definitions Used in This Document 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.
o A "user" is an individual person who is member of the IETF 1.3. Definitions Used in This Document
community. (Yes, that definition is purposely vague.)
o A "list" is an unordered set of filenames of Internet Drafts. A "user" is an individual person who is member of the IETF community.
Lists are specified by users.
o An "attribute" is a feature of a draft, such as its filename, its A "list" is an unordered set of Internet Drafts and groups of
current state in the IETF process, and so on. Attributes are Internet Drafts. Lists are specified by users.
usually displayed as columns in the Datatracker.
o A "row" is a set of attributes about a single draft that is An "attribute" is a feature of a draft, such as its filename, its
displayed in the Datatracker. current state in the IETF process, and so on. Attributes are usually
displayed as columns in the Datatracker.
o A "significant change in status" is all approvals and disposition. A "row" is a set of attributes about a single draft that is displayed
In the current process for drafts in the IETF stream, "all in the Datatracker.
approvals" means "publication requested" "in last call" (this is
IETF last call, not WG last call), and "IESG evaluation";
disposition is "approved" (for publication as an RFC), "RFC
published", and "dead".
1.2. Discussion of These Requirements 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:
This document is being discussed on the datatracker-rqmts@ietf.org o IETF stream: the WG states "Adopted by a WG", "In WG Last Call",
mailing list. See "WG Consensus: Waiting for Write-up", "Parked WG document", and
<https://www.ietf.org/mailman/listinfo/datatracker-rqmts> for more "Dead WG document"; the IESG states "Publication Requested", "In
information. 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"
o All streams: in addition to the above, the disposition states
"Approved", "RFC Published", and "Dead" are also included
There will be a BoF at IETF 79 in Beijing to discuss this draft. It 1.4. Expected user interactions
is currently being called "iddtspec", which somehow stands for
"Review of Datatracker Specifications to Follow Internet-Draft
Activities".
There is a plan to have one or two virtual meetings after Beijing to When a user wants to follow a group of drafts, he or she goes to the
discuss these requirements. 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
<https://www.ietf.org/mailman/listinfo/datatracker-rqmts>.
There will probably be virtual interim meetings to discuss this
document in late 2010 and 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
skipping to change at page 5, line 31 skipping to change at page 7, line 47
2.1.2. Requirement: A user can create multiple lists 2.1.2. Requirement: A user can create multiple lists
A user might have multiple areas of interest and would want to track 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 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 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 the drafts in a different area of interest. An IETF participant
might want to have a list of drafts that they are following closely, might want to have a list of drafts that they are following closely,
and another list of drafts written by work colleagues. and another list of drafts written by work colleagues.
2.1.3. Requirement: Some lists must be able to be private 2.1.3. Requirement: Some lists must be able to be private or anonymous
Seeing a list of drafts that covers multiple areas of interest can Seeing a list of drafts that covers multiple areas of interest can
tell you something about the person who created the list. For tell you something about the person who created the list. For
example, you might be able to guess that they might be looking for a example, you might be able to guess that they might be looking for a
job in a different field by looking at their list of drafts of job in a different field by looking at their list of drafts of
interest. Of course, anyone can follow individual drafts today interest. Of course, anyone can follow individual drafts today
without having that be exposed; however, following a particular group without having that be exposed; however, following a particular group
of drafts can reveal information about a person. of drafts can reveal information about a person.
Methods that might keep lists private include: There is a open issue about whether lists should be default be
private/anonymous or public, and how that default should be manifest
in the eventual UI for creating lists.
o The lists might only be available using passwords or some other The first proposed methods that might keep lists private/anonymous
common authentication mechanism. This would require that the are:
Datatracker have a subscription process for users that could
o Private lists might only be available using passwords or some
other common authentication mechanism. This would require that
the Datatracker have a subscription process for users that could
assign passwords, and a per-user process for adding lists to a assign passwords, and a per-user process for adding lists to a
user account. user account. (If the current Datatracker username and login
scheme is used, the interface needs to be improved so that getting
a new login, and changing one's password, are significantly
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.
o Lists might be assigned random URLs from a very large (2^128) 2.1.4. Requirement: It must be easy for IETF leadership and individuals
namespace, and the user who creates a list does not tell others to make lists they create publicly-readable
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.
Note that some lists will purposely be made public, so there will be Private or anonymous lists are fine for individuals, but publicly-
two types of lists. readable lists can magnify the value to the whole community. In
fact, some early commenters on this document emphasized that
publicly-readable lists will be more valuable to the IETF than
helping individuals track documents that are only of interest to
them.
2.1.4. Requirement: Specifying the drafts that are in a list must be Probably the easiest method to implement publicly-readable lists is
to make them read-only aliases for private or anonymous lists. This
would allow the list originators to control the contents of the list
as normal, but also allow anyone to view the results in the
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
transcribed without relying on copy-and-paste. The names in the URLs
for lists that are associated with IETF activities (initially, the
lists created by WG chairs and ADs) can be mnemonic, but other public
lists should have names that are not mnemonic in order to prevent
name-squatting.
It is important to note that publicly-readable lists can only be
changed by the owners. Allowing many people to change the contents
of a list would probably lead to lists that are not very useful to
typical users.
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 simple
When a user creates a new list, it must be easy to add individual When a user creates a new list, it must be easy to add individual
drafts to the list. There needs to be a mechanism that searches for drafts to the list. This could be done using the Datatracker's
potential drafts by partial filename, by partial or full title, and current search facility, and simply adding a "add to list" option for
by author. Further, when editing an existing list, it must be easy Further, when editing an existing list, it must be easy to add
to add additional drafts, and it must be easy to remove drafts from a additional drafts, and it must be easy to remove drafts from a list.
list.
2.1.5. 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 for creating lists. It should
be easy to add each of the following attributes when adding to or be easy to add each of the following attributes when adding to or
editing a list: 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
o All drafts that contain a particular text string o All drafts that contain a particular text string
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 every hour. 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 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.6. Requirement: Lists can dynamically include other lists 2.1.7. Requirement: Lists can dynamically include other lists
If a user is authorized to see the contents of a list, he or she can 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 include that other list in a different list. When the referenced
list changes, those changes are also reflected in the referring-to 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; 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. list B changes, the set of drafts in list A is automatically changed.
This feature is expected to be useful for experts (particularly WG This feature is expected to be useful for experts (particularly WG
chairs) who create lists on topics that others might consider chairs) who create lists on topics that others might consider
interesting. For example, if Alice creates a list that contains all 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 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 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 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 includes references to Alice's list as well as to a similar list
that Eric put together. that Eric put together.
There needs to be some way to prevent circular references in lists
that refer to other lists.
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. Depending on the method for keeping lists
private or anonymous, 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. For example, if the lists are user-
based, a user might be limited to having only a certain number of
lists; if they are anonymous, the Datatracker might have test to
prove that the person creating the list actually exists, such as a
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
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.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
list". 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 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 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 to the list: one for every change in status, and another for
significant change of status. Each Atom feed will have a stable URL significant change of status. Each Atom feed will have a stable URL
that can be used by feed readers. that can be used by feed readers.
Many IETF users are already using Atom feeds created by the IETF Many IETF users are already using Atom feeds created by the IETF
Tools Team for individual drafts. Using the new feeds for lists Tools Team for individual drafts. Using the new feeds for lists
described here will allow them to have better selection capabilities described here will allow them to have better selection capabilities
to reduce the number of feeds they need to follow. to reduce the number of feeds they need to follow.
2.2.3. Requirement: Every list has mail streams associated with it 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 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
(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.
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.)
2.3. Display in the Datatracker 2.2.5. Later Requirement: The tool must have instructions on how to use
it Atom feeds
When a list is displayed to the user in the Datatracker's web Even though Atom feeds have been around for years, they are new to
interface, each row represents a single draft. In a display, a many Internet users, and even experienced users only know how to use
particular draft should only included once; for example, if someone them in limited ways. The Datatracker should have at least a few
manually adds draft-ietf-cuteacronym-sometopic to his list and also paragraphs explaining how the Atom feeds that it provides can be used
specifies that all drafts from the "cuteacronym" WG are included in in different tools such as dedicated feed readers, online feed-
the list, that draft should only appear once in the display. 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 2.3.1. Requirement: Users can define how the rows are sorted in a
display display
There are many ways that a user might want to see the Datatracker's 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 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 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 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 order of changes of status so that those drafts changed recently
appear at the top of the list. appear at the top of the list.
When displaying a list, the Datatracker should allow easy sorting of The default is to first list the groups first in alphabetical order
the drafts with the following collation orders: 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 o Alphabetical by draft filename
o Alphabetical by draft title o Alphabetical by draft title
o Alphabetical by associated WG o Alphabetical by associated WG
o Date of publication of current version of the draft 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 change of status of any type
o Date of most recent significant change of status 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 Datatracker should save the last-chosen sorting for display with
the definition of the list. the definition of the list.
2.3.2. Requirement: Users can choose which attributes to display 2.3.2. Requirement: Users can choose which attributes to display
There are many attributes that might be displayed, and different 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 information that they want to see. Also,
users will have different display technologies: someone might users will have different display technologies: someone might
normally use a web browser on a large screen, but at other times use normally use a web browser on a large screen, but at other times use
the browser on their phone. the browser on their phone.
Choosing which attributes should be displayed should be simple for Choosing which attributes should be displayed should be simple for
the user. Also, the user should also be able to specify the order in the user. The Datatracker should save the last-chosen set of
which the attributes are displayed. The Datatracker should save the attributes for display with the definition of the list. The default
last-chosen set of attributes for display with the definition of the is to display is draft filename, draft title, date of current draft,
list. 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: The Datatracker should support display of the following attributes:
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 o Associated AD, if any
o Associated AD
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 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. The "included lists"
attribute might show a pop-up with the names of the lists, given that attribute might show a pop-up with the names of the lists, given that
list names might be long. list names might be long.
2.4. File Output 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 2.4.1. Requirement: Users can get their current list as a single file
Some users have their own tools for displaying and otherwise Some users have their own tools for displaying and otherwise
processing lists of drafts. To make this easier, users should be 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 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 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 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 because it is assumed that the user's program will sort the results
themselves. All attributes will be included because it is assumed themselves. All attributes will be included because it is assumed
that the user's programs will only deal with the ones the care about. that the user's programs will only deal with the ones the care about.
skipping to change at page 11, line 7 skipping to change at page 16, line 7
Datatracker views are discussed earlier in the document. Datatracker views are discussed earlier in the document.
Web applications, particularly those that store data on a web server, Web applications, particularly those that store data on a web server,
are a common source of security issues such as cross-site scripting are a common source of security issues such as cross-site scripting
attacks. The tool described in this document might also use access attacks. The tool described in this document might also use access
control for lists, and access control and authentication also cause control for lists, and access control and authentication also cause
security issues if not implemented properly. security issues if not implemented properly.
5. Acknowledgements 5. Acknowledgements
Early ideas used in this document were contributed by Russ Housley, Ideas used in this document were contributed by Scott Bradner, Leslie
John Levine, Ray Pelletier, Blake Ramsdell, Julian Reschke, Yaron Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen,
Sheffer, and Andrew Sullivan. 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.
6. References 6. Informative References
6.1. Normative 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 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
6.2. Informative References
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
Appendix A. Some Known Open Issues [WGSTATES]
Juskevicius, E., "Definition of IETF Working Group
Document States", draft-ietf-proto-wgdocument-states (work
in progress), October 2010.
Given the very early stage of this document, there are actually many Appendix A. Possible Tracking of Non-draft Documents
more open issues than are listed here. 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. Many of these topic were offered before the -00 draft
by early reviewers.
o One big feature that is desired is a way to say "tell me if this NOTE: This is the first draft to include the functionality listed in
draft does not change state in the next nnn days". This gives a the next four subsections. Thus, it is not at all clear if any of
"dashboard" style capability. Doing this will mean holding more these will be a requirement, a later requirement, or a non-
state on the Datatracker. requirement.
o People get confused about the states of non-IETF streams (IRTF, Further, even if one or more of these non-draft items is made a
IAB, ISE). These should be covered explicitly. Also, need requirement, it is not clear whether they will be included in the
definitions of "significant change in status" for the three non- same lists with drafts. That is, if tracking RFC status changes are
IETF streams. 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.
o There will be an interesting and difficult interplay between A.1. Tracking RFC Status Changes and Errata
privacy and sharing lists. If someone shares a list, that person
doesn't want anyone modifying the contents of the list. So, there
might need to be "sharing a shadow list" or something similar.
o There may be legal issues with keeping user data private if we use The contents of RFCs never change after they are published. However,
login accounts. 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.
o Is there a formal definition for "drafts associated with a Currently, the only way for the Datatracker to see these changes is
particular WG"? by polling structured files on the RFC Editor site and parsing them.
o When an AD agrees to sponsor an individual submission, does the A.2. Tracking WG Charter Changes
Datatracker consider that draft associated with the AD? If not,
that needs to be dealt with here.
o Should the file output be in all the interesting formats (XML and It will soon be easier to track changes in WG charters and
JSON and tab-separated text) or just one? 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.
o As people coalesce on requirements for display, maybe mock up some A.3. Tracking IANA Registry Changes
HTML examples and put them in the document.
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.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.
Appendix B. Some Known Open Issues
Given the early stage of this document, there are actually many more
open issues than are listed here. 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.
o There may be legal issues with keeping user data private if we use
login accounts.
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.
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.
o How prescriptive do we want to be? Should this say things like New open issues added in -02:
"JavaScript pop-up" and "CSS" and such?
o Should paging be supported for long lists in the HTML display? 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
be seen), that private information needs to be invisible in lists
so that it is not accidentally exposed.
o Should "significant change in status" be judged by the list
creator, such as by a series of check boxes for every possible
status change?
o Idea for a later requirement: A list creator can add comments
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
display.
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.
Appendix B. Differences between -00 and -01 Appendix C. Differences Between -00 and -01
Added info for the mailing list. 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
document is now clear that they are read-only.
Removed the open issue "Is there a formal definition for 'drafts
associated with a particular WG'?" based on a response from Henrik
Levkowetz on the mailing list.
Removed some open issues that could be incorporated later: "Should
paging be supported for long lists in the HTML display?" "Should the
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
say things like "JavaScript pop-up" and "CSS" and such?" because
there is no need to go to that level.
Added some more open issues.
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. 86 change blocks. 
188 lines changed or deleted 561 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/