[homenet] summary of Gateway 2 Gateway side meeting

[Michael Richardson <[e-mail]>]

On Tuesday 2022-07-26, six local people and three remote attendees got
together to talk about the Gateway to Gateway communication situation.
The remote participant access was probably very poor, but that's the
situation today for side meetings.

After some introductions, the slides from Wei were opened and the group
started to walk through them.

{ the slides and background document
https://github.com/mcr/building-local-emergency-comms/blob/main/presentations/Gateway-To-Gateway-Communication-sidemeeting.pdf
  https://www.ietf.org/archive/id/draft-richardson-snac-building-use-case-00.html }


There were numerous clarifying questions such as:

1) what kind of connectivity is really needed?
2) do devices talk to their own gateways only?  Do they talk to other gateways?
3) do devices talk to other devices?
4) how is the security context setup for his communication?

There was a general pessimism that a routing protocol like OSPFv3 would do a good job.

There was a fair bit of discussion about what are the road blocks to a
converged network like this.  It was felt that there were significant
regulatory roadblocks, and it would be quite difficult to get those
regulations changed.  An answer to this was: yes, that's true, but what kind
of network can be we build that might begin to satisfy the regulator?

Could such a network be deployed for non-emergency systems (or non-emergency
uses) and then, based upon the observed performance of such a network
(perhaps including fire drills), would a regulator begin to see this as
reasonable?

(As an aside: what are the cost savings of such a converged network?  There
could be direct savings in terms of wiring and maintenance, but also indirect
savings through new opportunities enabled)

There was no opinion about RPL/RFC6550, as there was not enough familiarity
with it.

A question arose: in emergencies, do we even need bi-directional
communications?

If communications is based upon Object Security (COSE not DTLS/OSCORE), then
could it all be done via an Information Centric Networking paradigm?  In such
a thing, actuators are not connected to sensors by pre-configuration, but
rather actuators observe outputs from sensors (which may be multicast), and
when some set of conditions occurs, the actuator does something.

There was general agreement that ICN could be a very interesting direction to
take.

It would take onboarding of all devices so that they had an appropriate
credential that could be validated against a (set of) trust anchors.

Also, because ICN does not involve making active (in the TCP sense)
connections to the sensors, it means that there is no inherent trust that
must be created in the sensors in order for them to communicate: they simply
announce their state and allow the network to do its thing.

At this point, the time ran out and the group walked to the social event at
the museum.


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide