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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Mon, Jul 8, 2019 at 1:54 PM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> 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 <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. 

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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux