Re: I-D Action: draft-wilde-updating-rfcs-00.txt

"Scott O. Bradner" <sob@sobco.com> Sun, 11 December 2016 21:23 UTC

Return-Path: <sob@sobco.com>
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 3EE5F1297C3 for <ietf@ietfa.amsl.com>; Sun, 11 Dec 2016 13:23:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.109
X-Spam-Level:
X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no 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 zYRwiRZSz8lE for <ietf@ietfa.amsl.com>; Sun, 11 Dec 2016 13:23:20 -0800 (PST)
Received: from sobco.sobco.com (unknown [136.248.127.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A52412950B for <ietf@ietf.org>; Sun, 11 Dec 2016 13:23:20 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by sobco.sobco.com (Postfix) with ESMTP id D02AC35032D1; Sun, 11 Dec 2016 16:23:18 -0500 (EST)
X-Virus-Scanned: amavisd-new at sobco.com
Received: from sobco.sobco.com ([127.0.0.1]) by localhost (sobco.sobco.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67_u9tQSL1jJ; Sun, 11 Dec 2016 16:23:17 -0500 (EST)
Received: from [10.0.1.16] (173-166-5-69-newengland.hfc.comcastbusiness.net [173.166.5.69]) by sobco.sobco.com (Postfix) with ESMTPSA id B1D9335032BF; Sun, 11 Dec 2016 16:23:17 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Subject: Re: I-D Action: draft-wilde-updating-rfcs-00.txt
From: "Scott O. Bradner" <sob@sobco.com>
In-Reply-To: <378400590145685410530968@JcK-HP8200>
Date: Sun, 11 Dec 2016 16:23:14 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B38298D-078F-4EFF-B25C-81B61714307F@sobco.com>
References: <147389550726.29872.13885747896056913688.idtracker@ietfa.amsl.com> <0f129603-20c0-921f-6a67-e5a4c74b3c41@gmail.com> <CAA=duU0NNCeL1EP5iJo9YxDmgdtgXSpa+GO1Xs_i38HMrFxSKQ@mail.gmail.com> <b4ab1536-0eb4-0bb4-d441-79cfd74cfd9c@joelhalpern.com> <66D4FC4D5384B187F1571399@JcK-HP8200> <9a3ff314-e778-b416-182f-0dd687f434ce@dret.net> <378400590145685410530968@JcK-HP8200>
To: Erik Wilde <erik.wilde@dret.net>
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/vf0twZaL0cYsZCXV3ZD8u-qpadU>
Cc: IETF discussion list <ietf@ietf.org>, dret@ca.com
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
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: Sun, 11 Dec 2016 21:23:22 -0000

see, for example, https://datatracker.ietf.org/doc/draft-ietf-newtrk-repurposing-isd/

Scott (network WG chair)


> On Dec 11, 2016, at 2:22 PM, John C Klensin <john-ietf@jck.com> wrote:
> 
> Erik,
> 
> Sorry for the delay in responding. Let me try a very high-level
> summary of the implications of what I, at least, consider the
> most important history of the problem you are trying to bite off
> a piece of (others will have other histories).  First, it isn't
> easy.  Even if one just ignores the various flavors of
> Informational documents, the right documentation rules for
> single-stage processes (e.g., BCPs) are inevitably different
> from those for two (and previously three)-stage technical
> standards track ones.  That problem is further complicated by
> the fact that we use BCPs, and occasionally technical standards,
> for what are really procedural or policy statement documents.
> Second, there is a complexity tradeoff.  Today, for normative
> documents, we have BCP documents and 2 1/2 levels of standards
> track  one (depending on what one thinks Experimental is).  
> 
> The issues of updating and categories are also inevitably
> complicated by the nearly-orthogonal one of interrelated and
> interdependent documents, some developed at different times and
> by different groups and often with non-obvious overlaps.
> 
> We tried to take all of this on some years ago in a WG called
> "NEWTRK".  It was not successful.  In particular (and trying to
> state this as neutrally as I can manage), the WG concluded that
> we needed a new type of Standards Track document that would talk
> about status and relationships among documents, rather than
> being one or more technical specification itself.  At least some
> of what you seem to be proposing would go into those
> standards-description documents and not the technical
> specifications themselves.  In addition, at least some of us
> believe that the relevant documents would be living documents
> with change histories rather than the inherently-static (at
> least per-document) RFC series.  
> 
> WIthout revisiting the argument and various opinions about
> motivations, the IESG concluded that the idea was just too
> complicated and/or inappropriate and the idea when nowhere.  In
> retrospect, they might have been right.  Or not.  Either way,
> the experience left many of us reluctant to start nibbling at
> the issues again unless there was a comprehensive plan that the
> IETF was willing to sing off on.
> 
> However, I do believe that it is unrealistic to believe one can
> take on inter-document relationships without at least reviewing
> the issues that the NEWTRK WG examined and the options it
> considered.
> 
> best,
>    john
> 
> 
> 
> --On Wednesday, December 07, 2016 21:52 -0800 Erik Wilde
> <erik.wilde@dret.net> wrote:
> 
>> hello john.
>> 
>> On 2016-09-15 09:37, John C Klensin wrote:
>>> Independent of where it is discussed (as
>>> long as it is on a public list), this I-D would be, at least
>>> IMO, a much more satisfactory basis for discussion if it
>>> demonstrated more convincingly that the author was aware of
>>> those earlier discussions and had considered them, rather than
>>> assuming (or appearing to assume) that no one had thought
>>> about these topics.
>> 
>> it was not my intention to ignore or belittle previous
>> discussions. it just occurred to me as a frequent reader of
>> RFCs that there is a large variation in quality how updates
>> are documented. the idea was that some simple documentation
>> guidelines might help to improve that, without necessarily
>> being hard definitions on what exactly updates are, and how
>> exactly they have to be documented.
>> 
>> i'd be more than happy to include these earlier discussions,
>> but i am afraid if that involves going through a long list of
>> mail archives, this simply is beyond the time commitment i can
>> reasonably make. i'd be more than happy to have somebody
>> co-authoring and filling in those gaps, but that of course
>> assumes that somebody else would be willing to put in the
>> effort of writing up this history.
>> 
>> thanks and cheers,
>> 
>> dret.
> 
> 
> 
>