draft-ietf-genarea-datatracker-community-03.txt   draft-ietf-genarea-datatracker-community-04.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational December 20, 2010 Intended status: Informational January 17, 2011
Expires: June 23, 2011 Expires: July 21, 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-03 draft-ietf-genarea-datatracker-community-04
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 June 23, 2011. This Internet-Draft will expire on July 21, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
1.2. Context for This Document . . . . . . . . . . . . . . . . 5 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
1.3. Definitions Used in This Document . . . . . . . . . . . . 6 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
1.4. Expected user interactions . . . . . . . . . . . . . . . . 7 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7
1.5. Discussion of These Requirements . . . . . . . . . . . . . 7 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
2. Requirements for Tools Features . . . . . . . . . . . . . . . 7 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1. Requirement: Lists of drafts can be large . . . . . . 7 2.1.1. Requirement: Lists of drafts can be large . . . . . . 7
2.1.2. Requirement: Every Datatracker user can create a 2.1.2. Requirement: Every Datatracker user can create a
list . . . . . . . . . . . . . . . . . . . . . . . . . 7 list . . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . 8
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 . . 8
2.1.5. Requirement: Specifying the drafts that are in a 2.1.5. Requirement: Specifying the drafts that are in a
list must be simple . . . . . . . . . . . . . . . . . 9 list must be simple . . . . . . . . . . . . . . . . . 9
2.1.6. Requirement: Adding groups of drafts to a list by 2.1.6. Requirement: Adding groups of drafts to a list by
attribute must be simple . . . . . . . . . . . . . . . 9 attribute must be simple . . . . . . . . . . . . . . . 9
2.1.7. Tombstone: lists dynamically including other lists . . 9 2.1.7. Tombstone: lists dynamically including other lists . . 10
2.1.8. Later Requirement: Users can add comments to say 2.1.8. Later Requirement: Users can add comments to say
why they added a draft or group . . . . . . . . . . . 10 why they added a draft or group . . . . . . . . . . . 10
2.1.9. Requirement: These extensions must not make the 2.1.9. Requirement: These extensions must not make the
Datatracker take up too many resources . . . . . . . . 10 Datatracker take up too many resources . . . . . . . . 10
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10 2.1.10. Requirement: Private information must not be
exposed in lists . . . . . . . . . . . . . . . . . . . 11
2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1. Requirement: Users can be notified when a draft 2.2.1. Requirement: Users can be notified when a draft
changes status . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . 11 with it . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.3. Requirement: Every list has mail streams 2.2.3. Requirement: Every list has mail streams
associated with it . . . . . . . . . . . . . . . . . . 11 associated with it . . . . . . . . . . . . . . . . . . 11
2.2.4. Requirement: Notifications need to specify which 2.2.4. Requirement: Notifications need to specify which
list caused the notification . . . . . . . . . . . . . 11 list caused the notification . . . . . . . . . . . . . 12
2.2.5. Later Requirement: The tool must have instructions 2.2.5. Later Requirement: The tool must have instructions
on how to use it Atom feeds . . . . . . . . . . . . . 11 on how to use it Atom feeds . . . . . . . . . . . . . 12
2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12
2.3.1. Requirement: Users can define how the rows are 2.3.1. Requirement: Users can define how the rows are
sorted in a display . . . . . . . . . . . . . . . . . 12 sorted in a display . . . . . . . . . . . . . . . . . 12
2.3.2. Requirement: Users can choose which attributes to 2.3.2. Requirement: Users can choose which attributes to
display . . . . . . . . . . . . . . . . . . . . . . . 12 display . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3. Requirement: Users can flag drafts with dates in 2.3.3. Requirement: Users can flag drafts with dates in
the future . . . . . . . . . . . . . . . . . . . . . . 13 the future . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4. Requirement: Users can specify highlighting of 2.3.4. Requirement: Users can specify highlighting of
drafts with recent changes . . . . . . . . . . . . . . 13 drafts with recent changes . . . . . . . . . . . . . . 14
2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14
2.4.1. Requirement: Users can get their current list as a 2.4.1. Requirement: Users can get their current list as a
single file . . . . . . . . . . . . . . . . . . . . . 14 single file . . . . . . . . . . . . . . . . . . . . . 14
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
6. Informative References . . . . . . . . . . . . . . . . . . . . 15 6. Informative References . . . . . . . . . . . . . . . . . . . . 16
Appendix A. Possible Tracking of Non-draft Documents . . . . . . 15 Appendix A. Possible Tracking of Non-draft Documents . . . . . . 16
A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 16 A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 16
A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 16 A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 17
A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 16 A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 17
A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16 A.4. Tracking Changes in the Liason Statement Directory . . . . 17
Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 16 A.5. Tracking Changes in Documents Outside the IETF Sphere . . 17
Appendix C. Differences Between -02 and -03 . . . . . . . . . . . 17 Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix C. Ideas that Might Be Implemented Later . . . . . . . . 18
Appendix D. Differences Between -03 and -04 . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
IMPORTANT NOTE: This is an early draft of a set of requirements. It
has gone through one round of community review at IETF 79 in Beijing,
and thus probably is missing things that should be included, and some
of the things in this draft are wrong and will be changed in future
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,
words in the draft's title, author, associated Working Group (WG) or words in the draft's title, author, associated Working Group (WG) or
skipping to change at page 10, line 41 skipping to change at page 11, line 11
lists if it seems that storing them on the Datatracker is taking too lists if it seems that storing them on the Datatracker is taking too
many resources. The Datatracker can periodically send mail to the many resources. The Datatracker can periodically send mail to the
user reminding them to delete lists that are no longer needed. user reminding them to delete lists that are no longer needed.
Culling presents a problem, however, for user-based lists that are Culling presents a problem, however, for user-based lists that are
made public. The creator of a list might no longer be using it, but made public. The creator of a list might no longer be using it, but
others might be. Thus, it is likely that the Datatracker needs to be 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 be able to maintain lists long-term even if their creators are no
longer using them. longer using them.
2.1.10. Requirement: Private information must not be exposed in lists
Any private information in the Datatracker must be excluded from any
displays of the lists or streams created in this document. This
private information includes private notes in the IESG balloting for
a draft, and probably other data that currently is restricted to
being seen by certain members of the IETF leadership.
2.2. Notifications 2.2. 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". This requirement can be met with Atom feeds and mail streams, list". This requirement can be met with Atom feeds and mail streams,
skipping to change at page 15, line 39 skipping to change at page 16, line 33
[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.
[WGSTATES] [WGSTATES]
Juskevicius, E., "Definition of IETF Working Group Juskevicius, E., "Definition of IETF Working Group
Document States", draft-ietf-proto-wgdocument-states (work Document States", draft-ietf-proto-wgdocument-states (work
in progress), October 2010. in progress), October 2010.
Appendix A. Possible Tracking of Non-draft Documents Appendix A. Possible Tracking of Non-draft Documents
NOTE: This is the first draft to include the functionality listed in It is not at all clear if any of these will be a requirement, a later
the next four subsections. Thus, it is not at all clear if any of requirement, or a non-requirement. Further, even if one or more of
these will be a requirement, a later requirement, or a non- these non-draft items is made a requirement, it is not clear whether
requirement. they will be included in the same lists with drafts. That is, if
tracking RFC status changes are considered a requirement, it is not
Further, even if one or more of these non-draft items is made a clear whether a user would include the RFCs in a list that also
requirement, it is not clear whether they will be included in the contains draft, or whether they would need to create two lists, one
same lists with drafts. That is, if tracking RFC status changes are for drafts and one for RFCs.
considered a requirement, it is not clear whether a user would
include the RFCs in a list that also contains draft, or whether they
would need to create two lists, one for drafts and one for RFCs.
A.1. Tracking RFC Status Changes and Errata A.1. Tracking RFC Status Changes and Errata
The contents of RFCs never change after they are published. However, The contents of RFCs never change after they are published. However,
that does not mean that nothing alters the meaning of the RFC. In that does not mean that nothing alters the meaning of the RFC. In
specific, an RFC can be updated or obsoleted by another RFC; also, specific, an RFC can be updated or obsoleted by another RFC; also,
errata can be made against RFCs. A user who cares about the RFC errata can be made against RFCs. A user who cares about the RFC
might want to know when these changes are made. might want to know when these changes are made.
Currently, the only way for the Datatracker to see these changes is Currently, the only way for the Datatracker to see these changes is
skipping to change at page 16, line 41 skipping to change at page 17, line 33
Adding this functionality may be tricky for some registries. For Adding this functionality may be tricky for some registries. For
example, if a developer cared about DKIM signature tags, they would example, if a developer cared about DKIM signature tags, they would
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.4. Tracking Changes in Documents Outside the IETF Sphere A.4. Tracking Changes in the Liason Statement Directory
Users might want to know when a new liaison statement is sent by the
IETF, or when one is received by the IETF.
A.5. Tracking Changes in Documents Outside the IETF Sphere
Users might want to track documents that relate to IETF activities 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.
Appendix B. Some Known Open Issues Appendix B. Some Known Open Issues
Given the early stage of this document, there are actually many more This list is mostly meant to remind the author of topics that need to
open issues than are listed here. This list is mostly meant to be updated in future versions of the document, and to spur readers to
remind the author of topics that need to be updated in future think of even more open issues.
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 o When an AD agrees to sponsor an individual submission, does the
Datatracker consider that draft associated with the AD? If not, Datatracker consider that draft associated with the AD? If not,
that needs to be dealt with here. that needs to be dealt with here.
o Thought: add a button in the normal Datatracker output to add a
particular draft to a particular list. Appendix C. Ideas that Might Be Implemented Later
o If the Datatracker contains private information (that is still to
be seen), that private information needs to be invisible in lists The following are ideas for the new tool that are not currently being
so that it is not accidentally exposed. considered for the first round of development, but are being
o Should "significant change in status" be judged by the list documented for possible future use. Items here might move between
creator, such as by a series of check boxes for every possible this list and the list of requirements that are expected to be in the
status change? first round.
o Idea for a later requirement: A list creator can add comments
about who might be interested in following the list. o The normal Datatracker display could have a button to add a
o It should be easy to remove items from list in the Datatracker particular draft to the user's personal list.
display.
o Allow each user to determine what "significant change in status"
is for the list they create. This could be done by a series of
check boxes for every possible status change.
o A list creator can add a list-level comment about who might be
interested in following the list.
o If the agendas for an upcoming meeting are scraped for draft o If the agendas for an upcoming meeting are scraped for draft
names, it would be possible to add an attribute to a draft that names, it would be possible to add an attribute to a draft that
lists that WG agenda(s) on which it appears. lists that WG agenda(s) on which it appears.
o In the section on "Adding groups of drafts to a list by
attribute", add an attribute for "all drafts that are referenced
by any draft in a particular list".
o Make it possible to add all drafts that have a certain section to o Make it possible to add all drafts that have a certain section to
a list (non-trivial IANA considerations, ASN.1 modules in a list (non-trivial IANA considerations, ASN.1 modules in
appendicies, ...). appendicies, ...).
o In 2.1.6, add "All drafts that are referenced by any draft on list
XXXX"
o Another possible stream: liaison statements.
Appendix C. Differences Between -02 and -03 Appendix D. Differences Between -03 and -04
Made the number of lists per person from "many" to "one". This was Removed the "early" note from the intro.
done throughout the document, but is particularly apparent in 2.1.2.
Resolved the "private or anonymous" question by making lists private, Added a requirement on private data not being exposed.
based on ownership of a Datatracker account. This primarily affects
2.1.3, which now also covers the requirement that private lists also
have a public read-only component. This change assumes that private
lists are a requirement.
Talked more about role-based lists, particularly in 2.1.4, making all Added an appendix of ideas that could possibly be added later.
those lists publicly-readable.
Got rid of the requirement that lists can dynamically include other Removed the "legal issues for user data" open issue because no one
lists, making 2.1.7 a tombstone. Also modifed 2.2.3 and 2.3.2 listed any.
because of this change.
Added two new open issues ("all drafts referenced by another list" Moved many open issues to the "possibly later" list.
and "liaison statements stream").
Author's Address Author's Address
Paul Hoffman Paul Hoffman
VPN Consortium VPN Consortium
Email: paul.hoffman@vpnc.org Email: paul.hoffman@vpnc.org
 End of changes. 31 change blocks. 
79 lines changed or deleted 85 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/