Re: [Alldispatch] [No-draft-expiry] Taking draft-thomson-gendispatch-no-expiry-03 forward

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

 



On Wed, 24 Jan 2024, Eliot Lear wrote:

[speaking as an individual only]

Subject: Re: [Alldispatch] [No-draft-expiry] Taking draft-thomson-gendispatch-no-expiry-03 forward

I will start with the minor issue: changing the language from expired to inactive is not helpful, and defeats the
purpose of the notion of a "draft".

I agree with Eliot. We already have many flavours of RFCs that the
majority of people outside the IETF know nothing about. I do not
think adding draft flavours will improve the understanding for
people outside the IETF.

 *  We occasionally see drafts that are misrepresented as our works.

I somewhat agree here, but more importantly, any system that can be used
to store arbitrary data will be abused. I would feel more comfortable if
only WG adopted / AD sponsored drafts would not expire. That would raise
the minimum level to "The IETF at least at some point seriously
considered this proposal".`


 *  Reference to unfinished works can lead to interoperability problems.  This would have happened with each and
    every draft I have ever written and read, to one extent or another.  Some changes are small, like a field size,
    and some are dramatic, like encoding changes.  Confusion can set in when we say that a draft has become
    inactive/expired when it may again become active.  This community has barely any control over if/when that will
    happen.  We can say that this is the fault of the authors, but the harm itself might not accrue to them.  A
    perfect example of this would be IANA considerations that reference a draft.  If a value is allocated for a
    particular version of a draft and a new version comes out, does that code point still map to the protocol
    behavior previously described?  Absent additional information, no one can say.  For our own processes, at least
    we can require that the reference be updated as part of the publication process, as we do.  But once drafts are
    no longer tombstoned, this passes from our control in other circumstances.

I agree.

I find the motivation cited in the draft for the proposed change rather
weak.

If a draft has become a defacto standard, perhaps a WG or new process
should then pick up the publication process, possibly downgraded to
Informational RFC as no changes can be made anymore. This should only
be done when active deployment of significant scale or importance is
happening using the draft specification.

Paul




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

  Powered by Linux