Subject: Re: [TOOLS-DEVELOPMENT] [Tools-discuss] Server Transition Briefing

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Apr 2020 14:07:02 -0400

Russ Housley <[email-masked]> wrote:
    > Here is a summary of the discussion on the call that took place on
    > March 11th.

Thank you.

    > Q4. What are the next steps toward separation of services to reduce
    > fragility and increase flexibility?

    > It was suggested that the IETF leverage things that are available in the
    > market wherever possible.  That is, avoid building custom software where
    > possible.

    > It was suggested that public cloud services should be used instead of
    > private cloud services.

I think that your notes do not adequately capture this tussle.
I think that Richard Barnes feels quite strongly about this.

I think that many others, while enthusiastic about not duplicating effort,
are concerned about loss of control, in particular, inability to deploy our
specifications early, and to do it properly, rather than "popularily"

    > It was suggested that microservices be explored.  An OpenID Connect or
    > OAuth 2.0 identity provider could be used to enable microservices.  Some
    > things that might be migrated to microservices are the Internet-Draft
    > repository and the Datatracker database.

The submission system... got this today, not for the first time:

obiwan-[ietf/anima/bootstrap](2.6.5) mcr 10066 %make submit
curl -S -F "user=[email-masked]" -F "xml=@ALL-dtbootstrap-anima-keyinfra.xml" https://datatracker.ietf.org/api/submit
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>504 Gateway Timeout</title>
</head><body>
<h1>Gateway Timeout</h1>
<p>The gateway did not receive a timely response
from the upstream server or application.</p>
</body></html>

so I repeat:

obiwan-[ietf/anima/bootstrap](2.6.5) mcr 10067 %make submit
curl -S -F "user=[email-masked]" -F "xml=@ALL-dtbootstrap-anima-keyinfra.xml" https://datatracker.ietf.org/api/submit
Validation Error: {'__all__': ['A submission with same name and revision is currently being processed. <a href="/submit/status/111297/">Check the status here.</a>']}%

I don't know if status.io can help us with this :-(

    > Wrap Up: Was this discussion useful?  If so, how often should we hold a
    > similar discussion?

    > People felt the discussion was useful, and it was suggested that they
    > be held quarterly.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "John Levine" <[email-masked]>
Date: 2 Apr 2020 21:54:49 -0400

>specifications early, and to do it properly, rather than "popularily"

It's more than that, it's also tradeoffs of time and technical risk.
As I recall, we were talking about a commercial monitor service we
could deploy now vs one we might get someone to write later, perhaps
much later.  While I agree that to the extent it makes sense we should
eat our own dogfood, we have limited programming resources and no
reason to believe we can get a lot more people interested in working
on our unusual tools in our unusual environment.  (I have some xml2rfc
files here I'd like to diff.)

When we depend on software where the number of people who know it well
enough to maintain it can be counted on one's thumbs, that's a risk,
and one that I think we need to balance against the risk of using
someone else's less dogfoody commercial package.

R's,
John

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Apr 2020 19:54:31 -0400

> much later.

I don't think that there was much opposition to the proposed monitoring service.
(status.io won't solve all monitoring problems, but it is a good step)

It was more about how monolithic our datatracker is, and why we aren't
leveraging a more distributed architecture that incorporates other systems.
Why we aren't container and kubernetes and cloud-bursting...

    > someone else's less dogfoody commercial package.

I don't know if we have the financial leverage to actually get much.
**We can't even get Webex to dogfood IPv6** but I think that we should
explore what we can get.

---

From: "John R Levine" <[email-masked]>
Date: 7 Apr 2020 20:24:29 -0400

> Why we aren't container and kubernetes and cloud-bursting...

Right.  Some of those are rather trendy, but it's impressive how quickly 
one can spin up docker containers and replicate them to get more 
performance and move them from one place to another and (sometimes) swap 
in new versions of stuff.

> **We can't even get Webex to dogfood IPv6** but I think that we should

Much though I love the IETF, we are not a big enough customer to make 
vendors do something different.  We might have some effect via moral 
persuasion ("standards!  auditability! open source!") but that's 
different.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Michael Richardson <[email-masked]>
Date: Wed, 08 Apr 2020 17:01:05 -0400

<#secure method=pgpmime mode=sign>

    > I think that Richard Barnes feels quite strongly about this.

To connect my incomplete dots better...

    > The submission system... got this today, not for the first time:

...

    > from the upstream server or application.</p>

I think that a place where we could benefit from public scalable cloud is the
submission and API (sub-)system(s).
There are a bunch of different ways that this could be done.

I wonder if, with the stretch out of the virtual meetings if the average DT
usage is higher in general, and if the number of IDs submitted per day is
also higher.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [