Hi,
I do agree with Pascal and Michael (details inline), the document is supposed to be modified and improved after WG adoption, this is not WGLC. Ciao L. -----Original Message----- From: 6lo <6lo-boun...@ietf.org> On Behalf Of Pascal Thubert (pthubert) Sent: Thursday, 9 February 2023 09:32 To: Michael Richardson <mcr+i...@sandelman.ca>; Kerry Lynn <kerlyn=40ieee....@dmarc.ietf.org> Cc: carles.go...@upc.edu; 6lo@ietf.org Subject: Re: [6lo] Call for WG adoption of draft-li-6lo-path-aware-semantic-addressing-01 Hi Kerry and Michael > Kerry Lynn > <kerlyn=40ieee....@dmarc.ietf.org<mailto:kerlyn=40ieee....@dmarc.ietf.org>> > wrote: > > My main reason is that the draft has no Security Considerations > section, > > and I am not sure the > > scheme can be made secure. I believe the WG should always > consider the > > I don't think that the lack of a SC section is a reason not to adopt. > (They are *drafts* and do not need to be complete. This is not WGLC) > > If you think that the scheme can never be secured, then that would be > different. Yes, this is WG adoption not IETF last call. For the use cases I have in mind, this scheme is actually a lot safer than more dynamic stuff. [LI] The security consideration part is one of the unfinished section of the document, but: - since this is a WG adoption call we do not need it finalized now. - This proposal IMO does not introduce any new security threat. We will continue work with 6lo participant to provide a complete and fair security considerations section. > > > Second, the fact that routing is based on addressing makes me wonder > > whether this effort > > would encroach on Routing Area's charter. > > I don't think that they want it. There's no routing. Think of a network that's an array or a matrix of sensors, hard wired, like a ccd. Say you want to reach each sensor in the ccd with IPv6/6LoWPAN. You could index them x, y, and encode x, y in an IP address so the addressing is automatic and predictable. No need of ND, all usable addresses known in advance so you can block a number of well-known attacks. Now, say that instead of being organized as an array, the sensors are organized as an hard wired tree (possibly with redundancy depending on the application). Just like you may be doing with a few switches at home today, no meshing, no need for STP. Should that make a difference? Couldn't we automatically and predictably assign an address to each of these sensors? The application I have in mind uses hard wired devices and switches and everything is done at L2. There's a L2 form of L2 learning that feels like transparent bridging. It's over complicated for the need, and prone to bugs. With the proposed scheme, the address embeds the structure of the last hop which can be more complex than x or x,y and still as predictable. From the IP perspective it's still one hop, no routing. [LI] Nice example :-) > > > Third, one potential application that has been suggested is low-cost > > sensors in server racks, > > yet I have seen no suggested wired MAC for this application. RFC 8163 > > covers this base. [LI] I do not see the need to define a specific MAC, the solution is general in the proposed scope. RFC 8163 is one possible solution for one specific scenario and this document does not claim that it should be deployed everywhere or replace anything existing. As a lot of other technologies it offers an alternative (for specific use cases). > > I don't buy this solution either, btw. You need a good use case for that I guess. Once the WG owns the draft, we can improve the encoding and possibly extend it to more classical physical structure. Note that x and x,y are very simple trees and already supported. [LI] Looks like a good plan :-) All the best Pascal > -- > Michael Richardson <mcr+i...@sandelman.ca<mailto:mcr+i...@sandelman.ca>>, > Sandelman Software Works > -= IPv6 IoT consulting =- > > _______________________________________________ 6lo mailing list 6lo@ietf.org<mailto:6lo@ietf.org> https://www.ietf.org/mailman/listinfo/6lo
_______________________________________________ 6lo mailing list 6lo@ietf.org https://www.ietf.org/mailman/listinfo/6lo
