> An "Informational" specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation.
A lot of people associate "RFC" with standards track RFCs so I felt this could cause some confusion.
Also, RFCs are certainly not only standards track. There is a mix of types including Informational, Experimental and Standards track RFCs.
There was no claim that RFCs must be standards track, this is actually a false relation the last line explicitly calls out people for having. Maybe it should have been made even clearer this is a false assumption without relying on context.
I wonder if RFC 2026 is worthy of its own HN post. Just submitted :).
The stages of "standardness" have been there since the 1980s. Many important RFCs have never gone beyond Draft.
As an example of an equivilant informational draft I was involved in https://www.ietf.org/archive/id/draft-lapuh-spb-deployment-0... I can say it reached this stage with basically no review.
If you wanted to have an equivalently published document on centralisation stating the exact opposite of everything this one does you could have it up by the end of the month without worrying about review.
That said, they say right at the top that this is Informational, don't they?
Also, if you did try "an equivalently published document on centralisation stating the exact opposite" of the IETF position, I have a suspicion you'd run into some problems. Wouldn't you? At least some public statements that "that's just his opinion, man."
That said there is nothing wrong with conflicting informational RFCs, they are meant to share information with the community not to convey consensus so it's fine to have conflicting views as long as it sources from differing information. That said it's generally considered better for you and the other person try to come to a common understanding and share that information as one informational document.