> Le 8 août 2022 à 17:00, Michael Richardson <mcr+i...@sandelman.ca> a écrit :
>
>
> 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
> }
> Thanks for reporting this. > > 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. I’m getting concerned that we are trying to boil the ocean. We should reduce the scope of this work to what is achievable. The proponents seemed to suggest a more narrow use case. My 2 cents Marc > > 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 > > > > > -- > Snac mailing list > s...@ietf.org > https://www.ietf.org/mailman/listinfo/snac
signature.asc
Description: Binary data
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
