"Bogaert, Bart (Nokia - BE)" <[email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
