On 1/11/16, 3:11 PM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
> >> 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? Data model. Acee > >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
