RFC 6293

Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker

📅 published June 2011, from ietf

RFC 6293: Requirements for Internet-Draft Tracking by the IETF Community in the Datatracker 🎀

Okay bestie, here's the deal: this is an Informational RFC from June 2011, written by P. Hoffman of the VPN Consortium. It's an IETF product, but it's just for info, not a Standards Track spec. The header has no Obsoletes or Updates line, so it doesn't replace or change any other RFC. 💅 ISSN 2070-1721.

Abstract 💖

This doc lays out a list of requirements for upgrading the IETF Datatracker so that any IETF community member, leadership included, can easily track how the Internet-Drafts and RFCs they care about are doing. 🦋

Status of This Memo ✨

Not a Standards Track spec, we're clear. 🌸 It's published purely for information.

It's an IETF product and it reflects what the IETF community agreed on. It got public review and the IESG approved it for publication. But being IESG-approved doesn't automatically make something a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 if you want the details. 🧚

For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc6293. 💜

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. Code components pulled out of this doc must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, just like the Simplified BSD License says. 💀

Table of Contents 📋

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  Context for This Document  . . . . . . . . . . . . . . . .  4
  1.3.  Definitions Used in This Document  . . . . . . . . . . . .  5
  1.4.  Expected User Interactions . . . . . . . . . . . . . . . .  6
2.  Requirements for Tools Features  . . . . . . . . . . . . . . .  6
  2.1.  Lists  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
    2.1.1.  Requirement: Lists of I-Ds and RFCs can be large . . .  6
    2.1.2.  Requirement: Every Datatracker user can create one
            list . . . . . . . . . . . . . . . . . . . . . . . . .  7
    2.1.3.  Requirement: Read-only views of private lists can
            be made visible to others  . . . . . . . . . . . . . .  7
    2.1.4.  Requirement: The Datatracker must support optional
            publicly-readable lists for WGs and Area Directors . .  7
    2.1.5.  Requirement: Specifying the I-Ds and RFCs that are
            in a list must be simple . . . . . . . . . . . . . . .  8
    2.1.6.  Requirement: Adding groups of I-Ds to a list by
            attribute must be simple . . . . . . . . . . . . . . .  8
    2.1.7.  Requirement: Private information must not be
            exposed in lists . . . . . . . . . . . . . . . . . . .  9
  2.2.  Notifications  . . . . . . . . . . . . . . . . . . . . . .  9
    2.2.1.  Requirement: Users can be notified when an I-D
            changes status . . . . . . . . . . . . . . . . . . . .  9
    2.2.2.  Requirement: Every list has Atom feeds associated
            with it  . . . . . . . . . . . . . . . . . . . . . . .  9
    2.2.3.  Requirement: Every list has mail streams
            associated with it . . . . . . . . . . . . . . . . . . 10
    2.2.4.  Requirement: Notifications need to specify which
            list caused the notification . . . . . . . . . . . . . 10
  2.3.  Display in the Datatracker . . . . . . . . . . . . . . . . 10
    2.3.1.  Requirement: Users can define their Datatracker
            document view  . . . . . . . . . . . . . . . . . . . . 10
    2.3.2.  Requirement: Users can choose which attributes to
            display  . . . . . . . . . . . . . . . . . . . . . . . 11
    2.3.3.  Requirement: Users can flag I-Ds with dates in the
            future . . . . . . . . . . . . . . . . . . . . . . . . 12
    2.3.4.  Requirement: Users can specify highlighting of
            I-Ds and RFCs with recent changes  . . . . . . . . . . 12
  2.4.  File Output  . . . . . . . . . . . . . . . . . . . . . . . 12
    2.4.1.  Requirement: Users can get their current list as a
            single file  . . . . . . . . . . . . . . . . . . . . . 12
3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5.  Informative References . . . . . . . . . . . . . . . . . . . . 13
Appendix A.  Possible Tracking of Other Data . . . . . . . . . . . 15
  A.1.  Tracking WG Charter Changes  . . . . . . . . . . . . . . . 15
  A.2.  Tracking IANA Registry Changes . . . . . . . . . . . . . . 15
  A.3.  Tracking Changes in the Liason Statement Directory . . . . 15
  A.4.  Tracking Changes in Documents Outside the IETF Sphere  . . 15
  A.5.  Tracking Additions to the IPR Statement Repository . . . . 16
Appendix B.  Ideas that Might Be Implemented Later . . . . . . . . 16

1. Introduction ✨

The IETF Datatracker is where lots of IETF community members go to check the status of Internet-Drafts (I-Ds) and RFCs, and to pull up the ones that match what they're looking for. 🔍 The current one lives at <https://datatracker.ietf.org/>, and anyone can use it to search active I-Ds and RFCs and get a list that matches their criteria. (It also covers expired I-Ds, but those aren't the point here.) 🍓

You can search by I-D filename, words in the I-D title, I-D author list, associated Working Group (WG), IETF area, the responsible Area Director (AD), or IESG status. For RFCs you can search by number or by words in the title. The results list has six columns: filename or RFC number, the document's title, the date it was published, its status in the IETF or RFC process, IPR statements, and the responsible AD (if there is one). 💅

Instead of hunting through search every time, users might want to make a list of the I-Ds they normally follow. Some will keep that list private, and others will want to share it. 🫶

Different people want updates in different ways, and that's totally valid. Lots of users want to be notified right away, through an Atom feed (see [RFC4287]) or an automatically generated email. Lots of others only want to check in when they open a Web page. Some want the data for a list so they can feed it into other tools. And of course, some people want all three! 🌈 All of these help users keep track of I-Ds as they move through their lifecycle.

1.1. Usage Scenarios 🦋

The main reason for these changes to the Datatracker is to let a bunch of different people track I-Ds and RFCs, so they can see when important events happen. Some examples:

  • A WG chair might want to keep a list of all the I-Ds from other WGs that relate to active I-Ds in his or her WG. 👑
  • That same WG chair might want to help WG members follow the same I-Ds that he or she is following. 🧚
  • Someone who cares about an established topic such as the DNS may want to follow the various I-Ds that might make changes to the DNS, and also be aware if any of the DNS RFCs are later updated and/or have errata posted against them. This covers not only I-Ds in the many WGs that directly change the DNS (DNSEXT, DNSOP, BEHAVE, and so on), but also individual submissions, IAB I-Ds, IRTF I-Ds, and Independent submissions. 💜
  • Developers who aren't active in the IETF process might want to lightly follow I-Ds and RFCs on a particular topic, so they can watch for things that might affect their implementations. 🎀
  • An IETF "regular" might want to follow parts of the process by focusing on all the I-Ds being shepherded by a particular Area Director. 🌸

1.2. Context for This Document 🧚

This doc describes the requirements for extending the Datatracker to add these capabilities. Once it's complete, it may be used to issue an RFP for designing and building these enhancements. 💖

Some requirements here are labelled "later requirements". The items without that label are expected to be part of the initial RFP, since they give the community the most benefit. The later requirements might go into a later RFP. ⭐

The initial general requirements that led to the specific requirements in this doc describe tools that include:

  • the ability to create one or more (possibly large) lists of I-Ds that community members want to follow
  • the ability to get notifications when particular I-Ds from a list change state
  • the ability to see all of the state changes that have occurred on all the I-Ds in a list over a specified range of dates
  • the ability to set the granularity of the changes (such as "every change", "just approvals and publication", and so on)
  • the ability to organize views of a list in many fashions that would be useful to different types of community members
  • the ability to share and merge lists with other community members

Quick note: [RFC2026] describes the process that I-Ds go through before they either become RFCs or get abandoned. The Datatracker doesn't control that process. It just reports the current state of each I-D as it moves along. 🦋

Part 1 of 4 is done, and part 2 is next. Don't leave me on read, bestie. 🫶💅

1.3. Definitions Used in This Document

okay so a user is just an individual person who's part of the IETF community 💖

a list is an unordered set of RFCs, I-Ds, and groups of I-Ds 📚 lists get specified by users, and sometimes the author is a role instead of a person, like a WG chair being the one who specifies the list for their WG 🧚

an attribute is a feature of an I-D or RFC, like its filename or RFC number, or where it currently is in the IETF or RFC process. attributes usually show up as columns in the Datatracker 📊

a row is the set of attributes about one single I-D or RFC that shows up in the Datatracker 🌸

a significant change in status is all approvals and dispositions of an I-D. assuming the changes to the Datatracker in [RFC6174], [RFC6175] and [ALTSTREAMS] are made, "all approvals" means these states:

  • IETF stream: the WG states Adopted by a WG, In WG Last Call, WG Consensus: Waiting for Write-up, Parked WG document, and Dead WG document; the IESG states Publication Requested, In Last Call, IESG Evaluation, and Sent to the RFC Editor
  • IAB stream: Active IAB Document, Community Review, and Sent to the RFC Editor
  • IRTF stream: Active RG Document, In RG Last Call, Awaiting IRSG Reviews, In IESG Review, Sent to the RFC Editor, and Document on Hold Based On IESG Request
  • ISE stream: Submission Received, In ISE Review, In IESG Review, Sent to the RFC Editor, and Document on Hold Based On IESG Request
  • All streams: in addition to the above, the disposition states Approved, RFC Published, and Dead are also included

an update to an RFC is the announcement of a newer RFC that updates or obsoletes the base RFC 🔥 it also covers an in-place change to the RFC's maturity level, the RFC's status being changed to historic, or an announcement of an errata posted for the base RFC ✨

1.4. Expected User Interactions

when a user wants to follow a group of I-Ds and/or RFCs, they head to the Datatracker and create a new list 💅 the requirements for lists are in Section 2.1. once the list exists, the user has three ways to see when the I-Ds and/or RFCs in it get updated:

  • by going to the Datatracker page for the list (see Section 2.3) 🌈
  • by subscribing to the Atom feed for the list (see Section 2.2.2) in a feed reader that fetches updates automatically 🦋
  • by subscribing to the mail stream for the list (see Section 2.2.3) and reading it in their mail reader 💌

2. Requirements for Tools Features ✨

this section is where the requirements for the tool from earlier live 🎀 the eventual tool, if it gets built, might have more features than what's listed here. but before this document is finished, it should contain as many requirements as possible that the IETF community can agree on 🫶

2.1. Lists

2.1.1. Requirement: Lists of I-Ds and RFCs can be large

an active IETF participant might want to follow the status of hundreds of I-Ds and dozens of RFCs 😭 for example, some ADs have 100 I-Ds in their area. they might also want to follow I-Ds outside their area that affect documents in their area 👀

2.1.2. Requirement: Every Datatracker user can create one list

when a user gets a Datatracker account, that account comes with an empty list already set up 🍓 normally only the owner of the account can change the list, though the Secretariat can also modify it as part of its support role for the Datatracker. each Datatracker user is limited to one list 🧚

for this requirement to be met, it must be easy for any community member to get a Datatracker account. account setup must not involve any direct action from the Secretariat. but the Secretariat is in charge of supporting Datatracker accounts (lost passwords, odd interactions, and so on), so adding more accounts could mean more work for them 🙈

the only person who can edit the contents of a private list is the person who knows the password to the account the list is linked to 🔒

2.1.3. Requirement: Read-only views of private lists can be made visible to others

some users will want to share a read-only view of their list 👑 every private list gets a URL that leads to the Datatracker view of the list, and that URL has to be shareable without letting others edit the list. the Atom feed for a private list also has to be shareable without giving anyone the ability to edit the list 🦋

2.1.4. Requirement: The Datatracker must support optional publicly-readable lists for WGs and Area Directors

it's super common in the IETF for users to follow the work of an entire WG, not just single I-Ds and RFCs inside a WG 💖 it's also really common for work related to a WG to happen outside the WG, either in other WGs or as individual efforts. lots of WG chairs keep an eye on that outside-the-WG activity for different reasons 👀

a smaller group of community members follows an entire Area's worth of topics 🌸 those topics often happen inside the WGs of an area, but not always. for example, some topics related to the Security Area happen in WGs in the Applications Area.

so it would be useful for community members to find a list that matches the WGs or Areas they care about ✨ the WG lists could be maintained by the WG chairs, and the Area lists would likely be maintained by the ADs. note that these lists are not mandatory. for example, a WG chair might not choose to maintain one for a WG whose topic is extremely broad 🌈

WG chairs and Area Directors already have Datatracker accounts, so meeting this requirement just means linking those accounts to the role that controls the list 💅

2.1.5. Requirement: Specifying the I-Ds and RFCs that are in a list must be simple

when a user creates a new list, it must be easy to add single I-Ds and RFCs to it 🦋 this could be done with the Datatracker's current search facility, by adding an "add to list" option to the display of searched-for I-Ds. when editing an existing list, it must also be easy to add more I-Ds and RFCs, and easy to remove I-Ds and RFCs from it 🧹

2.1.6. Requirement: Adding groups of I-Ds to a list by attribute must be simple

I-Ds have lots of attributes, and some users might want to follow every I-D that has a particular attribute 🤩 some attributes make sense for specifying lists, and some don't. it should be easy to add each of the following attributes when adding to or editing a list:

  • All I-Ds associated with an particular WG
  • All I-Ds associated with all WGs in an particular Area
  • All I-Ds with a particular responsible AD
  • All I-Ds with a particular author
  • All I-Ds with a particular document shepherd
  • All I-Ds that have a reference to a particular RFC
  • All I-Ds that have a reference to a particular I-D
  • All I-Ds that are referenced by a particular RFC
  • All I-Ds that are referenced by a particular I-D
  • All I-Ds that contain a particular text string

these attributes are dynamic, so the list of I-Ds with a particular attribute will change after the user adds that attribute to a list ⏰ the Datatracker should update lists with dynamic attributes as often as is sensible for the server environment, like once an hour or more.

some of these attributes are based on heuristics from programs that parse I-Ds, so they're inherently not completely reliable 💀

2.1.7. Requirement: Private information must not be exposed in lists

any private information in the Datatracker must be kept out of every display of the lists or mail streams 🙊 that includes private notes from the IESG balloting for an I-D, and probably other data that's currently only visible to certain members of the IETF leadership 🔐

2.2. Notifications

2.2.1. Requirement: Users can be notified when an I-D changes status

some users don't want to keep checking the Datatracker's display page to find out when an I-D or RFC has been updated 😭 they want to be notified right after the change happens. the Datatracker needs to support this kind of immediate notification, where "immediate" means within an hour of a change to any I-D or RFC in the list ⚡ this requirement can be met with Atom feeds and mail streams, which are covered in the next two sections.

the Datatracker might create a generic "notifications engine" that can generate the Atom feeds and mail streams. that engine could later be used to add other notification types, like a Jabber feed 🧚

2.2.2. Requirement: Every list has Atom feeds associated with it

the list will have two Atom feeds generated from its changes: one for every change in status, and another for significant change of status 📮 each Atom feed will have a stable URL that feed readers can use 🦋

a lot of IETF users already use Atom feeds from the IETF Tools Team for single I-Ds. the new list feeds will give them better selection options, so they can cut down on how many feeds they need to follow 💖

2.2.3. Requirement: Every list has mail streams associated with it

a user can subscribe to two mail streams generated from the list's changes: one for every change in status, and another for significant change of status 💌

the mail streams send a message for each change, and they are not batched (like one message per day) 🙅 users who want less frequent, batched notifications need to use the Atom feeds instead of the mail streams.

2.2.4. Requirement: Notifications need to specify which list caused the notification

users might have feeds and/or subscriptions to multiple lists 🌀 to tell apart duplicate notifications from different lists, the body of the message in the Atom feed or mail stream needs to say which list generated the notification 🎯 (ideally, a user who wants notifications will make one list based on multiple lists. but if they subscribe to several lists, this requirement at least suggests they should limit their overlapping subscriptions 💅)

2.3. Display in the Datatracker

2.3.1. Requirement: Users can define their Datatracker document view ✨

Okay so, there are SO many ways someone might want to see the Datatracker's HTML view of a list 💅 For example, a user might want it sorted alphabetically by I-D filename and RFC number, but after being off the net for a week, they'd want it sorted by changes of status so the stuff that changed recently is right at the top 🔥

The default is to list I-Ds in alphabetical order by I-D filename, with RFCs at the end. When someone is displaying a list, the Datatracker should allow easy sorting of the I-Ds with these collation orders:

  • Alphabetical by I-D filename and RFC number
  • Alphabetical by document title
  • Alphabetical by associated WG
  • Date of publication of current version of the document
  • Date of most recent change of status of any type
  • Date of most recent significant change of status

In displays, a particular I-D or RFC should only be included once 🫶 For example, if someone manually adds draft-ietf-cuteacronym-sometopic to their list and also says that all I-Ds from the "cuteacronym" WG are included, that I-D should still only show up once. The column saying which included list(s) contain this I-D helps keep that from becoming a mess of lost info 🦋

Users might also want to group the I-Ds using the groupings in the list, like "all I-Ds from this WG" or "all I-Ds that contain this word in the title" 🌸

The Datatracker should save the last-chosen sorting for display with the definition of the list 💜

2.3.2. Requirement: Users can choose which attributes to display 🎀

There are lots of attributes that could be displayed, and different users want to see different info. Also, people use different display tech: someone might be on a big screen with a Web browser one minute, then on their phone the next 📱

Choosing which attributes get displayed should be simple for the user ✨ The Datatracker should save the last-chosen set of attributes for display with the definition of the list. The default is to display the I-D filename or RFC number, document title, date of current I-D or RFC publication date, status in the RFC queue or RFC process, the associated stream (IETF WG, IRTF RG, IAB, or ISE), whether it was changed within the last 7 days, and included list(s) that contain this I-D 🍓

The Datatracker should support display of the following attributes:

  • I-D filename
  • I-D title
  • Date of current I-D
  • Status in the IETF process
  • Associated WG or RG
  • Associated AD, if any
  • Changed within the last 1 day
  • Changed within the last 2 days
  • Changed within the last 7 days

There's some leeway in how the Datatracker might display these attributes 🌈 For example, the "changed within" attributes might be shown with a check mark or a colored box ✅

2.3.3. Requirement: Users can flag I-Ds with dates in the future 🧚

When tracking I-Ds, some users want to say "tell me if this I-D has not changed state by a particular date" 🙈 Like when an I-D is starting a two-week last call, or when an I-D author has promised a new version by the end of the week. This feature gives the user a "dashboard" style capability, and it's giving organized 💅

For each I-D, the user should be able to set a marker date by which an update is expected. The Datatracker display will give a visual indication if the marker date has passed but no change in status has happened. It must be very easy for the user to remove these update-expected markers 🧹

2.3.4. Requirement: Users can specify highlighting of I-Ds and RFCs with recent changes 🔥

Okay, this one's a little tricky. The Datatracker cannot easily keep track of when a user last looked at the page for a particular list 👀 So instead, it needs to let a user say which range of dates they care about most. To do that, the user needs to be able to easily set the amount of time they consider recent, either as "the past nnn hours", "the past nnn days", or "since this particular date" 💜

2.4. File Output 📁

2.4.1. Requirement: Users can get their current list as a single file 🦋

Some users have their own tools for displaying and processing lists of I-Ds and RFCs, and honestly, same 🫶 To make that easier, users should be able to get a machine-parsable file with a well-known format and syntax that contains all the data used to create the current display. The order of the records in the file doesn't matter, since it's assumed the user's program will sort the results itself. All attributes will be included too, because it's assumed the user's programs will only deal with the ones they care about 💅

When a list is marshaled into a data file, each record represents a single I-D or RFC. In a file, a particular I-D or RFC is only included once. For example, if someone manually adds draft-ietf-cuteacronym-sometopic to their list and also says that all I-Ds from the "cuteacronym" WG are included, that I-D only appears once in the file ✨

This feature will let anyone create their own mash-ups and Web sites based on the IETF data, and it's SO much easier than adding features to the Datatracker. It can also cater to narrow audiences 🌸 The format of this file has yet to be determined 🧚

3. Security Considerations 🔐

A tool for tracking the status of I-Ds and RFCs can affect the privacy of its users 🙈 Someone could possibly figure out relevant info about a user if they knew what that user was tracking. Yikes 😭

Web applications, especially ones that store data on a Web server, are a common source of security issues, like cross-site scripting attacks 💀 The tool described in this document might also use access control for lists, and access control and authentication can also cause security issues if they aren't implemented properly. So be careful, bestie 🫶

4. Acknowledgements 🌷

Ideas used in this document were contributed by Scott Bradner, Leslie Daigle, Spencer Dawkins, Aaron Falk, Russ Housley, Tero Kivinen, Barry Leiba, John Levine, Henrik Levkowetz, Kurtis Lindqvist, Andy Malis, Ray Pelletier, Blake Ramsdell, Julian Reschke, Jim Schaad, Yaron Sheffer, Robert Sparks, Andrew Sullivan, and Sean Turner 👑

5. Informative References 📚

  • [ALTSTREAMS] Hoffman, P., "Data Tracker States and Annotations for the IAB, IRTF, and Independent Submission Streams", Work in Progress, May 2011.
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
  • [RFC6174] Juskevicius, E., "Definition of IETF Working Group Document States", RFC 6174, March 2011.
  • [RFC6175] Juskevicius, E., "Requirements to Extend the Datatracker for IETF Working Group Chairs and Authors", RFC 6175, March 2011.
  • [RFC6292] Hoffman, P., "Requirements for a Working Group Charter Tool", RFC 6292, June 2011.

Appendix A. Possible Tracking of Other Data 🧩

It is not at all clear if any of these will be a requirement, a later requirement, or a non-requirement 🤷‍♀️ Even if one or more of these non-I-D items becomes a requirement, it's not clear whether they'd be included in the same lists as I-Ds. Like, if tracking IANA registry changes is a requirement, it's unclear whether a user would put the registries in a list that also has I-Ds, or whether they'd need two lists: one for I-Ds and one for IANA registries 🤔

A.1. Tracking WG Charter Changes 📝

It will soon be easier to track changes in WG charters and milestones; see [RFC6292] for more information 💖 Someone subscribing to the mail stream for a WG would be able to see each of these changes. With the expected changes, the Datatracker would be able to update WGs in a list without any polling ✨

A.2. Tracking IANA Registry Changes 🗂️

Developers may need to get values from IANA registries for their software and hardware implementations 💻 They might want to know when a registry changes, like when entries are added or current entries are updated. So being able to get notified when a registry changes would be valuable to them 🦋

Adding this functionality may be tricky for some registries. For example, if a developer cared about DKIM signature tags, they'd have to subscribe to <http://www.iana.org/assignments/dkim-parameters/>, which (currently) covers a handful of registries, all related to DKIM. So a change to the DKIM hash algorithms would trigger a message saying the registry had changed, even though the DKIM signature tags registry hadn't 🙃

A.3. Tracking Changes in the Liason Statement Directory 💌

Users might want to know when a new liaison statement is sent by the IETF or when one is received by the IETF 📬

A.4. Tracking Changes in Documents Outside the IETF Sphere 🌍

Users might want to track documents that relate to IETF activities but are produced by other standards development organizations (SDOs) such as the W3C, the IEEE, the Unicode Consortium, the ITU, and others 🌐 To track these documents, the tracker would need to poll occasionally and possibly scrape listings from HTML 🕸️

A.5. Tracking Additions to the IPR Statement Repository ⚖️

Users might want to know when a new IPR statement is submitted 📑

Appendix B. Ideas that Might Be Implemented Later ✨

okay so this section is the "ooh wouldn't it be cute if" wishlist 🧚 these are ideas for the new tool that are NOT being considered for the first round of development, but they're getting written down for maybe later 💅 and fr, items from this list could totally graduate up to the requirements list that gets built in the first round 🦋

  • The Datatracker could list all of the publicly-readable lists (or at least the ones tied to IETF activities) 🌸 and have links from WG pages in the Datatracker to the publicly-readable lists the WG chairs maintain 🫶
  • Earlier drafts of this RFC included a requirement to be able to include other lists. bestie, that was a whole vibe, but it got decided that doing it in a safe and understandable way would be too difficult 💀 the big worry was detecting and handling loops 🙈 so later versions of the Datatracker might bring it back 🔄
  • In public lists, it might be useful for someone to understand why particular I-Ds and/or groups got added. 📝 letting the person who built the list add a comment field would help everyone else get the motivation ✨
  • The Datatracker might remove lists if storing them is eating too many resources. 🍓 it could periodically mail the user a reminder to delete lists they no longer need 📬
  • The normal Datatracker display could have a button to add a particular I-D to the user's personal list. 🎀 one click, no cap 👑
  • Allow each user to decide what "significant change in status" means for the list they create. ⭐ this could be done with a series of check boxes for every possible status change 💖
  • A list creator can add a list-level comment about who might be interested in following the list. 💜 main character energy for the curator 👑
  • If the agendas for an upcoming meeting get scraped for I-D names, it would be possible to add an attribute to an I-D that lists the WG agenda(s) it appears on. 🗓️ that's giving organized 💅
  • In the section on "Adding groups of I-Ds to a list by attribute", add an attribute for "all I-Ds that are referenced by any I-D in a particular list". 🔗 the referencing web is so iconic 🕸️
  • Make it possible to add all I-Ds that have a certain section to a list (non-trivial IANA considerations, ASN.1 modules in appendices, MIBs, ABNF, XML modules, ...). 🧩 literally every spec-nerd's dream 🤓
  • Even though Atom feeds have been around for years, they're new to many Internet users, and even experienced users only know how to use them in limited ways. 😭 so the Datatracker should have at least a few paragraphs explaining how the Atom feeds it provides can be used in different tools, like dedicated feed readers, online feed-display services, and so on 📰🌈

Author's Address 🖋️

Paul Hoffman VPN Consortium

EMail: paul.hoffman@vpnc.org

📦 where this page comes from