"Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > "Bogaert, Bart (Nokia - BE)" <bart.boga...@nokia.com> wrote: > > A more realistic (at least in my > > opinion) is the case where you can insert different cards in a slot > > of a system. If the operator plans that a certain slot will contain > > a board offering e.g. DSL lines then the model-name could reflect > > the HW name of that card. > > Can you go through this example in some more details, e.g. show the > data that the operator set (like the XML I showed)? > > [Bart Bogaert] Assume we have the following in the device already: > <entity> > <physical-entity> > <model-name>system-1</model-name> > <class>ianaent:chassis</class> > </physical-entity> > </entity> > > And assume the following is sent as pre-configuration: > <entity> > <physical-entity> > <model-name>dsl-brd-type1</model-name> > <class>ianaent:module</class> > <parent-rel-pos>2</parent-rel-pos> > <contained-in>system-1</contained-in> > </physical-entity> > </entity> > > When at a later stage, a board is plugged in the position > corresponding to parent-rel-pos 2, the system is able to detect > whether the model-name corresponds to dsl-brd-type-1 and accepts the > pre-configured values. In case a different model name is detected > (e.g. eth-brd-type-1) a mismatch alarm is to be raised indicating that > an eth-brd-type-1 has been detected while a dsl-brd-type-1 was > expected as the pre-configuration does not match with the actual configuration.
In these examples, you don't have the <name> key leaf. It seems that in the case of containment, you want to be able to use <contained-in> and <parent-rel-pos> as identification leafs (probably regardless of which <name> is assigned by the system), and <mode-name> and <class> as matching leafs? What about the non-containment case, how would you do pre-configuration in that case? Use the <name> anyway? [Bart Bogaert] The name leaf has been left out in this example as it is not "relevant" in this discussion (name can be allocated by the operator or can be system-generated in some way if needed). In this example the containment is relevant as we want subscriber interfaces that will be created to be linked to the correct port of the correct board. Not sure what you mean with the "non-containment case" but in that case the object is referred to by its name (in most cases this will be a key in the list) but somehow the resource will be part of some kind of stack (be in the same part of the data tree or in a linked case e.g. using the back-pointer from the object in the interfaces space to a port in the entity space. /Bart /martin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
