RFC 2360

Guide for Internet Standards Writers

📅 published June 1998, from ietf

RFC 2360: Guide for Internet Standards Writers 🎀

Okay bestie, here's the tea on this one. It's RFC 2360, called Guide for Internet Standards Writers, from the Network Working Group. G. Scott is the Editor, writing from the Defense Information Systems Agency. It came out in June 1998 and is filed as a Best Current Practice (that's BCP 22 💅). It doesn't list any RFCs that it obsoletes or updates, so it's sitting pretty on its own ✨

Status of this Memo

This document is an Internet Best Current Practice for the Internet Community 🌸 It's asking people for discussion and ideas on how to make it better, and it can be shared as much as you want, no limits 🦋

Copyright Notice

Abstract

Okay so this doc is basically a guide for people who write Internet standards 📝 It breaks down what makes a standard coherent, unambiguous, and easy to interpret, which is literally the whole goal 🙌 It also calls out the habits that have caused specs to be unclear in the past, leading to implementations that don't play nicely together 😭 You'll use these guidelines alongside RFC 2223, "Instructions to RFC Authors" 🎀

1     Introduction   . . . . . . . . . . . . . . . . . . . . . . . 2
2     General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1   Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2   Protocol Description   . . . . . . . . . . . . . . . . . . . 4
2.3   Target Audience  . . . . . . . . . . . . . . . . . . . . . . 5
2.4   Level of Detail  . . . . . . . . . . . . . . . . . . . . . . 5
2.5   Change Logs  . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6   Protocol Versions  . . . . . . . . . . . . . . . . . . . . . 6
2.7   Decision History   . . . . . . . . . . . . . . . . . . . . . 6
2.8   Response to Out of Specification Behavior  . . . . . . . . . 6
2.9   The Liberal/Conservative Rule  . . . . . . . . . . . . . . . 7
2.10  Handling of Protocol Options   . . . . . . . . . . . . . . . 8
2.11  Indicating Requirement Levels  . . . . . . . . . . . . . . . 9
2.12  Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13  IANA Considerations  . . . . . . . . . . . . . . . . . . .  10
2.14  Network Management Considerations  . . . . . . . . . . . .  10
2.15  Scalability Considerations . . . . . . . . . . . . . . . .  10
2.16  Network Stability  . . . . . . . . . . . . . . . . . . . .  11
2.17  Internationalization . . . . . . . . . . . . . . . . . . .  11
2.18  Glossary   . . . . . . . . . . . . . . . . . . . . . . . .  11
3     Specific Guidelines  . . . . . . . . . . . . . . . . . . .  12
3.1   Packet Diagrams  . . . . . . . . . . . . . . . . . . . . .  12
3.2   Summary Tables   . . . . . . . . . . . . . . . . . . . . .  13
3.3   State Machine Descriptions . . . . . . . . . . . . . . . .  13
4     Document Checklist . . . . . . . . . . . . . . . . . . . .  15
5     Security Considerations  . . . . . . . . . . . . . . . . .  16
6     References . . . . . . . . . . . . . . . . . . . . . . . .  16
7     Acknowledgments  . . . . . . . . . . . . . . . . . . . . .  18
8     Editor's Address . . . . . . . . . . . . . . . . . . . . .  18
9     Appendix . . . . . . . . . . . . . . . . . . . . . . . . .  19
10    Full Copyright Statement . . . . . . . . . . . . . . . . .  20

1. Introduction 🍓

This doc is the guide for Internet standard writers, and it's all about how to write a standards-track document with clarity, precision, and completeness ✨ These tips come from both the wins and the flops in past IETF specs 😅 You use them together with RFC 2223, "Instructions to RFC Authors", or whatever update that one gets. Heads up that some of these guidelines might not fit every situation 🙈

The big goal is to boost the odds that multiple implementations of a protocol will interoperate 🫶 Following these won't guarantee interop, ngl, but unclear specs are a known blocker, so fixing that is huge 💅

Good specs help a lot of people. Implementers have a better shot at matching the spec 🔥 Protocol testers can turn the spec into clear, testable statements 🧪 And purchasers and users get a much better idea of what the protocol can actually do 💖

If you want more on how protocols get standardized, check out BCP 9/RFC 2026, "The Internet Standards Process -- Revision 3" 📚 For some design thinking, RFC 1958, "Architectural Principles of the Internet", has you covered 🌈

2. General Guidelines 🌸

Multiple readers and implementers need to walk away with the same understanding of a document, or everything gets messy fast 😭 So information should be orderly and detailed. The guidelines in this section are meant to help you produce exactly that. The IESG may require that all or some of these sections show up in a standards-track document 👑

2.1. Discussion of Security 🔐

Okay this part is so important. If the Internet is going to reach its full potential in business, government, and personal life, it has to promise users that their information stays free from tampering or compromise 💜 Strong security sections in standards-track docs help build that confidence. Above all, new protocols and practices must not make overall Internet security worse 😤

Some people out there are motivated and skilled enough to exploit circumstances, events, or weaknesses in the system to cause harm 💀 Deliberate or accidental user behavior can also open the door to attacks. The damage could be anything from disrupting or denying network service all the way to wrecking user systems. Information disclosure is a problem too, since it can hand attackers a way into another system or reveal patterns that could be used to hurt a person, organization, or network. This is an especially big worry for standards that define part of the Management Information Base (MIB) 👀

Standards authors have to accept that their protocol will be attacked, period 🫠 They are responsible for figuring out which attacks are possible and describing them in the document. The only exception is if they can convincingly argue that an attack isn't realistic in a specific environment, and then they must restrict the protocol to that environment.

Once the document has thoroughly identified the security risks, the authors must come up with and detail a defense against those attacks 🛡️ They must discuss the countermeasures used, or the risk users accept by using the protocol. Countermeasures can come from a protocol mechanism or from relying on external mechanisms. Authors should know about existing security mechanisms and reuse them when it's practical. When a cryptographic algorithm is used, the protocol should be written so that it can be swapped for a different algorithm later ✨ Finally, authors should share implementation hints or guidelines, like how to handle untrustworthy data or peer systems 🙌

Security measures change things in the environment where they're used 🎀 Users might get more constrained in what they can do on the Internet, or service might slow down. The effects that security measures have on the protocol's use and performance should be discussed.

You can put the security discussion in the Security Considerations section, or spread it throughout the document wherever it's relevant to a specific part of the spec. The second approach is great because it makes security a built-in part of the protocol's development, not an afterthought 🧚 If security shows up throughout the document, the Security Considerations section still must summarize it and point back to the right sections. That way, both implementers and users really notice the protocol's security measures 💖

Inside the Security Considerations section, it can also be worth talking about the path not taken 🛤️ There may be several security mechanisms that didn't get picked, for reasons like cost, difficulty of implementation, or not working well in a given network environment. By listing what they didn't use and why, editors show that the working group really thought about security 🧠 This also gives users the info they need to decide whether one of the skipped mechanisms might suit their own needs better.

A document with more security guidance is in the works 👀 Authors should grab a copy of the finished RFC to help them write the security part of their standard.

And honestly? It's no longer acceptable for a Security Considerations section to just say that security wasn't considered when the standard was written 🙅‍♀️ Not the vibe at all.

Some good examples of Security Considerations sections are STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939 📖 For more on this topic, RFC 2316, "Report of the IAB Security Architecture Workshop", has extra info 🔥

2.2. Protocol Description 📘

Standards-track docs must include a description of the protocol 💅 That description must cover the protocol's purpose, its intended functions, the services it provides, and the arena, circumstances, or any special considerations for how it gets used.

The authors know a LOT about why the protocol exists 🧠 But the reader is more likely to have general networking knowledge than expertise in this specific protocol. Explaining its purpose and use gives the reader a reference point and shows where it fits into the Internet 🗺️ STD 54/RFC 2328 was recommended to the STDGUIDE working group as a good example of this in its "Protocol Overview" section 👑

The protocol's general description must also explain how the different parties to the protocol relate to each other 🤝 One way to do that is by showing typical packet sequences.

This goes for the algorithms a protocol uses too 🧮 You need a detailed description of the algorithms, or a citation to readily available references that describe them. Non-negotiable.

2.3. Target Audience 🎯

RFCs have been written for all kinds of purposes, from super technical to administrative 📋 The ones written as standards should clearly say who they're for, like designers, implementers, testers, help desk staff, educators, end users, or anyone else 💜 If the document is talking to more than one audience, each audience's section needs to be identified. The whole point is to help readers find and focus on what they came for, and to skip past anything that might confuse them, distract them, or be extra 🌈

2.4. Level of Detail

okay so the author has to think about how much detail actually helps the reader get the protocol's intent 🧠✨ concise text is lowkey the move because it's easier to read, there's less chance of two parts of the spec fighting each other 🥊, the reader can spot the required mechanisms super fast 👀, and it's easier to figure out what an implementation needs to do 💅

the catch? a reader might not fully get the why behind the protocol, so they make assumptions and end up with implementation errors 😭

longer descriptions can be needed to explain purpose, background, rationale, implementation experience, or to give tutorial info 🎀 that helps the reader really understand the protocol. BUT long text has its own problems 💀 it can be hard to find the actual protocol requirements, the same mechanism might get described in multiple places (which leads to misreading or conflict), and it's just harder to get through. also, english isn't the first language for a lot of people reading IETF standards around the world 🌍 so that matters too!!

one approach is splitting the standard into sections: one that describes the protocol concisely, and another section for the explanatory stuff 🧚 the STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 are examples of this method 🫶

2.5. Change Logs

as a document moves along the standards track, from Proposed to Draft or Draft to Full, or cycles in level, it's going to change because people understand the protocol better or have more implementation experience 🦋 so to help implementers keep track of what's changed, a log showing what has changed from the previous version of the specification is required (see Appendix) 📝

2.6. Protocol Versions

super common situation: the standard is specifying a new version of an existing protocol 🌈 when that happens, the authors should spell out the differences between the old version and the new one. this should include the rationale for the changes, like implementation experience, changes in technology, responding to user demand, etc. 💖

2.7. Decision History

reaching consensus in standards development takes some seriously tough choices 😤 those choices get made through working group discussions or from implementation experience. if the author includes the basis for a contentious decision, nobody has to keep re-arguing it later once the original people have moved on 🙈 and honestly, knowing the "why" is just as useful to an implementer as knowing the "how" ✨ for example, the option that wasn't picked might have been simpler to implement, so including the reasons can stop future implementers from taking nonstandard shortcuts 💅

2.8. Response to Out of Specification Behavior

a detailed description of what to do when something acts differently from the spec, or goes beyond it, is really useful 🔥 this is an area where implementers often disagree about the right response 👀 so if the standard author specifies a common response, different implementations are less likely to end up in conflict 🤝

the standard should describe responses to behavior that is explicitly forbidden or outside the boundaries the specification defines 🚫 there are two possible approaches for these cases: discarding, or invoking error-handling mechanisms. if discarding is the choice, detailing the disposition may be necessary. for instance: treat dropped frames as if they were never received, or reset an existing connection or adjacency state 🧊

the specification should also describe actions taken when a critical resource or a performance-scaling limit is exceeded 😱 this is necessary wherever there's a risk of network degradation or operational failure. in those cases, consistent behavior between implementations is necessary 💯

2.9. The Liberal/Conservative Rule

this rule was first stated in STD 5/RFC 791, and it's known for helping implementation robustness and interoperability 🎀 it goes like this:

"Be liberal in what you accept, and conservative in what you send".

or, in other words, establish restrictions on what a protocol transmits, but be able to deal with every conceivable error that's received 🫠 ngl, caution is urged when using this approach in standards track protocols 🚨 it has, in the past, led to vendor fights when interoperability fails. the sender accuses the receiver of not being liberal enough, and the receiver accuses the sender of not being conservative enough 😭 so the author is obligated to provide extensive detail on send and receive behavior 📖

to avoid confusion between the two, it's recommended that standard authors specify send and receive behavior separately 🧁 the description of reception is going to need the most detail 👑 because implementations are expected to keep operating no matter what error they receive. so the actions that achieve that result need to be laid out in the protocol specification 🛠️ standard authors should care about achieving a level of cooperation that limits network disruption, not just how to survive on the network 🌸 the appearance of undefined information or conditions must not cause a network or host failure ⚠️ this requires specifying how to attempt acceptance of most of the packets. there are two approaches available: either use as much of the packet's content as possible, or invoke error procedures. the author should specify a dividing line for when to take which approach 🍓

a case worth thinking about is a routing protocol, where accepting flawed information can cause network failure 💀 for protocols like this, the specification should identify packets that could have different interpretations, and mandate that they be rejected completely, or specify the nature of the attempt to recover some information from them 🔍 for example: routing updates that contain more data than the tuple count shows. the protocol authors should consider whether some trailing data can be accepted as additional routes, or whether to reject the entire packet as suspect because it's non-conformant 🙅‍♀️

2.10. Handling of Protocol Options

specifications with lots of optional features make implementation more complex, and raise the chance of non-interoperable implementations 😵 the danger is that different implementations may pick some combination of options that can't interoperate with each other 🥲

as the document moves along the standards track, implementation experience shall determine the need for each option 🔬 implementation shall show whether the option should be a mandatory part of the protocol or remain an option. if an option isn't implemented as the document advances, it must be removed from the protocol before it reaches draft standard status 🗑️

so, options shall only be present in a protocol to address a real requirement ✨ for example, options can support future extensibility of the protocol, a particular market (e.g., the financial industry), or a specific network environment (e.g., a network constrained by limited bandwidth) 🧚 they shall not be included as a means to "buy-off" a minority opinion 🙅 and omitting the optional item shall have no interoperability consequences for the implementation that does so 🫶

one possible approach is to document protocol options in a separate specification 📚 this keeps the main protocol specification clean, and makes it clear that the options aren't required to implement the protocol. whether they appear within the specification or in a separate document, the text shall discuss the full implications of either using the option or not, and the case for choosing either course 💜 as part of this, the author needs to consider and describe how the options are used alongside other protocols. the text must also specify the default conditions of all options. for security checking options, the default condition is on, or enabled 🔒

there are occasions when mutually exclusive options appear within the protocol 🙃 that means implementing one optional feature rules out implementing the other. for clarity, the author needs to state when to implement one or the other, what the effect of choosing one over the other is, and what problems the implementer or user may face ⚡ the choice of one or the other options shall have no interoperability consequences between multiple implementations 💖

2.11. Indicating Requirement Levels

the BCP 14/RFC 2119, "Key words for use in RFCs to Indicate Requirement Level", defines several words that are necessary for writing a standards track document 📜 editors of standards track documents must not deviate from those definitions, because they're meant to identify interoperability requirements or limit potentially harmful behavior 🚧 the capitalization of these words is the accepted norm, and it can help spot an unintentional or unreasonable requirement 👀 these words have been used in several RFCs, with the first instances being STD 3/RFC 1122/RFC 1123 🌷

2.12. Notational Conventions

formal syntax notations can be used to define complicated protocol concepts or data types, and to specify values of those data types 🧩 this lets the protocol be written without worrying about how the implementation is built, or how the data type is represented during transfer 🫧 the spec gets simplified because it can be presented as "axioms" that will be proven by implementation 🧪

the formal specification of the syntax used should be referenced in the text of the standard. any extensions, subsets, alterations, or exceptions to that formal syntax should be defined within the standard 📎

STD 11/RFC 822 is an example of this 💌 in RFC 822 (Section 2 and Appendix D), the Backus-Naur Form (BNF) meta-language was extended so its representation was smaller and easier to understand 🌟 another example is STD 16/RFC 1155 (Section 3.2), where a subset of the Abstract Syntax Notation One (ASN.1) is defined 🎀

the author of a standards track protocol needs to think about a few things before using a formal syntax notation 🤔 is the formal specification language being used parseable by an existing machine? if no parser exists, is there enough information in the specification to permit building a parser? if not, the reader likely won't have enough information to decide what the notation means 😬 also, the author should remember that machine-parseable syntax is often unreadable by humans, and can make the specification excessively long 📏 so syntax notations cannot take the place of a clearly written protocol description 💅✨

2.13. IANA Considerations ✨

okay so bestie, the whole Internet runs on everyone agreeing on the same little numbers for parameter fields 🔢. Standards track protocols get used by tons of people, so those values have to be unique. Here's the tea: an IETF working group doesn't have the authority to assign those values for the protocol it developed 🙅‍♀️. That job belongs to the Internet Assigned Numbers Authority (IANA), the central authority for assigning unique parameter values for Internet protocols 👑. So if you're writing a developing protocol, you need to coordinate with IANA on the rules and procedures for managing the number space, and that coordination needs to be finished before you submit the Internet Draft to the standards track 💅.

There's a document in preparation that digs into identifier assignment policy and gives specific text to task IANA with running it 📝. Standards authors should grab a copy once it's finalized as an RFC 🎀.

If you want more on parameter assignment and what's currently assigned, check out STD 2, RFC 1700, "Assigned Numbers" (http://www.iana.org) 🦋.

2.14. Network Management Considerations 🛠️

When it's relevant, every standard needs to discuss how to manage the protocol being specified 🧑‍💻. That management process should be compatible with the current IETF Standard management protocol. On top of that, a MIB must be defined within the standard or in a companion document 📚. The MIB must be compatible with the current Structure of Management Information (SMI) and parseable using a tool such as SMICng 🧩. If management or a MIB isn't necessary, this section of the standard should explain why it's not relevant to the protocol 🙈.

2.15. Scalability Considerations 📈

The standard should set limits on how big the use can get, e.g., tens of millions of sessions, gigabits per second, etc., and set limits on the resources used, e.g., round trip time, computing resources, etc. 🚀 This matters because it shows whether the network can handle the number of users and how complicated their relationships are 🌐. The STD 53/RFC 1939 has an example of a section like this 💜. If it doesn't apply to the protocol, the standard should include an explanation of why not 🙃.

2.16. Network Stability 🌊

A standard should talk about how network topology relates to convergence behavior 🗺️. Part of that is identifying any topology that would be troublesome for the protocol. Also, the specification should address any possible destabilizing events, and the means by which the protocol resists them or recovers from them 🛡️. The goal is making sure the network stabilizes in a timely fashion after a change, and that a combo of errors or events won't plunge it into chaos 😭. STD 34/RFC 1058 is a good example, since its sections cover how that protocol handles the effects of changing topology 🦕.

The obvious case is a routing protocol. But an application protocol can also have dynamic behavior that affects the network 📡. Like, a messaging protocol could suddenly dump a huge number of messages onto the network 💬. So editors of an application protocol will have to consider possible impacts to network stability and convergence behavior 🫶.

2.17. Internationalization 🌍

Once upon a time the Internet had a geographic boundary and was English only 🙈. Now it's international, so data gets exchanged in a bunch of languages and character sets 🗣️. To meet the requirements of an international Internet, a standard must conform to the policies in BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages" 🌸.

2.18. Glossary 📖

Every standards track RFC should have a glossary, because words can mean a lot of things 🤷‍♀️. By defining any new words, the author avoids confusing or misleading implementers. The definition should appear the first time the word shows up in the protocol specification, and also in a separate glossary section 🎀.

Protocol definitions will rely on lots of words that show up all the time in IETF documents. All authors must know the commonly accepted definitions of those words 💅. FYI 18/RFC 1983, "Internet Users' Glossary", gives Internet-specific definitions, and deviating from them is strongly discouraged 🚫. If circumstances force a deviation, the author should say they're altering the commonly accepted definition and give the rationale for why it's necessary. The altered definition must be included in the Glossary section 📝.

If the author uses the word as commonly defined, she doesn't have to include the definition in the glossary 💖. At a minimum, FYI 18/RFC 1983 should be referenced as a source 🦋.

3. Specific Guidelines 🎀

The following are guidelines on how to present specific technical info in standards 🧁.

3.1. Packet Diagrams 📦

Most link, network, and transport layer protocols have packet descriptions 🔗. Packet diagrams in the standard are super helpful for the reader 🙌. The preferred form is a sequence of long words in network byte order, each word horizontal on the page, with bit numbering at the top 🔢:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Prio. |                   Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In cases where a packet is strongly byte-aligned rather than word-aligned (e.g., when byte-boundary variable-length fields are used), display packet diagrams in a byte-wide format. The author can use different height boxes for short and long words, and broken boxes for variable-length fields 💖:

                           0 1 2 3 4 5 6 7
                          +-+-+-+-+-+-+-+-+
                          |    Length N   |
                          +-+-+-+-+-+-+-+-+
                          |               |
                          +    Address    +
                                 ...
                          +   (N bytes)   +
                          |               |
                          +-+-+-+-+-+-+-+-+
                          |               |
                          +  2-byte field +
                          |               |
                          +-+-+-+-+-+-+-+-+

3.2. Summary Tables 📋

Some protocol specs are super lengthy, sometimes 100 pages or more 📚. In those cases, a summary table can reduce the risk of conformance failure by an implementation through oversight 😬. A summary table itemizes what in a protocol is mandatory, optional, or prohibited. Summary tables don't guarantee conformance, but they help an implementer check that they've addressed all protocol features ✅.

The summary table will consist of, at a minimum, four (4) columns: Protocol Feature, Section Reference, Status, and References/Footnotes. The author may add columns if they further explain or clarify the protocol 🎨.

In the Protocol Feature column, list the protocol's characteristics, for example, a command word. We recommend grouping series of related transactions under descriptive headers, for example, RECEPTION 🗂️.

Section reference directs the implementer to the section, paragraph, or page that describes the protocol feature in detail 🔍.

Status indicates whether the feature is mandatory, optional, or prohibited. The author can use either a separate column for each possibility, or a single column with appropriate codes 💜. These codes need to be defined at the start of the summary table to avoid confusion. Possible status codes:

    M    - must or mandatory
    MN   - must not
    O    - optional
    S    - should
    SN   - should not
    X    - prohibited

In the References/Footnotes column, authors can point to other RFCs that are necessary to consider in implementing this protocol feature, or any footnotes necessary to explain the implementation further 🦋.

The STD 3/RFC 1122/RFC 1123 provides examples of summary tables ✨.

3.3. State Machine Descriptions ✨

okay so a super handy way to show how a protocol behaves is a state machine 🤖 A protocol gets described as a series of states, each one resulting from a command, operation, or transaction. State machines define the variables and constants that set up a state, the events that trigger transitions, and the actions that happen during those transitions. Once you have that, you can follow the protocol's dynamic behaviour as a sequence of state transitions for any given event 🧠 Transitions can be drawn as diagrams, written as tables, or laid out as time lines.

Now, the important bit: state machines are never supposed to replace the detailed text description of the spec. They're extras that go alongside the text 💅 If the two ever disagree, the protocol specification shall always take precedence 🫶

When you draw a state transition diagram, show each possible protocol state as a box, connected by state transition arcs. The author should label each arc with the event that causes the transition, and put any actions taken during the transition in parentheses. The STD 5/RFC 1112 has a good example of this. ASCII text is the preferred storage format for RFCs, so only simple diagrams are doable 🌸 For anything more complicated or extensive, tables can summarise the transitions.

In a state transition table, the events go vertically and the states go horizontally. Each cell uses the form action/new state, which shows both the transition and the action. Commas separate multiple actions, and extra lines get used when needed. Authors should list multiple actions in the order they must be executed, if that matters. Letters after a state point to an explanatory footnote. A dash ('-') means an illegal transition 🚫 The STD 51/RFC 1661 has an example of this kind of table. Here are the first columns and rows of that table as an example:

           | State
           |    0         1         2         3         4         5
     Events| Initial   Starting  Closed    Stopped   Closing   Stopping
     ------+-----------------------------------------------------------
      Up   |    2     irc,scr/6     -         -         -         -
      Down |    -         -         0       tls/1       0         1
      Open |  tls/1       1     irc,scr/6     3r        5r        5r
      Close|    0       tlf/0       2         2         4         4
           |
       TO+ |    -         -         -         -       str/4     str/5
       TO- |    -         -         -         -       tlf/2     tlf/3

STD 18/RFC 904 also shows state transitions as a table, but it writes them as n/a, where n is the next state and a is the action 🙃 The RFC 1661 method is the one preferred, since the new state logically follows the action. RFC 904's Appendix C also models transitions as the Cartesian product of two state machines. That's a more complex representation that can be hard to follow if you're not already used to the format, so we recommend that authors use tables the way the previous paragraph describes 💖

The last way to show state changes is a time line 🕰️ The two sides of the time line stand for the machines taking part in the exchange. The author lists the states each machine enters as time moves downward along the outside of the time line. Inside the time line, show the actions that cause the state transitions. Here's an example:

            client                                     server

               |                                          |
               |                                          |   LISTEN
   SYN_SENT    |-----------------------                   |
               |                       \ syn j            |
               |                        ----------------->|   SYN_RCVD
               |                                          |
               |                        ------------------|
               |        syn k, ack j+1 /                  |
   ESTABLISHED |<----------------------                   |
               |                                          |

4. Document Checklist 📋

okay bestie, here's a checklist built from all the guidelines above, so you can check any document against it 💜

Does it identify the security risks? Are countermeasures for each potential attack provided? Are the effects of the security measures on the operating environment detailed?
Does it explain the purpose of the protocol or procedure? Are the intended functions and services addressed? Does it describe how it relates to existing protocols?
Does it consider scaling and stability issues?
Have procedures for assigning numbers been coordinated with IANA?
Does it discuss how to manage the protocol being specified? Is a MIB defined?
Is a target audience defined?
Does it reference or explain the algorithms used in the protocol?
Does it give packet diagrams in recommended form, if applicable?
Is there a change log?
Does it describe differences from previous versions, if applicable?
Does it separate explanatory portions of the document from requirements?
Does it give examples of protocol operation?
Does it specify behavior in the face of incorrect operation by other implementations?
Does it delineate which packets should be accepted for processing and which should be ignored?
If multiple descriptions of a requirement are given, does it identify one as binding?
How many optional features does it specify? Does it separate them into option classes?
Have all combinations of options or option classes been examined for incompatibility?
Does it explain the rationale and use of options?
Have all mandatory and optional requirements been identified and documented by the accepted key words that define Internet requirement levels?
Does it conform to the current internationalization policies of the IETF?
Are the recommended meanings for common Internet terms used?
If not, are new or altered definitions for terms given in a glossary?

5. Security Considerations 🔐

this one is serious, bestie 😤 This document doesn't define a protocol or procedure that could be attacked. What it does do is set guidelines for the information that should be included in RFCs headed for the standards track. When it comes to security, IETF standards authors are called on to clearly spell out the threats the protocol faces, and how the protocol does or does not give its users security assurances. No vibes-based security, periodt 🛡️

6. References 📚

here are all the references, every single one, with the details intact ✨

[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791 September 1981.
[RFC 904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, June 1988.
[RFC 1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1123] Braden, R., "Requirements for Internet hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992.
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662, July 1994.
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. (http://www.iana.org)
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and Language", RFC 2277, January 1998.
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.

7. Acknowledgments 🫶

huge thanks to Peter Desnoyers and Art Mellor, who started the work on this document 🌈 Others who chipped in were:

Bernard Aboba
Harald T. Alvestrand
Fred Baker
Scott Bradner
Brian Carpenter
Robert Elz
Dirk Fieldhouse
Dale Francisco
Gary Malkin
Neal McBurnett
Thomas Narten
Craig Partridge
Vern Paxson
Mike O'Dell
Henning Schulzrinne
Kurt Starsinic
James Watt

8. Editor's Address 📬

Gregor D. Scott
Director, Defense Information Systems Agency
ATTN: JIEO-JEBBC
Ft. Monmouth, NJ  07703-5613
USA

Phone:    (732) 427-6856
Fax:      (732) 532-0853
EMail:    scottg@ftm.disa.mil

9. Appendix 🌟

CHANGES FROM DRAFT -06

here's what changed after IESG review 👀

References to RFC 1543 were changed to RFC 2223, which obsoleted it.
In section 2.1, "export control" was dropped as a valid reason for not selecting a security mechanism. Ambiguous or conflicting sentences were removed too.
In section 2.1, a reference to RFC 2315 was added as an additional source of information.
Section 2.5 was changed to highlight that the Change Log's purpose is to assist implementers.
The IANA Considerations section (2.13) was rewritten to highlight that the IANA guidelines document is work in progress, but should be used when it becomes available.
Section 3.4 Character Sets was deleted and replaced by section 2.17 Internationalization.
Spelling and grammar corrections were made.

CHANGES FROM DRAFT -05

A sentence pointing to a pending document that further addresses IANA considerations was added to section 2.13. The current draft of that document is draft-iesg-iana-considerations-02.txt. A clause stating that the IANA established the assignment policies was removed, since it appeared to conflict with the intent of the referenced ID. Placeholders for the BCP and RFC number were added to the text and reference section.
A new section (2.5) requiring change logs as documents progress along the standards track was added.
References to RFC 2044 were changed to RFC 2279, which obsoleted it.
Spelling and grammar corrections were made.

CHANGES FROM DRAFT -04

A paragraph pointing to a pending document that further addresses security was updated.

10. Full Copyright Statement ✨

You can copy this document and pass it around, and you can make derivative works that comment on it, explain it, or help people implement it, and publish and distribute those too, in whole or in part, with no restrictions of any kind. The catch is that the above copyright notice and this paragraph have to be included on all of those copies and derivative works. 🫶

But this document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The exceptions are when you need it for developing Internet standards, where the copyright procedures in the Internet Standards process have to be followed, or when you're translating it into a language other than English. 🌸

The permissions here are perpetual, meaning they're forever and won't be revoked by the Internet Society or its successors or assigns. Forever, iykyk 💜

Last bit, the disclaimer, and it's giving serious 😭 This document and the information in it are provided "AS IS", and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. No cap, that's the whole legal vibe ✨

📦 where this page comes from

ietf: rfc2360 1998-06
💖 girlified by claude-haiku-5-5 on 2026-10-15: a language model's rewrite of the original, under its terms