The “simple” 38 step journey to getting an RFC | Hacker News Reader

The “simple” 38 step journey to getting an RFC

blog.benjojo.co.uk

141 pointsgreyface-30 comments

In 2008 I was one of two software architects at Linden Lab (makers of Second Life.) We were re-factoring our "organic" UDP based virtual world protocol and figured it was in everyone's best interest to publish an informational RFC about what we were doing. It made good political sense cause it allowed us to tell the "we're trying to build an open virtual world" story we thought would take us to the next level. That is, we were trying to be more "open" than "closed" and we wanted to tell that story.

We thought it would be a simple process to publish one or two 100 page informational RFCs, get a bit of feedback and be done with it in a few months.

Two years later we had a working group and several mature internet drafts. I won't go into the drama about why the IDs never turned into RFCs, but my advice...

Never let anyone talk you into chartering a working group when all you want to do is publish an informational RFC. Also, when dealing with large multi-national companies with more lawyers and sales-people than engineers, make sure you get everything (notarized documents indicating they disclaim IP interests in the area of the internet draft) in writing first. Do not depend on them saying "hey, at the end of the process we're going to have to disclaim IP in this field anyway, so why would we lie to you?" They will wait until the last possible moment and then fail to disclaim their IP, scuttling the RFC process. I guess it's just in their nature.

Oh hey, which Linden were you? I wonder if we met.

I used to be quite active over there. Memory is fuzzy at this point but I recall that people reverse-engineered the protocol, so I'm curious how this all fits together.

RFCs can be published with IPR declarations existing.

Missing from this discussion is that once you identify a WG that might possibly be a good host for your work, you should really spend some time lurking on the mailing list and understand what efforts they already have, and more importantly what their agenda is. They have a trajectory, and while the WG might consider proposals technically within their charter, it helps if this draft is sympathetic and not redundant with work that's ongoing.

If RFCs were RFCs, it would be easier.

But in history, RFCs became loose or strict standards. From that day on, everyone has tried have to their own RFC stamped; because there’s an economic advantage to being the standard bearer.

So, the process has become more and more convoluted to avoid having as many “standards” as there are interested parties.

Steve Crocker and Jon Postel must be laughing at us.

That’s an interesting evolution of the phrase “standard bearer,” I’m not sure if it is a pun or not.

A poor use of the words for sure. “standard originator” would have been better.

It's an excellent use of words, especially given modern standardisation practices - if Google adds something new into Chrome and publishes an RFC at the same time, are they not marching at the front of the implementers, the standard inviting others to follow in their footsteps?

> standard inviting others to follow in their footsteps?

And an message to anyone in the way to vacate or feel the point of a gladius and the hobnails of a caliga.

I dunno, I kinda like it. The standard bearer in an army is sorta seen as a brave position… but really, it is also one of prestige, possibly political advantage, and the other units in your cohort might actually prioritize defending you.

> and the other units in your cohort might actually prioritize defending you.

They'd better, if they want to win a battle.

Even losing the battle wouldn't necessarily be the end of it. Going home without your standard was really not a good look for the unit.

How crazy and bureaucratic the Internet has grown!

RFC #1 was basically a one-pager: https://www.rfc-archive.org/getrfc?rfc=1#gsc.tab=0

RFC #371 was literally a conference advertisement: https://www.rfc-archive.org/getrfc?rfc=371#gsc.tab=0

There is even a “List of April Fools' Day RFCs” article on wikipedia:

https://en.m.wikipedia.org/wiki/April_Fools%27_Day_Request_f...

Peter Salus and Thom Limoncelli collected those in book form a decade or so back that we published and is still in print: https://www.peerllc.com/peer-to-peer-books/the-complete-apri...

And here I was thinking the internet was just for cat videos!

Seriously though... IETF process is the way it is because of a long history of humans arguing with each other over process, intent and interpretation. Add to that all the drama about IP in the 90s and you get a perfect storm of bureaucracy. But the weird thing is we're probably better off with the bureaucracy than without it. I only saw a bit of the process in 2008-2010 when I convened several BOF sessions and chartered a working group, but it did seem like the rules were there to prevent shenanigans.

I learned PLENTY of history in the Application area, none of which seemed to be documented anywhere. I would guess people had different recollections of that history anyway.

IETF process is byzantine, but if you ask around, the greybeards have a story or two describing why each bit of bureaucratic process was introduced.

> I am organizing a computer communication network demonstration to run in parallel with the sessions. This demonstration will provide attendees with the opportunity to gain first hand experience in the use of a computer network.

Definitely worth of a RFC!

> RFC #1 was basically a one-pager

You have a strange notion of “one-pager”. It’s eleven pages; strip headers, footers, excess blank lines, table of contents, and three diagrams, and it’s still over 300 lines (some 70 blank) and 2000 words.

If anyone is wondering what "AUTH48" means - it's the author review part of the process, just prior to the document being published, where the authors get a last chance to look over the revised document and make sure there aren't any typos etc. It's meant to last 48 hours, hence the name, but nowadays in practice it can stretch to weeks.

Step 1: write an RFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFC

Step 2: write an RFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFRFC

…and so on

Every post this guy writes is illuminating – strongly recommend checking out his archive if you like digging into the weeds.

+1. I've written one non-controversial RFC, and this is exactly it. What's missing is if the area you're working in controversial or has many, many stakeholders. For example of this just look at the DMARCbis last call happening now. There apparently is an art form to getting controversial work published by the IETF. It can by garnering a lot of support, but few well meaning voices can sink that effort as well. Working for a big tech company can hamper your efforts as well as some of those well meaning activists don't like big tech. I feel that work sponsored by small and medium sized companies has the best shot of actually happening.

I didn't know RFCs are being written with xml2rfc directly anymore; I was under the impression most work was now happening through https://github.com/cabo/kramdown-rfc, which lets you hand-write markdown instead of hand-writing XML.

And then https://github.com/martinthomson/i-d-template, though a bit elaborate, does automate a lot of IETF stuff, including use of kramdown-rfc.

A lot of people do write in markdown but when things finally get the RFC Production Center they work with the XML directly. This can actually cause problems if you want to produce a revised RFC (jargon: a "-bis") later, because the copy edit changes are in the XML and need to be backported to the markdown. The pro move is to backport the changes during the publication cycle as part of reviewing the copy-edit changes the RPC makes.

"...this can also be a bad thing, in that the bar to entry in theory is quite low, meaning you might have to deal with people arguing in questionably bad faith, or who don’t have first hand real world experience of the subject."

FWIW, this isn't something that can only happen in the IETF. Lots of other SDOs can have this issue. Some (usually corporate sponsored) participants in SDOs participate solely to slow down/poison work. Usually as an effort to gain market share while things are debated and become the de facto standard rather than allow something they may not implement become standardized.

I assume the author typoed "recuse" (rather than intending "recurse") when itemising the feedback options!

Interesting to see the process under the covers these days. Faintly depressing, when one compares to what one reads about the Postel steered early days.

Obligatory nod to my favourite bittersweet RFC-2468 (the number choice there has always struck me as a stroke of genius).

Why on earth is anyone whining about the processes behind making an Internet Change Request, aka RFC?

I once spent around 18 months to two years getting a corporation to use DHCP properly (ie stop registering all devices MAC addresses for static leases) and I consider that a quick win.

RFCs deal with the entire internets and should require quite a lot of oversight. Three and a half years for a BGP change is a breathtakingly fast change and frankly reckless!

The author isn't whining, he's simply sharing his experience.

> ...as people were operating outside of the normal environment (working from home, entirely virtual meetups...

Why is this an issue? @greyface-, you and your team are unable to work remotely because it's outside your environment?

If you don't like remote work, great. But, not everyone else enjoys wasting hours-per-week of their life commuting (unpaid) to an uncomfortable, cold office full of constant destraction and middle-school politics.

If you do, great! keep it to yourself instead of pushing an agenda that no one wants.

> @greyface-, you

FWIW, I didn't write the article - I just posted it here.

Reply on news.ycombinator.com