> > [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.
What I see here is an attempt to provide a constraint on operational state which may trigger an alarm from the device if the operational state is present but different from what was provided as a constraint. I do not see pre-configuration here. [Bart Bogaert] When sending a configuration request to a device while there is no HW physically present yet is what we call pre-provisioning meaning that the configuration is made up-front in attendance of the HW being plugged at a later stage. When the plugged HW does not meet the pre-configured data I think it is normal that an alarm is raised but that does not take away the fact that the device was configured in advance. /Bart /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/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
