idnits 2.17.1
draft-ietf-genarea-datatracker-community-04.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (January 17, 2011) is 4848 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Hoffman
3 Internet-Draft VPN Consortium
4 Intended status: Informational January 17, 2011
5 Expires: July 21, 2011
7 Requirements for Draft Tracking by the IETF Community in the Datatracker
8 draft-ietf-genarea-datatracker-community-04
10 Abstract
12 The document gives a set of requirements for extending the IETF
13 Datatracker to give individual IETF community members, including the
14 IETF leadership, easy methods for tracking the progress of the
15 Internet Drafts of interest to them.
17 Status of this Memo
19 This Internet-Draft is submitted in full conformance with the
20 provisions of BCP 78 and BCP 79.
22 Internet-Drafts are working documents of the Internet Engineering
23 Task Force (IETF). Note that other groups may also distribute
24 working documents as Internet-Drafts. The list of current Internet-
25 Drafts is at http://datatracker.ietf.org/drafts/current/.
27 Internet-Drafts are draft documents valid for a maximum of six months
28 and may be updated, replaced, or obsoleted by other documents at any
29 time. It is inappropriate to use Internet-Drafts as reference
30 material or to cite them other than as "work in progress."
32 This Internet-Draft will expire on July 21, 2011.
34 Copyright Notice
36 Copyright (c) 2011 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (http://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
49 Table of Contents
51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
52 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
53 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
54 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
55 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7
56 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
57 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
58 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
59 2.1.1. Requirement: Lists of drafts can be large . . . . . . 7
60 2.1.2. Requirement: Every Datatracker user can create a
61 list . . . . . . . . . . . . . . . . . . . . . . . . . 8
62 2.1.3. Requirement: Read-only views of private lists can
63 be made visible to others . . . . . . . . . . . . . . 8
64 2.1.4. Requirement: The Datatracker must support optional
65 publicly-readable lists for WGs and Area Directors . . 8
66 2.1.5. Requirement: Specifying the drafts that are in a
67 list must be simple . . . . . . . . . . . . . . . . . 9
68 2.1.6. Requirement: Adding groups of drafts to a list by
69 attribute must be simple . . . . . . . . . . . . . . . 9
70 2.1.7. Tombstone: lists dynamically including other lists . . 10
71 2.1.8. Later Requirement: Users can add comments to say
72 why they added a draft or group . . . . . . . . . . . 10
73 2.1.9. Requirement: These extensions must not make the
74 Datatracker take up too many resources . . . . . . . . 10
75 2.1.10. Requirement: Private information must not be
76 exposed in lists . . . . . . . . . . . . . . . . . . . 11
77 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 11
78 2.2.1. Requirement: Users can be notified when a draft
79 changes status . . . . . . . . . . . . . . . . . . . . 11
80 2.2.2. Requirement: Every list has Atom feeds associated
81 with it . . . . . . . . . . . . . . . . . . . . . . . 11
82 2.2.3. Requirement: Every list has mail streams
83 associated with it . . . . . . . . . . . . . . . . . . 11
84 2.2.4. Requirement: Notifications need to specify which
85 list caused the notification . . . . . . . . . . . . . 12
86 2.2.5. Later Requirement: The tool must have instructions
87 on how to use it Atom feeds . . . . . . . . . . . . . 12
88 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 12
89 2.3.1. Requirement: Users can define how the rows are
90 sorted in a display . . . . . . . . . . . . . . . . . 12
91 2.3.2. Requirement: Users can choose which attributes to
92 display . . . . . . . . . . . . . . . . . . . . . . . 13
93 2.3.3. Requirement: Users can flag drafts with dates in
94 the future . . . . . . . . . . . . . . . . . . . . . . 14
95 2.3.4. Requirement: Users can specify highlighting of
96 drafts with recent changes . . . . . . . . . . . . . . 14
98 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 14
99 2.4.1. Requirement: Users can get their current list as a
100 single file . . . . . . . . . . . . . . . . . . . . . 14
101 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
102 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
103 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
104 6. Informative References . . . . . . . . . . . . . . . . . . . . 16
105 Appendix A. Possible Tracking of Non-draft Documents . . . . . . 16
106 A.1. Tracking RFC Status Changes and Errata . . . . . . . . . . 16
107 A.2. Tracking WG Charter Changes . . . . . . . . . . . . . . . 17
108 A.3. Tracking IANA Registry Changes . . . . . . . . . . . . . . 17
109 A.4. Tracking Changes in the Liason Statement Directory . . . . 17
110 A.5. Tracking Changes in Documents Outside the IETF Sphere . . 17
111 Appendix B. Some Known Open Issues . . . . . . . . . . . . . . . 17
112 Appendix C. Ideas that Might Be Implemented Later . . . . . . . . 18
113 Appendix D. Differences Between -03 and -04 . . . . . . . . . . . 18
114 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
116 1. Introduction
118 The IETF Datatracker is used by many IETF community members to find
119 the status of Internet Drafts (I-Ds) and view drafts that meet
120 particular criteria. The current Datatracker, found at
121 , allows anyone to search for active
122 I-Ds and get a list of drafts matching the given criteria. (The
123 Datatracker also allows for searching RFCs and expired I-Ds, but
124 those are not relevant to this discussion.)
126 Users can search in the Datatracker by the filename of the draft,
127 words in the draft's title, author, associated Working Group (WG) or
128 IETF area, the responsible Area Director (AD), or IESG status. The
129 returned list of drafts includes five columns: draft filename (with
130 an active link to an HTMLized version of the draft maintained by the
131 IETF tools team), the draft's title, the date it was submitted, its
132 status in the IETF process, and the responsible AD (if any). For
133 example, the output of a search in the current Datatracker can be
134 seen at .
136 Instead of using the search capability of the Datatracker to manually
137 find I-Ds of interest, users might want to create a list of drafts
138 that they normally follow. Some users will want to keep their list
139 to themselves, but others will want to allow others to view their
140 list.
142 Different users in the IETF community will have different ways that
143 they want to get information on draft updates and status. Many users
144 will want to be notified immediately, such as through an Atom feed
145 (see [RFC4287]) or automatically-generated email. Many users will
146 want to only find out about updates when they go to a web page. Many
147 users might want to get the data for a list as input to other tools.
148 And, of course, some users will want all three. All of these desires
149 are related to the overall desire to track drafts through their
150 lifecycle.
152 1.1. Usage Scenarios
154 The main motivation for these proposed changes to the Datatracker is
155 to allow a variety of potential users to be able to track drafts and
156 thus be better able to see when important events happen. A few
157 examples include:
159 o A WG chair might want to keep a list of all the drafts from other
160 WGs that relate to active drafts in his or her WG.
162 o That same WG chair might want to help WG members be able to follow
163 the same drafts that he or she is following.
165 o Someone who cares about an established topic such as the DNS may
166 want to follow the various drafts that might make changes to the
167 DNS. This would include not only drafts that are in the many WGs
168 that directly are changing the DNS (DNSEXT, DNSOP, BEHAVE, and so
169 on), but also individual submissions, IAB drafts, and even IRTF
170 research.
172 o Developers who are not active in the IETF process might want to
173 lightly follow drafts on a particular topic to watch for things
174 that might affect their implementations.
176 o An IETF "regular" might want to follow parts of the process by
177 focusing on all the drafts that are being shepherded by a
178 particular Area Director.
180 1.2. Context for This Document
182 This document describes the requirements for extending the
183 Datatracker for such capabilities. When complete, this document may
184 be used to issue an RFP for the design and development of these
185 enhancements to the Datatracker. This document was prepared at the
186 request of the IAOC.
188 Some of the requirements in this document are listed as "later
189 requirements". This means that these requirements might not be part
190 of the first RFP for adding these enhancements.
192 The statement of work that led to this document says "The tools that
193 will eventually be provided to individuals in the community include":
195 o the ability to create one or more (possibly large) lists of I-Ds
196 that they want to follow
198 o the ability to get notifications when individual drafts from a
199 list changes state
201 o the ability to see all of the state changes that have occurred on
202 all the drafts in a list over a specified range of dates
204 o the ability to set the granularity of the changes (such as "every
205 change", "just approvals and publication", and so on)
207 o the ability to organize their views of a list in many fashions
208 that would be useful to different types of community members
210 o the ability to share and merge lists with other community members
212 Note that [RFC2026] describes the process that Internet Drafts go
213 through before they either become RFCs or are abandoned. The
214 Datatracker does not control this process: instead, it simply reports
215 on the current state of individual drafts as they go through the
216 process.
218 During the early discussion of these requirements, some community
219 members proposed that it would be very useful to track other types of
220 documents, such as WG charters. Appendixes A through D list these
221 proposals. It is not clear currently if those sections will be part
222 of the initial deployment of the requirements in the main body of
223 this document.
225 1.3. Definitions Used in This Document
227 A "user" is an individual person who is member of the IETF community.
229 A "list" is an unordered set of Internet Drafts and groups of
230 Internet Drafts. Lists are specified by users. In some cases, the
231 authors are role-based, such as a WG chair being the specifier of the
232 list associated with that WG.
234 An "attribute" is a feature of a draft, such as its filename, its
235 current state in the IETF process, and so on. Attributes are usually
236 displayed as columns in the Datatracker.
238 A "row" is a set of attributes about a single draft that is displayed
239 in the Datatracker.
241 A "significant change in status" is all approvals and disposition of
242 the draft. Assuming that the changes to the Datatracker specified in
243 [WGSTATES] and [ALTSTREAMS] are made, "all approvals" means the
244 following:
246 o IETF stream: the WG states "Adopted by a WG", "In WG Last Call",
247 "WG Consensus: Waiting for Write-up", "Parked WG document", and
248 "Dead WG document"; the IESG states "Publication Requested", "In
249 Last Call", and "IESG Evaluation"
251 o IAB stream: "Active IAB Document", "Community Review", and "Sent
252 to the RFC Editor"
254 o IRTF stream: "Active RG Document", "In RG Last Call", "Awaiting
255 IRSG Reviews", "In IESG Review", "Sent to the RFC Editor", and
256 "Document on Hold Based On IESG Request"
258 o ISE stream: "Submission Received", "In ISE Review", "In IESG
259 Review", "Sent to the RFC Editor", and "Document on Hold Based On
260 IESG Request"
262 o All streams: in addition to the above, the disposition states
263 "Approved", "RFC Published", and "Dead" are also included
265 1.4. Expected user interactions
267 When a user wants to follow a group of drafts, he or she goes to the
268 Datatracker and creates a new list. The requirements for lists are
269 given in Section 2.1. After a list is created, the user has three
270 ways that he or she might see when drafts in the list are updated:
272 o By going to the Datatracker page for the list (see Section 2.3)
274 o By subscribing to the Atom feed for the list (see Section 2.2.2)
275 in a feed reader that automatically fetches updates
277 o By subscribing to the mail stream for the list (see Section 2.2.3)
278 and reading the stream in their mail reader
280 1.5. Discussion of These Requirements
282 This document is being discussed on the datatracker-rqmts@ietf.org
283 mailing list. For more information, see
284 .
286 There will probably be virtual interim meetings to discuss this
287 document in early 2011.
289 2. Requirements for Tools Features
291 This section defines the requirements for the tool described earlier
292 in this document. The eventual tool, if implemented, may have more
293 features than are listed here; however, before this document is
294 finished, it should contain as many requirements as possible upon
295 which the IETF community can agree.
297 2.1. Lists
299 2.1.1. Requirement: Lists of drafts can be large
301 An active IETF participant might want to follow the status of
302 hundreds of drafts. For example, some ADs have 100 drafts in their
303 area, and they may also want to follow drafts outside their area that
304 affect documents in their area.
306 2.1.2. Requirement: Every Datatracker user can create a list
308 When a user gets a Datatracker account, that account comes with an
309 empty list pre-defined. The list can nomrally be modified only by
310 the owner of the account, although the Secretariat can also modify
311 the list as part of its support role for the Datatracker.
313 In order for this requirement to be met, it must be easy for any
314 community member to get a Datatracker account. Account setup must
315 not involve any direct action on the part of the Secretariat.
316 However, the Secretariat will be responsible for support of
317 Datatracker accounts (lots passwords, odd interactions, and so on),
318 so this addition of more Datatracker accounts will potentially
319 increase the amount of work the Secretariat must do.
321 The only person who can edit the contents of a private list is the
322 person who knows the password to the account with which the list is
323 associated.
325 2.1.3. Requirement: Read-only views of private lists can be made
326 visible to others
328 Some users will want to make available a read-only view of their
329 list. Each private list will have a URL that leads to the
330 Datatracker view of the list; that URL must be able to be safely
331 shared with others. In this case, "safely" means "will not help
332 others be able to edit the list". Similarly, the Atom feed
333 associated with a private list should be able to be safely shared
334 with others>
336 2.1.4. Requirement: The Datatracker must support optional publicly-
337 readable lists for WGs and Area Directors
339 It is common in the IETF for users to follow the work of an entire
340 WG, not just individual drafts within a WG. It is also very common
341 that some work that is related to a WG happens outside the WG, either
342 in other WGs or as individual efforts. Many WG chairs monitor this
343 outside-the-WG activity for various reasons.
345 A smaller number of community members to follow an entire Area's
346 worth of topics. Again, these topics often happen within the WGs of
347 an area, but not always; for example, some topics related to the
348 Security Area happen in WGs in the Applications Area.
350 Because of this, it would be useful for community members to be able
351 to find a list which corresponds to the WGs or Areas in which they
352 are interested. The WG lists could be maintained by the WG chairs;
353 the Area lists would likely be maintained by the ADs. Note that such
354 lists are not mandatory; for example, a WG chair might not choose to
355 maintain such a list for a WG whose topic is extremely broad.
357 Both Working Group chairs and Area Directors currently already have
358 Datatracker accounts, so fulfilling this requirement only involves
359 associating those accounts with the role that controls the list.
361 Proposed later requirements include having the Datatracker list all
362 of the publicly-readable lists (or certainly at least the ones
363 associated with IETF activities), and having links from WG pages in
364 Datatracker to the publicly-readable lists maintained by the WG
365 chairs.
367 2.1.5. Requirement: Specifying the drafts that are in a list must be
368 simple
370 When a user creates a new list, it must be easy to add individual
371 drafts to the list. This could be done using the Datatracker's
372 current search facility, and simply adding a "add to list" option for
373 Further, when editing an existing list, it must be easy to add
374 additional drafts, and it must be easy to remove drafts from a list.
376 2.1.6. Requirement: Adding groups of drafts to a list by attribute must
377 be simple
379 Drafts have many attributes, and some users might want to follow all
380 of the drafts that have a particular attribute. Some, but not all,
381 attributes have values that make sense in specifying lists. It
382 should be easy to add each of the following attributes when adding to
383 or editing a list:
385 o All drafts associated with an individual WG
387 o All drafts associated with all WGs in an individual Area
389 o All drafts with a particular responsible AD
391 o All drafts with a particular author
393 o All drafts with a particular document shepherd
395 o All drafts that have a reference to a particular RFC
397 o All drafts that have a reference to a particular draft
399 o All drafts that are referenced by a particular RFC
400 o All drafts that are referenced by a particular draft
402 o All drafts that contain a particular text string
404 These attributes are dynamic, and thus the list of drafts that have a
405 particular attribute will change after the user adds that attribute
406 to a list. The Datatracker should update lists with dynamic
407 attributes as often as is sensible for the server environment, such
408 as once an hour or more.
410 Note that some of these attributes are derived by programs created by
411 the IETF Tools Team that parse drafts and are therefore inherently
412 not completely reliable.
414 2.1.7. Tombstone: lists dynamically including other lists
416 Earlier versions of this draft had a requirement that lists needed to
417 be able to include other lists. While this may still be desired, it
418 was decided that implementing this in a safe and understandable way
419 would be too difficult. Later versions of the Datatracker might
420 include this feature.
422 2.1.8. Later Requirement: Users can add comments to say why they added
423 a draft or group
425 In public lists, it might be useful for someone to be able to
426 understand why particular drafts and/or groups are added. Allowing
427 the user who put together the list to add a comment field would help
428 someone else see the motivation.
430 2.1.9. Requirement: These extensions must not make the Datatracker take
431 up too many resources
433 Currently, the only state that the Datatracker keeps for its users is
434 a very small set of attributes assigned to a username-password pair.
435 The extensions described here will cause the Datatracker to need to
436 keep more information, namely lists. Each list might have additional
437 associated state as well. This could lead to the Datatracker needing
438 a larger amount of storage and other resources. When this document
439 is near completion, it would probably be good to list exactly which
440 new state will be kept on the Datatracker server.
442 In order to reduce the chance that these extensions would strain the
443 Datatracker, some sort of denial-of-service prevention should be used
444 when the extensions are added. A later requirement might be to cull
445 lists if it seems that storing them on the Datatracker is taking too
446 many resources. The Datatracker can periodically send mail to the
447 user reminding them to delete lists that are no longer needed.
449 Culling presents a problem, however, for user-based lists that are
450 made public. The creator of a list might no longer be using it, but
451 others might be. Thus, it is likely that the Datatracker needs to be
452 be able to maintain lists long-term even if their creators are no
453 longer using them.
455 2.1.10. Requirement: Private information must not be exposed in lists
457 Any private information in the Datatracker must be excluded from any
458 displays of the lists or streams created in this document. This
459 private information includes private notes in the IESG balloting for
460 a draft, and probably other data that currently is restricted to
461 being seen by certain members of the IETF leadership.
463 2.2. Notifications
465 2.2.1. Requirement: Users can be notified when a draft changes status
467 Some users do not want to go to the Datatracker's display page to
468 find out when a draft has been updated. Instead, they want to be
469 notified immediately after the draft is changed. The Datatracker
470 needs to support this type of immediate notification, where
471 "immediate" means "within an hour of a change to any draft in the
472 list". This requirement can be met with Atom feeds and mail streams,
473 as described in the next two sections.
475 The Datatracker might create a generic "notifications engine" that
476 can be used to generate the Atom feeds and mail streams. This engine
477 can then be used to later add other notification types, such as a
478 Jabber feed.
480 2.2.2. Requirement: Every list has Atom feeds associated with it
482 The list will have two Atom feeds that are generated from the changes
483 to the list: one for every change in status, and another for
484 significant change of status. Each Atom feed will have a stable URL
485 that can be used by feed readers.
487 Many IETF users are already using Atom feeds created by the IETF
488 Tools Team for individual drafts. Using the new feeds for lists
489 described here will allow them to have better selection capabilities
490 to reduce the number of feeds they need to follow.
492 2.2.3. Requirement: Every list has mail streams associated with it
494 A user can subscribe to two email streams that are generated from the
495 changes to the list: one for every change in status, and another for
496 significant change of status.
498 Note that the mail streams are for each change; they are not batched
499 (such as one message per day). Users who want less frequent but
500 batched notifications need to use the Atom feeds instead of the mail
501 streams.
503 2.2.4. Requirement: Notifications need to specify which list caused the
504 notification
506 Users might have feeds and/or subscriptions to multiple lists. In
507 order to disambiguate duplicate notifications from multiple lists,
508 the body of the message in the Atom feed or mail stream needs to say
509 which list generated the notification. (Ideally, a user who wants
510 notifications will make one list based on multiple lists, but if they
511 subscribe to multiple lists, this requirement will at least suggest
512 to them that they want to limit their overlapping subscriptions.)
514 2.2.5. Later Requirement: The tool must have instructions on how to use
515 it Atom feeds
517 Even though Atom feeds have been around for years, they are new to
518 many Internet users, and even experienced users only know how to use
519 them in limited ways. The Datatracker should have at least a few
520 paragraphs explaining how the Atom feeds that it provides can be used
521 in different tools such as dedicated feed readers, online feed-
522 display services, and so on.
524 2.3. Display in the Datatracker
526 2.3.1. Requirement: Users can define how the rows are sorted in a
527 display
529 There are many ways that a user might want to see the Datatracker's
530 HTML view of a list. For example, a user might want to normally see
531 it in alphabetical order by the drafts' filenames, but after the user
532 is of the net for a week, he or she might want to see the list in
533 order of changes of status so that those drafts changed recently
534 appear at the top of the list.
536 The default is to first list the groups first in alphabetical order
537 by group name, then individual drafts in alphabetical order by draft
538 filename. When displaying a list, the Datatracker should allow easy
539 sorting of the drafts with the following collation orders:
541 o Alphabetical order by group name followed by individual drafts
542 (default)
544 o Alphabetical by draft filename
545 o Alphabetical by draft title
547 o Alphabetical by associated WG
549 o Date of publication of current version of the draft
551 o Date of most recent change of status of any type
553 o Date of most recent significant change of status
555 In displays, a particular draft should only included once; for
556 example, if someone manually adds draft-ietf-cuteacronym-sometopic to
557 his list and also specifies that all drafts from the "cuteacronym" WG
558 are included in the list, that draft should only appear once in the
559 display. The column saying which included list(s) contain this draft
560 helps alleviate this loss of information.
562 The user might also want to group the files using the groupings in
563 the list, such as "all drafts from this WG" and "all drafts that
564 contain this word in the title".
566 The Datatracker should save the last-chosen sorting for display with
567 the definition of the list.
569 2.3.2. Requirement: Users can choose which attributes to display
571 There are many attributes that might be displayed, and different
572 users will have different information that they want to see. Also,
573 users will have different display technologies: someone might
574 normally use a web browser on a large screen, but at other times use
575 the browser on their phone.
577 Choosing which attributes should be displayed should be simple for
578 the user. The Datatracker should save the last-chosen set of
579 attributes for display with the definition of the list. The default
580 is to display is draft filename, draft title, date of current draft,
581 status in stream process, associated WG or RG, whether it was changed
582 within the last 7 days, and included list(s) which contain this
583 draft.
585 The Datatracker should support display of the following attributes:
587 o Draft filename
589 o Draft title
591 o Date of current draft
592 o Status in the IETF process
594 o Associated WG or RG
596 o Associated AD, if any
598 o Changed within the last 1 day
600 o Changed within the last 2 days
602 o Changed within the last 7 days
604 There is some leeway for how the Datatracker might display these
605 attributes. For example, the "changed within" attributes might be
606 shown with a check mark or a colored box.
608 2.3.3. Requirement: Users can flag drafts with dates in the future
610 When tracking drafts, some users want to be able to say "tell me if
611 this draft has not changes state by a particular date" such as when a
612 draft is starting a two-week last call or a draft author has promised
613 a new version by the end of the week. This feature gives the user a
614 "dashboard" style capability.
616 For each draft in a list, the user should be able to set one date-
617 based deadline. When using the display version of the Datatracker,
618 if that date has passed and no change in status happened between the
619 time that the user set the deadline and the set date, the Datatracker
620 will highlight the deadline in red. It must also be easy to remove
621 these deadlines.
623 2.3.4. Requirement: Users can specify highlighting of drafts with
624 recent changes
626 The Datatracker cannot easily keep track of when a user last looked
627 at the page for a particular list. Thus, it instead needs to let a
628 user say which range of dates they are most interested in. To that
629 end, the user needs to be able to easily specify the amount of time
630 they consider recent, either as "the past nnn hours", "the past nnn
631 days", or "since this particular date".
633 2.4. File Output
635 2.4.1. Requirement: Users can get their current list as a single file
637 Some users have their own tools for displaying and otherwise
638 processing lists of drafts. To make this easier, users should be
639 able to get a machine-parsable file that has a well-known format and
640 syntax that contains all the data that was used to create the current
641 display. The order of the records in the file is not important
642 because it is assumed that the user's program will sort the results
643 themselves. All attributes will be included because it is assumed
644 that the user's programs will only deal with the ones the care about.
646 When a list is marshaled into a data file, each record in the file
647 format represents a single draft. In a file, a particular draft is
648 only included once; for example, if someone manually adds
649 draft-ietf-cuteacronym-sometopic to his list and also specifies that
650 all drafts from the "cuteacronym" WG are included in the list, that
651 draft only appears once.
653 This feature will allow anyone to create mash-ups of their own and
654 create their own web sites based on the IETF data. This is
655 significantly easier than adding features to the Datatracker, and is
656 able to cater to narrower audiences.
658 The format of the file will be XML or JSON or tab-separated fields in
659 a text file. The decision on which format is supported will be based
660 on the desires of the community while discussing this document.
661 (Imagine how much fun that will be!) Regardless of the format
662 chosen, a syntax will need to be specified.
664 3. IANA Considerations
666 None.
668 4. Security Considerations
670 A tool for tracking the status of Internet Drafts can affect the
671 privacy of its users. The requirements for privacy of the
672 Datatracker views are discussed earlier in the document.
674 Web applications, particularly those that store data on a web server,
675 are a common source of security issues such as cross-site scripting
676 attacks. The tool described in this document might also use access
677 control for lists, and access control and authentication also cause
678 security issues if not implemented properly.
680 5. Acknowledgements
682 Ideas used in this document were contributed by Scott Bradner, Leslie
683 Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen,
684 Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy
685 Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad,
686 Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner.
688 6. Informative References
690 [ALTSTREAMS]
691 Hoffman, P., "Data Tracker States and Annotations for the
692 IAB, IRTF, and Independent Submission Streams",
693 draft-hoffman-alt-streams-tracker (work in progress),
694 September 2010.
696 [CHARTERTOOL]
697 Hoffman, P., "Requirements for a Working Group Charter
698 Tool", draft-ietf-genarea-charter-tool (work in progress),
699 October 2010.
701 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
702 3", BCP 9, RFC 2026, October 1996.
704 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
705 Syndication Format", RFC 4287, December 2005.
707 [WGSTATES]
708 Juskevicius, E., "Definition of IETF Working Group
709 Document States", draft-ietf-proto-wgdocument-states (work
710 in progress), October 2010.
712 Appendix A. Possible Tracking of Non-draft Documents
714 It is not at all clear if any of these will be a requirement, a later
715 requirement, or a non-requirement. Further, even if one or more of
716 these non-draft items is made a requirement, it is not clear whether
717 they will be included in the same lists with drafts. That is, if
718 tracking RFC status changes are considered a requirement, it is not
719 clear whether a user would include the RFCs in a list that also
720 contains draft, or whether they would need to create two lists, one
721 for drafts and one for RFCs.
723 A.1. Tracking RFC Status Changes and Errata
725 The contents of RFCs never change after they are published. However,
726 that does not mean that nothing alters the meaning of the RFC. In
727 specific, an RFC can be updated or obsoleted by another RFC; also,
728 errata can be made against RFCs. A user who cares about the RFC
729 might want to know when these changes are made.
731 Currently, the only way for the Datatracker to see these changes is
732 by polling structured files on the RFC Editor site and parsing them.
734 A.2. Tracking WG Charter Changes
736 It will soon be easier to track changes in WG charters and
737 milestones; see [CHARTERTOOL] for more information. Someone
738 subscribing to the stream for a WG would be able to see each of these
739 changes. With the expected changes, the Datatracker would be able to
740 update WGs in a list without any polling.
742 A.3. Tracking IANA Registry Changes
744 Developers may need to get values from IANA registries for their
745 software/hardware implementations. They might want to know when the
746 registry changes, such as additional entries or updates to current
747 entries. Thus, being able to be notified when a registry changes
748 would be valuable to them.
750 Adding this functionality may be tricky for some registries. For
751 example, if a developer cared about DKIM signature tags, they would
752 have to subscribe to
753 which (currently)
754 covers a handful of registries, all related to DKIM. Thus, a change
755 to the DKIM hash algorithms would trigger a message showing that the
756 registry had changed, even though the DKIM signature tags registry
757 had not.
759 A.4. Tracking Changes in the Liason Statement Directory
761 Users might want to know when a new liaison statement is sent by the
762 IETF, or when one is received by the IETF.
764 A.5. Tracking Changes in Documents Outside the IETF Sphere
766 Users might want to track documents that relate to IETF activities
767 but are produced by other standards development organizations (SDOs)
768 such as the W3C, the IEEE, the Unicode Consortium, the ITU, and
769 others. In order for the tracker to track these documents, it would
770 need to poll occasionally and possibly scrape listings from HTML.
772 Appendix B. Some Known Open Issues
774 This list is mostly meant to remind the author of topics that need to
775 be updated in future versions of the document, and to spur readers to
776 think of even more open issues.
778 o When an AD agrees to sponsor an individual submission, does the
779 Datatracker consider that draft associated with the AD? If not,
780 that needs to be dealt with here.
782 Appendix C. Ideas that Might Be Implemented Later
784 The following are ideas for the new tool that are not currently being
785 considered for the first round of development, but are being
786 documented for possible future use. Items here might move between
787 this list and the list of requirements that are expected to be in the
788 first round.
790 o The normal Datatracker display could have a button to add a
791 particular draft to the user's personal list.
793 o Allow each user to determine what "significant change in status"
794 is for the list they create. This could be done by a series of
795 check boxes for every possible status change.
797 o A list creator can add a list-level comment about who might be
798 interested in following the list.
800 o If the agendas for an upcoming meeting are scraped for draft
801 names, it would be possible to add an attribute to a draft that
802 lists that WG agenda(s) on which it appears.
804 o In the section on "Adding groups of drafts to a list by
805 attribute", add an attribute for "all drafts that are referenced
806 by any draft in a particular list".
808 o Make it possible to add all drafts that have a certain section to
809 a list (non-trivial IANA considerations, ASN.1 modules in
810 appendicies, ...).
812 Appendix D. Differences Between -03 and -04
814 Removed the "early" note from the intro.
816 Added a requirement on private data not being exposed.
818 Added an appendix of ideas that could possibly be added later.
820 Removed the "legal issues for user data" open issue because no one
821 listed any.
823 Moved many open issues to the "possibly later" list.
825 Author's Address
827 Paul Hoffman
828 VPN Consortium
830 Email: paul.hoffman@vpnc.org