Re: [Roll-bier-dt] Fwd: Bier interim in January

Toerless Eckert <> Wed, 28 November 2018 21:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97464131045 for <>; Wed, 28 Nov 2018 13:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JtfjkEwFAgoX for <>; Wed, 28 Nov 2018 13:39:34 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2A3B413104A for <>; Wed, 28 Nov 2018 13:39:32 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 88617548740; Wed, 28 Nov 2018 22:39:27 +0100 (CET)
Received: by (Postfix, from userid 10463) id 79562440210; Wed, 28 Nov 2018 22:39:27 +0100 (CET)
Date: Wed, 28 Nov 2018 22:39:27 +0100
From: Toerless Eckert <>
To: Alvaro Retana <>
Cc: "" <>, Peter van der Stok <>, "Pascal Thubert (pthubert)" <>, IJsbrand Wijnands <>, "" <>
Message-ID: <>
References: <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Roll-bier-dt] Fwd: Bier interim in January
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "ROLL WG Design Team for bitstring addressing. See" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Nov 2018 21:39:39 -0000

sorry i this is a rant, but your email reads a bit
like pushing one of my buttons where i am somewhat sensitive.

In anima i had to live through the ADs asking just to have specs
to implement, only that later on in WG and IESG review more
and more questiosn where asked for the sepcs to become more
explanational by reviewers because they didn't understand thre
functionality just from the specification part and so we ended
up with humunguous spec drafts because we where asked not to
publish arch documents.

I don't think we need to sequentialize explaining the framework
and working on the specification of its components. Ideally,
we can start with just enough of an outline of a framework so
that we can agree on the resulting component specifications and
start those quickly.Wwe continue to add explanations to the component
framework doc while we are working on the specs, therefore allowing
to keep the specs crisp but also have a vehicle to deliver better

To also give my  classic reference: I would have never understood
RFC2362 and its revisions of the followind decades if there wouldn't
have been draft-ietf-idmr-pim-arch, and i think its a big failure of
the IETF to not have published that as an RFC. But then again, i
was back then not in the role of the three author/implementers of
the PIM-SM spec, but in the role of an operator of PIM-SM.


On Wed, Nov 28, 2018 at 12:00:10PM -0800, Alvaro Retana wrote:
> Just a high-level comment/question???. Off topic...
> I???m hoping that "to set the stage for the set of required followup
> documents specifying the solution??? means that the informational document(s)
> will most likely serve their purpose as inspiration for the solution
> only???and not be published as RFCs.  Is that the intent?  Or is the intent
> to publish that as requirements, framework, or whatever-else RFCs???and
> *later* work on solutions?
> I realize that without knowing the specific content of those document it
> may be hard to provide a definite answer???so I???m just looking for intent at
> this point.
> Thanks!
> Alvaro.
> On November 28, 2018 at 11:25:19 AM, Toerless Eckert ( wrote:
> a) Lets first determine what the next step is in the documents for
> roll-bier that we want to achieve by IETF104.
> Ines was suggesting that we should consider a high-level overview
> draft, for example reformatting into draft form what we had worked
> out in slides and the etherpad in the design team. Primarily goal
> would be to set the stage for the set of required followup documents
> specifying the solution.
> I could take a stab at that, but maybe good parts of this should come
> fro pascals document, e.g.: splitting up the informational parts from
> the normative parts and extending on the informational ones .. ?
> And then fesible next steps for the drafts specifying the solution.
> Right now the primary documents existing are the one from pascal
> and carsten, so i would like their input for how they could see
> those documents evolve until 104.
> Please chime in if this is the right goal, and if so, what it should
> entail.

> _______________________________________________
> Roll-bier-dt mailing list