This is a really big help to anyone trying to implement TCP. At one previous job, we had to wade through ~20 RFCs to figure out how to write a hardware TCP system, paying particular attention to which RFC supersedes which sections of other RFCs. Consolidating to one RFC without the crazy dependency chain is a big improvement!
I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.
I never really realized that this symptom was common with RFCs as well.
Is there something about how governing bodies work that lead to this style of output? Why aren't we using a bit more modern techniques now, more akin to how word processors let you see the diffs inline but also the final format? Or git-style PRs that show the deltas but you can always just view "main"?
This is the natural end result of committee-style work - because if you work on a "diff" you can force the discussion to only touch some small parts of the whole, but if you work on an "updated document", even if everyone kind of agrees the only change necessary is to Section 7, the fact that the whole document is "up for discussion" causes the whole thing to be up for discussion.
In both cases they can still produce the "final document" which the government is often better at than standards bodies.
In the IETF's case, this is because, by policy, RFCs are immutable once published. You can update an RFC by publishing a new RFC that specifies the changes, or a new one that obsoletes the original entirely (this document does both to various RFCs). There is also an errata process for simple mistakes.
That means that minor changes tend to accumulate in other documents over the years. You could imagine tooling that automatically incorporates these changes into the presented document, like you suggest, but someone would have to build that tooling. That is a bit challenging, as the format of an RFC that updates another is not designed for such automated processing (e.g., go read this document and tell me what changes should be made to the text of RFC 5961, which it updates), and because the format of a published RFC is not semantic (e.g., adding a new section will not automatically renumber the remaining sections, because it's just a .txt file).
You could also design a different policy, but immutability has its advantages, too, and the current policy has been in use for decades, so the case for switching would have to be pretty compelling.
So for now the "Updated by:" header at the top of each document is what you get.
> I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.
Most governments do maintain a consolidated version of their laws, but that's something different than the bills. Compare it with GitHub: the consolidated version is the head of the repository, while the bills are Pull Requests.
E.g. for the US there's the US code: https://uscode.house.gov/; which for every section has both the text as currently in effect, as well as a list of all historical amendments.
> I wish government legislature did this with their bills. Reading a piece of legislation is maddening because it's always just a description of diffs, without seeing the final outcome.
The state of Washington does. Our legal code is called the "Revised Code of Washington" because there is a state employee, called the Code Reviser, whose job description is "apply the diffs":
They do a great job, too. Each section/subsection of the RCW comes with links to the bills which revised it, and each of those is formatted using strikeouts (removed text) and underlines (added text).
The federal government should be embarrassed by this.
The UK does this (but only since 2006, ish, and it's not guaranteed to be fully up to date everywhere). For example, here's an act made in 1981 and amended many times since:
Inserted or altered text is in heavy square brackets, and removed text is replaced with a row of full stops; both are labelled with a code starting with F, which indexes a reference in a box below the section. The references are hyperlinks to the amending legislation; sometimes there is a link to both an act which enabled the amendment, and a statutory instrument which applied it.
There's a slider at the top which lets you see the legislation as it stood in the past (as far as 1991), before each amendment was made.
Amendments made before 1991 are applied, but not sliderable:
Some governments do. For instance, check Brazil's constitution: http://www.planalto.gov.br/ccivil_03/constituicao/constituic... which has for changed articles both the original text (in strike through), the updated text, and hyperlinks to the legislation which was the source of each change. (And it's not just the constitution, all federal legislation has pages presenting in that format.)
This process pre-dates computing. And the law in general defers to precedent, history, and customs - that's part of what Common Law is.
Eventually the legislative process will catch up and use something akin to version control. But that's just automating what is currently a manual process. And the bottleneck for making progress isn't the difficulty of updating the law - not by a long shot.
FWIW some bills just say something like:
1. Strike 27 Section 2(g) (which is 100 paragraphs)
2. Insert the following under 27 Section 2(g) (followed by an entirely rewritten bit of law)
Even all the sections, paragraphs, etc with the numbers, capital letters, lowercase letters, and so on are really just a manual form of hyperlinking and bookmarking so the code can have cross-references.
That's also something that could be a lot easier to write, update, and read if we had a VCS for writing laws.
> Why aren't we using a bit more modern techniques now, ...
because those in power don't care, this problem doesn't really affect them, they don't know about potential solutions (too old and/or not programmers), they are afraid of structural change anyhow, etc, etc.
Legal case research is is even worse, if you can imagine. Digging through court decisions is all about finding chains and piecing together the current precedent. Oh and in the old days of legal reference texts, you always had to check for the "pocket parts". Updates to the law after the text was published went sent out as small pamphlets, much like errata, and they were literally placed in pockets at the back of the books.
Most changes are in self contained documents because they are inherently experimental. After a while they become so useful and widespread that everyone needs them, and hopefully a bis rolls them all up.
It is cool to see such a central piece of the Internet puzzle get an updated specification.
This quote from the RFC provides both the context of this document and is an indication as to why it seemingly took so long for this particular update to be published:
> This document is largely a revision of RFC 793, of which Jon Postel was the editor. Due to his excellent work, it was able to last for three decades before we felt the need to revise it.
See the Abstract and Section "1. Purpose and Scope":
"Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793."
"The purpose of this document is to bring together all of the IETF Standards Track changes and other clarifications that have been made to the base TCP functional specification (RFC 793) and to unify them into an updated version of the specification."
Nevertheless, it seems that some updates and clarifications were also done:
"It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168."
In all seriousness, all important technical documents should do this -- as the implementation and use cases evolve, re-define the standard, documenting the canonical changes and clarifying everything.
New IP stack RFCs are a chicken or the egg problem without a reference implementation to test with. How do you release it into the wild without a say Linux or windows implement one first?
[+] [-] pclmulqdq|3 years ago|reply
[+] [-] amelius|3 years ago|reply
[+] [-] Lightbody|3 years ago|reply
I never really realized that this symptom was common with RFCs as well.
Is there something about how governing bodies work that lead to this style of output? Why aren't we using a bit more modern techniques now, more akin to how word processors let you see the diffs inline but also the final format? Or git-style PRs that show the deltas but you can always just view "main"?
[+] [-] bombcar|3 years ago|reply
In both cases they can still produce the "final document" which the government is often better at than standards bodies.
[+] [-] derf_|3 years ago|reply
That means that minor changes tend to accumulate in other documents over the years. You could imagine tooling that automatically incorporates these changes into the presented document, like you suggest, but someone would have to build that tooling. That is a bit challenging, as the format of an RFC that updates another is not designed for such automated processing (e.g., go read this document and tell me what changes should be made to the text of RFC 5961, which it updates), and because the format of a published RFC is not semantic (e.g., adding a new section will not automatically renumber the remaining sections, because it's just a .txt file).
You could also design a different policy, but immutability has its advantages, too, and the current policy has been in use for decades, so the case for switching would have to be pretty compelling.
So for now the "Updated by:" header at the top of each document is what you get.
[+] [-] Denvercoder9|3 years ago|reply
Most governments do maintain a consolidated version of their laws, but that's something different than the bills. Compare it with GitHub: the consolidated version is the head of the repository, while the bills are Pull Requests.
E.g. for the US there's the US code: https://uscode.house.gov/; which for every section has both the text as currently in effect, as well as a list of all historical amendments.
[+] [-] octoberfranklin|3 years ago|reply
The state of Washington does. Our legal code is called the "Revised Code of Washington" because there is a state employee, called the Code Reviser, whose job description is "apply the diffs":
http://www.leg.wa.gov/CodeReviser/
It sounds a bit silly at first but having gotten used to having instant access to the end product I think this is an excellent use of my tax dollars.
https://apps.leg.wa.gov/rcw/
They do a great job, too. Each section/subsection of the RCW comes with links to the bills which revised it, and each of those is formatted using strikeouts (removed text) and underlines (added text).
The federal government should be embarrassed by this.
[+] [-] twic|3 years ago|reply
https://www.legislation.gov.uk/ukpga/1981/69
Inserted or altered text is in heavy square brackets, and removed text is replaced with a row of full stops; both are labelled with a code starting with F, which indexes a reference in a box below the section. The references are hyperlinks to the amending legislation; sometimes there is a link to both an act which enabled the amendment, and a statutory instrument which applied it.
There's a slider at the top which lets you see the legislation as it stood in the past (as far as 1991), before each amendment was made.
Amendments made before 1991 are applied, but not sliderable:
https://www.legislation.gov.uk/aep/Hen3c23/52/23/section/XXI...
[+] [-] cesarb|3 years ago|reply
[+] [-] xenadu02|3 years ago|reply
Eventually the legislative process will catch up and use something akin to version control. But that's just automating what is currently a manual process. And the bottleneck for making progress isn't the difficulty of updating the law - not by a long shot.
FWIW some bills just say something like:
1. Strike 27 Section 2(g) (which is 100 paragraphs) 2. Insert the following under 27 Section 2(g) (followed by an entirely rewritten bit of law)
Even all the sections, paragraphs, etc with the numbers, capital letters, lowercase letters, and so on are really just a manual form of hyperlinking and bookmarking so the code can have cross-references.
That's also something that could be a lot easier to write, update, and read if we had a VCS for writing laws.
[+] [-] pas|3 years ago|reply
because those in power don't care, this problem doesn't really affect them, they don't know about potential solutions (too old and/or not programmers), they are afraid of structural change anyhow, etc, etc.
[+] [-] cratermoon|3 years ago|reply
[+] [-] wbl|3 years ago|reply
[+] [-] eru|3 years ago|reply
[+] [-] q-big|3 years ago|reply
[+] [-] cesarb|3 years ago|reply
To give an official source for that: https://datatracker.ietf.org/doc/rfc9293/ says "Last updated: 2022-08-18" which indeed was yesterday.
[+] [-] michaelmior|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] adunk|3 years ago|reply
This quote from the RFC provides both the context of this document and is an indication as to why it seemingly took so long for this particular update to be published:
> This document is largely a revision of RFC 793, of which Jon Postel was the editor. Due to his excellent work, it was able to last for three decades before we felt the need to revise it.
[+] [-] netfortius|3 years ago|reply
[+] [-] justnotworthit|3 years ago|reply
[+] [-] bpoyner|3 years ago|reply
[+] [-] harvie|3 years ago|reply
[+] [-] q-big|3 years ago|reply
"Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793."
"The purpose of this document is to bring together all of the IETF Standards Track changes and other clarifications that have been made to the base TCP functional specification (RFC 793) and to unify them into an updated version of the specification."
Nevertheless, it seems that some updates and clarifications were also done:
"It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168."
[+] [-] egberts1|3 years ago|reply
I worked with Sally (of ISC) on TCP Westwood.
We used OpNet Simulator (~1.0) to exercise massive pseudo-traffic when testing.
https://egbert.net/blog/articles/tcp-evolution.html
https://opnetprojects.com/opnet-projects/opnet2-1/
[+] [-] lxe|3 years ago|reply
In all seriousness, all important technical documents should do this -- as the implementation and use cases evolve, re-define the standard, documenting the canonical changes and clarifying everything.
[+] [-] sgt|3 years ago|reply
[+] [-] billpg|3 years ago|reply
[+] [-] q-big|3 years ago|reply
> https://www.rfc-editor.org/rfc/rfc793
RFC 9293 is a new version of STD 7 (TCP).
[+] [-] m3kw9|3 years ago|reply
[+] [-] wmf|3 years ago|reply
[+] [-] oeoe|3 years ago|reply
[+] [-] q-big|3 years ago|reply
EDIT: Also consider that the "evil bit" is part of the IPv4 header, and not of the TCP header.