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

Toerless Eckert <tte@cs.fau.de> Wed, 28 November 2018 21:55 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: roll-bier-dt@ietfa.amsl.com
Delivered-To: roll-bier-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DBC213104D for <roll-bier-dt@ietfa.amsl.com>; Wed, 28 Nov 2018 13:55:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o16QsxfcTR4g for <roll-bier-dt@ietfa.amsl.com>; Wed, 28 Nov 2018 13:54:59 -0800 (PST)
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 4AAAE130F8E for <roll-bier-dt@ietf.org>; Wed, 28 Nov 2018 13:54:59 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 05D8754810F; Wed, 28 Nov 2018 22:54:55 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EDB13440210; Wed, 28 Nov 2018 22:54:54 +0100 (CET)
Date: Wed, 28 Nov 2018 22:54:54 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: IJsbrand Wijnands <ice@cisco.com>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>, "roll-bier-dt@ietf.org" <roll-bier-dt@ietf.org>, Peter van der Stok <stokcons@bbhmail.nl>
Message-ID: <20181128215454.6e7armzhym7o6iji@faui48f.informatik.uni-erlangen.de>
References: <012c8d11cfcfcddb9f49bc74ed9dad0b@bbhmail.nl> <CAMMESswx2KCzmpO8Tyc0SerZ3aXPUatCDUZwQYN5JY-VgkF=5w@mail.gmail.com> <20181113093018.t7ucy5lgk7h62orq@faui48f.informatik.uni-erlangen.de> <4eab6824d2ad45cc829794cab687f6cc@XCH-RCD-001.cisco.com> <34EF1690-6B32-4844-969A-A8C87FB0A9CF@cisco.com> <20181128162515.jge5c6gnozfuwsdg@faui48f.informatik.uni-erlangen.de> <20181128162515.jge5c6gnozfuwsdg@faui48f.informatik.uni-erlangen.de> <CAMMESswZFrGExNXqbVNCAYDVTBQ5OGxtNjeNJ_3YSv1RA=Rz0w@mail.gmail.com> <20181128213927.cjtiz5hifj2qkcjp@faui48f.informatik.uni-erlangen.de> <CAMMESsw5MJntvPqysMsdqnU2vjdH7OP3RMooGN9_acYS+bDPcQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMMESsw5MJntvPqysMsdqnU2vjdH7OP3RMooGN9_acYS+bDPcQ@mail.gmail.com>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll-bier-dt/C--3y4u_BBdOAlM8jQov8tihWBE>
Subject: Re: [Roll-bier-dt] Fwd: Bier interim in January
X-BeenThere: roll-bier-dt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "ROLL WG Design Team for bitstring addressing. See https://trac.ietf.org/trac/roll/wiki/roll-bier-dt" <roll-bier-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll-bier-dt>, <mailto:roll-bier-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll-bier-dt/>
List-Post: <mailto:roll-bier-dt@ietf.org>
List-Help: <mailto:roll-bier-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll-bier-dt>, <mailto:roll-bier-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2018 21:55:02 -0000

On Wed, Nov 28, 2018 at 01:49:48PM -0800, Alvaro Retana wrote:
> Toerless:
> 
> I am not a fan of publishing stand-alone framework/requirements/use cases.

I hope my explanation made it clear that this should not be the goal.
If you think that how i outlined it makes sense, let me know, or how
you think it should be changed. Overall i just think there is limited
interest to work on things not getting published as RFCs.

> 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 think what we need should be similar to what we have in some of the
explanations in Pascals document and the IETF103 slides i did.

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

See above. I would like not do do throwaway work, and you let me know
if you think if drafts not becoming RFC are throwaway. If you don't
think they are, then please tell me who still knows
draft-ietf-idmr-pim-arch

> Let???s just keep that in mind going forward???

Sure
 
Cheers
    Toerless
> 
> Thanks!
> 
> Alvaro.
> 
> On November 28, 2018 at 4:39:30 PM, Toerless Eckert (tte@cs.fau.de) 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
> explanations.
> 
> 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.
> 
> Cheers
> Toerless
> 
> 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 (tte@cs.fau.de)
> 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
> > Roll-bier-dt@ietf.org
> > https://www.ietf.org/mailman/listinfo/roll-bier-dt
> 
> 
> -- 
> ---
> tte@cs.fau.de

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