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. > > 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
