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

[Toerless Eckert <[e-mail]>]

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, [e-mail], Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
> 
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss

-- 
---
[e-mail]