RFC 4693

IETF Operational Notes

📅 published October 2006, from ietf

RFC 4693 💖 IETF Operational Notes 🎀

Bestie, look at this header first. 🧚 It's an Experimental doc from October 2006, written by H. Alvestrand at Google for the Network Working Group. It's listed as RFC 4693. The header doesn't list anything it obsoletes or updates, so it's not replacing or changing any other RFC. 💅

Status of this Memo ✨

This memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind 🙈. The authors want feedback and ideas for making it better, and distribution of this memo is unlimited 🌈.

Copyright (C) The Internet Society (2006).

Abstract 🦋

okay so this doc introduces a brand new document series for IETF operations docs 🎀. These are supposed to be more ephemeral than RFCs (less formal, less forever), but more referenceable than Internet-Drafts, with clearer handling rules than a random Web page 💀. The proposal is to run this series as an RFC 3933 process experiment 🔥.

Table of Contents 📑

   1. Introduction ....................................................2
   2. A Description of the ION Mechanism ..............................2
      2.1. Properties of an ION .......................................2
      2.2. ION Approval ...............................................3
      2.3. Draft IONs .................................................3
      2.4. The ION Store ..............................................4
   3. Proposed Initial IONs ...........................................4
   4. Success Criteria and Sunset Period ..............................5
   5. Background and Motivation .......................................6
   6. IANA Considerations .............................................7
   7. Security Considerations .........................................8
   8. Acknowledgements ................................................8
   9. References ......................................................8
      9.1. Normative References .......................................8
      9.2. Informative References .....................................8

1. Introduction 🌸

This doc introduces a new series called the IETF Operational Notes, or IONs 🍓.

The whole point is to capture the procedures the IETF follows that just don't fit the RFC process 🫶. RFCs are the wrong vehicle for those, so IONs fill the gap ✨.

The IONs series does not change the IETF process rules already written down in the currently valid BCP documents 👑. Hands off the BCPs, bestie 💅.

This series is a process experiment under RFC 3933 [RFC3933] 🧪.

2. A Description of the ION Mechanism 🎀

2.1. Properties of an ION 💖

An ION is a document with a set of attributes, which the spec calls "front page matter" 📄. The spec doesn't put any limits on what else an ION can contain, so you do you 🌈.

Every ION has these attributes:

  • A name, which can be used as the filename of the document 🗂️
  • A title 🏷️
  • A date of approval 📅
  • An identification of the body that approved this version ✍️

The format of the document isn't restricted by this doc 🤷‍♀️. It's suggested that there be an ION that describes the expectations for ION formats 📝, which is very on brand for this whole series 😭.

An ION is a versioned document 🦋. When a new ION gets issued with the same name, it obsoletes the previous version 🫠. If someone wants to retire an ION, they issue an ION saying "This document name is now obsolete" 🪦.

The ION name plus the approval date makes a stable identifier for one particular version of an ION 🔒. Once it's published, it shall never be changed, although it may be withdrawn (see below) 🙈.

The properties list doesn't include a "category" 🚫. The set of documents that might be IONs is extremely wide, and nobody knows yet which categories would make sense. The question of categories might get revisited at the end of the experiment period 👀.

Procedurally, an ION has the formal authority of a statement from its approving body 👑. That means an ION cannot change the IETF procedures documented in the BCP series, since the BCP series represents a determination of IETF consensus 💅.

2.2. ION Approval 🫶

Every ION is always approved by some body 🪩. This document gives the IESG authority over the practical management of the series and over defining the detailed processes and rules that go with it 👑.

The IESG, the IAB, and the IAOC are all given the right to approve IONs by this document ✨. The IESG, IAB, or IAOC may decide that other groups or roles should get that right too 🌸.

The ION-approving groups are expected to issue IONs about their own areas of responsibility 🎀. Where it isn't obvious who's responsible for an ION, they should use common sense 🧠.

An updated ION will normally be approved by the same body that approved the previous version, or by another body with the approval of the previously-approving body 🔁. If there's a conflict, or the previous body no longer exists, the IESG decides who gets to approve the updated ION 🧑‍⚖️.

A decision by any body other than the IESG to approve an ION can be appealed to the IESG, and the IESG can nullify that approval 🚨. A decision of the IESG can be appealed using the common IETF appeals procedure, except that an IESG decision to nullify an IAB approval of an ION can't be appealed to the IAB 🙅‍♀️. Bestie, that's a whole plot twist 😭.

If the IESG ever stops existing, its successors or assignees take over the tasks this document gave the IESG 🫡.

2.3. Draft IONs 🍓

Nothing says an ION has to be published as a draft first 🤍. It'll be desirable in lots of cases though, so this doc describes the properties and procedures for draft IONs 🦋.

Draft IONs don't get an approval date or an identification of the approving body. Instead, they have information about:

  • The word "DRAFT", prominently displayed 🚧
  • The publication date and time 🕰️
  • The approval date of the document it is intended to update (if any) 🔄
  • The body that is intended to approve this version 👑
  • The appropriate forum for discussion of this draft (if any) 💬

2.4. The ION Store 🗄️

All approved IONs get archived, in all their versions, and made publicly available from resources run by the IETF secretariat 🌈. The store should be reachable by common methods like HTTP and FTP 🌐. It should offer easy access to the "current" version of every ION, and bulk download of all IONs, all versions 📦.

This doc doesn't constrain the form of the ION Store, but it does mandate that a public one exists 🫶.

Public draft IONs are published separately from the approved IONs 🧾. Old versions may be published in the draft store, and they must be kept in a version management system for the duration of the experiment 🗃️. Experience will show what the best draft retention policy is if the series ever becomes permanent 🔮.

5. Background and Motivation ✨

okay so the IETF is an open org, which means there are ALWAYS newcomers showing up wanting to learn how things get done 🌸 so the org has to write down its processes and procedures in a way people can actually access 📖

it's also a big org, so when procedures change, a bunch of people want to know about it, figure out what changed, and maybe protest or appeal it if they disagree 😤 very much a group-chat-drama energy, ngl 💅

at the present time (spring 2006), there are three kinds of documents the IETF uses to document how it operates 🎀

  • BCP and Informational RFCs 📜 these need an IETF consensus call for BCP, approval by the IESG, and usually a ton of debate and effort to change. they also tie up editing resources in the final edit stage, and in practice they're limited to ASCII. the BCP number gives you a stable reference for new versions of a document, but an updated Info RFC gets a completely different identifier from the RFC it updates. "updates/obsoletes" links can share some of that info, but they can also be super confusing to follow 🙈
  • Web pages 🌐 these can be changed without notice, they give you very little ability to track changes, and they have no formal standing. it's giving "who even has the right to update this??" energy, and nobody's sure what the process for updating them is 💀 looking at a Web page, it's hard to tell whether it's a current procedure, a procedure that was introduced and then abandoned, or a draft of a future one 😭 for some procedures, the informal docs in the "IESG Guide" wiki have partly cleared things up, but that wiki has no official status 🫠
  • "floating" Internet-Drafts 🦋 these get updated often, in a trackable way, but they have no approval mechanism, they're limited (in practice) to ASCII, and using them as semi-permanent docs clutters up their real job as 6-month temporary working documents 🧹

this note introduces a brand new series that fulfils the requirements for "something in between" 💜

  • unlike RFCs, they can be produced without a post-editing stage, and they can be in any format the controllers of the series choose (so web pages with hyperlinks are allowed, which is a big win for newcomers 🧚)
  • also unlike RFCs, they can be produced by any body the IESG gives the right to use the mechanism. this means certain procedures can get updated without waiting on the IESG approval cycle 🏃‍♀️
  • unlike Internet-Drafts, they have an explicit approval step. this lets a reader easily tell the difference between an idea and an operational procedure ✨
  • unlike Web pages, there's an explicit mechanism for finding "all current versions", plus a mechanism for tracking the history of a document 📚

the "author" attribute has quite deliberately been left off the required property list 🙈 yes there are lots of cases where naming an author is a Good Thing, but the responsibility for an approved ION rests with the approving body, so that's where accountability lives 👑

Note: This proposal is NOT intended to affect the standards track in any way. a side effect may be fewer "process BCPs" getting emitted, but that has no direct bearing on the IETF's technical specifications, so it's not within the scope of the NEWTRK working group 🫶

6. IANA Considerations 🌷

IONs will not include protocol specifications, so IONs will make no requests for IANA actions. IANA will not need to review all IONs 💅

this document makes no requests of IANA either ✨

7. Security Considerations 🔐

IONs will not include protocol specifications, so they shouldn't have much need to talk about security the way RFCs do 🙈

8. Acknowledgements 🫶

many people have contributed over the years to the ideas I've tried to express here 💖

I'm especially indebted to John Klensin for his work on finding a balance between formalism and flexibility in the IETF process 🌈 and for his earlier attempts at creating a document series like this as an adjunct to the "ISD" effort, plus his many valuable comments on this document 👑

also, Dave Crocker, Spencer Dawkins, Jeff Hutzelman, Sam Hartman, and David Black (gen-ART reviewer) gave valuable comments at Last Call time 🎀

9. References 📚

9.1. Normative References 💜

[RFC3933]  Klensin, J. and S. Dawkins, "A Model for IETF Process
           Experiments", BCP 93, RFC 3933, November 2004.

9.2. Informative References 🧚

[RFC3005]  Harris, S., "IETF Discussion List Charter", BCP 45,
           RFC 3005, November 2000.

[RFC3683]  Rose, M., "A Practice for Revoking Posting Rights to IETF
           mailing lists", BCP 83, RFC 3683, February 2004.

[RFC3934]  Wasserman, M., "Updates to RFC 2418 Regarding the
           Management of IETF Mailing Lists", BCP 94, RFC 3934,
           October 2004.

[RFC3978]  Bradner, S., "IETF Rights in Contributions", BCP 78,
           RFC 3978, March 2005.

[RFC3979]  Bradner, S., "Intellectual Property Rights in IETF
           Technology", BCP 79, RFC 3979, March 2005.

Author's Address 🦋

Harald Tveit Alvestrand
Google
Beddingen 10
N-7014 Trondheim
Norway

EMail: harald@alvestrand.no

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔥

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on the extent to which any license under such rights might or might not be available. it also doesn't represent that it has made any independent effort to identify any such rights. info on the procedures for rights in RFC documents can be found in BCP 78 and BCP 79 📜

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr 🌐

the IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. please address that info to the IETF at ietf-ipr@ietf.org 💌

Acknowledgement 💖

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). 🫶

📦 where this page comes from