Subject: a brief pondering

From: Eliot Lear <[email-masked]>
Date: Sat, 21 Mar 2020 11:12:59 +0100

We’re all obviously in serious situation.  I hope this message finds you
all ok.  Health workers are on the front line of all of this.  We in
Switzerland took a minute out of our days yesterday to applaud them.
 And we’ll do so again and again, as well as those who can't work from home.

In the midst of all of this, I want to point out that the work of the IT
industry over the last fifty years has led to our ability to physically
distance from one another while still being able to see, hear, and
interact with our friends and loved ones.  This organization has had a
lot to do with that, building a stack that, while certainly not perfect,
seems to be up to the task in this crisis. I’m quite grateful to this
group (amongst others) that we have the technology to know how my loved
ones are, and today, my wife and daughter get to go to a virtual baby
shower.  Pretty cool.

Eliot

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 21 Mar 2020 15:54:05 +0000

+1 to this sentiment, Eliot! I find it humbling that the work of this and other parts of the tech community over decades have built something so amazing that it is helping the world sustain itself & communicate. It is wonderful for each of us to have played a small role in that.

Which leads me to a question: what can this community (and similar/adjacent ones) do productively together to help? What new things are happening on the network from which we can learn and quickly adapt/improve?

Jason

On 3/21/20, 6:14 AM, "ietf on behalf of Eliot Lear" <[email-masked] on behalf of [email-masked]> wrote:

    Eliot

---

From: Narelle Clark <[email-masked]>
Date: Sun, 22 Mar 2020 15:06:44 +1100

On Sun, 22 Mar 2020 at 02:55, Livingood, Jason
<[email-masked]> wrote:
>
> Which leads me to a question: what can this community (and similar/adjacent ones) do
> productively together to help? What new things are happening on the network from
> which we can learn and quickly adapt/improve?

We can keep the internet running. That's what I'm being told to do!!

And we're onto it.

Narelle

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Mar 2020 06:45:11 +0100

On 2020-03-21, at 16:54, Livingood, Jason <[email-masked]> wrote:
> 
> what can this community (and similar/adjacent ones) do productively together to help

The one thing that would be most useful for me right now would be a document with operational considerations for keeping WebRTC running (e.g., How not to mess it up with your firewall).

Grüße, Carsten

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 22 Mar 2020 11:21:15 +0100

> On 22. Mar 2020, at 06:45, Carsten Bormann <[email-masked]> wrote:
> 
Would that be another candidate for C238?

Best regards und alles Gute
Michael

---

From: Nick Hilliard <[email-masked]>
Date: Sun, 22 Mar 2020 12:40:33 +0000

> We can keep the internet running. That's what I'm being told to do!!

this is going to become an increasingly interesting proposition now that 
factories have been told to shut down:

> https://www.politico.eu/article/italy-closes-all-nonessential-factories-to-halt-spread-of-coronavirus-giuseppe-conte/

> "We decided to take a further step. The government decided to close
> on the whole national territory all productive activities which are
> not strictly necessary, crucial, indispensable to ensure essential
> goods and services," Conte said.
... and data centres have begun to block customers from entry:

> https://www.equinix.com/lp/equinix-coronavirus-statement-to-customers-and-partners/

> All IBX facilities are operational at this time. IBX locations in
> France, Germany, Italy and Spain are under restricted access,
> effective Monday, March 23 at 8:00am CET until further notice,
> meaning visitors, customers, customer contractors and non-critical
> Equinix vendors will not be permitted to enter the IBX facilities.

("IBX" is marketing nonsense for "data centre")

This is going to great, until we end up with a train crash.

Is a WDM components manufacturer strictly necessary, or crucial or 
indispensible?  What about the screw fitting manufacturer that they 
depend on? Or the plastics production manufacturer for the equipment 
casing or packaging?  Or the tyre sales shop for when the delivery van 
has a puncture?

What happens when one bit of the supply chain fails and all of a sudden 
you have major kit failure and then a large geographic area loses 
connectivity, and the medical referral and treatment system falls over 
because they depended on communications which was supposed to work?

Society is now actively threatening the supply of nails and this is 
putting us at risk of losing the kingdom.

There is an extraordinarily complex supply chain interdependency for 
almost everything, ranging from food to medical supplies to 
communications. You can't arbitrarily block or close down bits of this 
and expect other parts to work, any more than you can expect to remove 
large chunks out of a jenga pile and expect it not to break, badly.

Nick

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 22 Mar 2020 14:51:05 +0100

> Would that be another candidate for C238?

Not sure that it needs to get stuck there, but yes, it might be a useful part of that suite of documents.  A lot of people here have been in the trenches long enough that they know deeply what breaks WebRTC in a firewall, and it would be a useful operational-area exercise to extract that knowledge and make it presentable (and RFP-referenceable!) to firewall builders and maintainers.

Grüße, Carsten

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 22 Mar 2020 16:55:27 -0500

On Sun, Mar 22, 2020 at 8:52 AM Carsten Bormann <[email-masked]> wrote:

> >> The one thing that would be most useful for me right now would be a
> document with operational considerations for keeping WebRTC running (e.g.,
> How not to mess it up with your firewall).
> Not sure that it needs to get stuck there, but yes, it might be a useful
> part of that suite of documents.  A lot of people here have been in the
> trenches long enough that they know deeply what breaks WebRTC in a
> firewall, and it would be a useful operational-area exercise to extract
> that knowledge and make it presentable (and RFP-referenceable!) to firewall
> builders and maintainers.
>

I was hoping Michael was kidding, but since he's not ...

As much as I enjoyed some getting some TSVWG doc unstuck from C238, someday
that cluster needs to finally empty out,

On a related note, I wonder if this document would be a candidate for MOPS?

Best,

Spencer

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 22 Mar 2020 23:16:53 +0100

> On 22. Mar 2020, at 22:55, Spencer Dawkins at IETF <[email-masked]> wrote:
> 
> 
> 
Michael was. But Carsten took is seriously. I would like to see such a document, but don't keep it
in the RFC editor queue for a long time...

Best regards
Michael
> 
> As much as I enjoyed some getting some TSVWG doc unstuck from C238, someday that cluster needs to finally empty out, 
>

---

From: Adam Roach <[email-masked]>
Date: Sun, 22 Mar 2020 22:21:58 -0500

> The one thing that would be most useful for me right now would be a document with operational considerations for keeping WebRTC running (e.g., How not to mess it up with your firewall).

See RFC 4787.

/a

---

From: Adam Roach <[email-masked]>
Date: Sun, 22 Mar 2020 22:23:31 -0500

On 3/22/2020 4:55 PM, Spencer Dawkins at IETF wrote:
> As much as I enjoyed some getting some TSVWG doc unstuck from C238, 
> someday that cluster needs to finally empty out,

All cluster 238 documents are in the RFC Editor queue. There's no 
conventional way that you could create a normative dependency on any one 
of them to a new document, and that's the only way that a document could 
get added to the cluster.

/a

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 23 Mar 2020 10:23:33 +0100

If you operate a firewall, let UDP through when the first packet comes 
from inside.

If you run a service, make sure you have plenty of TURN capacity.

If you write documents, do NOT join them into C238 :-)

---

From: Michael Richardson <[email-masked]>
Date: Mon, 23 Mar 2020 17:08:20 -0400

> We can keep the internet running. That's what I'm being told to do!!

And there is more: people are now noticing when jitter and bufferbloat
actually matter, and ability to send A/V directly from end to end point
really does matter.

I just wish that more of the tools/platforms were:
1) supporting IPv6
2) providing better diagnostics as to what path a particular speaker was using.
3) am I having a problem transmitting, or are they having a problem receiving?

I think that we will see a direct relationship between using IPv6, and
seamless/trouble-free communications.

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

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Mar 2020 17:50:17 -0400

At the meta level, now would be a really good time for IETF to announce
what we would like ISPs to deliver as the base connection for fast,
reliable work at home:

* IPv6 with a block of at least 256 addresses available to the customer.
* Support port forwarding.
* etc.

Applications really should be connecting peer-to-peer for two party
communications. A reflector becomes pretty much inevitable for n>2 of
course.

On the usability side, something that is really pissing me off is having to
search through multiple menus to find out what the call sign for a user is
on various apps. By call sign, I mean 'that which I type in to connect to
someone not in the contacts directory'.

Don't expect me to 'remember' because I am having to fix this for someone
else. Alternatively, it may be six months since I last used the app. And
no, it is not obviously their email address (many people have six or more)
or their phone number (again, they can have multiple).

There is a school of 'usability' where the user is insulated from the
information they actually need to perform their task lest it confuse them.
The dirty secret of usability engineering is that most of the focus is on
hyper-optimizing the experience for the first fifteen minutes of use. That
is the average length of a demo before a sale.

A related problem is working out where to enter the call sign.

---

From: Narelle Clark <[email-masked]>
Date: Tue, 24 Mar 2020 09:36:44 +1100

All very nice things but right now most of us are making sure a) we have
enough bandwidth and b) troubleshoot customer remote access issues.

Narelle

On Tue, 24 Mar. 2020, 8:50 am Phillip Hallam-Baker, <[email-masked]>
wrote:

> On the usability side, something that is really pissing me off is having
> to search through multiple menus to find out what the call sign for a user
> is on various apps. By call sign, I mean 'that which I type in to connect
> to someone not in the contacts directory'.
>

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 24 Mar 2020 07:06:31 +0100

The equinix web page goes on to say:

> Our on-site IBX staff will continue to serve all customers through the
> execution of tickets of Smart Hands, Trouble, Cross Connects, and
> Inbound/Outbound Shipments. However, we ask that customers try to limit
> their requests to critical work only.
>
> For business-critical requests that would normally entail a customer
> site visit, we will evaluate fee waivers for our Smart Hands service on
> a case-by-case basis

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 24 Mar 2020 13:08:19 +0000

>> site visit, we will evaluate fee waivers for our Smart Hands service on

You can operate a point of presence in lights out mode, but it needs to 
be set up to do so and maintained in that state.  If your installation 
depends on local maintenance, it takes time, effort and expense to get 
it to the point that you can successfully run it remotely.

The difficulty of imposing a customer exclusion policy like this is that 
it creates additional systemic fragility at a time when systemic 
fragility is the number one thing that we need not to happen.

Nick