search

ietf-ivy-wg / network-inventory-yang

Other
0 stars 3 forks source link

Refine NE assembly-id attribute #33

Closed italobusi closed 2 months ago

italobusi commented 5 months ago

Refine the name and description of the assembly-id attribute for the NE

YuChaode commented 5 months ago

For part-number, it is really not needed for NE. And for assembly-id, i am wandering whether we need this id or not. Currently we have ne-id, uuid, asset-id and URI defined in the current model, i think it is sufficient for NE. And for this terminology of assembly-id, there is not a common understanding in transport industry. so i propose to remove part-number instead of refining it to assembly-id, and use the product-name attribute of current module to provide this assembly-id information?

lana-wu commented 5 months ago

I think "assembly-id" is confusing. I suggest that "model-name" in RFC 8348 be reused.

italobusi commented 4 months ago

I am ok with "model-name" but I am also wondering what would be the difference between "model-name" and "product-name" ...

IMHO, we have two options:

  1. remove the "assembly-id" attribute and keep the "product-name" attribute
  2. remove both the "product-name" and "assembly-id" attributes and add a new "model-name" attribute

I have a slight preference for option 1 but I can live with option 2 as well

lana-wu commented 4 months ago

It seems to me that "asset-id" is user-assigned tracking identifier for a component, or NE, or a rack , but "product-name" is vendor-specific? I think "asset-id" and "product-name" are not equivalent. Instead of "assembly-id", my suggestion is for "product-name".

dieterbeller commented 4 months ago

It is still unclear to me what the NE assembly-id attribute should reflect. Is the meaning an assembly or shelf kit composed of the NE's main shelf and several necessary HW entities? If so, the assembly or shelf kit should be modeled like any other HW component and should have a least a part number and an optional name as it is an order-able item. Or, is it the intention to model the inventory data of all these components forming the assembly or shelf kit as separate items with their component specific inventory data?

italobusi commented 4 months ago

It seems to me that "asset-id" is user-assigned tracking identifier for a component, or NE, or a rack , but "product-name" is vendor-specific? I think "asset-id" and "product-name" are not equivalent. Instead of "assembly-id", my suggestion is for "product-name".

Sorry, I made a confusion between "asset-id" and "assembly-id" :(

I have amended my comment as:

IMHO, we have two options:

  1. remove the "assembly-id" attribute and keep the "product-name" attribute
  2. remove both the "product-name" and "assembly-id" attributes and add a new "model-name" attribute

I have a slight preference for option 1 but I can live with option 2 as well

Therefore, I agree with you to use "product-name" instead of "assembly-id"

I also agree with you that the "asset-id" is a user-assigned identifier (as indicated in the current I-D) and that it applies to both components and NEs.

However, I have noted that the "asset-id" for the NE is currently missing: I have #36 to track this issue

italobusi commented 4 months ago

Following the same proposal in https://github.com/ietf-ivy-wg/network-inventory-yang/issues/15#issuecomment-1955249852, for the NE we can remove part-number/assembly-id and define:

  product-name as the “he system-assigned, vendor-specific and human-readable string describing the network element”
  serial-number as the “The system-assigned and vendor-specific serial number of the network element”
italobusi commented 4 months ago

2024-02-21 Base Network Inventory weekly call

The following attributes have been agreed:

italobusi commented 3 months ago

2024-03-06 Base Network Inventory weekly call

The YANG descriptions in the I-D version uploaded for IETF 119 are not fully aligned with the descriptions agreed during the call on February 21, 2024

italobusi commented 2 months ago

Closed with 683ea0729a10a841b3fa7de3ec57eb8f33920e0c