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