Re: Things that used to be clear (was Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

[Eric Rescorla <[e-mail]>]

On Mon, Jul 8, 2019 at 1:54 PM Keith Moore <[e-mail]>
wrote:

> 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.


Hmm... Not quite [0]. As I said, the current I-D system works adequately
for the
purposes of test deployments. The point I was trying to make here was that
we regularly deploy on I-Ds, so a rule about how you shouldn't be deploying
on anything but an RFC wouldn't work for us.

>From my perspective, what is lacking is the ability to make minor updates
to the RFC to correct grammar errors, fix obvious errors, clarify
ambiguities,
etc. without re-spinning the RFC. Something like TLS quickly accumulates
a bunch of trivial errata of this kind that it's not worth re-spinning the
RFC
for, but would be useful to update the for readers. But as I said, that's
a different problem.

-Ekr

[0] Though this exists, e.g.,
https://tools.ietf.org/html/draft-ietf-quic-transport