--- snip ---

> > > I think the idea would be explained along these lines:
> > > 
> > > The sytem conceptually behaves like this:
> > > 
> > > 1.  When a physical component is detected, the system will initialize
> > >     an entry in the /hardware-state/component list.
> > > 
> > >     If there is an entry in /hardare/component list with a matching
> > >     (class,parent,parent-rel-pos) triple, then the state entry is
> > >     initialized with the configured values for all configured leafs
> > >     (name, mfg-name, ...).
> [Bart Bogaert] this is correct

I assume that you do the validation check that you describe below also in
this case?
[Bart Bogaert] Indeed

> > > 
> > >     If there is no such matching entry, the system assigns a 'name'
> > >     in an implementation-specific manner.
> [Bart Bogaert] This is correct
> > > 
> > >     If there is an entry in /hardare/component list with a matching
> > >     'name' and where the triple (class,parent,parent-rel-pos) is not
> > >     set, then the state entry is initialized with the configured
> > >     values for all configured leafs (name, mfg-name, ...).
> [Bart Bogaert] We currently expect that these leafs contain meaningful 
> values but we will not copy the leaf values from config to state but 
> populate the state fields with what is detected from the HW and raise 
> a mismatch alarm.

Do you expect all configured leafs to contain meaningful values, i.e., do
you validate that all leafs (serial-num, mfg-name, model-name) match?

This procedure would change how serial-num currently is handled.  I don't
have a strong opinion on this, but I note that serial-num is writable in the
ENTITY-MIB.  Maybe someone can comment on why it is writable in the MIB, and
if this is a use case that we want to support?
[Bart Bogaert] No, in this case we expect the triplet to be meaningful
(class,parent,parent-rel-pos) as this identifies the HW entity and on top of
that the mfg-name and model-name are checked.  In case there is a mismatch
an alarm is generated.  The other leafs (defined in ietf-entity) are
implemented as described in the entity YANG model.

Regards, Bart

> Possibly the operational state is set to disabled.  So when a mismatch 
> Is found between what is set in /hardware/component and what is 
> detected a mismatch alarm is raised.
> > > 
> > >     Otherwise, the state entry is initialized with the detected values
> > >     for all leafs.
> [Bart Bogaert] This is correct
> > > 
> > > 2.  If the /hardware/component list is modified (i.e., someone changed
> > >     the config), then the system MUST behave as if it was restarted
> > >     and followed the procedure in (1).
> [Bart Bogaert] This is correct
> 
> Regards,
> Bart
> > 
> > This way of pre-configuring that name may indeed make sense. Lets 
> > see if this is what BBF really wanted.
> > 
> > /js

/martin

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to