On 1/11/16, 2:54 PM, "netmod on behalf of Martin Bjorklund" <netmod-boun...@ietf.org on behalf of m...@tail-f.com> wrote:
>Ladislav Lhotka <lho...@nic.cz> wrote: >> Hi Gert, >> >> > On 11 Jan 2016, at 14:25, Gert Grammel <ggram...@juniper.net> wrote: >> > >> > Lada, >> > >> > The requirement says: >> > D. When a configuration change for any intended configuration >> > node has been successfully applied to the server (e.g. not >> > failed, nor deferred due to absent hardware) then the >> > existence and value of the corresponding applied >> > configuration node must match the intended configuration >> > node. >> > >> > I don't see that this would limit the case you described below. In >> > your case there is no intended config, hence there is no >> > "corresponding applied configuration" either. >> >> You are right, the requirement can be interpreted this way. I thought >> that applied configuration was supposed to be identical to intended >> after some synchronization period. > >This is a very important point to clarify. Can there ever be data in >"applied" that is not in "intended"? I think Anees & Rob previously >said "no", but I might be wrong. My opinion is that there is a 1-1 relationship between “applied” and “intended” config. Thanks, Acee > > > >/martin > > >> >> > >> > Besides that, the case you mentioned should be clearly in scope. >> >> Great, then I am open to discussing what this could mean for the >> existing modules (ietf-interfaces, ietf-routing, ACL etc.). >> >> One useful change to YANG semantics could be that a leafref with >> require-instance=true would refer to applied >> configuration. Specifically, the ACL module could then simply use >> "if:interface-ref" (with require-instance=true) as the type for >> "input-interface". >> >> Thanks, Lada >> >> > >> > >> > --Gert >> > >> >> -----Original Message----- >> >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Ladislav >> >> Lhotka >> >> Sent: 07 January 2016 11:20 >> >> To: NETMOD WG >> >> Subject: [netmod] applied configuration and system-controlled entries >> >> >> >> Hi, >> >> >> >> a good use of applied configuration could be to formalize the concept >> >> of >> >> system-controlled entries as defined in RFC 7223, routing-cfg, and >> >> probably >> >> elsewhere, too. >> >> >> >> My idea is that system-controlled interfaces or other entries would >> >> appear in >> >> applied configuration, but not in intended configuration until >> >> something needs >> >> to be really configured. We could then permit leafrefs from intended >> >> configuration to refer to leafs in applied configuration. One case >> >> where this >> >> would be useful is the ACL module, where match conditions refering to >> >> interfaces currently have to use plain strings as references to >> >> interface names. >> >> >> >> However, the above idea seems to be at odds with requirement 1D in >> >> opstate- >> >> reqs-02. I wonder: could that requirement be relaxed or removed so >> >> that the >> >> above use case can be supported? >> >> >> >> Thanks, Lada >> >> >> >> -- >> >> Ladislav Lhotka, CZ.NIC Labs >> >> PGP Key ID: E74E8C0C >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> netmod mailing list >> >> netmod@ietf.org >> >> https://www.ietf.org/mailman/listinfo/netmod >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
