Closed oscargdd closed 5 months ago
2023-05-17 Network Inventory weekly call
It was clarified the issue applies to the identification of the network element and not to the identification of the components
Using the node-id, which is an URI, allows also using UUID to identify NEs but allows other types of identification
Chaode has raised concerns with using the node-id to correlate a node in the topology model with a NE in the inventory model in case of multi-layer NE
Need to continue the discussion next week
2023-06-14 Network Inventory weekly call
It was clarified the issue applies to the identification of the network element and not to the identification of the components
Using the node-id, which is an URI, allows also using UUID to identifiy NEs but allows other types of identification
Chaode has raised concerns with using the node-id to correlate a node in the topology model with a NE in the inventory model in case of multi-layer NE
Need to continue the discussiong it
It has been clarified that the URI used for ne-id is not correlated with the node-id in the topology model: the navigation between the inventory and the topology view can be done using the ietf-hw-inventory-ref-topo model
Agreement to change the key for the network-element list to be an URI rather than a UUID
2024-01-17 Network Inventory weekly call
The list keys used to be UUID in the CCAMP WG draft but the ne-id and component-id have been defined as string, with the plan to re-discuss their types at a later stage
Jan: strings are hard to interpret but keys are intended just to identify something so they do not need to be interpreted
Agreed to keep the ne-id and component-id as string to keep the model very flexible (URI and UUID are also strings)
RFC 8345 uses node-id for the indexing of the nodes. It would be better to have the same convention. Either reuse the node-id type, or use inet:uri. This way it is not restricted to the use of uuids.