Guidelines for component specific attributes

[italobusi]

Add an example of YANG code for the grouping (Component-Specific Info Design section)

[italobusi]

2023-12-20 Network Inventory weekly call

There was not time to discuss whether to use the choice or when statements to define component specific attributes: to be discussed in the next call

It has been pointed out that Netmod WG has recently had a similar discussion about choice versus when statement: it may be worthwhile reviewing the Netmod WG discussion before the next call

[italobusi]

I think there are three possible options

Option 1 (case+when)

+--ro component* [component-id]
   +--ro component-id            string
   +--ro class                   union
   ...........................................
   +--ro (component-class)?
   |  +--:(chassis)
   |  |  +--ro chassis-specific-info   // when
   |  +--:(container)
   |  |  +--ro slot-specific-info   // when
   |  +--:(module)
   |  |  +--ro board-specific-info   // when
   |  +--:(port)
   |     +--ro port-specific-info   // when
   ...........................................

Option 2 (when-only)

+--ro component* [component-id]
   +--ro component-id            string
   +--ro class                   union
   ...........................................
   +--ro chassis-specific-info   // when
   +--ro slot-specific-info      // when
   +--ro board-specific-info     // when
   +--ro port-specific-info      // when
   ...........................................

Option 3 (case-only)

+--ro component* [component-id]
   +--ro component-id            string
   +--ro (class)
   |  +--:(chassis)
   |  |  +--ro chassis!
   |  +--:(container)
   |  |  +--ro container!
   |  +--:(module)
   |  |  +--ro module!
   |  +--:(port)
   |     +--ro port!
   ...........................................

Option 1 provides duplicated information and I would prefer not to adopt it: see also the mail thread on Netmod WG

Option 3 would be preferable to Option 2 because, according to RFC8407, "when" statement evaluation is generally more expensive than "if-feature" or "choice" statements

Option 2 would be preferable to Option 1 because it allows re-use of identities defined by IANA for hardware components and it is more aligned with RFC8348

[italobusi]

2024-01-17 Network Inventory weekly call

Agreed to adopt option 3 since it is easier to understand from the code and lighter to implement

• [ ] @YuChaode update the YANG model and I-D text accordingly

[italobusi]

2024-01-24 Base Network Inventory weekly call

Chaode has a concern with removing the class attribute. Without this attribute it would not be possible to do some filtering to retrieve all the components of a given class

This issue requires further discussion in the next call(s)

[italobusi]

2024-02-21 Base Network Inventory weekly call

Option 2 agreed to solve the filtering issue

• [ ] @YuChaode : update the draft and model accordingly

[nigel-r-davis]

Apologies, just looking at the iana definition of port:

identity port { base ianahw:hardware-class; description "This identity is applicable if the hardware class is some sort of networking port capable of receiving and/or transmitting networking traffic."; }

To me this is particularly ambiguous. The port is a conceptual grouping of connector/pin combinations potentially across several pieces of hardware that support a meaningful signal. It is not clear to me how this would be the categorization of a relevant component in the inventory.

I was also unable to find board in iana hw (on https://www.iana.org/assignments/yang-parameters/yang-parameters.xhtml in https://www.iana.org/assignments/yang-parameters/iana-hardware@2018-03-13.yang).

[italobusi]

The board is defined as module in IANA:

  identity module {
    base ianahw:hardware-class;
    description
      "This identity is applicable if the hardware class is some sort
       of self-contained sub-system.  If a module component is
       removable, then it should be modeled within a container
       component; otherwise, it should be modeled directly within
       another physical component (e.g., a chassis or another
       module).";
  }

I would suggest to re-use the same terminology as in IANA for the component-specific containers to avoid ambiguity

[italobusi]

Closed with PR #39