Moin, (Repost to list as my original reply had a wrong From:) On Thu, 2024-10-03 at 07:57 +0300, Saku Ytti wrote:
On Thu, 3 Oct 2024 at 07:04, Jeff Behrns via NANOG <nanog@nanog.org> wrote
This seems like a total misuse of the RFC framework / process and more a grab at publicity, but I'll play along...bogon. You should include the term "bogon". Someday when I'm done keeping actual production networks alive, I may wade into the morass of IETF & IEEE and work on trimming the fat...or maybe just retire. It's a tough call.
Not saying I agree or disagree, what is the definition of appropriate use and how does this particular draft violate in comparison to the existing corpus?
Someone might want to argue RFCs are for technical implementations, but there are increasingly many RFCs with no relevance to technical implementations at all, which are significantly more soft ball than the work proposed here.
There are a couple of operations focused WGs (DNSOP, GROW) that indeed produce mostly operational documents; And, i mean, operational guidance is at least as old as RFC1032 (being the first one springing to my mind; Likely older ones exist, but I don't have them at the top of my head.). The purpose of this document is mostly just summarizing the terms currently used, as the ambiguity of terms makes documents sometimes a bit difficult: The peer [BGP neighbor] to which our router peers [has established a session] so we can peer [process of having a peering relationship] with our peer [AS relationship] has been depeered [removal of BGP sessions]. It is not meant to be authoritative, i.e., unlike RFC8499 for DNS, to ensure that it has some chance of actually making progress without having to order dedicated truckloads of planks for the new bikeshed to build (yes, i know, the shed should be made of concrete instead of wood; But that is how i'd build it). With best regards, Tobias