On Mon, Jul 08, 2019 at 02:06:05PM -0700, Eric Rescorla wrote:
> On Mon, Jul 8, 2019 at 1:54 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx>
> wrote:
> > 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.
It'd be nice to have something like a wikified "living RFC" where we can
keep track of proposed, accepted, and rejected edits kinda like we do
errata, but with a much better UI, and where we can keep track of
consensus status for each proposed edit, all such that at some point we
can cut a new RFC from that by pressing a button.
xml2rfc is great, but it lacks wiki-ness, though we could probably
develop HTML+JS tooling to give xml2rfc that missing wiki-ness.
This really does feel a bit like a tooling problem. That if we had the
right tools, something like a cross between GitHub, Markdown, wiki,
xml2rfc, the datatracker, and the errata tracker, we'd have a much much
easier time re-spinning RFCs.
Things like Google docs are great at concurrent editing (which we
probably don't quite need for this, provided there is always someone
willing to be editor for a living RFC), but are no good for editing
RFCs. I'd much rather have something like LyX[0] as a UI for editing
RFCs, but that's not (and never will be) webby so forget that.
Another thing is that I'm starting to have trouble keeping track of all
the RFC numbers in my head for all the RFCs I need to be aware of. It'd
be very nice if we really did have RFC XXXX-YY where -YY is subsequent
versions. E.g., instead of RFC 3280 and 5280 we should have RFCs 2459,
2459-01, 2459-02. This would be especially useful for WGs that have
closed down, and also for RFCs like the PKIX ones that have lots of
extensibility and room for extensions to be supplied in other RFCs.
Also, think of the channel binding type IANA registry, which doesn't
require an RFC for each type, just a specification somewhere. A lot of
what we do in the IETF doesn't really need a publication process as
heavy-duty as the RFC publication process.
None of the above addresses the need for I-D stability markers. We're
identifying a lot of related issues and thinking up possible solutions.
Let's not lose track of the specific needs/problems we identify.
The TLS WG, besides needing something much better than errata and RFC
respins, also needs better I-D metadata for the protocol and
implementation development processes.
And it's not TLS WG alone either.
For example, we don't have a lot of energy in KITTEN WG, so we don't
really need better I-D metadata (at least not at this time), but better
RFC maintenance/respin processes and tooling would be a godsend.
Nico
[0] Surprise! after all, I wrote the now-unmaintained lyx2rfc for a
reason...
