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 <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet