Kent Watsen <kwat...@juniper.net> wrote: > > > >> 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. > > This conversation seems to mirrors the we had regarding the i2rs > topologoy model
Yes. >, where we landed on a leafref in 'running' could > point to a config true node in 'operational-state' With 'require-instance false'? That doesn't really mean that it points to anything in operational state. > as to apply > configuration to, for instance, system-discovered underlays...or > do I misunderstand, is the intention here for the leafref to point > to a config false node? Yes. If we had revised datastores, this model would probably look different. /martin _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
