Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability.

Toerless Eckert <tte@cs.fau.de> Wed, 22 July 2020 15:11 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04C593A0888 for <architecture-discuss@ietfa.amsl.com>; Wed, 22 Jul 2020 08:11:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=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 38ULbPXisigt for <architecture-discuss@ietfa.amsl.com>; Wed, 22 Jul 2020 08:11:16 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC9A3A086C for <architecture-discuss@ietf.org>; Wed, 22 Jul 2020 08:11:15 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 44651548068; Wed, 22 Jul 2020 17:11:10 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 39DE3440043; Wed, 22 Jul 2020 17:11:10 +0200 (CEST)
Date: Wed, 22 Jul 2020 17:11:10 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: John R Levine <johnl@taugh.com>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org
Message-ID: <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de>
References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> <e60ef33-3f73-4e39-c73e-ea107da2b587@taugh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <e60ef33-3f73-4e39-c73e-ea107da2b587@taugh.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/ocrjOTDcWkdWF-w-ohzNZPKMJY4>
Subject: Re: [arch-d] clusterpation, was Proposed IAB program: Evolvability, Deployability , & Maintainability.
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jul 2020 15:11:19 -0000

Obviously we could invent a new RFC publication status like "conditional",
so anything with unresolved normative references gets first published
as a conditional RFC having a new normative section of conditional
normative dependencies, pointing to the draft versions.

As soon as ALL the required normative references exist as RFCs too,
they are all updated in status from conditional to whatever their 
ultimate target status was.

Cheers
    Toerless

On Wed, Jul 22, 2020 at 10:18:38AM -0400, John R Levine wrote:
> On Wed, 22 Jul 2020, Brian E Carpenter wrote:
> > > I think we all agree that we don't ever want to see another document
> > > cluster as large or as long-lived as C238. ...
> > > 
> > > But I would rather not attempt to invent processes to try and guess
> > > how best to prevent hypothetical superclusters. ...
> 
> > That would be wise, but by the time anybody notices, it may be too late.
> 
> The RPC certainly knows how big the clusters are.  I've asked them to tell
> me if they notice any getting large.
> 
> > The question on the table, I think, is what factors lead to the formation
> > of such a cluster, and what design issues should be considered to avoid it?
> 
> Nothing exotic, it's a bunch of drafts with interlinked cross-references. If
> I saw that happening, I'd try and do a topological sort and see if some of
> them can get un-linked, or at least if the linked ones can progress
> together.  The reason C238 gpt so big is that there were drafts in the queue
> that had references to other drafts that weren't done until two years later.
> 
> Regards,
> John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
tte@cs.fau.de