On Thu, Sep 14, 2017 at 1:30 PM, Kent Watsen <kwat...@juniper.net> wrote:
> > > > > > > > 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. > > > This might break non-NMDA clients expecting to see the system-created config in retrieval responses. I think vendors will decide their own transition plans and decide how much disruption at once is OK. > 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. > > > > > If I can only do YANG validation on expanded templates in <intended>, does that mean it is impossible to do YANG validation on the templates themselves in <running>? The template subtree can only use YANG constraints on external structures in <intended> and not refer to itself in anyway (in <running>)? The RD draft sure has a lot of normative details for something that does not use RFC 2119 terminology at all. I didn't know a Standards Track document could omit these terms. Architecture documents are usually Informational. IMO the RD draft should not mention YANG or XPath at all. That should be moved to an update to RFC 7950. Those parts need more work anyway. The ARCH can move forward without any dependence on YANG details. > Kent // contributor > > > > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
