Re: [netmod] I-D Action: draft-ietf-netmod-entity-02.txt

[Martin Bjorklund <[e-mail]>]

"Bogaert, Bart (Nokia - BE)" <[e-mail]> wrote:
> Hi Martin,
> 
> > "Bogaert, Bart (Nokia - BE)" <[e-mail]> 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

Ok.

> 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?

I am not sure I understand the question.  Suppose the config tree is
empty, and the system boots and populates the state tree with all
detected harwdare.  Next, a client would like to pre-provision a
module in a chassis that exists in state.  If the leafref is to the
config tree, the client would have to create both the chassis and the
module in the config tree, since the leafef would otherwise fail to
validate.

> 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.

Correction: I am fine with changing the string to a leafref to state.

> [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)?

So are you ok with a leafref to state?


/martin