> I agree with Balazs that system-created nodes in running are quite common and > the vendors doing it have no intention of changing it. Of course, what else were they going to do pre-NMDA…and also before require-instance false? Green-field deployments wouldn't be encumbered with backwards-compatibility. Existing implementations are in a bind, but I'd recommend following nmda-guidelines. For UC1: the loopback would only show in <operational> (as an applied instance of a config true leaf), and the leafref would be require-instance false. When committing configuration that referenced loopback, the server sees that the referenced leaf is not in <running>/<intended>, but it could see that it is or is-not in <operational>. And, if it is not in <operational>, the server might return a warning to the client, or not, assuming the client will use other mechanisms to discover what configuration was not applied. For UC2: similar response. The server could return a warning (e.g., a synchronous update) or the client can discover the unapplied config afterwards using other mechanisms. > If the added nodes need to be saved in non-volatile storage then then > definitely > belong in <running>. Neither of Balazs's use-cases regard persisted data, at least I didn't read it that way. > IMO the architecture is rather opaque wrt/ the interactions between > datastores, > especially the interactions between <running> and <intended>. Now it not only > prunes inactive nodes, it adds system nodes? A template in <running> could be flattened, which has the apparent side-effect of creating nodes, but not any nodes, just those per the input from <running>. As the draft says: <intended> does not persist across reboots; its relationship with <running> makes that unnecessary. Generically speaking, <running> can contain processing instructions that are consumed at commit time to simultaneously create the <intended> view, and these PIs are the only thing that can cause a deviation between the two datastores. > Maybe it is too early for NMDA to be making lots of rules about how > YANG works with new (and unimplemented) datastores. Juniper has the equivalent of <intended> already. I think others said they had something like it as well. Kent // contributor
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
