Re: [Chirp] getting started chirpily

Toerless Eckert <> Thu, 23 January 2020 23:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3B63F1200C7 for <>; Thu, 23 Jan 2020 15:13:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZvH9svYxjfyA for <>; Thu, 23 Jan 2020 15:13:41 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 038431200BA for <>; Thu, 23 Jan 2020 15:13:41 -0800 (PST)
Received: from ( [IPv6:2001:638:a000:4134::ffff:52]) by (Postfix) with ESMTP id 90EEB548005; Fri, 24 Jan 2020 00:13:35 +0100 (CET)
Received: by (Postfix, from userid 10463) id 83A4C440059; Fri, 24 Jan 2020 00:13:35 +0100 (CET)
Date: Fri, 24 Jan 2020 00:13:35 +0100
From: Toerless Eckert <>
To: Stephen Farrell <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <>
Subject: Re: [Chirp] getting started chirpily
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "CHallenges for Internet Resilience \(proto-\)Program" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 23 Jan 2020 23:13:42 -0000


I think its obvious from my prior remarks that my primary expertise
and interest would be in resilience related to network layer,
eg: diverse path routing, merging/splitting traffic, exposing
path diversity to forwarding plane and applications so end-to-end
path diversity could become a more comprehensive service,
integrating / expanding protocols like MP-TCP so they could use this
to choose between more throughput or more resilience or with network
coding both.

I think it would be great if we could find cycles to even collect
and document what we have to define a framework, because i think
there is not a single good reference to this type of network service
overall, just a lot of interesting bits and pieces in our world
of specs and a lot more badly published deployment practices in
those operators that already use this.

And of course, it also relates to existing WG in some way:
For example, efforts like DetNet ultimately would also need to have
this service (path diversity), but it hasn't really been subject
of any further review to identify of gaps in our tool chest.
Except that for example IP will not be a sufficient forwarding
plane to do DetNet type PEROF.

There is of course always the problem of cycles folks can spend,
including myself. If i can manage to get some long lingering stuff
off my back soon...  ;-))


On Thu, Jan 23, 2020 at 03:24:48PM +0000, Stephen Farrell wrote:
> Hiya,
> So we currently have 17 subscribers to this list, which
> isn't huge, but maybe that'll be good too:-)
> How's about we get started anyway - I think the first
> thing I'd be interested in knowing is what folks would
> do work on in this space. Once we have a better idea
> of that we can chat about how to go forward. So,
> what'd you suggest? Please reply to this or start a
> new thread on whatever topic you think may be a good
> one for this list...
> In case it helps get the juices flowing, one resilience
> topic where I could see possible improvement relates
> to PKI and, specifically, to letsencrypt. I think LE
> have done a fantastic job with helping https deployment
> (and esp cert renewals) over the last 4ish years, but
> it'd likely be a pretty bad day for the Internet if they
> had to go away for some reason. (There are commercial CAs
> as alternatives, but it'd still be quite a day if LE had
> to cease operations.)
> I don't have any specific protocol suggestions to make
> related to that at the moment (though maybe one could look
> at acme and client implementations to see if they'd fall
> over during a transition period) so for now am mostly
> wondering if there are other fine services (like LE) that
> use IETF developed protocols, on which we're fairly
> dependent, and where the impact of our protocol designs
> in the face of external changes might not be obvious.
> Cheers,
> S.
> PS: I'm not making a claim that the LE issue above is
> the most important or something I think we must examine,
> it's just to try help get people thinking. (And if we
> really were gonna consider that topic, the first thing
> to do might be to chat with acme/LE folks, which I've
> not done:-)

pub   RSA 4096/7B172BEA 2017-12-22 Stephen Farrell (2017) <>
> sub   RSA 4096/36CB8BB6 2017-12-22

> -- 
> Chirp mailing list