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

Toerless Eckert <tte@cs.fau.de> Wed, 22 July 2020 17:09 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 19E6B3A0B5F for <architecture-discuss@ietfa.amsl.com>; Wed, 22 Jul 2020 10:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 toQICO9N3Foq for <architecture-discuss@ietfa.amsl.com>; Wed, 22 Jul 2020 10:09:16 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.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 80DDC3A0B58 for <architecture-discuss@ietf.org>; Wed, 22 Jul 2020 10:09:16 -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 D3752548068; Wed, 22 Jul 2020 19:09:10 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id CDEE5440043; Wed, 22 Jul 2020 19:09:10 +0200 (CEST)
Date: Wed, 22 Jul 2020 19:09:10 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: tom petch <ietfc@btconnect.com>
Cc: John R Levine <johnl@taugh.com>, "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
Message-ID: <20200722170910.GO13675@faui48f.informatik.uni-erlangen.de>
References: <20200722040028.728C81D5EB94@ary.qy> <0355ce38-cb6d-d4da-52e0-6176e529ca5f@gmail.com> <e60ef33-3f73-4e39-c73e-ea107da2b587@taugh.com> <20200722151110.GM13675@faui48f.informatik.uni-erlangen.de> <fb26337f-42e6-6ce-2d92-c0a63936fe31@taugh.com> <AM7PR07MB62487D74D835F1D336FF07D5A0790@AM7PR07MB6248.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <AM7PR07MB62487D74D835F1D336FF07D5A0790@AM7PR07MB6248.eurprd07.prod.outlook.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/8VjDOyS55rL5eFW-wlRl2A7PGok>
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 17:09:19 -0000

Thanks, Tom, inline

On Wed, Jul 22, 2020 at 04:19:17PM +0000, tom petch wrote:
> From: Architecture-discuss <architecture-discuss-bounces@ietf.org> on behalf of John R Levine <johnl@taugh.com>
> Sent: 22 July 2020 16:38
> 
> > 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.
> 
> If we're going to republish RFCs I would rather address the general
> versioning question rather than just this special case.

Maybe use the cluster problem case as a test balloon for generic versioning,
aka: Lets not create a meta clustet, where the initial benefit of solving
the cluster problem has to wait for the last open question on versioning
to be resolved first.

> But for this
> special case, I still think a better route is to push WGs to deal with
> drafts in an order that doesn't produce huge clusters.

I think everybody will tell you that this is not possible in general
than how we deal with it this today. You can not simply re-assign
authors to first help finishing other documents. We are a community
of arbitrary specialization.

> Some of the drafts in C238 were so old that I worry that the world may
> have changed while the drafts snoozed.

Sure, but if this document would not have been pat of a cluster but
been published years ago as standard RFC it could be equally obsolete
now technically. Aka: do not raise requirements of usefulness against
cluster members over those RFCs that are not cluster members.

Heck, i am still trying to find time to go through all the IETF
process to downgrade 1989 IGMPv1 protocol from full standard to eg
historic and upgrade 2002 IGMPv3 to full standard. Aka: if you
wanted to bring in more applicability requirements against clusters
you just worsen the problem.

Cheers
    Toerless

> <tp>
> I have not looked at C238 but I do know of a draft I worked on that is awaiting progress on a Normative Reference which will fail because the world has changed.  This is a cross-WG issue where one WG sets out to provide something useful, others use it and then the something really useful changes in nature and becomes unusable.
> 
> This could happen with YANG common types modules.  Some WG have recognised that types needs several iterations to get right and so have held the types back until at least one using module is ready to advance with it which then reduces the risk.  Others just duplicate the definitions they want which can cause other issues.
> 
> Tom Petch
> 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
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss

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