idnits 2.17.1
draft-ietf-genarea-datatracker-community-07.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 (March 31, 2011) is 4774 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 March 31, 2011
5 Expires: October 2, 2011
7 Requirements for Internet-Draft Tracking by the IETF Community in the
8 Datatracker
9 draft-ietf-genarea-datatracker-community-07
11 Abstract
13 The document gives a set of requirements for extending the IETF
14 Datatracker to give individual IETF community members, including the
15 IETF leadership, easy methods for tracking the progress of the
16 Internet-Drafts and RFCs of interest to them.
18 Status of this Memo
20 This Internet-Draft is submitted in full conformance with the
21 provisions of BCP 78 and BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF). Note that other groups may also distribute
25 working documents as Internet-Drafts. The list of current Internet-
26 Drafts is at http://datatracker.ietf.org/drafts/current/.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 This Internet-Draft will expire on October 2, 2011.
35 Copyright Notice
37 Copyright (c) 2011 IETF Trust and the persons identified as the
38 document authors. All rights reserved.
40 This document is subject to BCP 78 and the IETF Trust's Legal
41 Provisions Relating to IETF Documents
42 (http://trustee.ietf.org/license-info) in effect on the date of
43 publication of this document. Please review these documents
44 carefully, as they describe your rights and restrictions with respect
45 to this document. Code Components extracted from this document must
46 include Simplified BSD License text as described in Section 4.e of
47 the Trust Legal Provisions and are provided without warranty as
48 described in the Simplified BSD License.
50 Table of Contents
52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
53 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 4
54 1.2. Context for This Document . . . . . . . . . . . . . . . . 5
55 1.3. Definitions Used in This Document . . . . . . . . . . . . 6
56 1.4. Expected user interactions . . . . . . . . . . . . . . . . 7
57 1.5. Discussion of These Requirements . . . . . . . . . . . . . 7
58 2. Requirements for Tools Features . . . . . . . . . . . . . . . 7
59 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 7
60 2.1.1. Requirement: Lists of I-Ds and RFCs can be large . . . 7
61 2.1.2. Requirement: Every Datatracker user can create a
62 list . . . . . . . . . . . . . . . . . . . . . . . . . 8
63 2.1.3. Requirement: Read-only views of private lists can
64 be made visible to others . . . . . . . . . . . . . . 8
65 2.1.4. Requirement: The Datatracker must support optional
66 publicly-readable lists for WGs and Area Directors . . 8
67 2.1.5. Requirement: Specifying the I-Ds and RFCs that are
68 in a list must be simple . . . . . . . . . . . . . . . 9
69 2.1.6. Requirement: Adding groups of I-Ds to a list by
70 attribute must be simple . . . . . . . . . . . . . . . 9
71 2.1.7. Requirement: Private information must not be
72 exposed in lists . . . . . . . . . . . . . . . . . . . 10
73 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 10
74 2.2.1. Requirement: Users can be notified when an I-D
75 changes status . . . . . . . . . . . . . . . . . . . . 10
76 2.2.2. Requirement: Every list has Atom feeds associated
77 with it . . . . . . . . . . . . . . . . . . . . . . . 10
78 2.2.3. Requirement: Every list has mail streams
79 associated with it . . . . . . . . . . . . . . . . . . 11
80 2.2.4. Requirement: Notifications need to specify which
81 list caused the notification . . . . . . . . . . . . . 11
82 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 11
83 2.3.1. Requirement: Users can define their Datatracker
84 document view . . . . . . . . . . . . . . . . . . . . 11
85 2.3.2. Requirement: Users can choose which attributes to
86 display . . . . . . . . . . . . . . . . . . . . . . . 12
87 2.3.3. Requirement: Users can flag I-Ds with dates in the
88 future . . . . . . . . . . . . . . . . . . . . . . . . 13
89 2.3.4. Requirement: Users can specify highlighting of
90 I-Ds and RFCs with recent changes . . . . . . . . . . 13
91 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 13
92 2.4.1. Requirement: Users can get their current list as a
93 single file . . . . . . . . . . . . . . . . . . . . . 13
94 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
95 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
96 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
97 6. Informative References . . . . . . . . . . . . . . . . . . . . 14
98 Appendix A. Possible Tracking of Other Documents . . . . . . . . 15
99 A.1. Tracking WG Charter Changes . . . . . . . . . . . . . . . 15
100 A.2. Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
101 A.3. Tracking Changes in the Liason Statement Directory . . . . 16
102 A.4. Tracking Changes in Documents Outside the IETF Sphere . . 16
103 A.5. Tracking Additions to the IPR Statement Repository . . . . 16
104 Appendix B. Ideas that Might Be Implemented Later . . . . . . . . 16
105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
107 1. Introduction
109 The IETF Datatracker is used by many IETF community members to find
110 the status of Internet-Drafts (I-Ds) and RFCs, and view I-Ds and RFCs
111 that meet particular criteria. The current Datatracker, found at
112 , allows anyone to search for active
113 I-Ds and RFCs, and get a list matching the given criteria. (The
114 Datatracker also allows for expired I-Ds, but those are not relevant
115 to this discussion.)
117 Users can search in the Datatracker by the filename of the I-D, words
118 in the I-D title, I-D author list, associated Working Group (WG),
119 IETF area, the responsible Area Director (AD), or IESG status. They
120 can search for RFCs by number or words in the title. The returned
121 list of I-Ds and/or RFCs includes sixTestVM columns: filename or RFC
122 number (with an active link to an HTMLized version maintained by the
123 IETF tools team), the document's title, the date it was published,
124 its status in the IETF or RFC process, IPR statements, and the
125 responsible AD (if any). For example, the output of a search in the
126 current Datatracker can be seen at . [[ Note
127 to RFC Editor: Please remve the preceding sentence ("For example,
128 ...") before publication. ]]
130 Instead of using the search capability of the Datatracker to manually
131 find I-Ds and RFCs of interest, users might want to create a list of
132 I-Ds that they normally follow. Some users will want to keep their
133 list to themselves, but others will want to allow others to view
134 their list.
136 Different users in the IETF community will have different ways that
137 they want to get information on I-D and RFC updates and status. Many
138 users will want to be notified immediately, such as through an Atom
139 feed (see [RFC4287]) or automatically-generated email. Many users
140 will want to only find out about updates when they go to a web page.
141 Many users might want to get the data for a list as input to other
142 tools. And, of course, some users will want all three. All of these
143 assist users in tracking I-Ds through their lifecycle.
145 1.1. Usage Scenarios
147 The main motivation for these proposed changes to the Datatracker is
148 to allow a variety of potential users to be able to track I-Ds and
149 RFCs, and thus be better able to see when important events happen. A
150 few examples include:
152 o A WG chair might want to keep a list of all the I-Ds from other
153 WGs that relate to active I-Ds in his or her WG.
155 o That same WG chair might want to help WG members be able to follow
156 the same I-Ds that he or she is following.
158 o Someone who cares about an established topic such as the DNS may
159 want to follow the various I-Ds that might make changes to the
160 DNS, as well as seeing if any of the DNS RFCs are later updated
161 and/or have errata posted against them. This would include not
162 only I-Ds that are in the many WGs that directly are changing the
163 DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual
164 submissions, IAB I-Ds, and even IRTF research. It would also
165 include RFCs from before when WGs were tracked.
167 o Developers who are not active in the IETF process might want to
168 lightly follow I-Ds and RFCs on a particular topic to watch for
169 things that might affect their implementations.
171 o An IETF "regular" might want to follow parts of the process by
172 focusing on all the I-Ds that are being shepherded by a particular
173 Area Director.
175 1.2. Context for This Document
177 This document describes the requirements for extending the
178 Datatracker for such capabilities. When complete, this document may
179 be used to issue an RFP for the design and development of these
180 enhancements to the Datatracker.
182 Some of the requirements in this document are listed as "later
183 requirements". It is expected that items listed in this document
184 would be part of the initial RFP because they provide the highest
185 benefit to the community; the later requirements might be part of a
186 later RFP.
188 The initial general requirements that led to the specific
189 requirements this document described tools that include:
191 o the ability to create one or more (possibly large) lists of I-Ds
192 that they want to follow
194 o the ability to get notifications when individual I-Ds from a list
195 changes state
197 o the ability to see all of the state changes that have occurred on
198 all the I-Ds in a list over a specified range of dates
200 o the ability to set the granularity of the changes (such as "every
201 change", "just approvals and publication", and so on)
203 o the ability to organize their views of a list in many fashions
204 that would be useful to different types of community members
206 o the ability to share and merge lists with other community members
208 Note that [RFC2026] describes the process that I-Ds go through before
209 they either become RFCs or are abandoned. The Datatracker does not
210 control this process: instead, it simply reports on the current state
211 of each I-D as it goes through the process.
213 1.3. Definitions Used in This Document
215 A "user" is an individual person who is member of the IETF community.
217 A "list" is an unordered set of RFCs, I-Ds, and groups of I-Ds.
218 Lists are specified by users. In some cases, the authors are role-
219 based, such as a WG chair being the specifier of the list associated
220 with that WG.
222 An "attribute" is a feature of an I-D or RFC, such as its filename or
223 RFC number, its current state in the IETF or RFC process, and so on.
224 Attributes are usually displayed as columns in the Datatracker.
226 A "row" is a set of attributes about a single I-D or RFC that is
227 displayed in the Datatracker.
229 A "significant change in status" is all approvals and disposition of
230 an I-D. Assuming that the changes to the Datatracker specified in
231 [RFC6174], [RFC6175] and [ALTSTREAMS] are made, "all approvals" means
232 the following:
234 o IETF stream: the WG states "Adopted by a WG", "In WG Last Call",
235 "WG Consensus: Waiting for Write-up", "Parked WG document", and
236 "Dead WG document"; the IESG states "Publication Requested", "In
237 Last Call", "IESG Evaluation", and "Sent to the RFC Editor"
239 o IAB stream: "Active IAB Document", "Community Review", and "Sent
240 to the RFC Editor"
242 o IRTF stream: "Active RG Document", "In RG Last Call", "Awaiting
243 IRSG Reviews", "In IESG Review", "Sent to the RFC Editor", and
244 "Document on Hold Based On IESG Request"
246 o ISE stream: "Submission Received", "In ISE Review", "In IESG
247 Review", "Sent to the RFC Editor", and "Document on Hold Based On
248 IESG Request"
250 o All streams: in addition to the above, the disposition states
251 "Approved", "RFC Published", and "Dead" are also included
253 An "update to an RFC" is the announcement of a newer RFC that updates
254 or obsoletes the base RFC, an in-place change to the RFC's maturity
255 level, the RFC's status being changed to historic, or an announcement
256 of an errata posted for the base RFC.
258 1.4. Expected user interactions
260 When a user wants to follow a group of I-Ds and/or RFCs, he or she
261 goes to the Datatracker and creates a new list. The requirements for
262 lists are given in Section 2.1. After a list is created, the user
263 has three ways that he or she might see when I-Ds and/or RFCs in the
264 list are updated:
266 o By going to the Datatracker page for the list (see Section 2.3)
268 o By subscribing to the Atom feed for the list (see Section 2.2.2)
269 in a feed reader that automatically fetches updates
271 o By subscribing to the mail stream for the list (see Section 2.2.3)
272 and reading the mail stream in their mail reader
274 1.5. Discussion of These Requirements
276 [[ This section is to be removed before the RFC is published. ]]
278 This document is being discussed on the datatracker-rqmts@ietf.org
279 mailing list. For more information, see
280 .
282 2. Requirements for Tools Features
284 This section defines the requirements for the tool described earlier
285 in this document. The eventual tool, if implemented, may have more
286 features than are listed here; however, before this document is
287 finished, it should contain as many requirements as possible upon
288 which the IETF community can agree.
290 2.1. Lists
292 2.1.1. Requirement: Lists of I-Ds and RFCs can be large
294 An active IETF participant might want to follow the status of
295 hundreds of I-Ds and dozens of RFCs. For example, some ADs have 100
296 I-Ds in their area, and they may also want to follow I-Ds outside
297 their area that affect documents in their area.
299 2.1.2. Requirement: Every Datatracker user can create a list
301 When a user gets a Datatracker account, that account comes with an
302 empty list pre-defined. The list can normally be modified only by
303 the owner of the account, although the Secretariat can also modify
304 the list as part of its support role for the Datatracker.
306 In order for this requirement to be met, it must be easy for any
307 community member to get a Datatracker account. Account setup must
308 not involve any direct action on the part of the Secretariat.
309 However, the Secretariat will be responsible for support of
310 Datatracker accounts (lost passwords, odd interactions, and so on),
311 so this addition of more Datatracker accounts will potentially
312 increase the amount of work the Secretariat must do.
314 The only person who can edit the contents of a private list is the
315 person who knows the password to the account with which the list is
316 associated.
318 2.1.3. Requirement: Read-only views of private lists can be made
319 visible to others
321 Some users will want to make available a read-only view of their
322 list. Each private list will have a URL that leads to the
323 Datatracker view of the list; that URL must be able to be shared
324 without giving others the ability to edit the list. Similarly, the
325 Atom feed associated with a private list must be able to be shared
326 without giving others the ability to edit the list.
328 2.1.4. Requirement: The Datatracker must support optional publicly-
329 readable lists for WGs and Area Directors
331 It is common in the IETF for users to follow the work of an entire
332 WG, not just single I-Ds and RFCs within a WG. It is also very
333 common that some work that is related to a WG happens outside the WG,
334 either in other WGs or as individual efforts. Many WG chairs monitor
335 this outside-the-WG activity for various reasons.
337 A smaller number of community members to follow an entire Area's
338 worth of topics. Again, these topics often happen within the WGs of
339 an area, but not always; for example, some topics related to the
340 Security Area happen in WGs in the Applications Area.
342 Because of this, it would be useful for community members to be able
343 to find a list which corresponds to the WGs or Areas in which they
344 are interested. The WG lists could be maintained by the WG chairs;
345 the Area lists would likely be maintained by the ADs. Note that such
346 lists are not mandatory; for example, a WG chair might not choose to
347 maintain such a list for a WG whose topic is extremely broad.
349 Both Working Group chairs and Area Directors currently already have
350 Datatracker accounts, so fulfilling this requirement only involves
351 associating those accounts with the role that controls the list.
353 2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list
354 must be simple
356 When a user creates a new list, it must be easy to add single I-Ds
357 and RFCs to the list. This could be done using the Datatracker's
358 current search facility, and simply adding a "add to list" option to
359 the display of searched-for I-Ds. Further, when editing an existing
360 list, it must be easy to add additional I-Ds and RFCs, and it must be
361 easy to remove I-Ds and RFCs from a list.
363 2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must
364 be simple
366 I-Ds have many attributes, and some users might want to follow all of
367 the I-Ds that have a particular attribute. Some, but not all,
368 attributes have values that make sense in specifying lists. It
369 should be easy to add each of the following attributes when adding to
370 or editing a list:
372 o All I-Ds associated with an particular WG
374 o All I-Ds associated with all WGs in an particular Area
376 o All I-Ds with a particular responsible AD
378 o All I-Ds with a particular author
380 o All I-Ds with a particular document shepherd
382 o All I-Ds that have a reference to a particular RFC
384 o All I-Ds that have a reference to a particular I-D
386 o All I-Ds that are referenced by a particular RFC
388 o All I-Ds that are referenced by a particular I-D
390 o All I-Ds that contain a particular text string
392 These attributes are dynamic, and thus the list of I-Ds that have a
393 particular attribute will change after the user adds that attribute
394 to a list. The Datatracker should update lists with dynamic
395 attributes as often as is sensible for the server environment, such
396 as once an hour or more.
398 Note that some of these attributes are based on heuristics derived by
399 programs that parse I-Ds, and are therefore inherently not completely
400 reliable.
402 2.1.7. Requirement: Private information must not be exposed in lists
404 Any private information in the Datatracker must be excluded from any
405 displays of the lists or mail streams. This private information
406 includes private notes in the IESG balloting for an I-D, and probably
407 other data that currently is restricted to being seen by certain
408 members of the IETF leadership.
410 2.2. Notifications
412 2.2.1. Requirement: Users can be notified when an I-D changes status
414 Some users do not want to go to the Datatracker's display page to
415 find out when an I-D or RFC has been updated. Instead, they want to
416 be notified immediately after the change. The Datatracker needs to
417 support this type of immediate notification, where "immediate" means
418 within an hour of a change to any I-D or RFC in the list. This
419 requirement can be met with Atom feeds and mail streams, as described
420 in the next two sections.
422 The Datatracker might create a generic "notifications engine" that
423 can be used to generate the Atom feeds and mail streams. This engine
424 can then be used to later add other notification types, such as a
425 Jabber feed.
427 2.2.2. Requirement: Every list has Atom feeds associated with it
429 The list will have two Atom feeds that are generated from the changes
430 to the list: one for every change in status, and another for
431 significant change of status. Each Atom feed will have a stable URL
432 that can be used by feed readers.
434 Many IETF users are already using Atom feeds created by the IETF
435 Tools Team for single I-Ds. Using the new feeds for lists described
436 here will allow them to have better selection capabilities to reduce
437 the number of feeds they need to follow.
439 2.2.3. Requirement: Every list has mail streams associated with it
441 A user can subscribe to two mail streams that are generated from the
442 changes to the list: one for every change in status, and another for
443 significant change of status.
445 Note that the mail streams are for each change; they are not batched
446 (such as one message per day). Users who want less frequent but
447 batched notifications need to use the Atom feeds instead of the mail
448 streams.
450 2.2.4. Requirement: Notifications need to specify which list caused the
451 notification
453 Users might have feeds and/or subscriptions to multiple lists. In
454 order to disambiguate duplicate notifications from multiple lists,
455 the body of the message in the Atom feed or mail stream needs to say
456 which list generated the notification. (Ideally, a user who wants
457 notifications will make one list based on multiple lists, but if they
458 subscribe to multiple lists, this requirement will at least suggest
459 to them that they want to limit their overlapping subscriptions.)
461 2.3. Display in the Datatracker
463 2.3.1. Requirement: Users can define their Datatracker document view
465 There are many ways that a user might want to see the Datatracker's
466 HTML view of a list. For example, a user might want the view
467 displayed in alphabetical order by the I-Ds' filenames and RFC
468 numbers, but after the user is off the net for a week, he or she
469 might want the view displayed in order of changes of status so that
470 those I-Ds and RFCs changed recently appear at the top.
472 The default is to list I-Ds in alphabetical order by I-D filename,
473 with RFCs at the end. When displaying a list, the Datatracker should
474 allow easy sorting of the I-Ds with the following collation orders:
476 o Alphabetical by I-D filename and RFC number
478 o Alphabetical by document title
480 o Alphabetical by associated WG
482 o Date of publication of current version of the document
484 o Date of most recent change of status of any type
485 o Date of most recent significant change of status
487 In displays, a particular I-D or RFC should only included once; for
488 example, if someone manually adds draft-ietf-cuteacronym-sometopic to
489 his list and also specifies that all I-Ds from the "cuteacronym" WG
490 are included in the list, that I-D should only appear once in the
491 display. The column saying which included list(s) contain this I-D
492 helps alleviate this loss of information.
494 The user might also want to group the I-Ds using the groupings in the
495 list, such as "all I-Ds from this WG" and "all I-Ds that contain this
496 word in the title".
498 The Datatracker should save the last-chosen sorting for display with
499 the definition of the list.
501 2.3.2. Requirement: Users can choose which attributes to display
503 There are many attributes that might be displayed, and different
504 users will have different information that they want to see. Also,
505 users will have different display technologies: someone might
506 normally use a web browser on a large screen, but at other times use
507 the browser on their phone.
509 Choosing which attributes should be displayed should be simple for
510 the user. The Datatracker should save the last-chosen set of
511 attributes for display with the definition of the list. The default
512 is to display the I-D filename or RFC number, document title, date of
513 current I-D or RFC publication date, status in the RFC stream or RFC
514 process, associated WG or RG, whether it was changed within the last
515 7 days, and included list(s) which contain this I-D.
517 The Datatracker should support display of the following attributes:
519 o I-D filename
521 o I-D title
523 o Date of current I-D
525 o Status in the IETF process
527 o Associated WG or RG
529 o Associated AD, if any
531 o Changed within the last 1 day
532 o Changed within the last 2 days
534 o Changed within the last 7 days
536 There is some leeway for how the Datatracker might display these
537 attributes. For example, the "changed within" attributes might be
538 shown with a check mark or a colored box.
540 2.3.3. Requirement: Users can flag I-Ds with dates in the future
542 When tracking I-Ds, some users want to be able to say "tell me if
543 this I-D has not changes state by a particular date" such as when an
544 I-D is starting a two-week last call or an I-D author has promised a
545 new version by the end of the week. This feature gives the user a
546 "dashboard" style capability.
548 For each I-D, the user should be able to set a marker date by which
549 an update is expected. The Datatracker display will provide a visual
550 indication if the marker date has passed but no change in status has
551 occurred. It must be very easy for the user to remove these update-
552 expected markers.
554 2.3.4. Requirement: Users can specify highlighting of I-Ds and RFCs
555 with recent changes
557 The Datatracker cannot easily keep track of when a user last looked
558 at the page for a particular list. Thus, it instead needs to let a
559 user say which range of dates they are most interested in. To that
560 end, the user needs to be able to easily specify the amount of time
561 they consider recent, either as "the past nnn hours", "the past nnn
562 days", or "since this particular date".
564 2.4. File Output
566 2.4.1. Requirement: Users can get their current list as a single file
568 Some users have their own tools for displaying and otherwise
569 processing lists of I-Ds and RFCs. To make this easier, users should
570 be able to get a machine-parsable file that has a well-known format
571 and syntax that contains all the data that was used to create the
572 current display. The order of the records in the file is not
573 important because it is assumed that the user's program will sort the
574 results themselves. All attributes will be included because it is
575 assumed that the user's programs will only deal with the ones the
576 user cares about.
578 When a list is marshaled into a data file, each record in the file
579 format represents a single I-D or RFC. In a file, a particular I-D
580 or RFC is only included once; for example, if someone manually adds
581 draft-ietf-cuteacronym-sometopic to his list and also specifies that
582 all I-Ds from the "cuteacronym" WG are included in the list, that I-D
583 only appears once.
585 This feature will allow anyone to create mash-ups of their own and
586 create their own web sites based on the IETF data. This is
587 significantly easier than adding features to the Datatracker, and is
588 able to cater to narrow audiences. The format of this file has yet
589 to be determined.
591 3. IANA Considerations
593 None.
595 4. Security Considerations
597 A tool for tracking the status of I-Ds and RFCs can affect the
598 privacy of its users. Someone could possibly determine relevant
599 information about a user if they knew what that user was tracking.
601 Web applications, particularly those that store data on a web server,
602 are a common source of security issues such as cross-site scripting
603 attacks. The tool described in this document might also use access
604 control for lists, and access control and authentication also cause
605 security issues if not implemented properly.
607 5. Acknowledgements
609 Ideas used in this document were contributed by Scott Bradner, Leslie
610 Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen,
611 Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy
612 Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad,
613 Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner.
615 6. Informative References
617 [ALTSTREAMS]
618 Hoffman, P., "Data Tracker States and Annotations for the
619 IAB, IRTF, and Independent Submission Streams",
620 draft-hoffman-alt-streams-tracker (work in progress),
621 September 2010.
623 [CHARTERTOOL]
624 Hoffman, P., "Requirements for a Working Group Charter
625 Tool", draft-ietf-genarea-charter-tool (work in progress),
626 October 2010.
628 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
629 3", BCP 9, RFC 2026, October 1996.
631 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
632 Syndication Format", RFC 4287, December 2005.
634 [RFC6174] Juskevicius, E., "Definition of IETF Working Group
635 Document States", RFC 6174, March 2011.
637 [RFC6175] Juskevicius, E., "Requirements to Extend the Datatracker
638 for IETF Working Group Chairs and Authors", RFC 6175,
639 March 2011.
641 Appendix A. Possible Tracking of Other Documents
643 It is not at all clear if any of these will be a requirement, a later
644 requirement, or a non-requirement. Further, even if one or more of
645 these non-I-D items is made a requirement, it is not clear whether
646 they will be included in the same lists with I-Ds. That is, if
647 tracking IANA registry changes are considered a requirement, it is
648 not clear whether a user would include the registries in a list that
649 also contains I-Ds, or whether they would need to create two lists,
650 one for I-Ds and one for IANA registries.
652 A.1. Tracking WG Charter Changes
654 It will soon be easier to track changes in WG charters and
655 milestones; see [CHARTERTOOL] for more information. Someone
656 subscribing to the mail stream for a WG would be able to see each of
657 these changes. With the expected changes, the Datatracker would be
658 able to update WGs in a list without any polling.
660 A.2. Tracking IANA Registry Changes
662 Developers may need to get values from IANA registries for their
663 software/hardware implementations. They might want to know when the
664 registry changes, such as additional entries or updates to current
665 entries. Thus, being able to be notified when a registry changes
666 would be valuable to them.
668 Adding this functionality may be tricky for some registries. For
669 example, if a developer cared about DKIM signature tags, they would
670 have to subscribe to
671 which (currently)
672 covers a handful of registries, all related to DKIM. Thus, a change
673 to the DKIM hash algorithms would trigger a message showing that the
674 registry had changed, even though the DKIM signature tags registry
675 had not.
677 A.3. Tracking Changes in the Liason Statement Directory
679 Users might want to know when a new liaison statement is sent by the
680 IETF, or when one is received by the IETF.
682 A.4. Tracking Changes in Documents Outside the IETF Sphere
684 Users might want to track documents that relate to IETF activities
685 but are produced by other standards development organizations (SDOs)
686 such as the W3C, the IEEE, the Unicode Consortium, the ITU, and
687 others. In order for the tracker to track these documents, it would
688 need to poll occasionally and possibly scrape listings from HTML.
690 A.5. Tracking Additions to the IPR Statement Repository
692 Users might want to know when a new IPR statement is submitted.
694 Appendix B. Ideas that Might Be Implemented Later
696 The following are ideas for the new tool that are not currently being
697 considered for the first round of development, but are being
698 documented for possible future use. Items here might move between
699 this list and the list of requirements that are expected to be in the
700 first round.
702 o The Datatracker could list all of the publicly-readable lists (or
703 certainly at least the ones associated with IETF activities), and
704 have links from WG pages in Datatracker to the publicly-readable
705 lists maintained by the WG chairs.
707 o Earlier versions of this I-D had a requirement that lists needed
708 to be able to include other lists. While this may still be
709 desired, it was decided that implementing this in a safe and
710 understandable way would be too difficult. In particular, there
711 was a concern about detecting and handling loops. Later versions
712 of the Datatracker might include this feature.
714 o In public lists, it might be useful for someone to be able to
715 understand why particular I-Ds and/or groups are added. Allowing
716 the user who put together the list to add a comment field would
717 help someone else see the motivation.
719 o The Datatracker might remove lists if it seems that storing them
720 on the Datatracker is taking too many resources. The Datatracker
721 can periodically send mail to the user reminding them to delete
722 lists that are no longer needed.
724 o The normal Datatracker display could have a button to add a
725 particular I-D to the user's personal list.
727 o Allow each user to determine what "significant change in status"
728 is for the list they create. This could be done by a series of
729 check boxes for every possible status change.
731 o A list creator can add a list-level comment about who might be
732 interested in following the list.
734 o If the agendas for an upcoming meeting are scraped for I-D names,
735 it would be possible to add an attribute to an I-D that lists that
736 WG agenda(s) on which it appears.
738 o In the section on "Adding groups of I-Ds to a list by attribute",
739 add an attribute for "all I-Ds that are referenced by any I-D in a
740 particular list".
742 o Make it possible to add all I-Ds that have a certain section to a
743 list (non-trivial IANA considerations, ASN.1 modules in
744 appendices, MIBs, ABNF, XML modules, ...).
746 o Even though Atom feeds have been around for years, they are new to
747 many Internet users, and even experienced users only know how to
748 use them in limited ways. The Datatracker should have at least a
749 few paragraphs explaining how the Atom feeds that it provides can
750 be used in different tools such as dedicated feed readers, online
751 feed-display services, and so on.
753 Author's Address
755 Paul Hoffman
756 VPN Consortium
758 Email: paul.hoffman@vpnc.org