Subject: [Chirp] getting started chirpily

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Jan 2020 15:24:48 +0000

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:-)

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 24 Jan 2020 00:13:35 +0100

Stephen:

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

Cheers
    Toerless

> to do might be to chat with acme/LE folks, which I've

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

> -- 
> Chirp mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/chirp

-- 
---
[email-masked]