"Bogaert, Bart (Nokia - BE)" <[email protected]> wrote: > -----Original Message----- > From: Martin Bjorklund [mailto:[email protected]] > Sent: 24 January 2017 11:37 > To: Bogaert, Bart (Nokia - BE) <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt > > "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? 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). 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. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
