RFC 6359

Datatracker Extensions to Include IANA and RFC Editor Processing Information

📅 published September 2011, from ietf

RFC 6359 📄✨ Datatracker Extensions to Include IANA and RFC Editor Processing Information

bestie, this one is the Informational RFC, so it's a guide and not a rule book 🦋 Here's the title block:

  • Who wrote it: S. Ginoza (AMS), M. Cotton (ICANN), and A. Morris (AMS) 🫶
  • Category: Informational 🌸
  • ISSN: 2070-1721
  • Date: September 2011 📅
  • Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates, so it doesn't replace or amend anything 💅

Now let's get into it 💖

Abstract

okay so this doc captures what's needed to plug IANA and RFC Editor state info into the Datatracker 🎀 The goal is one unified tool where the community can track their document as it goes from Internet-Draft (I-D) version -00 all the way to RFC ✨ Once the Datatracker holds that data from -00 to RFC, the Datatracker, IANA, and RFC Editor can automate way more stuff together 🤖 That means less manual labor, fewer processing errors, and less delay, which is honestly iconic 👑 So the doc also lays out the requirements that would make that automation possible 🔥

Status of This Memo

this is not an Internet Standards Track spec 💀 It's published just for information 🌈

It's a product of the Internet Engineering Task Force (IETF) and it represents consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨ Not every IESG-approved document is 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, and how to give feedback, head to http://www.rfc-editor.org/info/rfc6359 🦋

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published 📜 Please read these carefully, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions 🔥 They come with no warranty, as the Simplified BSD License describes 💅

This document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008 🌸 The people who control the copyright in some of that material may not have given the IETF Trust permission to allow changes outside the IETF Standards Process 😭 So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process 🚫 The one exceptions are formatting it for publication as an RFC, or translating it into languages other than English 🌈

1. Introduction ✨

so the IETF Datatracker is a web-based system for managing info about Internet-Drafts (I-Ds) and RFCs, IPR disclosures, liaison statements, and a bunch of other important parts of the document process [IDTRACKER] 💖 In this doc, "IETF Datatracker" is just a generic name for the existing tool that tracks state changes as Internet-Drafts get processed 🎀 The "IETF" in the name doesn't mean the tool is only for the IETF document stream, because this doc stretches its use to the other streams described in [RFC4844] 🌸

The Datatracker reports on the status of I-Ds that have been sent to the IESG for evaluation and publication 🦋 It's going to be extended, following the requirements in [RFC6174] and [RFC6322], to track a document from version -00 until it's requested for IESG evaluation 🧚 But here's the tea: the Datatracker, ICANN (which does the IANA function), and the RFC Editor all run on separate systems, and they can see different amounts of what happens after the stream managers approve a document for publication as an RFC 👀 So this doc defines what the Datatracker needs to add in IANA and RFC Editor state info, so it covers an I-D's whole life from version -00 to RFC publication 💅

This doc also lists the processes between IANA, the RFC Editor, and the Secretariat (through the Datatracker) that should be automated for accuracy and timely processing ⭐ It includes some details about those IANA, RFC Editor, and Secretariat processes, but it does not define any of them 🙅‍♀️ Those processes keep getting reviewed for optimization, and they need to stay flexible so they can adapt to new policy and environment changes 🔄 Each entity sets and defines its own processes 🫶

IANA and the RFC Editor are functions that are independent of the IETF 🌈 When an Internet-Draft enters the IANA queue, IANA keeps ownership of its own data, state names, and tracking systems 💜 Same deal for the RFC Editor's queue: the RFC Editor keeps ownership of its data, state names, and tracking systems 🎀 This doc talks about how the data from the IANA and RFC Editor queues can show up better in the Datatracker, so the IETF community can see the state of a document during its whole lifetime 👑

Before an Internet-Draft is approved for publication as an RFC, the Datatracker is the definitive source for IANA status info, and IANA data can be edited there (by IANA and the Secretariat) ✨ After an Internet-Draft is approved for publication as an RFC, the IANA tracking system becomes the definitive source for IANA status info, and the data can't be edited in the Datatracker anymore 🔒 At that point, the Datatracker data is only a reflection of the IANA tracking system's data 🪞 If the two ever disagree after that point, the IANA tracking system's data is assumed to be correct 🫡

The RFC Editor's tracking system is always the definitive source for RFC Editor status of a document 🌸 RFC Editor data can't be edited through the Datatracker 🙈 The info in the Datatracker is always a reflection of what's in the RFC Editor's tracking system 🦋

2. Integration of Data between the IANA and Datatracker ✨

2.1. IANA Information to Be Added to the Datatracker ✨

Okay so bestie, IANA touches IETF stream documents at 4 different stages on the way from I-D to RFC 💅: IETF Last Call, IESG Review, Document Approval (for publication), and RFC Publication.

Most of these state changes and issues are not captured in the Datatracker 🙈. For the IRTF (Internet Research Task Force) and Independent streams, the IANA review process starts when IESG Review is requested. For the IAB (Internet Architecture Board) stream, review starts when publication as an RFC is requested.

This section lays out the requirements for adding extra IANA information to the Datatracker. It's giving organized 🎀

  • IETF Last Call Comments

Right now, IANA reviews I-Ds that have been sent to IETF Last Call, puts comments in their data system, then emails those comments to the authors and WG chairs, and then to the IESG 📧. The comments also get manually entered into the Datatracker for the public record. The problem is that it's hard to tell whether the IANA issues have actually been resolved 😭. So to make tracking easier, the Datatracker needs a display showing 5 new IANA substates, kind of like how RFC Editor State is already shown in the Datatracker ✨ (see the example later in this section of how IANA state information could show up for draft-example-00).

  1. IANA Review Needed

This substate lets the community, Secretariat, and IANA easily track which documents have or haven't been reviewed by IANA 👀. If the substate is not set to "IANA Not OK", "IANA OK -- Actions Needed", or "IANA OK -- No Actions Needed", it should be set to "IANA Review Needed" by default (this is the first substate for tracking IANA data). For documents that come from a non-IETF stream, the default is used.

  1. IANA OK -- Actions Needed

This substate covers documents that need IANA actions, where the IANA Considerations section describes those actions correctly 🔥.

  1. IANA OK -- No Actions Needed

This substate covers documents that need no IANA actions, where the IANA Considerations section says so correctly 🌸.

Note: The substate will be set to "IANA OK -- Action Needed" or "IANA OK -- No Actions Needed" (from "IANA Not OK") once any outstanding issues have been resolved. The comments section will be used to give details in the History log about whether there are no IANA actions, the text is OK, or the issues have been resolved.
  1. IANA Not OK

If IANA has issues with the text of a document's IANA Considerations section, the substate should be set to "IANA Not OK", and the comment field should be filled in with a description of the issues and questions 😤. On top of any questions IANA might have, IANA will also note in the comments field whether expert review is required, whether the document depends on another document (e.g., document B registers values in a registry created by document A, which hasn't been published yet), and whether a registry expert appointment is required.

  1. Version Changed -- Review Needed

This substate lets the community, Secretariat, and IANA easily track documents that were already reviewed and then changed 🔄. When a version of an Internet-Draft in Last Call has changed, IANA needs to review it again, to make sure either the IANA considerations haven't changed, or any changes that affect IANA actions are clear. This substate applies to I-Ds that are in any substate except "IANA Review Needed" and "Version Changed -- Review Needed".

When new versions come out, the Datatracker will automatically set the IANA substate to "Version Changed -- Review Needed" 🦋.

Information about the status of the IANA review (one of the 5 substates above) should be included as part of the evaluation message (sent to the IESG), so IANA can figure out whether, and what, further action is needed 💜.

All comments will be recorded in the History log. But to cut down on redundancy and manual effort, the Datatracker should be able to receive state information and related comments from the IANA tracking system 🧚. There should be a notification that comments have been entered in the IANA-maintained system, and getting those comments into the Datatracker and sending them out to the authors should be automated.

  • IESG Evaluation

Not every document gets an IETF Last Call, so this state is sometimes the first time IANA looks at a document 👀. For a document that wasn't IETF Last Called, IANA reviews it, enters comments in their own tracking system, emails the authors and other interested parties (e.g., WG chairs, ISE (Independent Submissions Editor)), and then enters those same comments into the Datatracker, where they get recorded in the History log. When a document was IETF Last Called, IANA checks for version changes and re-reviews documents to make sure any IANA issues that were found have been resolved 🫶.

Comments will keep being recorded in the History log. But to cut down on redundancy and manual effort, the Datatracker should let IANA enter substate information and related comments into the IANA tracking system, and sending those comments to the authors and entering them into the Datatracker should be automated ✨.

Ideally, the authors will have responded to and resolved any IANA issues before the document is slated for an IESG telechat 💖. However, if a document still has an "IANA Not OK", "Version Changed -- Review Needed", or "IANA Review Needed" substate and is slated for the IESG telechat, it should be called out in the Agenda Package. For example, it could look like this:

 o draft-example-00
   Title of Internet-Draft
   Note: John Doe (jdoe@example.com) is the document shepherd.
   Token: Jane Doe
   IANA: IANA Not OK

This makes sure that IANA and the Area Directors (ADs) know there are still IANA issues to fix before publication, or that initial or follow-up IANA review is needed and not yet done (when the substate is "IANA Review Needed" or "Version Changed -- Review Needed") 🚨.

  • Document Approved for Publication

Once a document is approved for publication, it enters the IANA queue and gets tracked using IANA-defined states 🍓. This state information isn't currently available through the Datatracker. So that the community can see the IANA processing states without getting redirected to the IANA queue, the Datatracker should be extended to include IANA state information as IANA defines it. For example, IANA state information could show up in the metadata portion of the document like this:

Document type:          Active Internet-Draft (FOO WG document)
Last updated:           2010-09-20
State:                  RFC Ed Queue
RFC Editor State:       EDIT IANA
IANA State:             In Progress
Intended status:        Proposed Standard

IANA state-change information will link to the IANA queue and will be captured as a line item in the History log. IANA will notify the Datatracker whenever changes are made in the IANA queue 🔔.

Once the IANA actions are completed, the Datatracker History log will be updated to include the actions IANA completed (i.e., the author-approved actions). This information will include the same information that is sent to the RFC Editor when IANA actions are completed ✅.

The IANA State field can be any of the states IANA defines. The list of IANA state names in use when this document was published is given in Appendix A. However, IANA states are defined by IANA and are subject to change 🌈. If there are any discrepancies between the state names listed in this document and those on the IANA queue page (http://www.iana.org/about/performance/ietf-draft-status/), the IANA queue is definitive. States may be added or removed by IANA, and IANA will work with the IETF Administrative Oversight Committee (IAOC) to update the Datatracker as needed 💅.

  • RFC Publication

References to the I-D get updated to point to the RFC once it's published, and minor updates may be made to match the published RFC 🦋. This data will be tracked in the Datatracker to show when the references in the IANA registries were updated to include the newly assigned RFC number ⭐.

2.2. Future IANA Information to Be Available via the Datatracker 🔮

The document "Definition of IETF Working Group Document States" [RFC6174] includes the following:

4.3.1.  Awaiting Expert Review/Resolution of Issues Raised

   This tag means that someone (e.g., an author or editor of the
   WG draft, or a WG Chair) has initiated an expert review of the
   document and the review has not yet been completed and/or the
   resolution of issues raised by the review has not yet been
   completed.  Examples of expert reviews include cross-area
   reviews, MIB Doctor reviews, security expert reviews, and IANA
   reviews.

   WG drafts tagged with this annotation should retain the tag
   until the review is complete and possibly until any issues
   raised in the review are addressed.

IANA is in the process of documenting how an expert review is conducted during the lifetime of an Internet-Draft 📝. Once that process is defined, the Datatracker should be updated to show whether a document requires "Expert Review" [RFC5226] (either for the entire document or a portion of it), whether the expert reviewer has issues with what they were asked to review, and, if applicable, whether the expert reviewer has approved or rejected the requested registration(s). A document may need expert reviews again before publication if the text relevant to the review has changed since the expert saw it 🔁. In cases where the document creates a new registry, an indicator of whether the IESG needs to appoint an expert would also be really useful 🙌.

2.3. Permissions to Change IANA State Information 🔐

IANA state changes should be automated, but IANA should also be able to log in to the Datatracker and update the system manually 🧑‍💻.

The IETF Secretariat should also be able to change the IANA state if necessary 🫡.

This feature is only expected to be used to correct issues. It is not meant to be part of regular operations 🙅‍♀️.

3. Integration of Data between the RFC Editor and Datatracker ✨

okay so for a long time the RFC Editor was basically a total black box 📦. You'd submit your doc, something happened in the middle, and then an RFC just popped out. The community was like "hi, can we see what's going on?" so state info got posted on the RFC Editor website. some of it is on the Datatracker now too, but for real transparency the Datatracker should also hold extra RFC Editor state and process info (like MISSREF) 🫶. this section lays out what needs to be added so we get one unified end-to-end tracking system 🔥.

3.1. RFC Editor Information to Be Added to the Datatracker

once a doc is approved for publication, it enters the RFC Editor queue and gets tracked with RFC-Editor-defined states 🧚. some of that state info is already visible, but it isn't stored in the History log (bestie, that's the gap 💀). the RFC-Editor-defined state info keeps showing up the way it does now. on top of that, every time a doc changes state, a line item gets entered into the History log. the RFC Editor shall continue to provide a queue file so data can be extracted, and there will also be a machine-readable notification sent to the Datatracker whenever state changes are made 💅.

RFC Editor state info should continue to appear in the metadata portion of the document on the Datatracker. for example, an entry might look like this (including the IANA State info):

      Document type:          Active Internet-Draft (TLS WG document)
      Last updated:           2010-09-20
      State:                  RFC Ed Queue
      RFC Editor State:       EDIT IANA
      IANA State:             In Progress
      Intended status:        Proposed Standard

the RFC Editor State field can be any of the states the RFC Editor defines. the list of RFC Editor state names in use when this document was published is in Appendix B, but the RFC Editor owns those states and they can change 🌸. if the state names in this document don't match what's on the RFC Editor queue page (http://www.rfc-editor.org/queue2.html), the RFC Editor queue is definitive, no debate 👑. states may be added or removed by the RFC Editor, and the RFC Editor will work with the IAOC to update the Datatracker as necessary.

although RFC Editor state info is already on the Datatracker, it should get some extra data so people can actually understand where their doc is at 🦋. specifically, the Datatracker should be updated to include the following:

  1. links to AUTH48 pages AUTH48 pages tell you which authors have approved the document for publication, whether AD approval is required, and sometimes a summary of issues that need to be resolved before the document can move forward.
  2. links to the cluster pages Clusters are defined as documents with normative reference dependencies, and documents that have been requested for simultaneous publication. (For more information, see http://www.rfc-editor.org/cluster_def.html.) The cluster pages give you a view of the entire set of state information for clustered documents 🍓. Note: The RFC Editor has been working with the cluster data to provide the community with accurate state information at the appropriate level of detail. The RFC Editor database may require significant updates before this data can be integrated with the Datatracker.
  3. RFC metadata upon publication The RFC Editor will notify the Datatracker when a new RFC has been published, and the Datatracker should be able to automatically update the relevant fields with data about the published RFC. in particular, the RFC number will be recorded on the Datatracker. but note that all fields are subject to change during editing and should be updated. for example, the document title and the list of authors are sometimes changed, and character counts and page counts are always changed 🙈.
  4. notation when documents are withdrawn from the RFC Editor queue If a document is to be removed from the RFC Editor / IANA queues, the responsible party (e.g., AD or Secretariat) should change the state of the document on the Datatracker to something other than "RFC Ed Queue". the Datatracker should provide a text box so the responsible party can record details about the state change. the state change and the related details will be recorded in the History log. the state change will trigger an email message to the RFC Editor and IANA as notification that the state of the document has been set to the newly assigned state, with the details from the text box. the RFC Editor and IANA will update their queues accordingly, and the document will disappear from their respective queues 🧹.

4. Other Updates to the Datatracker ✨

okay so the main goal here is getting IANA and RFC Editor process state onto the Datatracker display ✅, but the Datatracker could also hold extra data for IANA and the RFC Editor to get more automation going. less automation means fewer delays and fewer processing errors, and honestly that's a whole glow-up 💖. this section defines the requirements for Datatracker updates that cut out some of the admin tasks staff currently do by hand.

4.1. Datatracker to IANA

when a document is approved for publication, data will be provided in a machine-readable format. it will include (on top of the usual Document/Protocol Action emails) the data the RFC Editor asked for in Section 4.2 🎀.

4.2. Datatracker to RFC Editor

when a document is approved for publication, data will be provided in a machine-readable format. it will include the following (in addition to the usual Document/Protocol Action emails):

  • I-D String
  • Document Title
  • Author List
  • Author Email Addresses
  • Author Organizations (if available)
  • Expedited Goal Date (if applicable) Note: This field needs to be editable for post-approval changes.
  • Publication Status (as defined in [RFC2026])
  • Consensus (yes/no)
  • Source (Working Group or Research Group name, Individual, or alternate-stream name) Note: The RFC Editor database may require updates before Research Group data can be received from the Datatracker.
  • IESG Contact
  • Document Shepherd <email> Note: This is the individual currently listed in the "Personnel" section of a Document/Protocol Action.
  • IANA Actions Required

most of these are already stored on the Datatracker 🌈. the following fields need to be added:

  • Expedited Goal Date
  • Consensus (yes/no)
  • Document Shepherd <email>
  • IANA Actions Required

"Consensus" is used as in [RFC5741], and it determines the right Status of This Memo text to apply to IETF and IRTF documents 📜. the Consensus field should be set by the responsible individuals, and it should be listed in the Agenda Package provided before an IESG telechat. that way the Area Directors can quickly review the status of the documents under review and fix the field if Consensus wasn't received 🫶.

also, the Agenda Package provided before an IESG telechat should show the expiration date of the IETF Last Call. this will help the ADs and the Secretariat keep track of the IETF Last Call timeline ⏰.

when a document has been added to the RFC Editor queue (i.e., it shows an RFC Editor state on the Datatracker), an automated note should be sent to the Secretariat to acknowledge the announcement was received 💌.

4.2.1. Notifications

the Datatracker should notify the RFC Editor and the Sponsoring AD when a version of an I-D has been made available after the document has been approved for publication 🔔.

the Datatracker should also notify the RFC Editor and IANA when the state of an I-D has been moved to something other than "RFC Ed Queue" or "RFC Published". that's when it should be removed from the RFC Editor and IANA processing queues. see item 4) in Section 3.1 for more details.

4.2.2. Datatracker Extensions for Alternate Streams

once the Datatracker has been updated for the alternate streams [RFC6322], the following should be automated 🤖:

  • The Datatracker should not expire any I-Ds that are under review for publication.
  • The Datatracker should automatically notify the approving body when an I-D that is under review has been updated (i.e., a new version has been made available).
  • The Datatracker should be updated so that the Agenda package lists I-Ds according to the stream that requested publication. this should give extra clarity during IESG Reviews, since there will be a clear indication of which stream a document comes from 🧚‍♀️.

4.2.2.1. Publication Requests

RFC 6322 [RFC6322] lists the requirements for extending the Datatracker to account for alternate-stream states and annotations. the document introduces the "Sent to the RFC Editor" state, which means the document is complete and has been sent to the RFC Editor for publication 💜.

the Datatracker will give the alternate streams a way to generate a uniform publication request. using the Datatracker, the stream managers should be able to generate a publication request with the relevant information for any approved I-D.

the Datatracker will also provide the data (the same data provided for any IETF publication request, see Section 4.2) in a machine-readable format. this data will be available to the IANA and RFC Editor, so data entry into their systems can be automated 🦾.

this update will let the IANA and RFC Editor handle documents in a similar way, no matter which stream the document comes from. main character energy 👑✨

4.3. Reporting Requirements ✨

okay bestie, the Datatracker needs a "Show Discrepancies" feature 🔍💅. It should show every record that fits certain criteria, meaning anything that looks like a mismatch. On top of showing that on screen, it should also email defined interested parties at regular intervals (e.g., weekly) 📬. This feature is only for IANA, the RFC Editor, and the Secretariat, so their queues stay in sync 🫶. It's going to be super helpful as the Datatracker grows, now and later, because everyone needs to be getting the right messages and data 💖.

We start with an initial set of discrepancies, and more can be added over time 🌸. The first batch could look like this:

  • Show drafts that have passed through the state "Approved Announcement sent" but do not have an RFC Editor state. 👀
  • Show drafts that have IANA state "In Progress", but RFC Editor State is not equal to "IANA" or does not contain "*A" (see Appendix B). 🤔
  • Show drafts that have IANA state "Waiting on RFC Editor" or "RFC-Ed-Ack", but RFC Editor State is "IANA" or contains "*A" (see Appendix B). 😭
  • Show drafts that have a state of something other than "RFC Ed Queue" or "RFC Published" that are listed in the RFC Editor or IANA queues. 💀

5. Security Considerations

Okay, the big reveal 🥁: this document does not propose any new Internet mechanisms, and it has no security implications for the Internet 🦋✨. No drama, no risks, just vibes 💅.

Appendix A. Current IANA States and Definitions

These are the IANA states that are currently defined 🎀:

  • No value (blank): a new document has been received by IANA, but no actions have been taken yet 🌱
  • In Progress: IANA is currently processing the actions for this document ⚙️
  • Waiting on Authors: IANA is waiting on the document's authors to respond 🙋‍♀️
  • Waiting on ADs: IANA is waiting on the IETF Area Directors to respond 🕰️
  • Waiting on WGC: IANA is waiting on the IETF Working Group Chairs to respond 🕰️
  • Waiting on RFC Editor: IANA has notified the RFC Editor that the actions have been completed 📨
  • RFC-Ed-Ack: request completed, and the RFC Editor has acknowledged receiving IANA's message that the actions are done 🎉
  • On Hold: IANA has paused work on the document ⏸️
  • No IC: request completed, and there were no IANA actions for this document 🍃

IANA states are defined by IANA and can change, so no cap, the IANA queue wins 👑. If the state names in this document don't match what's on the IANA queue page at http://www.iana.org/about/performance/ietf-draft-status/, go with the IANA queue. Periodt 💅.

Appendix B. Current RFC Editor States and Definitions

These are the RFC Editor Queue states that are currently defined 📚:

  • AUTH = Awaiting Author Action ✍️
  • AUTH48 = Awaiting final author approval 💌
  • EDIT = Approved by the stream manager (e.g., IESG, IAB, IRSG, ISE), awaiting processing and publishing 🚀
  • IANA = RFC-Editor/IANA Registration Coordination 🤝
  • IESG = Holding for IESG Action 🛑
  • ISR = Independent Submission Review by the ISE 🔎
  • ISR-AUTH = Independent Submission awaiting author update, or in discussion between author and ISE 💬
  • REF = Holding for normative reference (followed by I-D string of referenced document) 📎
  • RFC-EDITOR = Awaiting final rfc-editor review before AUTH48 🧐
  • TO = Time-out period during which the IESG reviews document for conflict/concurrence with other IETF working group work (followed by date) 🗓️
  • MISSREF = Awaiting missing normative reference 🫠

RFC Editor states are defined by the RFC Editor and can change too 🌈. If the state names here don't match the RFC Editor queue page at http://www.rfc-editor.org/queue2.html, that queue page is the final word 👑.

There are also a couple of state annotations that show up in RFC Editor state-change emails 📧. They don't change the Datatracker in any way, but they're listed here so you have the full picture 🧚:

  • *A = indicates that IANA actions are required ⭐
  • *R = indicates potential REFerence holds 🧷

Normative References

[IDTRACKER] "The IETF Datatracker tool", Web Application:
            https://datatracker.ietf.org/, August 26, 2011.

[RFC2026]   Bradner, S., "The Internet Standards Process --
            Revision 3", BCP 9, RFC 2026, October 1996.

[RFC4844]   Daigle, L., Ed., and Internet Architecture Board, "The
            RFC Series and RFC Editor", RFC 4844, July 2007.

[RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an
            IANA Considerations Section in RFCs", BCP 26, RFC 5226,
            May 2008.

[RFC5741]   Daigle, L., Ed., Kolkman, O., Ed., and IAB, "RFC Streams,
            Headers, and Boilerplates", RFC 5741, December 2009.

[RFC6174]   Juskevicius, E., "Definition of IETF Working Group
            Document States", RFC 6174, March 2011.

[RFC6322]   Hoffman, P., "Datatracker States and Annotations for the
            IAB, IRTF, and Independent Submission Streams", RFC 6322,
            July 2011.

Acknowledgments

The authors would like to thank these amazing people for their input 🫶💜:

Amanda Baber
Glen Barney
Adrian Farrel
Alice Hagens
Paul Hoffman
Russ Housley
Ed Juskevicius
Henrik Levkowetz
Cindy Morgan
Ray Pelletier
Peter Saint-Andre
Robert Sparks
Amy Vezza

Authors' Addresses

Sandy Ginoza
Association Management Solutions
48377 Fremont Blvd., Suite 117
Fremont, CA 94538
United States

Phone: +1 (510) 492-4000
EMail: sginoza@amsl.com
URI: http://www.amsl.com/


Michelle Cotton
Internet Corporation for Assigned Names and Numbers
4676 Admiralty Way, Suite 330
Marina del Rey, CA 90292
United States

Phone: +310-823-9358
EMail: michelle.cotton@icann.org
URI:   http://www.iana.org/


Alexa Morris
Association Management Solutions
48377 Fremont Blvd., Suite 117
Fremont, CA 94538
United States

Phone: +1 (510) 492-4000
EMail: amorris@amsl.com
URI: http://www.amsl.com/
📦 where this page comes from