> On 11 Jan 2016, at 14:54, Martin Bjorklund <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. >
Yup, I also had this impression. Lada > > > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
