> On 11 Jan 2016, at 15:07, Acee Lindem (acee) <a...@cisco.com> wrote: > > > > 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.
Do you mean their data model or instances? The point is: if the device has an interface, say "eth0" that is operational and configurable, but hasn't been configured so far via intended config, then does "eth0" entry appear in the "if:interface" list of applied config or not? Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
