Re: [netmod] AD review of draft-ietf-netmod-entity-06

[Martin Bjorklund <[e-mail]>]

Hi,

"Bogaert, Bart (Nokia - BE/Antwerp)" <[e-mail]> wrote:
> Hi Martin,
> 
> We had a discussion on this and we have some concerns about below
> statement (behavior in the description statement):
> 
> >    This leaf can be configured.  The configured value is used only if
> >    the server cannot determine the vendor-specific serial number from
> >    the component itself.
> 
> For the above sentence “server cannot determine” we have 2 cases:
> 1. It can’t be determined because there is nothing detected.
> According to the NMDA-draft it is clear that in this case there is no
> row for the associated component and hence no data. I think this case
> is covered by the sentence in the latest draft-ietf-netmod-entity for
> the list “component” where it is stated: “When the server detects a
> new hardware component, it initializes a list entry in the operational
> state.”, so the above sentence only applies for the second case below.

Ok.

> 2. The second case is that something is detected but it can’t be read.
> We do not see a reason to use the value configured for the leafs
> ‘serial-num’, ‘mfg-name’ and ‘model-name’ of a matching entry in the
> configuration data.  These leafs are defined as optional so why would
> we report something entered by an operator in the operational
> datastore that intends to report on what is detected?  Is it not
> better to not report them at all?  In an NMDA context it would be
> possible to have a different value (or no value at all) for certain
> leafs while there is something in the running/intended datastore.

The normal NMDA procedure for a configuration leaf is to repeat it in
operational state.  This is then the "applied configuration".  
I don't think we should have a special rule for these leafs.

This also means that a client that just wants to read all the serial
numbers can do so from one place, the operational state, regardless of
how they came into existance.


/martin


> 
> Best regards, Bart
> 
> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Robert
> Wilton
> Sent: Thursday, December 21, 2017 4:14 PM
> To: Martin Bjorklund <[e-mail]>; [e-mail]
> Subject: Re: [netmod] AD review of draft-ietf-netmod-entity-06
> 
> Hi Martin,
> 
> 
> On 21/12/2017 11:37, Martin Bjorklund wrote:
> > Hi,
> >
> > I need WG input on this issue.  The question is how to handle 
> > 'serial-num', 'mfg-name', and 'model-name'.  I think they should all 
> > be treated the same.  Based on previous WG discussion (see e.g. the 
> > mail thread "draft-ietf-netmod-entity issue #13"), I think they should
> > all be configurable, but the configured value is only used in 
> > operational state if the system cannot read it from the hardware.
> I think that this approach is probably OK:
>   - The client can always see the real value if it is available.
>   - If it is not available then they can assign a value via
>  configuration.
> 
> I was also considering an alternative approach of having a separate
> set of config false leaves for the "burnt in values".  And then having
> the configurable leaves always override the default operational
> values. E.g. similar to how an interface MAC address would expect to
> be handled.
> 
> But one set of leaves is probably sufficient.
> 
> Thanks,
> Rob
> 
> 
> >
> > So I suggest the following changes:
> >
> > OLD:
> >
> >        leaf serial-num {
> >          type string;
> >          config false;
> >          description
> >            "The vendor-specific serial number string for the
> >             component.  The preferred value is the serial number
> >             string actually printed on the component itself (if
> >             present).";
> >          reference "RFC 6933: entPhysicalSerialNum";
> >        }
> >
> > NEW:
> >
> >        leaf serial-num {
> >          type string;
> >          description
> >            "The vendor-specific serial number string for the
> >             component.  The preferred value is the serial number
> >             string actually printed on the component itself (if
> >             present).
> >
> >             This leaf can be configured.  There are two use cases for
> >             this; as a 'post-it' note if the server cannot determine
> >             this value from the component, or when pre-provisioning a
> >             component.
> >
> >             If the server can determine the serial number from the
> >             component, then that value is always used in operational
> >             state, even if another value has been configured.";
> >          reference "RFC 6933: entPhysicalSerialNum";
> >        }
> >
> > And corresponding text for 'mfg-name' and 'model-name'.
> >
> > And also:
> >
> > OLD:
> >
> >           When the server detects a new hardware component, it
> >           initializes a list entry in the operational state.
> >
> >           If the server does not support configuration of hardware
> >           components, list entries in the operational state are
> >           initialized with values for all nodes as detected by the
> >           implementation.
> >
> >           Otherwise, the following procedure is followed:
> >
> >             1. If there is an entry in the /hardware/component list in
> >                the intended configuration with values for the nodes
> >                'class', 'parent', 'parent-rel-pos' that are equal to
> >                the detected values, then:
> >
> >             1a. If the configured entry has a value for 'mfg-name'
> >                 that is equal to the detected value, or if the
> >                 'mfg-name' value cannot be detected, then the list
> >                 entry in the operational state is initialized with the
> >                 configured values for all configured nodes, including
> >                 the 'name'.
> >
> >                 Otherwise, the list entry in the operational state is
> >                 initialized with values for all nodes as detected by
> >                 the implementation.  The implementation may raise an
> >                 alarm that informs about the 'mfg-name' mismatch
> >                 condition.  How this is done is outside the scope of
> >                 this document.
> >
> >             1b. Otherwise (i.e., there is no matching configuration
> >                 entry), the list entry in the operational state is
> >                 initialized with values for all nodes as detected by
> >                 the implementation.
> >
> >           If the /hardware/component list in the intended
> >           configuration is modified, then the system MUST behave as if
> >           it re-initializes itself, and follow the procedure in (1).";
> >
> > NEW:
> >
> >           When the server detects a new hardware component, it
> >           initializes a list entry in the operational state.
> >
> >           If the server does not support configuration of hardware
> >           components, list entries in the operational state are
> >           initialized with values for all nodes as detected by the
> >           implementation.
> >
> >           Otherwise, the following procedure is followed:
> >
> >             1. If there is an entry in the /hardware/component list in
> >                the intended configuration with values for the nodes
> >                'class', 'parent', 'parent-rel-pos' that are equal to
> >                the detected values, then the list entry in operational
> >                state is initialized with the configured values,
> >                including the 'name'.  The leafs 'serial-num',
> >                'mfg-name', and 'model-name' are treated specially; see
> >                their descriptions for details.
> >
> >             2. Otherwise (i.e., there is no matching configuration
> >                entry), the list entry in the operational state is
> >                initialized with values for all nodes as detected by
> >                the implementation.
> >
> >           If the /hardware/component list in the intended
> >           configuration is modified, then the system MUST behave as if
> >           it re-initializes itself, and follow the procedure in (1).";
> >
> >
> >
> > /martin
> >
> >
> >
> >
> > Benoit Claise <[e-mail]> wrote:
> >> On 12/20/2017 4:00 PM, Martin Bjorklund wrote:
> >>> Benoit Claise <[e-mail]> wrote:
> >>>> Hi Martin,
> >>>>
> >>>> Thanks.
> >>>> Only kept the relevant excerpts.
> >>>>>> - Some objects are read-write in RFC6933:
> >>>>>>          entPhysicalSerialNum
> >>>>>>          entPhysicalAlias
> >>>>>>          entPhysicalAssetID
> >>>>>>          entPhysicalUris
> >>>>>>
> >>>>>> For example, entPhysicalSerialNum being read-write always bothered me.
> >>>>>> serial-num is now "config false", which is a good news IMO.
> >>>>> Actually, this was not the intention.  In 
> >>>>> draft-ietf-netmod-entity-03 this is configurable.  I missed this in
> >>>>> the conversion to NMDA.
> >>>> Ah. So no good news in this case...
> >>>>>> In the reverse direction, entPhysicalMfgName is read-only in 
> >>>>>> RFC6933, while it's "config true" in draft-ietf-netmod-entity
> >>>>> Yes, this was added per request from the WG.  See e.g. the thread 
> >>>>> "draft-ietf-netmod-entity issue #13".
> >>>> Sure. It was mainly an observation.
> >>>>> However, I think that what we have now is probably not correct.  I 
> >>>>> think that all nodes 'serial-num', 'mfg-name', and 'model-name' 
> >>>>> should be config true, and the description of list 'component' 
> >>>>> updated to reflect that all these tree leafs are handled the same way.
> >>>>>
> >>>>> I would like to know what the WG thinks about this.
> >>>> Talking as a contributor this time.
> >>>> It seems that inventory management is kind of broken when someone 
> >>>> can change 'serial-num', 'mfg-name', and 'model-name.
> >>> They can't really change them.  The configured values are only used 
> >>> (i.e. visible in the operational state) if the device cannot detect 
> >>> them automatically.  I.e., they work as "post-it" notes only.
> >> If I look at, for example, the mfg-name, description, this is not 
> >> what it says.
> >>
> >>     leaf mfg-name {
> >>             type string;
> >>             description
> >>               "The name of the manufacturer of this physical component.
> >>                The preferred value is the manufacturer name string
> >>                actually printed on the component itself (if present).
> >>
> >>                Note that comparisons between instances of the model-name,
> >>                firmware-rev, software-rev, and the serial-num nodes are
> >>                only meaningful amongst component with the same value of
> >>                mfg-name.
> >>
> >>                If the manufacturer name string associated with the
> >>                physical component is unknown to the server, then this
> >>                node is not instantiated.";
> >>             reference "RFC 6933 <https://tools.ietf.org/html/rfc6933>:
> >>             entPhysicalMfgName";
> >>
> >> Regards, Benoit
> >>
> >>>
> >>> /martin
> >>> .
> >>>
> > _______________________________________________
> > netmod mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netmod
> > .
> >
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod