draft-ietf-genarea-datatracker-community-08.txt   rfc6293.txt 
Network Working Group P. Hoffman Internet Engineering Task Force (IETF) P. Hoffman
Internet-Draft VPN Consortium Request for Comments: 6293 VPN Consortium
Intended status: Informational April 14, 2011 Category: Informational June 2011
Expires: October 16, 2011 ISSN: 2070-1721
Requirements for Internet-Draft Tracking by the IETF Community in the Requirements for Internet-Draft Tracking by
Datatracker the IETF Community in the Datatracker
draft-ietf-genarea-datatracker-community-08
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 and RFCs of interest to them. Internet-Drafts and RFCs of interest to them.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on October 16, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6293.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 3
1.2. Context for This Document . . . . . . . . . . . . . . . . 5 1.2. Context for This Document . . . . . . . . . . . . . . . . 4
1.3. Definitions Used in This Document . . . . . . . . . . . . 6 1.3. Definitions Used in This Document . . . . . . . . . . . . 5
1.4. Expected user interactions . . . . . . . . . . . . . . . . 7 1.4. Expected User Interactions . . . . . . . . . . . . . . . . 6
1.5. Discussion of These Requirements . . . . . . . . . . . . . 7 2. Requirements for Tools Features . . . . . . . . . . . . . . . 6
2. Requirements for Tools Features . . . . . . . . . . . . . . . 7 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 6
2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 7
2.1.2. Requirement: Every Datatracker user can create one 2.1.2. Requirement: Every Datatracker user can create one
list . . . . . . . . . . . . . . . . . . . . . . . . . 8 list . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3. Requirement: Read-only views of private lists can 2.1.3. Requirement: Read-only views of private lists can
be made visible to others . . . . . . . . . . . . . . 8 be made visible to others . . . . . . . . . . . . . . 7
2.1.4. Requirement: The Datatracker must support optional 2.1.4. Requirement: The Datatracker must support optional
publicly-readable lists for WGs and Area Directors . . 8 publicly-readable lists for WGs and Area Directors . . 7
2.1.5. Requirement: Specifying the I-Ds and RFCs that are 2.1.5. Requirement: Specifying the I-Ds and RFCs that are
in a list must be simple . . . . . . . . . . . . . . . 9 in a list must be simple . . . . . . . . . . . . . . . 8
2.1.6. Requirement: Adding groups of I-Ds to a list by 2.1.6. Requirement: Adding groups of I-Ds to a list by
attribute must be simple . . . . . . . . . . . . . . . 9 attribute must be simple . . . . . . . . . . . . . . . 8
2.1.7. Requirement: Private information must not be 2.1.7. Requirement: Private information must not be
exposed in lists . . . . . . . . . . . . . . . . . . . 10 exposed in lists . . . . . . . . . . . . . . . . . . . 9
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1. Requirement: Users can be notified when an I-D 2.2.1. Requirement: Users can be notified when an I-D
changes status . . . . . . . . . . . . . . . . . . . . 10 changes status . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Requirement: Every list has Atom feeds associated 2.2.2. Requirement: Every list has Atom feeds associated
with it . . . . . . . . . . . . . . . . . . . . . . . 10 with it . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Requirement: Every list has mail streams 2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 11 associated with it . . . . . . . . . . . . . . . . . . 10
2.2.4. Requirement: Notifications need to specify which 2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 11 list caused the notification . . . . . . . . . . . . . 10
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 11 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 10
2.3.1. Requirement: Users can define their Datatracker 2.3.1. Requirement: Users can define their Datatracker
document view . . . . . . . . . . . . . . . . . . . . 11 document view . . . . . . . . . . . . . . . . . . . . 10
2.3.2. Requirement: Users can choose which attributes to 2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 12 display . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.3. Requirement: Users can flag I-Ds with dates in the 2.3.3. Requirement: Users can flag I-Ds with dates in the
future . . . . . . . . . . . . . . . . . . . . . . . . 13 future . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.4. Requirement: Users can specify highlighting of 2.3.4. Requirement: Users can specify highlighting of
I-Ds and RFCs with recent changes . . . . . . . . . . 13 I-Ds and RFCs with recent changes . . . . . . . . . . 12
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . 13 single file . . . . . . . . . . . . . . . . . . . . . 12
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. Security Considerations . . . . . . . . . . . . . . . . . . . 13
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 5. Informative References . . . . . . . . . . . . . . . . . . . . 13
6. Informative References . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Possible Tracking of Other Data . . . . . . . . . . . 15
Appendix A. Possible Tracking of Other Documents . . . . . . . . 15
A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15 A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15
A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15 A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
A.3. Tracking Changes in the Liason Statement Directory . . . . 16 A.3. Tracking Changes in the Liason Statement Directory . . . . 15
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16 A.4. Tracking Changes in Documents Outside the IETF Sphere . . 15
A.5. Tracking Additions to the IPR Statement Repository . . . . 16 A.5. Tracking Additions to the IPR Statement Repository . . . . 16
Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16 Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
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 RFCs, and view I-Ds and RFCs the status of Internet-Drafts (I-Ds) and RFCs, and view I-Ds and RFCs
that meet particular criteria. The current Datatracker, found at that meet 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 RFCs, and get a list matching the given criteria. (The I-Ds and RFCs, and get a list matching the given criteria. (The
Datatracker also allows for expired I-Ds, but those are not relevant Datatracker also allows for expired I-Ds, but those are not relevant
to this discussion.) to this discussion.)
Users can search in the Datatracker by the filename of the I-D, words Users can search in the Datatracker by the filename of the I-D, words
in the I-D title, I-D author list, associated Working Group (WG), in the I-D title, I-D author list, associated Working Group (WG),
IETF area, the responsible Area Director (AD), or IESG status. They IETF area, the responsible Area Director (AD), or IESG status. They
can search for RFCs by number or words in the title. The returned can search for RFCs by number or words in the title. The returned
list of I-Ds and/or RFCs includes six columns: filename or RFC number list of I-Ds and/or RFCs includes six columns: filename or RFC
(with an active link to an HTMLized version maintained by the IETF number, the document's title, the date it was published, its status
tools team), the document's title, the date it was published, its in the IETF or RFC process, IPR statements, and the responsible AD
status in the IETF or RFC process, IPR statements, and the (if any).
responsible AD (if any). For example, the output of a search in the
current Datatracker can be seen at <http://imgur.com/DD3AL>. [[ Note
to RFC Editor: Please remve the preceding sentence ("For example,
...") before publication. ]]
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 and RFCs of interest, users might want to create a list of find I-Ds and RFCs of interest, users might want to create a list of
I-Ds that they normally follow. Some users will want to keep their I-Ds that they normally follow. Some users will want to keep their
list to themselves, but others will want to allow others to view list to themselves, but others will want to allow others to view
their list. their 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 I-D and RFC updates and status. Many they want to get information on I-D and RFC updates and status. Many
users will want to be notified immediately, such as through an Atom users will want to be notified immediately, such as through an Atom
feed (see [RFC4287]) or automatically-generated email. Many users feed (see [RFC4287]) or automatically-generated email. Many users
will want to only find out about updates when they go to a web page. 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 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 tools. And, of course, some users will want all three. All of these
assist users in tracking I-Ds through their lifecycle. assist users in tracking I-Ds through their lifecycle.
1.1. Usage Scenarios 1.1. Usage Scenarios
The main motivation for these proposed changes to the Datatracker is The main motivation for these proposed changes to the Datatracker is
to allow a variety of potential users to be able to track I-Ds and to allow a variety of potential users to be able to track I-Ds and
RFCs, and thus be better able to see when important events happen. A RFCs, and thus be better able to see when important events happen. A
few examples include: few examples include:
o A WG chair might want to keep a list of all the I-Ds from other o A WG chair might want to keep a list of all the I-Ds from other
WGs that relate to active I-Ds in his or her WG. WGs that relate to active I-Ds in his or her WG.
o That same WG chair might want to help WG members be able to follow o That same WG chair might want to help WG members be able to follow
the same I-Ds that he or she is following. the same I-Ds that he or she is following.
o Someone who cares about an established topic such as the DNS may o Someone who cares about an established topic such as the DNS may
want to follow the various I-Ds that might make changes to the want to follow the various I-Ds that might make changes to the
DNS, as well as seeing if any of the DNS RFCs are later updated DNS, as well as be aware if any of the DNS RFCs are later updated
and/or have errata posted against them. This would include not and/or have errata posted against them. This would include not
only I-Ds that are in the many WGs that directly are changing the only I-Ds that are in the many WGs that directly are changing the
DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual
submissions, IAB I-Ds, and even IRTF I-Ds. It would also include submissions, IAB I-Ds, IRTF I-Ds, and Independent submissions.
RFCs from before when WGs were tracked.
o Developers who are not active in the IETF process might want to o Developers who are not active in the IETF process might want to
lightly follow I-Ds and RFCs on a particular topic to watch for lightly follow I-Ds and RFCs on a particular topic to watch for
things that might affect their implementations. things that might affect their implementations.
o An IETF "regular" might want to follow parts of the process by o An IETF "regular" might want to follow parts of the process by
focusing on all the I-Ds that are being shepherded by a particular focusing on all the I-Ds that are being shepherded by a particular
Area Director. Area Director.
1.2. Context for This Document 1.2. Context for This Document
skipping to change at page 5, line 42 skipping to change at page 4, line 44
Some of the requirements in this document are listed as "later Some of the requirements in this document are listed as "later
requirements". It is expected that items listed in this document requirements". It is expected that items listed in this document
would be part of the initial RFP because they provide the highest would be part of the initial RFP because they provide the highest
benefit to the community; the later requirements might be part of a benefit to the community; the later requirements might be part of a
later RFP. later RFP.
The initial general requirements that led to the specific The initial general requirements that led to the specific
requirements this document described tools that include: requirements this document described tools that include:
o the ability to create one or more (possibly large) lists of I-Ds o the ability to create one or more (possibly large) lists of I-Ds
that they want to follow that community members want to follow
o the ability to get notifications when individual I-Ds from a list o the ability to get notifications when particular I-Ds from a list
change state change state
o the ability to see all of the state changes that have occurred on o the ability to see all of the state changes that have occurred on
all the I-Ds in a list over a specified range of dates all the I-Ds in a list over a specified range of dates
o the ability to set the granularity of the changes (such as "every o the ability to set the granularity of the changes (such as "every
change", "just approvals and publication", and so on) change", "just approvals and publication", and so on)
o the ability to organize their views of a list in many fashions o the ability to organize views of a list in many fashions that
that would be useful to different types of community members would be useful to different types of community members
o the ability to share and merge lists with other community members o the ability to share and merge lists with other community members
Note that [RFC2026] describes the process that I-Ds go through before Note that [RFC2026] describes the process that I-Ds go through before
they either become RFCs or are abandoned. The Datatracker does not they either become RFCs or are abandoned. The Datatracker does not
control this process: instead, it simply reports on the current state control this process: instead, it simply reports on the current state
of each I-D as it goes through the process. of each I-D as it goes through the process.
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 a member of the IETF
community.
A "list" is an unordered set of RFCs, I-Ds, and groups of I-Ds. A "list" is an unordered set of RFCs, I-Ds, and groups of I-Ds.
Lists are specified by users. In some cases, the authors are role- 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 based, such as a WG chair being the specifier of the list associated
with that WG. with that WG.
An "attribute" is a feature of an I-D or RFC, such as its filename or An "attribute" is a feature of an I-D or RFC, such as its filename or
RFC number, its current state in the IETF or RFC process, and so on. RFC number, its current state in the IETF or RFC process, and so on.
Attributes are usually displayed as columns in the Datatracker. Attributes are usually displayed as columns in the Datatracker.
skipping to change at page 7, line 13 skipping to change at page 6, line 17
IESG Request" IESG Request"
o All streams: in addition to the above, the disposition states o All streams: in addition to the above, the disposition states
"Approved", "RFC Published", and "Dead" are also included "Approved", "RFC Published", and "Dead" are also included
An "update to an RFC" is the announcement of a newer RFC that updates An "update to an RFC" is the announcement of a newer RFC that updates
or obsoletes the base RFC, an in-place change to the RFC's maturity or obsoletes the base RFC, an in-place change to the RFC's maturity
level, the RFC's status being changed to historic, or an announcement level, the RFC's status being changed to historic, or an announcement
of an errata posted for the base RFC. of an errata posted for the base RFC.
1.4. Expected user interactions 1.4. Expected User Interactions
When a user wants to follow a group of I-Ds and/or RFCs, he or she When a user wants to follow a group of I-Ds and/or RFCs, he or she
goes to the Datatracker and creates a new list. The requirements for goes to the Datatracker and creates a new list. The requirements for
lists are given in Section 2.1. After a list is created, the user lists are given in Section 2.1. After a list is created, the user
has three ways that he or she might see when I-Ds and/or RFCs in the has three ways that he or she might see when I-Ds and/or RFCs in the
list are updated: list are updated:
o By going to the Datatracker page for the list (see Section 2.3) 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) o By subscribing to the Atom feed for the list (see Section 2.2.2)
in a feed reader that automatically fetches updates in a feed reader that automatically fetches updates
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 mail stream in their mail reader and reading the mail stream in their mail reader
1.5. Discussion of These Requirements
[[ This section is to be removed before the RFC is published. ]]
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>.
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 I-Ds and RFCs can be large 2.1.1. Requirement: Lists of I-Ds and RFCs 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 I-Ds and dozens of RFCs. For example, some ADs have 100 hundreds of I-Ds and dozens of RFCs; for example, some ADs have 100
I-Ds in their area, and they may also want to follow I-Ds outside I-Ds in their area. Additionally, they may also want to follow I-Ds
their area that affect documents in their area. outside their area that affect documents in their area.
2.1.2. Requirement: Every Datatracker user can create one list 2.1.2. Requirement: Every Datatracker user can create one list
When a user gets a Datatracker account, that account comes with an When a user gets a Datatracker account, that account comes with an
empty list pre-defined. The list can normally be modified only by empty list pre-defined. The list can normally be modified only by
the owner of the account, although the Secretariat can also modify the owner of the account, although the Secretariat can also modify
the list as part of its support role for the Datatracker. Each the list as part of its support role for the Datatracker. Each
Datatracker user is restricted to having one list. Datatracker user is restricted to having one list.
In order for this requirement to be met, it must be easy for any In order for this requirement to be met, it must be easy for any
skipping to change at page 8, line 45 skipping to change at page 7, line 44
2.1.4. Requirement: The Datatracker must support optional publicly- 2.1.4. Requirement: The Datatracker must support optional publicly-
readable lists for WGs and Area Directors readable lists for WGs and Area Directors
It is common in the IETF for users to follow the work of an entire It is common in the IETF for users to follow the work of an entire
WG, not just single I-Ds and RFCs within a WG. It is also very WG, not just single I-Ds and RFCs within a WG. It is also very
common that some work that is related to a WG happens outside the WG, common that some work that is related to a WG happens outside the WG,
either in other WGs or as individual efforts. Many WG chairs monitor either in other WGs or as individual efforts. Many WG chairs monitor
this outside-the-WG activity for various reasons. this outside-the-WG activity for various reasons.
A smaller number of community members to follow an entire Area's A smaller number of community members follow an entire Area's worth
worth of topics. Again, these topics often happen within the WGs of of topics. Again, these topics often happen within the WGs of an
an area, but not always; for example, some topics related to the area, but not always; for example, some topics related to the
Security Area happen in WGs in the Applications Area. Security Area happen in WGs in the Applications Area.
Because of this, it would be useful for community members to be able Because of this, it would be useful for community members to be able
to find a list which corresponds to the WGs or Areas in which they to find a list that corresponds to the WGs or Areas in which they are
are interested. The WG lists could be maintained by the WG chairs; interested. The WG lists could be maintained by the WG chairs; the
the Area lists would likely be maintained by the ADs. Note that such Area lists would likely be maintained by the ADs. Note that such
lists are not mandatory; for example, a WG chair might not choose to lists are not mandatory; for example, a WG chair might not choose to
maintain such a list for a WG whose topic is extremely broad. maintain such a list for a WG whose topic is extremely broad.
Both Working Group chairs and Area Directors currently already have Both Working Group chairs and Area Directors currently already have
Datatracker accounts, so fulfilling this requirement only involves Datatracker accounts, so fulfilling this requirement only involves
associating those accounts with the role that controls the list. associating those accounts with the role that controls the list.
2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list 2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list
must be simple must be simple
When a user creates a new list, it must be easy to add single I-Ds When a user creates a new list, it must be easy to add single I-Ds
and RFCs to the list. This could be done using the Datatracker's and RFCs to the list. This could be done using the Datatracker's
current search facility, and simply adding a "add to list" option to current search facility, and simply adding an "add to list" option to
the display of searched-for I-Ds. Further, when editing an existing the display of searched-for I-Ds. Further, when editing an existing
list, it must be easy to add additional I-Ds and RFCs, and it must be list, it must be easy to add additional I-Ds and RFCs, and it must be
easy to remove I-Ds and RFCs from a list. easy to remove I-Ds and RFCs from a list.
2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must 2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must
be simple be simple
I-Ds have many attributes, and some users might want to follow all of I-Ds have many attributes, and some users might want to follow all of
the I-Ds that have a particular attribute. Some, but not all, the I-Ds that have a particular attribute. Some, but not all,
attributes have values that make sense in specifying lists. It attributes have values that make sense in specifying lists. It
skipping to change at page 10, line 42 skipping to change at page 9, line 42
in the next two sections. in the next two sections.
The Datatracker might create a generic "notifications engine" that The Datatracker might create a generic "notifications engine" that
can be used to generate the Atom feeds and mail streams. This engine 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 can then be used to later add other notification types, such as a
Jabber feed. 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 single I-Ds. Using the new feeds for lists described Tools Team for single I-Ds. Using the new feeds for lists described
here will allow them to have better selection capabilities to reduce here will allow them to have better selection capabilities to reduce
the number of feeds they need to follow. 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
skipping to change at page 12, line 4 skipping to change at page 10, line 51
o Alphabetical by I-D filename and RFC number o Alphabetical by I-D filename and RFC number
o Alphabetical by document title o Alphabetical by document title
o Alphabetical by associated WG o Alphabetical by associated WG
o Date of publication of current version of the document o Date of publication of current version of the document
o Date of most recent change of status of any type o Date of most recent 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 I-D or RFC should only be included once; In displays, a particular I-D or RFC should only be included once;
for example, if someone manually adds for example, if someone manually adds
draft-ietf-cuteacronym-sometopic to his list and also specifies that draft-ietf-cuteacronym-sometopic to his list and also specifies that
all I-Ds from the "cuteacronym" WG are included in the list, that I-D all I-Ds from the "cuteacronym" WG are included in the list, that I-D
should only appear once in the display. The column saying which should only appear once in the display. The column saying which
included list(s) contain this I-D helps alleviate this loss of included list(s) contain this I-D helps alleviate this loss of
information. information.
The user might also want to group the I-Ds using the groupings in the The user might also want to group the I-Ds using the groupings in the
list, such as "all I-Ds from this WG" and "all I-Ds that contain this list, such as "all I-Ds from this WG" and "all I-Ds that contain this
word in the title". 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. The Datatracker should save the last-chosen set of the user. The Datatracker should save the last-chosen set of
attributes for display with the definition of the list. The default attributes for display with the definition of the list. The default
is to display the I-D filename or RFC number, document title, date of is to display the I-D filename or RFC number, document title, date of
current I-D or RFC publication date, status in the RFC stream or RFC current I-D or RFC publication date, status in the RFC queue or RFC
process, the associated stream (IETF WG, IRTF RG, IAB, or ISE), process, the associated stream (IETF WG, IRTF RG, IAB, or ISE),
whether it was changed within the last 7 days, and included list(s) whether it was changed within the last 7 days, and included list(s)
which contain this I-D. that contain this I-D.
The Datatracker should support display of the following attributes: The Datatracker should support display of the following attributes:
o I-D filename o I-D filename
o I-D title o I-D title
o Date of current I-D o Date of current I-D
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
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. shown with a check mark or a colored box.
2.3.3. Requirement: Users can flag I-Ds with dates in the future 2.3.3. Requirement: Users can flag I-Ds with dates in the future
skipping to change at page 14, line 13 skipping to change at page 13, line 13
user cares about. user cares about.
When a list is marshaled into a data file, each record in the file When a list is marshaled into a data file, each record in the file
format represents a single I-D or RFC. In a file, a particular I-D format represents a single I-D or RFC. In a file, a particular I-D
or RFC is only included once; for example, if someone manually adds or RFC is only included once; for example, if someone manually adds
draft-ietf-cuteacronym-sometopic to his list and also specifies that draft-ietf-cuteacronym-sometopic to his list and also specifies that
all I-Ds from the "cuteacronym" WG are included in the list, that I-D all I-Ds from the "cuteacronym" WG are included in the list, that I-D
only appears once. only appears once.
This feature will allow anyone to create mash-ups of their own and This feature will allow anyone to create mash-ups of their own and
create their own web sites based on the IETF data. This is create their own Web sites based on the IETF data. This is
significantly easier than adding features to the Datatracker, and is significantly easier than adding features to the Datatracker, and is
able to cater to narrow audiences. The format of this file has yet able to cater to narrow audiences. The format of this file has yet
to be determined. to be determined.
3. IANA Considerations 3. Security Considerations
None.
4. Security Considerations
A tool for tracking the status of I-Ds and RFCs can affect the A tool for tracking the status of I-Ds and RFCs can affect the
privacy of its users. Someone could possibly determine relevant privacy of its users. Someone could possibly determine relevant
information about a user if they knew what that user was tracking. information about a user if they knew what that user was tracking.
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 4. Acknowledgements
Ideas used in this document were contributed by Scott Bradner, Leslie Ideas used in this document were contributed by Scott Bradner, Leslie
Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen, Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen,
Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy
Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad, Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad,
Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner. Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner.
6. Informative References 5. Informative References
[ALTSTREAMS] [ALTSTREAMS] Hoffman, P., "Data Tracker States and Annotations for
Hoffman, P., "Data Tracker States and Annotations for the the IAB, IRTF, and Independent Submission Streams",
IAB, IRTF, and Independent Submission Streams", Work in Progress, May 2011.
draft-hoffman-alt-streams-tracker (work in progress),
September 2010.
[CHARTERTOOL] [RFC2026] Bradner, S., "The Internet Standards Process --
Hoffman, P., "Requirements for a Working Group Charter Revision 3", BCP 9, RFC 2026, October 1996.
Tool", draft-ietf-genarea-charter-tool (work in progress),
October 2010.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
3", BCP 9, RFC 2026, October 1996. Syndication Format", RFC 4287, December 2005.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC6174] Juskevicius, E., "Definition of IETF Working Group
Syndication Format", RFC 4287, December 2005. Document States", RFC 6174, March 2011.
[RFC6174] Juskevicius, E., "Definition of IETF Working Group [RFC6175] Juskevicius, E., "Requirements to Extend the
Document States", RFC 6174, March 2011. Datatracker for IETF Working Group Chairs and Authors",
RFC 6175, March 2011.
[RFC6175] Juskevicius, E., "Requirements to Extend the Datatracker [RFC6292] Hoffman, P., "Requirements for a Working Group Charter
for IETF Working Group Chairs and Authors", RFC 6175, Tool", RFC 6292, June 2011.
March 2011.
Appendix A. Possible Tracking of Other Documents Appendix A. Possible Tracking of Other Data
It is not at all clear if any of these will be a requirement, a later It is not at all clear if any of these will be a requirement, a later
requirement, or a non-requirement. Further, even if one or more of requirement, or a non-requirement. Further, even if one or more of
these non-I-D items is made a requirement, it is not clear whether these non-I-D items is made a requirement, it is not clear whether
they will be included in the same lists with I-Ds. That is, if they will be included in the same lists with I-Ds. That is, if
tracking IANA registry changes are considered a requirement, it is tracking IANA registry changes are considered a requirement, it is
not clear whether a user would include the registries in a list that not clear whether a user would include the registries in a list that
also contains I-Ds, or whether they would need to create two lists, also contains I-Ds, or whether they would need to create two lists,
one for I-Ds and one for IANA registries. one for I-Ds and one for IANA registries.
A.1. Tracking WG Charter Changes A.1. Tracking WG Charter Changes
It will soon be easier to track changes in WG charters and It will soon be easier to track changes in WG charters and
milestones; see [CHARTERTOOL] for more information. Someone milestones; see [RFC6292] for more information. Someone subscribing
subscribing to the mail stream for a WG would be able to see each of to the mail stream for a WG would be able to see each of these
these changes. With the expected changes, the Datatracker would be changes. With the expected changes, the Datatracker would be able to
able to update WGs in a list without any polling. update WGs in a list without any polling.
A.2. Tracking IANA Registry Changes A.2. Tracking IANA Registry Changes
Developers may need to get values from IANA registries for their Developers may need to get values from IANA registries for their
software/hardware implementations. They might want to know when the software/hardware implementations. They might want to know when the
registry changes, such as additional entries or updates to current registry changes, such as additional entries or updates to current
entries. Thus, being able to be notified when a registry changes entries. Thus, being able to be notified when a registry changes
would be valuable to them. would be valuable to them.
Adding this functionality may be tricky for some registries. For Adding this functionality may be tricky for some registries. For
skipping to change at page 16, line 14 skipping to change at page 15, line 44
have to subscribe to have to subscribe to
<http://www.iana.org/assignments/dkim-parameters/> which (currently) <http://www.iana.org/assignments/dkim-parameters/> which (currently)
covers a handful of registries, all related to DKIM. Thus, a change covers a handful of registries, all related to DKIM. Thus, a change
to the DKIM hash algorithms would trigger a message showing that the to the DKIM hash algorithms would trigger a message showing that the
registry had changed, even though the DKIM signature tags registry registry had changed, even though the DKIM signature tags registry
had not. had not.
A.3. Tracking Changes in the Liason Statement Directory A.3. Tracking Changes in the Liason Statement Directory
Users might want to know when a new liaison statement is sent by the Users might want to know when a new liaison statement is sent by the
IETF, or when one is received by the IETF. IETF or when one is received by the IETF.
A.4. Tracking Changes in Documents Outside the IETF Sphere A.4. Tracking Changes in Documents Outside the IETF Sphere
Users might want to track documents that relate to IETF activities Users might want to track documents that relate to IETF activities
but are produced by other standards development organizations (SDOs) but are produced by other standards development organizations (SDOs)
such as the W3C, the IEEE, the Unicode Consortium, the ITU, and such as the W3C, the IEEE, the Unicode Consortium, the ITU, and
others. In order for the tracker to track these documents, it would others. In order for the tracker to track these documents, it would
need to poll occasionally and possibly scrape listings from HTML. need to poll occasionally and possibly scrape listings from HTML.
A.5. Tracking Additions to the IPR Statement Repository A.5. Tracking Additions to the IPR Statement Repository
Users might want to know when a new IPR statement is submitted. Users might want to know when a new IPR statement is submitted.
Appendix B. Ideas that Might Be Implemented Later Appendix B. Ideas that Might Be Implemented Later
The following are ideas for the new tool that are not currently being The following are ideas for the new tool that are not currently being
considered for the first round of development, but are being considered for the first round of development, but are being
documented for possible future use. Items here might move between documented for possible future use. Items from this list may move to
this list and the list of requirements that are expected to be in the the list of requirements that are expected to be integrated during
first round. the first round of development.
o The Datatracker could list all of the publicly-readable lists (or o The Datatracker could list all of the publicly-readable lists (or
certainly at least the ones associated with IETF activities), and certainly at least the ones associated with IETF activities), and
have links from WG pages in Datatracker to the publicly-readable have links from WG pages in the Datatracker to the publicly-
lists maintained by the WG chairs. readable lists maintained by the WG chairs.
o Earlier versions of this I-D had a requirement that lists needed o Draft versions of this RFC included a requirement to be able to
to be able to include other lists. While this may still be include other lists. While this may still be desired, it was
desired, it was decided that implementing this in a safe and decided that implementing this in a safe and understandable way
understandable way would be too difficult. In particular, there would be too difficult. In particular, there was a concern about
was a concern about detecting and handling loops. Later versions detecting and handling loops. Later versions of the Datatracker
of the Datatracker might include this feature. might include this feature.
o In public lists, it might be useful for someone to be able to o In public lists, it might be useful for someone to be able to
understand why particular I-Ds and/or groups are added. Allowing understand why particular I-Ds and/or groups are added. Allowing
the user who put together the list to add a comment field would the user who put together the list to add a comment field would
help someone else see the motivation. help someone else understand the motivation.
o The Datatracker might remove lists if it seems that storing them o The Datatracker might remove lists if it seems that storing them
on the Datatracker is taking too many resources. The Datatracker on the Datatracker is taking too many resources. The Datatracker
can periodically send mail to the user reminding them to delete can periodically send mail to the user reminding them to delete
lists that are no longer needed. lists that are no longer needed.
o The normal Datatracker display could have a button to add a o The normal Datatracker display could have a button to add a
particular I-D to the user's personal list. particular I-D to the user's personal list.
o Allow each user to determine what "significant change in status" o Allow each user to determine what "significant change in status"
skipping to change at page 17, line 45 skipping to change at page 17, line 25
use them in limited ways. The Datatracker should have at least a use them in limited ways. The Datatracker should have at least a
few paragraphs explaining how the Atom feeds that it provides can few paragraphs explaining how the Atom feeds that it provides can
be used in different tools such as dedicated feed readers, online be used in different tools such as dedicated feed readers, online
feed-display services, and so on. feed-display services, and so on.
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. 65 change blocks. 
142 lines changed or deleted 117 lines changed or added

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