Hi Martin, > "Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > > One more comment: > > > > The BBF proposal defines 'contained-in' as a leafref, the current > > version of the hardware model has defined 'parent' as a string. In > > the state container parent is defined as a leafref. Parent type > > should be the same in both config and state container. > > The reason for the 'string' in the config tree is that when it is > pre-configured, it doesn't really refer to a component in the state tree. > If it eventually matches a real component, the server will instantiate > an entry in the state tree, and at this point the parent > *is* a proper reference to another component. > > Note that the underlying type is the same in both cases. > [Bart Bogaert] Having it as leafref allows to verify that the parent > being configured is actually existing in the entity model (or defined > in the same transaction). Why would we remove the modelling > capability to check this consistency?
Do you mean a leafref to /hardware/component/name or /hardware-state/component/name? [Bart Bogaert] I was referring to /hardware/component, so parent is a leafref to /hardware/component/name. In /hardware-state it is a leafref to /hardware-state/component/name If we pick the former, it will not be possible to configure a component with a system controlled parent (unless you also add the system controlled parent to the configuration). [Bart Bogaert] Is there a reason to only have this parent in the state tree and not in the config tree? If we pick the latter you will not get any validation (since it has to be require-instance false). It is fine w/ me to change the type string to a leafref of the former type. [Bart Bogaert] If we leave it as a string it would mean that an external application would have to check whether the value of the string actually corresponds to a component that should exist (in the case of a non-system-controlled parent)? Regards, Bart /martin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
