[6lo] Re: [IPv6]WG Last Call on draft-ietf-6lo-path-awar e-semantic-addressing-09

Thanks Luigi.

As for the name, I asked ChatGTP and here's its answer:

**Semantic addressing** refers to a method of organizing, accessing, or retrieving information based on the meaning (semantics) of the content rather than its physical or structural location. It focuses on understanding and using the contextual relationships and meanings of data, often leveraging natural language processing (NLP) or artificial intelligence (AI) techniques.

### Key Features of Semantic Addressing:
1. **Content-Based Access**: Instead of relying on fixed identifiers like file paths or memory addresses, semantic addressing allows data to be accessed based on its meaning, such as keywords, topics, or concepts.
2. **Context Awareness**: It incorporates the context or relationships between pieces of data, making it possible to retrieve related information even if it isn't explicitly linked.
3. **Flexibility**: Data retrieval is less rigid, enabling users or systems to query based on broad or nuanced criteria.
4. **AI and NLP Integration**: It often involves machine learning algorithms, semantic networks, or knowledge graphs to understand and infer meaning from the data.

### Applications of Semantic Addressing:
- **Search Engines**: Delivering results based on user intent rather than exact keyword matches.
- **Knowledge Management**: Organizing and retrieving documents or information in enterprises based on themes or concepts.
- **Artificial Neural Networks**: Using semantic addressing in memory-augmented networks to retrieve relevant patterns or knowledge during computation.
- **Data Integration**: Aligning and accessing heterogeneous data sources in a meaningful way.

In essence, semantic addressing shifts the focus from "where data is stored" to "what the data means," making information systems more intuitive and intelligent.

Regards
    Brian Carpenter

On 17-Dec-24 23:33, Luigi IANNONE wrote:
> Brian, Esko,
> 
> Thanks a lot for your feedback.
> My comments inline.
> 
>> -----Original Message-----
>> From: Esko Dijk <[email protected]>
>> Sent: Monday, 16 December 2024 10:38
>> To: Brian E Carpenter <[email protected]>; [email protected]
>> Cc: [email protected]
>> 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 <[email protected]>
>> Sent: zondag 15 december 2024 02:23
>> To: [email protected]
>> Cc: [email protected]
>> 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
>>> [email protected]
>>> List Info: https://mailman3.ietf.org/mailman3/lists/[email protected]/
>>> --------------------------------------------------------------------
>>
>> _______________________________________________
>> 6lo mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
>> _______________________________________________
>> 6lo mailing list -- [email protected]
>> To unsubscribe send an email to [email protected]
_______________________________________________
6lo mailing list -- [email protected]
To unsubscribe send an email to [email protected]