Brian, Esko, Thanks a lot for your feedback. My comments inline.
> -----Original Message----- > From: Esko Dijk <esko.d...@iotconsultancy.nl> > Sent: Monday, 16 December 2024 10:38 > To: Brian E Carpenter <brian.e.carpen...@gmail.com>; 6lo@ietf.org > Cc: i...@ietf.org > Subject: [6lo] Re: [IPv6]WG Last Call on draft-ietf-6lo-path-aware-semantic- > addressing-09 > > > This is not semantic addressing in any way > I don't have a background on this term. If one considers it as "embedding > information into an IPv6 address", then it seems ok: there's information > embedded in the address about the position of a node in the network > topology. So no strong opinion on the term. > [LI] The original naming comes from the fact that we are adding a different semantic to the addresses, namely the path awareness. Personally I think the name is correct. "Path-aware Structured Addressing" is also meaningful IMO. I wonder whether is worth to change the name.... > > Path-Aware Static Addressing > > Path-Aware Systematic Addressing > > Path-Aware Synthetic Addressing > > If we need to avoid 'semantic' then maybe also: > > Path-Aware Structured Addressing > Path-Aware Spatial Addressing > > > But they do move (...). > > ... There should be a change management process, but there will always be > change. > > ... So the use cases are not truly *static*; they change from time to > > time > > Agree here. Also for the "smart home" scenario devices can get relocated. [LI] In the beginning we wanted to make clear that this solution is not meant for deployments with dynamic topologies. But may be we went to far .... 😉 I agree that we can clarify that "static" does not mean never ever changing.... > > > but I believe the draft lacks an important section on what happens when a > node *leaves* the network (how does the address get reclaimed?) and > when a node *moves* (how does the node know that it has moved, so that > it can release its old address and acquire a new one?). > > Agree also - even though the topology is largely static over the lifetime of a > system (for use cases in which PASA gets applied), there can still be changes. > A new subsection 6.X could describe maybe how changes are handled - > when/if they occur? > Some cases are: > - Child node gets removed (e.g. broken, or to insert it elsewhere = move) > - Router node gets removed/replaced - new Router might get a different > address - all devices in the tree under it get a new address. > - Node is moved (maybe it reboots, maybe it retains its power due to > whatever reason e.g. battery-backup and it still has its old state at the > moment it detects reattachment of its interface again) > - Root gets replaced (address doesn't change, but maybe it needs to run > PASA again to build its state, and all devices would get the same address > again?) > - ... > > The document could also declare such change cases as out of scope, but it > seems more useful to describe how PASA handles these cases (to me it > seems well able to handle these) and the impact of it (e.g. IP address > changes). > > There are some more indirect consequences of IP address change from the > application point of view (e.g. my cached address of a peer suddenly isn't > valid anymore and I need to rediscover its address) but many of those are > not exclusive to PASA, so these can be out of scope mostly. > E.g. a discovery method like unicast DNS-SD or CoRE-RD may be used to > rediscover the IP address of a particular host. > > One PASA-specific item that could be added to the Security Considerations is > the following: due to the address structure, it's likely that 1 or more > addresses get "re-used" in case of node changes like listed above. > That is, node 1 could be sending data to IP of node 2 which due to changes > now suddenly arrives at new node 3. In some other address assignment > methods like SLAAC, you would detect this situation due to an ICMPv6 error > on the destination not being reachable, which in turn triggers an IP address > rediscovery. > However with PASA you can't necessarily rely on the ICMPv6 error -- a > new/other node may be re-using that address. Not a show-stopper for > PASA, but something an adopter needs to be made aware of! (Even though > it should be obvious already for some readers.) [LI] Thanks a lot for these suggestions. We can clarify and add these points in a new revision of the document. Ciao L. > > Regards > Esko > > > -----Original Message----- > From: Brian E Carpenter <brian.e.carpen...@gmail.com> > Sent: zondag 15 december 2024 02:23 > To: 6lo@ietf.org > Cc: i...@ietf.org > Subject: [6lo] Re: [IPv6]WG Last Call on draft-ietf-6lo-path-aware-semantic- > addressing-09 > > Hi, > > Thanks for the chance to comment. > > Firstly, *please* do not use the word "semantic". This is not semantic > addressing in any way. It's a topological addressing scheme, and that's a good > idea. (Semantic addressing is a bad idea that wastes address bits. From the > title, I was expecting to hate this document.) > > If you like the PASA acronym, try: > > Path-Aware Static Addressing > Path-Aware Systematic Addressing > Path-Aware Synthetic Addressing > > (Or change the acronym to PATA: Path-Aware Topological Addressing.) > > I realise this affects several drafts, but IMHO "semantic" is just very > misleading. > > Some comments about use cases. It is stated that: > > > The PASA solution utilizes stable and static topology information... > > I think this over-simplifies the real world. Consider for example: > > > The smart grid power distribution network forms a typical tree topology... > > That's true (although it might be complicated by grid-tied solar generation.) > But that doesn't mean the topology is static - customers can be added or > disconnected at any time. Similarly, topology changes within a home can > happen (new appliance, new power outlet, etc.): > > > The Home Gateway, the PLC routers, and most of the home appliance > > are fixed in different locations. They rarely move after setup. > > But they do move (in my experience, they can move because of buying new > furniture, or for even smaller reasons). > > Similar comments apply to the data center monitoring use case; in a large DC > there will be changes every day. The same is true of industrial networks. > There should be a change management process, but there will always be > change. > > So the use cases are not truly *static*; they change from time to time. I can > see that the draft covers the case of a node *joining* the network, but I > believe the draft lacks an important section on what happens when a node > *leaves* the network (how does the address get reclaimed?) and when a > node *moves* (how does the node know that it has moved, so that it can > release its old address and acquire a new one?). > > Nits: > > > 4.2. Smart Home > > > > Smart home or home domotica > > "Domotica" is not an English word. It appears to be a trade name of some > kind. > > > The address assignment described in this document relies on the > > Generic Address Assignment mechanism described in > > [I-D.iannone-6lo-nd-gaao] > > Obsolete draft name. Should be draft-ietf-6lo-nd-gaao > > Regards > Brian Carpenter (not on the 6lo list) > > On 09-Dec-24 22:28, Shwetha wrote: > > Dear 6lo WG, > > (CC'ing 6man.) > > > > This message initiates WG Last Call on the following document: > > > > "Path-Aware Semantic Addressing (PASA) for Low power and Lossy > Networks" > > https://datatracker.ietf.org/doc/html/draft-ietf-6lo-path-aware-semant > > ic-addressing-09 > > <https://datatracker.ietf.org/doc/html/draft-ietf-6lo-path-aware-seman > > tic-addressing-09> > > > > This last call will end on Monday, 23rd of December. > > Please provide your feedback on this document on the mailing list. > > > > Thanks, > > Carles and Shwetha > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > i...@ietf.org > > List Info: https://mailman3.ietf.org/mailman3/lists/i...@ietf.org/ > > -------------------------------------------------------------------- > > _______________________________________________ > 6lo mailing list -- 6lo@ietf.org > To unsubscribe send an email to 6lo-le...@ietf.org > _______________________________________________ > 6lo mailing list -- 6lo@ietf.org > To unsubscribe send an email to 6lo-le...@ietf.org _______________________________________________ 6lo mailing list -- 6lo@ietf.org To unsubscribe send an email to 6lo-le...@ietf.org
