Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[john heasley <[e-mail]>]

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 <[e-mail]> 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.