Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)

john heasley <heas@shrubbery.net> Fri, 19 July 2019 18:37 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDE5120379 for <ietf@ietfa.amsl.com>; Fri, 19 Jul 2019 11:37:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p5njyIbmnZXw for <ietf@ietfa.amsl.com>; Fri, 19 Jul 2019 11:37:23 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1852F120376 for <ietf@ietf.org>; Fri, 19 Jul 2019 11:37:23 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id D5F7624470; Fri, 19 Jul 2019 18:37:22 +0000 (UTC)
Date: Fri, 19 Jul 2019 18:37:22 +0000
From: john heasley <heas@shrubbery.net>
To: "Joel M. Halpern" <jmh@joelhalpern.com>
Cc: ietf@ietf.org
Subject: Re: Evolving Documents (nee "Living Documents") side meeting at IETF105.)
Message-ID: <20190719183722.GF38674@shrubbery.net>
References: <ed9d3b5b-7442-fdee-8f0f-c614ca4b59e4@network-heretics.com> <CACWOCC-T13zD1DVKA1H3UTNG9iKdNz5TDzObYPk_A6sjfPKFug@mail.gmail.com> <8F980759-324F-49C5-925A-DF0EEABBBD21@network-heretics.com> <d08dbee2-7844-d813-0b93-5db503501c7e@gmail.com> <50E6B4DF-83FC-46A5-94E9-1FF08F597CCF@network-heretics.com> <F2D5DCCF-4051-444B-9522-9E11F9F93005@fugue.com> <869599E9-7571-4677-AB9A-961027549C54@network-heretics.com> <144ff436-a7a2-22f7-7b06-4d0b3bcfefac@joelhalpern.com> <20190719041456.GL33367@vurt.meerval.net> <254fc5f6-3576-a62f-b84f-a7c5d29b0055@joelhalpern.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <254fc5f6-3576-a62f-b84f-a7c5d29b0055@joelhalpern.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/7KRLLIWjOTEKgtBSEAXDyv1jKhw>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Jul 2019 18:37:24 -0000

Fri, Jul 19, 2019 at 12:56:19AM -0400, Joel M. Halpern:
> There is indeed an argument that operational guidance has the dual 
> properties of
> 1) needing to be out promptly
> 2) changing over time as the operational environment changes.

> I do realize that Job's initial motivation for this was specifically 
> operational.  But most of the discussion has not seemed to be restricted 

My motivation is operation, deployment, and development.  Eg; 7525 is all
three, mpov.

> to that.  I do know that various people have asked for much more dynamic 
> protocol specs.  And some of the examples cited have been protocol 
> specs.  That is what makes me nervous.

7525 is not protocol spec, if that is what you are referring to; it even
specifically says that it alters no RFC.

If you are referring to something emitted from Kumari's pitch of "stable
rfc version" (or whatever variation of that); I again ask that that
discussion be separate.

> If the focus is operational documents, there ought to be a way to do 
> something, and it ought to be worth a try.  Finding ways for the IETF to 
> be more useful to operators, and for operators to be able to participate 
> in a fashion taht is more eff3ective for what they need, does seem 
> valuable.

So too would be the additional operator involvement, in general.