alexkarle.com

Source for alexkarle.com
git clone git://git.alexkarle.com/alexkarle.com.git
Log | Files | Refs | README | LICENSE

commit 7c097dd1384dfc67f1ac2718970958fbc7bab3c5 (patch)
parent 5c06a97e2cdefde9f14a6c5aeeb19269bc796a19
Author: Alex Karle <alex@alexkarle.com>
Date:   Wed, 10 Nov 2021 22:52:31 -0500

gopher: Add entry on RFC's

This has come up a lot at work as we outline our processes. It's
interesting to see what has historically worked!

Diffstat:
Mgopher/phlog.txt | 31+++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+), 0 deletions(-)

diff --git a/gopher/phlog.txt b/gopher/phlog.txt @@ -13,6 +13,37 @@ just a collection of thoughts.. +What's in a RFC? [2021-11-10] +------------------------------------------------------- + +I've always idealized the RFC process of the IETF as +a way to effectively run a distributed project. And +it is, but it's *way* more complex and intricate than +I originally thought. This note serves to share some +of my findings. + +The biggest surprise was that RFC's can't just be +published. You have to send them to the "RFC Editor"! +This person can make minor edits and, at their +discretion, broadcast the document. When the process +first started, these were physical documents! + +RFC's begin life as Internet Drafts, where they are +iterated on, but there's no guarantee you _do_ get +published as an RFC (let alone an Internet Standard). + +And I suppose that's the disconnect between what I +envisioned (mailing list participants just asking for +feedback) and what reality is (a formal process with +a publisher, with gated entry). It's both "open" in +the sense that the publications can be redistributed, +but "closed" in the sense that the Editor decides +what makes the cut. It feels less community-oriented +than I expected; more formal. + +Just my 2c. + + Server Migration [2021-11-07] -------------------------------------------------------