"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > Please find response interleaved > > --- snip --- > > 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, ...). > [Bart Bogaert] this is correct
I assume that you do the validation check that you describe below also in this case? > > > > > > 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? > 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
