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

[Nico Williams <[e-mail]>]

On Wed, Jul 10, 2019 at 02:32:30PM -0400, Phillip Hallam-Baker wrote:
> I agree with much of this discussion but I have come to a very different
> perspective:
> 
> * Internet Standard status means nothing more than the fact that the legacy
> deployment is sufficiently large that further development of the
> specification is no longer feasible.

s/further development/further backwards-incompatible development/

> * Internet Standard status is not necessarily a desirable condition.

PS is enough for the vast majority of participants.

The thought of "when shall we move RFX xxxx to Standard?" never keeps me
awake at night.  It probably never keeps anyone else up at night.

That fact however might keep some of us awake at night :)

> * Internet Standard status will be reached regardless of whether the
> documents are good or not.

Indeed.  Respinning an RFC is hard work.  Respinning _and_ rewriting an
RFC is prohibitively expensive.

> We need to stop being so dogmatic about IETF process. It is not like it is
> working for us now or has worked well in the past. I propose a different
> approach
> 
> 1) Keep the two standards process levels but drop the notion that Internet
> Standard means the work is finished and will never change. [...]

That notion never existed!  The thing that is unchanging is the contents
of an RFC.  STD designations can (and they do) move to new RFCs that
obsolete the old ones.

> 3) Establish a maintenance WG in each area that is the place for continuing
> incremental development of standards. The Security area has LAMPS. I think
> that instead of the 'do the work, shut the WG' model applying to every WG
> in IETF, the maintenance groups should act as standing committees for very
> limited updates.

We are able to maintain RFCs from concluded WGs (e.g., SECSH).  But I
agree that having a WG per-area specifically for mainenance would be a
better way to do that.

> I fully sympathize with John Klensin's point about making changes to a spec
> after deployment. One of the reasons I have not been looking to get people
> using the Mesh until now is that I knew that the minute I started
> attracting users, that would eliminate my scope to make fundamental changes.

s/making changes/making backwards-incompatible changes/