"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > > "Bogaert, Bart (Nokia - BE)" <[email protected]> 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.
The 'name' is relevant since it is the unique identifier of a component. In fact, your example is a bit misleading. In the current model, the 'contained-in' leaf is a leafref to another physical-entity's 'name', but in your example it seems it refers to the 'model-name'. Note that there can be several physical-entities with the same 'model-name', so it cannot be used as a unique identifier. > 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. If the component that we want to (pre)configure is not contained in anything, we need to use some kind of unique identifier, which currently is the 'name'. This requires the operator to be able to predict the 'name' of any component that he'd like to pre-configure. If the component is contained in some other component that already is known, the operator needs to predict the 'parent-rel-pos' of the new component, but I assume this is ok. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
