"Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]> wrote: > Hi all, > > There are a few threads on the mailing list that touch on the concept > of system-controlled resources (mostly list entries): > > https://mailarchive.ietf.org/arch/msg/netmod/3fTSHIh_MfHzmuDCoicAGiXA2E0 > https://mailarchive.ietf.org/arch/msg/netmod/KIsSgKByQWpqYzA4i6Bwc8fuH3w > https://mailarchive.ietf.org/arch/msg/netmod/mjLJdiYErtNG41dJ5bJ5ji07cz0 > > A few drafts & RFCs also refer to the concept: > https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-04 > https://tools.ietf.org/html/rfc7223 > > Several vendor implementations have list entries (instance data) that > are populated by the server and can be referenced (leafref) from other > places in the configuration. These system entries are useful > pre-created policies, interfaces, etc that can then be used (and > referred-to) by operators in their explicit configuration. > > If those entries are only expected to exist in the <operational> > datastore, then in theory any references to them in user created > configuration will cause a validation problem in the candidate/running > (missing leafref target). > > One solution discussed in the mailing lists is to change every > reference to lists that could contain a system created entry to a > "require-instance false" leafref. But then some useful validation is > lost. In many cases the model is more correctly "require-instance > true" but the set of targets includes the system create entries. > > Another solution discussed is to have the system created entries > appear in the <intended> datastore (as part of template/expansion). > That would make validation pass on the intended datastore, but then > the candidate/running/startup datastores would not be valid (would be > missing leafref targets if any part of the config refers to system > created entries). THis sounds similar to the problem that has been > discussed in the past about the fact that templates (in the running) > basically mean the running/candidate aren't necessarily valid (until > after template expansion, which means only the intended would be > valid). > > Another approach could be to actually have those system created > entries show up in running/candidate. That would ensure that > references to those entries are valid.
This works if the "system created entries" behave just like any other entry, i.e., a client (with proper access rigths) can modify and delete them. If this is not the case, the next question is what happens if the client creates its own entry with the same name as a system created entry? Is this illegal, or will the user created entry override the system created entry? Another question to think about is what happpens with user config that refers to such a system created entry if a new software image is loaded where the system created entry is no longer present? /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
