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