Congratulations to @benjojo on getting an RFC through to publication!
3.5 years is fairly typical, I think, though I am slightly surprised by the long period before wg adoption. At least some of that was evidently due to COVID, but I wonder how much is different working groups (or areas) being more or less reluctant to adopt drafts. One thing that definitely varies a lot is how much implementation experience is expected at different stages of the process. The “running code” slogan is not always strictly true.
I’m amused that Ben’s diagram glosses over the “last call” stages. I guess it’s a sign that the document was thoroughly done so those stages were formalities, but sometimes they can be more contentious! There’s the working group last call, which confirms that the working group considers the document to be done. The document shepherd write-up happens at about this time. Before the IESG conducts their review, there is an IETF last call. Hopefully the document authors have already discussed their draft outside their working group if necessary, but the IETF last call is supposed to catch things that were overlooked. You can see them on the ietf-announce mailing list along with “protocol action” messages saying the IESG has approved a draft.
[The IESG is the internet engineering steering group, which consists of the IETF area directors. They do final document review, decide which working groups exist, and suchlike.]
I think it’s worth emphasizing the role of the meetings in the process. They happen three times a year (typically north america, europe, and asia) and each working group chair is expected to summarize their group’s work in progress, and draft authors usually report on the state of their documents to their working group. It’s a good time for authors to make sure that forward progress is happening and get things unstuck, whether or not they will be at the meeting in person.
though I am slightly surprised by the long period before wg adoption
I think I had the “pleasure” of having most of the contention happen during the working group adoption phase (this is where almost all of the email traffic was sent), after we got past WG Adoption and Last Call everyone ahead of us was in agreement with what we wanted to get done. Obvious this is not always going to be the case, but this is post is the reflection of how I found it :)
I found this article very interesting. I do know that the rfcs were never intended to be a standards body. I listened to an interesting article on ping that talked about this.
late 1960s - mid 1970s: getting the ARPANET working
The ARPANET itself was designed and operated by BBN, but the applications that ran over it were the responsibility of the computer centres that were connected. The RFC series came from this work.
The early RFCs are a mixture of newsletters, drafts and responses, and some specifications. This is when the classic Internet protocols originated: telnet, ftp, well-known ports
late 1970s: ARPANET maturity, early IP
ARPANET email was being refined and standardized (still using FTP as its transport)
Early IP work was published in the IEN series, internet engineering notes, separate from the RFC series that was specific to ARPANET at that time
early 1980s: preparation for IP on ARPANET
This is when the notion of domain names arose, first for email then generalized. SMTP and DNS were developed. The RFC series starts documenting IP. ARPANET telnet and ftp are adapted to work over TCP/IP.
mid 1980s: get IP working properly
The BSD networking stack. Van Jacobson congestion control. Routing between LANs and ARPANET. The IETF is established to cope with the growing scale of this work.
late 1980s / early 1990s: IP works
NSFNET replaces ARPANET as the backbone. BGP. Early commercial ISPs appear. International expansion.
This is about when the IETF and RFCs become standards rather than working documents, I think. RFCs 1122 and 1123 solidifying requirements for Internet implementations in 1989.
mid 1990s: hockey stick growth and commercialization
The US DOD and NSF start to divest and distribute their responsibility for internet governance. The dark days of the Network Solutions DNS monopoly. The early days of regional internet registries.
Classless inter-domain routing allows IPv4 to survive while IPv6 is designed. The IETF starts work on cryptographic security: IPSEC, DNSSEC. The WWW becomes the killer application.
The RFC series and the IETF settled down into something resembling their current form by this point.
late 1990s: death of Jon Postel
Sadly coincided with the effort to break the DNS monopoly, which led to the establisment of ICANN. The IANA and RFC Editor were no longer closely associated with one person, tho Postel’s team continued to do IANA and RFC Editor work for several years.
Since the 1990s the IETF is well established as an international standards development organization of the voluntary commercial kind. RFCs are definitely now the IETF standards series, though a few historical quirks remain.
It’s missing the part where you create a custom ABNF syntax, because you can’t have an RFC without one ;-P
Congratulations to @benjojo on getting an RFC through to publication!
3.5 years is fairly typical, I think, though I am slightly surprised by the long period before wg adoption. At least some of that was evidently due to COVID, but I wonder how much is different working groups (or areas) being more or less reluctant to adopt drafts. One thing that definitely varies a lot is how much implementation experience is expected at different stages of the process. The “running code” slogan is not always strictly true.
I’m amused that Ben’s diagram glosses over the “last call” stages. I guess it’s a sign that the document was thoroughly done so those stages were formalities, but sometimes they can be more contentious! There’s the working group last call, which confirms that the working group considers the document to be done. The document shepherd write-up happens at about this time. Before the IESG conducts their review, there is an IETF last call. Hopefully the document authors have already discussed their draft outside their working group if necessary, but the IETF last call is supposed to catch things that were overlooked. You can see them on the ietf-announce mailing list along with “protocol action” messages saying the IESG has approved a draft.
[The IESG is the internet engineering steering group, which consists of the IETF area directors. They do final document review, decide which working groups exist, and suchlike.]
I think it’s worth emphasizing the role of the meetings in the process. They happen three times a year (typically north america, europe, and asia) and each working group chair is expected to summarize their group’s work in progress, and draft authors usually report on the state of their documents to their working group. It’s a good time for authors to make sure that forward progress is happening and get things unstuck, whether or not they will be at the meeting in person.
I think I had the “pleasure” of having most of the contention happen during the working group adoption phase (this is where almost all of the email traffic was sent), after we got past WG Adoption and Last Call everyone ahead of us was in agreement with what we wanted to get done. Obvious this is not always going to be the case, but this is post is the reflection of how I found it :)
I found this article very interesting. I do know that the rfcs were never intended to be a standards body. I listened to an interesting article on ping that talked about this.
There were several phases to the history.
late 1960s - mid 1970s: getting the ARPANET working
The ARPANET itself was designed and operated by BBN, but the applications that ran over it were the responsibility of the computer centres that were connected. The RFC series came from this work.
The early RFCs are a mixture of newsletters, drafts and responses, and some specifications. This is when the classic Internet protocols originated: telnet, ftp, well-known ports
late 1970s: ARPANET maturity, early IP
ARPANET email was being refined and standardized (still using FTP as its transport)
Early IP work was published in the IEN series, internet engineering notes, separate from the RFC series that was specific to ARPANET at that time
early 1980s: preparation for IP on ARPANET
This is when the notion of domain names arose, first for email then generalized. SMTP and DNS were developed. The RFC series starts documenting IP. ARPANET telnet and ftp are adapted to work over TCP/IP.
mid 1980s: get IP working properly
The BSD networking stack. Van Jacobson congestion control. Routing between LANs and ARPANET. The IETF is established to cope with the growing scale of this work.
late 1980s / early 1990s: IP works
NSFNET replaces ARPANET as the backbone. BGP. Early commercial ISPs appear. International expansion.
This is about when the IETF and RFCs become standards rather than working documents, I think. RFCs 1122 and 1123 solidifying requirements for Internet implementations in 1989.
mid 1990s: hockey stick growth and commercialization
The US DOD and NSF start to divest and distribute their responsibility for internet governance. The dark days of the Network Solutions DNS monopoly. The early days of regional internet registries.
Classless inter-domain routing allows IPv4 to survive while IPv6 is designed. The IETF starts work on cryptographic security: IPSEC, DNSSEC. The WWW becomes the killer application.
The RFC series and the IETF settled down into something resembling their current form by this point.
late 1990s: death of Jon Postel
Sadly coincided with the effort to break the DNS monopoly, which led to the establisment of ICANN. The IANA and RFC Editor were no longer closely associated with one person, tho Postel’s team continued to do IANA and RFC Editor work for several years.
Since the 1990s the IETF is well established as an international standards development organization of the voluntary commercial kind. RFCs are definitely now the IETF standards series, though a few historical quirks remain.
This sounds like normal process stuff at BigCo where I used to work, for changing things as simple as the text on a button on a web page.
“We’re going to need to put together a working group …”