idnits 2.17.1
draft-ietf-genarea-datatracker-community-01.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 (October 21, 2010) is 4929 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 October 21, 2010
5 Expires: April 24, 2011
7 Requirements for Draft Tracking by the IETF Community in the Datatracker
8 draft-ietf-genarea-datatracker-community-01
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 April 24, 2011.
34 Copyright Notice
36 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
52 1.1. Definitions Used in This Document . . . . . . . . . . . . 4
53 1.2. Discussion of These Requirements . . . . . . . . . . . . . 4
54 2. Requirements for Tools Features . . . . . . . . . . . . . . . 5
55 2.1. Lists . . . . . . . . . . . . . . . . . . . . . . . . . . 5
56 2.1.1. Requirement: Lists of drafts can be large . . . . . . 5
57 2.1.2. Requirement: A user can create multiple lists . . . . 5
58 2.1.3. Requirement: Some lists must be able to be private . . 5
59 2.1.4. Requirement: Specifying the drafts that are in a
60 list must be simple . . . . . . . . . . . . . . . . . 6
61 2.1.5. Requirement: Adding groups of drafts to a list by
62 attribute must be simple . . . . . . . . . . . . . . . 6
63 2.1.6. Requirement: Lists can dynamically include other
64 lists . . . . . . . . . . . . . . . . . . . . . . . . 7
65 2.2. Notifications . . . . . . . . . . . . . . . . . . . . . . 7
66 2.2.1. Requirement: Users can be notified when a draft
67 changes status . . . . . . . . . . . . . . . . . . . . 7
68 2.2.2. Requirement: Every list has Atom feeds associated
69 with it . . . . . . . . . . . . . . . . . . . . . . . 7
70 2.2.3. Requirement: Every list has mail streams
71 associated with it . . . . . . . . . . . . . . . . . . 8
72 2.2.4. Requirement: Notifications need to specify which
73 list caused the notification . . . . . . . . . . . . . 8
74 2.3. Display in the Datatracker . . . . . . . . . . . . . . . . 8
75 2.3.1. Requirement: Users can define how the rows are
76 sorted in a display . . . . . . . . . . . . . . . . . 8
77 2.3.2. Requirement: Users can choose which attributes to
78 display . . . . . . . . . . . . . . . . . . . . . . . 9
79 2.4. File Output . . . . . . . . . . . . . . . . . . . . . . . 10
80 2.4.1. Requirement: Users can get their current list as a
81 single file . . . . . . . . . . . . . . . . . . . . . 10
82 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
83 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
84 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
85 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
86 6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
87 6.2. Informative References . . . . . . . . . . . . . . . . . . 11
88 Appendix A. Some Known Open Issues . . . . . . . . . . . . . . . 11
89 Appendix B. Differences between -00 and -01 . . . . . . . . . . . 12
90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
92 1. Introduction
94 IMPORTANT NOTE: This is a very early draft of a set of requirements.
95 It has gone through no general community review, and thus probably is
96 missing many things that should be included, and some of the things
97 in this draft are wrong and will be changed in future drafts.
98 Nothing in this draft should be considered solid.
100 The IETF Datatracker is used by many IETF community members to find
101 the status of Internet Drafts (I-Ds) and view drafts that meet
102 particular criteria. The current Datatracker, found at
103 , allows anyone to search for active
104 I-Ds and get a list of drafts matching the given criteria. (The
105 Datatracker also allows for searching RFCs and expired I-Ds, but
106 those are not relevant to this discussion.)
108 Users can search in the Datatracker by the filename of the draft,
109 words in the draft's title, author, associated Working Group (WG) or
110 IETF area, the responsible Area Director (AD), or IESG status. The
111 returned list of drafts includes five columns: draft filename (with
112 an active link to an HTMLized version of the draft maintained by the
113 IETF tools team), the draft's title, the date it was submitted, its
114 status in the IETF process, and the responsible AD (if any). For
115 example, the output of a search in the current Datatracker can be
116 seen at .
118 Instead of using the search capability of the Datatracker to manually
119 find I-Ds of interest, users might want to create lists of drafts
120 that they normally follow. Different users in the IETF community
121 will have different ways that they want to get information on draft
122 updates and status. Many users will want to be notified immediately,
123 such as through an Atom feed (see [RFC4287]) or automatically-
124 generated email. Many users will want to only find out about updates
125 when they go to a web page. Many users might want to get the data
126 for a list as input to other tools. And, of course, some users will
127 want all three. All of these desires are related to the overall
128 desire to track drafts through their lifecycle.
130 For example, a WG chair might want to keep a list of all the drafts
131 from other WGs that relate to active drafts in his or her WG.
132 Someone who cares about the DNS probably also wants to follow the
133 various drafts in different areas that affect the DNS. Developers
134 who are not active in the IETF process might want to follow drafts on
135 a particular topic to watch for things that might affect their
136 implementations.
138 This document describes the requirements for extending the
139 Datatracker for such capabilities. When complete, this document may
140 be used to issue an RFP for the design and development of these
141 enhancements to the Datatracker. This document was prepared at the
142 request of the IAOC.
144 Note that [RFC2026] describes the process that Internet Drafts go
145 through before they either become RFCs or are abandoned. The
146 Datatracker does not control this process: instead, it simply reports
147 on the current state of individual drafts as they go through the
148 process.
150 1.1. Definitions Used in This Document
152 o A "user" is an individual person who is member of the IETF
153 community. (Yes, that definition is purposely vague.)
155 o A "list" is an unordered set of filenames of Internet Drafts.
156 Lists are specified by users.
158 o An "attribute" is a feature of a draft, such as its filename, its
159 current state in the IETF process, and so on. Attributes are
160 usually displayed as columns in the Datatracker.
162 o A "row" is a set of attributes about a single draft that is
163 displayed in the Datatracker.
165 o A "significant change in status" is all approvals and disposition.
166 In the current process for drafts in the IETF stream, "all
167 approvals" means "publication requested" "in last call" (this is
168 IETF last call, not WG last call), and "IESG evaluation";
169 disposition is "approved" (for publication as an RFC), "RFC
170 published", and "dead".
172 1.2. Discussion of These Requirements
174 This document is being discussed on the datatracker-rqmts@ietf.org
175 mailing list. See
176 for more
177 information.
179 There will be a BoF at IETF 79 in Beijing to discuss this draft. It
180 is currently being called "iddtspec", which somehow stands for
181 "Review of Datatracker Specifications to Follow Internet-Draft
182 Activities".
184 There is a plan to have one or two virtual meetings after Beijing to
185 discuss these requirements.
187 2. Requirements for Tools Features
189 This section defines the requirements for the tool described earlier
190 in this document. The eventual tool, if implemented, may have more
191 features than are listed here; however, before this document is
192 finished, it should contain as many requirements as possible upon
193 which the IETF community can agree.
195 2.1. Lists
197 2.1.1. Requirement: Lists of drafts can be large
199 An active IETF participant might want to follow the status of
200 hundreds of drafts. For example, some ADs have 100 drafts in their
201 area, and they may also want to follow drafts outside their area that
202 affect documents in their area.
204 2.1.2. Requirement: A user can create multiple lists
206 A user might have multiple areas of interest and would want to track
207 each area on a different web page. Another example would be a WG
208 chair who wants to track the drafts in his or her WG separately from
209 the drafts in a different area of interest. An IETF participant
210 might want to have a list of drafts that they are following closely,
211 and another list of drafts written by work colleagues.
213 2.1.3. Requirement: Some lists must be able to be private
215 Seeing a list of drafts that covers multiple areas of interest can
216 tell you something about the person who created the list. For
217 example, you might be able to guess that they might be looking for a
218 job in a different field by looking at their list of drafts of
219 interest. Of course, anyone can follow individual drafts today
220 without having that be exposed; however, following a particular group
221 of drafts can reveal information about a person.
223 Methods that might keep lists private include:
225 o The lists might only be available using passwords or some other
226 common authentication mechanism. This would require that the
227 Datatracker have a subscription process for users that could
228 assign passwords, and a per-user process for adding lists to a
229 user account.
231 o Lists might be assigned random URLs from a very large (2^128)
232 namespace, and the user who creates a list does not tell others
233 the assigned URL. This method makes it impossible for someone to
234 search the entire set of assigned lists. Given that the URLs for
235 lists are most likely going to be copy-and-pasted anyway, having
236 long random strings in the list's URL is not an impediment.
238 Note that some lists will purposely be made public, so there will be
239 two types of lists.
241 2.1.4. Requirement: Specifying the drafts that are in a list must be
242 simple
244 When a user creates a new list, it must be easy to add individual
245 drafts to the list. There needs to be a mechanism that searches for
246 potential drafts by partial filename, by partial or full title, and
247 by author. Further, when editing an existing list, it must be easy
248 to add additional drafts, and it must be easy to remove drafts from a
249 list.
251 2.1.5. Requirement: Adding groups of drafts to a list by attribute must
252 be simple
254 Drafts have many attributes, and some users might want to follow all
255 of the drafts that have a particular attribute. Some, but not all,
256 attributes have values that make sense for creating lists. It should
257 be easy to add each of the following attributes when adding to or
258 editing a list:
260 o All drafts associated with an individual WG
262 o All drafts associated with all WGs in an individual Area
264 o All drafts with a particular responsible AD
266 o All drafts with a particular author
268 o All drafts with a particular document shepherd
270 o All drafts that have a reference to a particular RFC
272 o All drafts that have a reference to a particular draft
274 o All drafts that are referenced by a particular RFC
276 o All drafts that are referenced by a particular draft
278 o All drafts that contain a particular text string
280 These attributes are dynamic, and thus the list of drafts that have a
281 particular attribute will change after the user adds that attribute
282 to a list. The Datatracker should update lists with dynamic
283 attributes every hour.
285 Note that some of these attributes are derived by programs created by
286 the IETF Tools Team that parse drafts and are therefore inherently
287 not completely reliable.
289 2.1.6. Requirement: Lists can dynamically include other lists
291 If a user is authorized to see the contents of a list, he or she can
292 include that other list in a different list. When the referenced
293 list changes, those changes are also reflected in the referring-to
294 list; that is, if list A includes list B, and the set of drafts in
295 list B changes, the set of drafts in list A is automatically changed.
297 This feature is expected to be useful for experts (particularly WG
298 chairs) who create lists on topics that others might consider
299 interesting. For example, if Alice creates a list that contains all
300 the drafts that she thinks relate to TLS, and Bob has access to that
301 list, Bob can add that list to his personal list of things for which
302 he is interested. Bob might also create a list-of-lists about TLS
303 that includes references to Alice's list as well as to a similar list
304 that Eric put together.
306 2.2. Notifications
308 2.2.1. Requirement: Users can be notified when a draft changes status
310 Some users do not want to go to the Datatracker's display page to
311 find out when a draft has been updated. Instead, they want to be
312 notified immediately after the draft is changed. The Datatracker
313 needs to support this type of immediate notification, where
314 "immediate" means "within an hour of a change to any draft in the
315 list".
317 2.2.2. Requirement: Every list has Atom feeds associated with it
319 The list will have two Atom feeds that are generated from the changes
320 to the list: one for every change in status, and another for
321 significant change of status. Each Atom feed will have a stable URL
322 that can be used by feed readers.
324 Many IETF users are already using Atom feeds created by the IETF
325 Tools Team for individual drafts. Using the new feeds for lists
326 described here will allow them to have better selection capabilities
327 to reduce the number of feeds they need to follow.
329 2.2.3. Requirement: Every list has mail streams associated with it
331 A user can subscribe to two email streams that are generated from the
332 changes to the list: one for every change in status, and another for
333 significant change of status.
335 2.2.4. Requirement: Notifications need to specify which list caused the
336 notification
338 Users might have feeds and/or subscriptions to multiple lists. In
339 order to disambiguate duplicate notifications from multiple lists,
340 the body of the message in the Atom feed or mail stream needs to say
341 which list generated the notification. (Ideally, a user who wants
342 notifications will make one list based on multiple lists, but if they
343 subscribe to multiple lists, this requirement will at least suggest
344 to them that they want to limit their overlapping subscriptions.)
346 2.3. Display in the Datatracker
348 When a list is displayed to the user in the Datatracker's web
349 interface, each row represents a single draft. In a display, a
350 particular draft should only included once; for example, if someone
351 manually adds draft-ietf-cuteacronym-sometopic to his list and also
352 specifies that all drafts from the "cuteacronym" WG are included in
353 the list, that draft should only appear once in the display.
355 2.3.1. Requirement: Users can define how the rows are sorted in a
356 display
358 There are many ways that a user might want to see the Datatracker's
359 HTML view of a list. For example, a user might want to normally see
360 it in alphabetical order by the drafts' filenames, but after the user
361 is of the net for a week, he or she might want to see the list in
362 order of changes of status so that those drafts changed recently
363 appear at the top of the list.
365 When displaying a list, the Datatracker should allow easy sorting of
366 the drafts with the following collation orders:
368 o Alphabetical by draft filename
370 o Alphabetical by draft title
372 o Alphabetical by associated WG
374 o Date of publication of current version of the draft
375 o Date of most recent change of status of any type
377 o Date of most recent significant change of status
379 The Datatracker should save the last-chosen sorting for display with
380 the definition of the list.
382 2.3.2. Requirement: Users can choose which attributes to display
384 There are many attributes that might be displayed, and different
385 users will have different information that they want to see. Also,
386 users will have different display technologies: someone might
387 normally use a web browser on a large screen, but at other times use
388 the browser on their phone.
390 Choosing which attributes should be displayed should be simple for
391 the user. Also, the user should also be able to specify the order in
392 which the attributes are displayed. The Datatracker should save the
393 last-chosen set of attributes for display with the definition of the
394 list.
396 The Datatracker should support display of the following attributes:
398 o Draft filename
400 o Draft title
402 o Date of current draft
404 o Status in the IETF process
406 o Associated WG
408 o Associated AD
410 o Changed within the last 1 day
412 o Changed within the last 2 days
414 o Changed within the last 7 days
416 o Included list(s) which contain this draft
418 There is some leeway for how the Datatracker might display these
419 attributes. For example, the "changed within" attributes might be
420 shown with a check mark or a colored box. The "included lists"
421 attribute might show a pop-up with the names of the lists, given that
422 list names might be long.
424 2.4. File Output
426 2.4.1. Requirement: Users can get their current list as a single file
428 Some users have their own tools for displaying and otherwise
429 processing lists of drafts. To make this easier, users should be
430 able to get a machine-parsable file that has a well-known format and
431 syntax that contains all the data that was used to create the current
432 display. The order of the records in the file is not important
433 because it is assumed that the user's program will sort the results
434 themselves. All attributes will be included because it is assumed
435 that the user's programs will only deal with the ones the care about.
437 When a list is marshaled into a data file, each record in the file
438 format represents a single draft. In a file, a particular draft is
439 only included once; for example, if someone manually adds
440 draft-ietf-cuteacronym-sometopic to his list and also specifies that
441 all drafts from the "cuteacronym" WG are included in the list, that
442 draft only appears once.
444 This feature will allow anyone to create mash-ups of their own and
445 create their own web sites based on the IETF data. This is
446 significantly easier than adding features to the Datatracker, and is
447 able to cater to narrower audiences.
449 The format of the file will be XML or JSON or tab-separated fields in
450 a text file. The decision on which format is supported will be based
451 on the desires of the community while discussing this document.
452 (Imagine how much fun that will be!) Regardless of the format
453 chosen, a syntax will need to be specified.
455 3. IANA Considerations
457 None.
459 4. Security Considerations
461 A tool for tracking the status of Internet Drafts can affect the
462 privacy of its users. The requirements for privacy of the
463 Datatracker views are discussed earlier in the document.
465 Web applications, particularly those that store data on a web server,
466 are a common source of security issues such as cross-site scripting
467 attacks. The tool described in this document might also use access
468 control for lists, and access control and authentication also cause
469 security issues if not implemented properly.
471 5. Acknowledgements
473 Early ideas used in this document were contributed by Russ Housley,
474 John Levine, Ray Pelletier, Blake Ramsdell, Julian Reschke, Yaron
475 Sheffer, and Andrew Sullivan.
477 6. References
479 6.1. Normative References
481 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
482 3", BCP 9, RFC 2026, October 1996.
484 6.2. Informative References
486 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
487 Syndication Format", RFC 4287, December 2005.
489 Appendix A. Some Known Open Issues
491 Given the very early stage of this document, there are actually many
492 more open issues than are listed here. This list is mostly meant to
493 remind the author of topics that need to be updated in future
494 versions of the document, and to spur readers to think of even more
495 open issues. Many of these topic were offered before the -00 draft
496 by early reviewers.
498 o One big feature that is desired is a way to say "tell me if this
499 draft does not change state in the next nnn days". This gives a
500 "dashboard" style capability. Doing this will mean holding more
501 state on the Datatracker.
503 o People get confused about the states of non-IETF streams (IRTF,
504 IAB, ISE). These should be covered explicitly. Also, need
505 definitions of "significant change in status" for the three non-
506 IETF streams.
508 o There will be an interesting and difficult interplay between
509 privacy and sharing lists. If someone shares a list, that person
510 doesn't want anyone modifying the contents of the list. So, there
511 might need to be "sharing a shadow list" or something similar.
513 o There may be legal issues with keeping user data private if we use
514 login accounts.
516 o Is there a formal definition for "drafts associated with a
517 particular WG"?
519 o When an AD agrees to sponsor an individual submission, does the
520 Datatracker consider that draft associated with the AD? If not,
521 that needs to be dealt with here.
523 o Should the file output be in all the interesting formats (XML and
524 JSON and tab-separated text) or just one?
526 o As people coalesce on requirements for display, maybe mock up some
527 HTML examples and put them in the document.
529 o Thought: add a button in the normal Datatracker output to add a
530 particular draft to a particular list.
532 o How prescriptive do we want to be? Should this say things like
533 "JavaScript pop-up" and "CSS" and such?
535 o Should paging be supported for long lists in the HTML display?
537 Appendix B. Differences between -00 and -01
539 Added info for the mailing list.
541 Author's Address
543 Paul Hoffman
544 VPN Consortium
546 Email: paul.hoffman@vpnc.org