Re: [netmod] draft-ietf-netmod-entity issue #13

[Martin Bjorklund <[e-mail]>]

"Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> Hi,
> 
> --- snip ---
> 
> > > Well, this is not what I read out of
> > > 
> > > https://www.ietf.org/mail-archive/web/netmod/current/msg17039.html
> > > 
> > > since there are leafs like mfg-name and model-name that seem to be 
> > > hardware component properties.
> > 
> > The description statements in this email are just copied from the 
> > corresponding config false nodes.  I think they need to be rewritten; 
> > compare with serial-num.  This text can probably be further improved.
> > The idea is that the user probably would configure say mfg-name only 
> > if the system cannot detect it automatically.
> 
> I still wonder why it could be useful to provision things like the mfg-name
> or the serial-num. I would rather like to know what is really there instead
> of overwriting these properties.
> [Bart Bogaert] BBF did not propose to add serial-num, this is in the base
> ietf-entity YANG model.  For pluggable items it makes sense to add the model
> name and mfg-name.  In case of pre-provisioning (so preparing and sending a
> configuration to the device while the HW entity is actually not there yet)
> it makes sense to indicate what is the intended configuration.  When the HW
> entity is inserted at a later point in time the device could raise a
> mismatch alarm in case another entity is detected then the one that was
> "predicted" to be inserted at that position.

It would be very useful if you could comment explicitly on the
pre-provisioning algorithm I described in 
https://mailarchive.ietf.org/arch/msg/netmod/j0lbdkul9f_jJFVGz3aAAmqrEzs
(also cited below).

>From you text above it seems that you do not agree with my algorithm.


/martin


> Best regards,
> Bart
>  
> > > And the config list is still indexed by a name; so for list elements 
> > > that have a (class, parent, position) triple, the name would be 
> > > arbitrary and not necessarily matching the component name.
> > 
> > I think that the idea is that if there is a matching triple, then the 
> > system MUST use the configured 'name' as the 'name' also in the state 
> > list.  One reason for pre-confiugring these components is to be able 
> > to refer to them in other config.
> 
> This may make sense.
> 
> > > Well, if you understand the edits,...
> > 
> > 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, ...).
> > 
> >     If there is no such matching entry, the system assigns a 'name'
> >     in an implementation-specific manner.
> > 
> >     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, ...).
> > 
> >     Otherwise, the state entry is initialized with the detected values
> >     for all leafs.
> > 
> > 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).
> 
> This way of pre-configuring that name may indeed make sense. Lets see if
> this is what BBF really wanted.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod