draft-ietf-genarea-datatracker-community-07.txt   draft-ietf-genarea-datatracker-community-08.txt 
Network Working Group P. Hoffman Network Working Group P. Hoffman
Internet-Draft VPN Consortium Internet-Draft VPN Consortium
Intended status: Informational March 31, 2011 Intended status: Informational April 14, 2011
Expires: October 2, 2011 Expires: October 16, 2011
Requirements for Internet-Draft Tracking by the IETF Community in the Requirements for Internet-Draft Tracking by the IETF Community in the
Datatracker Datatracker
draft-ietf-genarea-datatracker-community-07 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 October 2, 2011. This Internet-Draft will expire on October 16, 2011.
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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 I-Ds and RFCs can be large . . . 7 2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 7
2.1.2. Requirement: Every Datatracker user can create a 2.1.2. Requirement: Every Datatracker user can create one
list . . . . . . . . . . . . . . . . . . . . . . . . . 8 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 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 . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . 9
2.1.7. Requirement: Private information must not be 2.1.7. Requirement: Private information must not be
skipping to change at page 4, line 19 skipping to change at page 4, line 19
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 sixTestVM columns: filename or RFC list of I-Ds and/or RFCs includes six columns: filename or RFC number
number (with an active link to an HTMLized version maintained by the (with an active link to an HTMLized version maintained by the IETF
IETF tools team), the document's title, the date it was published, tools team), the document's title, the date it was published, its
its status in the IETF or RFC process, IPR statements, and the status in the IETF or RFC process, IPR statements, and the
responsible AD (if any). For example, the output of a search in the responsible AD (if any). For example, the output of a search in the
current Datatracker can be seen at <http://imgur.com/DD3AL>. [[ Note current Datatracker can be seen at <http://imgur.com/DD3AL>. [[ Note
to RFC Editor: Please remve the preceding sentence ("For example, to RFC Editor: Please remve the preceding sentence ("For example,
...") before publication. ]] ...") 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.
skipping to change at page 5, line 14 skipping to change at page 5, line 14
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 seeing 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 research. It would also submissions, IAB I-Ds, and even IRTF I-Ds. It would also include
include RFCs from before when WGs were tracked. 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 45 skipping to change at page 5, line 45
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 they want to follow
o the ability to get notifications when individual I-Ds from a list o the ability to get notifications when individual I-Ds from a list
changes 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 their views of a list in many fashions
that would be useful to different types of community members that would be useful to different types of community members
skipping to change at page 8, line 6 skipping to change at page 8, line 6
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, and they may also want to follow I-Ds outside
their area that affect documents in their area. their area that affect documents in their area.
2.1.2. Requirement: Every Datatracker user can create a 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. the list as part of its support role for the Datatracker. Each
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
community member to get a Datatracker account. Account setup must community member to get a Datatracker account. Account setup must
not involve any direct action on the part of the Secretariat. not involve any direct action on the part of the Secretariat.
However, the Secretariat will be responsible for support of However, the Secretariat will be responsible for support of
Datatracker accounts (lost passwords, odd interactions, and so on), Datatracker accounts (lost passwords, odd interactions, and so on),
so this addition of more Datatracker accounts will potentially so this addition of more Datatracker accounts will potentially
increase the amount of work the Secretariat must do. increase the amount of work the Secretariat must do.
The only person who can edit the contents of a private list is the The only person who can edit the contents of a private list is the
skipping to change at page 12, line 6 skipping to change at page 12, line 6
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 included once; for In displays, a particular I-D or RFC should only be included once;
example, if someone manually adds draft-ietf-cuteacronym-sometopic to for example, if someone manually adds
his list and also specifies that all I-Ds from the "cuteacronym" WG draft-ietf-cuteacronym-sometopic to his list and also specifies that
are included in the list, that I-D should only appear once in the all I-Ds from the "cuteacronym" WG are included in the list, that I-D
display. The column saying which included list(s) contain this I-D should only appear once in the display. The column saying which
helps alleviate this loss of information. included list(s) contain this I-D helps alleviate this loss of
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
skipping to change at page 12, line 33 skipping to change at page 12, line 34
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 stream or RFC
process, associated WG or RG, whether it was changed within the last process, the associated stream (IETF WG, IRTF RG, IAB, or ISE),
7 days, and included list(s) which contain this I-D. whether it was changed within the last 7 days, and included list(s)
which 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
skipping to change at page 13, line 15 skipping to change at page 13, line 17
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
When tracking I-Ds, some users want to be able to say "tell me if When tracking I-Ds, some users want to be able to say "tell me if
this I-D has not changes state by a particular date" such as when an this I-D has not changed state by a particular date" such as when an
I-D is starting a two-week last call or an I-D author has promised a I-D is starting a two-week last call or an I-D author has promised a
new version by the end of the week. This feature gives the user a new version by the end of the week. This feature gives the user a
"dashboard" style capability. "dashboard" style capability.
For each I-D, the user should be able to set a marker date by which For each I-D, the user should be able to set a marker date by which
an update is expected. The Datatracker display will provide a visual an update is expected. The Datatracker display will provide a visual
indication if the marker date has passed but no change in status has indication if the marker date has passed but no change in status has
occurred. It must be very easy for the user to remove these update- occurred. It must be very easy for the user to remove these update-
expected markers. expected markers.
 End of changes. 12 change blocks. 
23 lines changed or deleted 26 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/