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

Alvaro Retana <> Wed, 28 November 2018 21:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C890613104D for <>; Wed, 28 Nov 2018 13:49:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7rLrsD4gS-8k for <>; Wed, 28 Nov 2018 13:49:50 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 39FFF128A6E for <>; Wed, 28 Nov 2018 13:49:50 -0800 (PST)
Received: by with SMTP id b141so23952155oii.12 for <>; Wed, 28 Nov 2018 13:49:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=v4qmzNPeJ0FucR/GphcnAzOjAdmad0W2kRYT/RMbhTY=; b=fx4reRNUMAApy4KzBtipLWz9FfiepIkfCLuwT4gwyGd4snYTvqAl/hkysL5wyJ9J1+ Tjfop57DW5vLBTQ0sSI3z5DlVp3FG+vI/jjVuUnuJFkX+SGNPif2O5PgTRPqdETrlqyP gdEptMd0n0KTl7Om6TpFWKOCS9jTNnH989dDFG09nYBD8326ebEDlgSxvbCpGTDFm6gy NdNMCA5gyTGITuQ64NaypxmuowQBnNGahaQ4yczsjmUcUBE21jYgaZtXkk6ghW7VtYEY 2egBqNVuXk4DbnazfCy4N+ah3gurP/d8TeWXLx4GXAm1+8spwAUS+ys2qlKcVlhW08+l 9ZqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=v4qmzNPeJ0FucR/GphcnAzOjAdmad0W2kRYT/RMbhTY=; b=OGpwhFtk4DqEsdpz9QHIqYR8rLCjViZNf52wYi4JX2ubFCBMK7DYzvQq+lB7kP0iYD EqoDjeXsgRx9p+axZtA4JZ/WOv8gc1X9GAZFw77U9I0TK5ixW9RoKsgjaCxcEfCQrraD uosV2B15A1/Rbv9wYTUcn5aMAzpOJ6OFJVEtK+JabzklvrrawenK1JGqVCfH+VTwt1C0 A5njb9TpVj73unQnCF+YGpKKLvXv2tmzbFQSD9d4m2XQtzgB/dtkn7hHh4P3JEREP/sr yZMdghYAEVHr3k8v6BKNtKJ/NbcnSs+ssuMmarlhcozhGsrwpk1YmtYUsTy+JUyv4dlu qZkA==
X-Gm-Message-State: AGRZ1gLja9CKfWm2CTTCiSUlCqL9EJQiyKKXaEGkSF+5iGXGJRO6ZVR/ AXlqz80e1Bd4rHCi1/OtWUQ6+et2Bz43GcQe4HQ=
X-Google-Smtp-Source: AJdET5dtAzxLLevSwVxNo4Zzn4gXfnIyTr42/5SdeH76VcH3nPzJOuXUXJFBlQSdPYWjP5nJRvg8nbSQ7xw1rF5+MvA=
X-Received: by 2002:aca:d00a:: with SMTP id h10mr20583076oig.316.1543441789509; Wed, 28 Nov 2018 13:49:49 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Wed, 28 Nov 2018 13:49:48 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
X-Mailer: Airmail (528)
MIME-Version: 1.0
Date: Wed, 28 Nov 2018 13:49:48 -0800
Message-ID: <>
To: Toerless Eckert <>
Cc: IJsbrand Wijnands <>, "Pascal Thubert (pthubert)" <>, "" <>, "" <>, Peter van der Stok <>
Content-Type: multipart/alternative; boundary="0000000000009862dd057bc08b28"
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:49:53 -0000


I am not a fan of publishing stand-alone framework/requirements/use cases.
But as I said before, without knowing the specific contents of the
documents it is not easy to provide a one-size-fits-all answer.

I’m asking early so we don’t end up in the situation you mention below and
we are in sync.  There are many ways to go about documenting the support
material…not all of them end up as RFCs…but also we don’t need to end up in
not publishing something that is needed/important/valuable.

Let’s just keep that in mind going forward…



On November 28, 2018 at 4:39:30 PM, Toerless Eckert ( wrote:

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
> 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 (
> 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