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