--- snip --- > [Bart Bogaert] If we stick to the use case of equipment the > pre-configuration is based on containment and names attributed to the > entities by the operator. I tried to explain that so far names > attributed to entities have no other meaning then identifying the > entity and, as allocated by the operator, there is nothing to be > predicted: it is known.
Dut even in your example of simple containment, it works b/c the operators knows the name of the parent, and the parent-rel-pos. Right? So what if you need to pre-configue two levels of containment? [Bart Bogaert] As the operator assigns the names, he knows them on all layers You know the name of the top-level component, so you can pre-configure the first child. But then you'll have to know the name of this first child in order to pre-configure the grand child. Or are you saying that the system always creates and gives names to all top-level components, and then the operator or system can given name to sub-components? --- snip --- > [Bart Bogaert] As indicated above that might be true for equipment > (entity) objects but pre-configuration could also include definition > on top of these pre-configured ports and in this case there will > certainly be configuration of leafs that are characteristic for the > to-be offered service and which will be defined on top of a port > (hence the augment of interfaces with back-pointer to the port > entity). Also in this case the operator knows exactly on top of which > port the interface will be created. The name attributed to the > interface has no special meaning to the SW of the device apart from > giving it a unique reference. The name is set by the network operator > and can basically be anything (that is why I say that it has no > special meaning to the SW in the device). As the names are set by the > operator there is nothing that requires prediction. The name-binding > as it is referred to here comes from the model where the leafrefs point to the name of underlying resource (be it entity or interface). I have a hard time trying to understand what you actually need. It now seems that you want to pre-configure some physical entity in order to be able to refer to it from higher-level models. Is this correct? Thus, you don't really want to pre-configure any leafs in the entity model, except for the name. Remember that the thread started with a request to have the 'class' and 'contained-in' leafs in the config list physical-entity, and 'class' being mandatory. [Bart Bogaert] I agree but these leafs are added with the pre-configuration use case in mind maybe it drifted a bit off... I think we can end this thread here. /Bart > Maybe we have a different understand of "pre-configuration"? For me > it simply means that an operator is able to create a configuration in > the device without the HW supporting this configuration being > physically present but is getting stored in the database of the device > (I'm explaining it as it is in our SNMP-based devices). The > configuration gets applied once the supporting HW is plugged in the > device (given the fact that the plugged HW matches what was previously configured). Right, this is also my understanding of pre-configuration. /martin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
