"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? /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
