Mon, Jul 08, 2019 at 04:54:06PM -0400, Keith Moore: > On 7/8/19 4:26 PM, john heasley wrote: > > > Sat, Jul 06, 2019 at 12:44:14PM -0700, Eric Rescorla: > >> On Sat, Jul 6, 2019 at 11:55 AM Theodore Ts'o <tytso@xxxxxxx> wrote: > >> > >>> I suspect people have been jumping off to something which is harder, > >>> and perhaps for them, more interesting, which is signalling that a > >>> particular I-D version is one that is worthy of being implemented, and > >>> perhaps, deployed in a world where new implementations can be reliably > >>> rolled out to a large percentage of the installed base in 2-3 months. > >>> One answer is of course the experimental RFC, but the problem is that > >>> a lot of people see RFC and immediately assume, it's a stable, > >>> IETF-blessed standard documentation, regardless of the "Experimental" > >>> tag on the top of every single page of said document. > >>> > >> An experimental RFC would not address the need I am talking about: we're > >> spinning one of these every 1-4 months, and doing WGLC, IETF-LC, and RFC > >> processing would cause far too much delay. > >> > >> -Ekr > > exactly; neither experimental nor informational address the desire completely. > > So what it sounds like you need is a link to an internet-draft but > without the version number at the end, that always points to the current > version of that Internet-draft. eh, not exactly; there are baggage and expectation associated with that name that does not seem appropriate/necessary. I want RFC 7525 to not be a RFC nor a draft, instead a Living Document (LD) that the WG publishes on github (or pick another SCM) with WG consensus, and does not take a year+ to publish or update. It may reference RFCs, drafts, CVEs, free/commerical tools, other LDs, etc etc to form recommendations; such as ciphers required, what to avoid, how to deploy, etc. if there is a burning urge/need in someone's pants to chisel some part of it into a rfc as a separate effort, do that separately and maybe it will be published before it is a relic. I'd accept not permitting the reference of drafts, but there could be value to pointing the direction the WG is heading. A draft, a WG item or not, already has different perceived value from a RFC. it is NOT for spec of new protocols, altering protocols, ... Other drafts and RFCs, eg: BGP over TLS, should be able to point to this and simply say follow these WG recommendations and make no or very very few TLS-specific statements/recommendations of its own. Thus that BGP over TLS RFC does not need to be updated as TLS evolves or TLS RFCs come/go, nor does it need to make recommendations about TLS itself - something that the authors may not be qualified to comment about. Another example would be Benoit's periodic state of netmod/netconf emails, while he was AD. Very useful and much of it would be useful in an LD. It could even include a map of documents for a technology; which RFCs apply to BGP, what are the dependencies for BGP LS, etc. I expect the audience to be IETF participants/authors, implementers, and users. And, the authors to be the relevent WG and published with/by WG consensus; without specific solicitation of IESG/IAB/etc, though not forbidden. I believe this is close to what Snijders is pitching, perhaps equivalent, but dissimilar from Kumari's pitch. And, I wish the two be separated. This is not about experimentation or early development; that is and should be a separate discussion. it is about easing mapping of dependencies or a given technology, communication of recommenations, and application/deployment recommendations that evolve more quickly.
