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 > > > > 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. 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 > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
