Hi,
So the applied leaf is being used as a complicated boolean?
IMO your draft (using attributes similar to with-defaults=report-all-tagged,
not containers) is the best compromise because:
- the data models are not touched
- no datastores are required
- the same string is used to identify the data node no matter what
state needs to be checked
- client has to request the metadata somehow so no impact
on clients that do not care about this issue
- a single boolean attribute applied="true" is all that is really needed
Andy
On Fri, Oct 2, 2015 at 1:16 PM, Robert Wilton <[email protected]> wrote:
> Hi Andy,
>
> It was clarified by Rob Shakir in the meeting that the applied-cfg leaf is
> only used to indicate whether the configuration represented by the
> intended-cfg leaf has been applied.
>
> But it appears that my proposed text for 1D may have caused some
> confusion. Please see inline ...
>
> On 02/10/2015 19:11, Andy Bierman wrote:
>
> Hi,
>
> What about the data models that do not follow 1D?
>
> - templates: the intended data model and applied data model are disjoint
>
>
> This came up towards the end of the interim, and my understanding is that
> it acceptable for any templating solution to have to adhere to that
> constraint above.
>
>
> - 'auto-duplex' corner-case: the intended and applied leaf are the same,
> but they
> will never have the same value
>
> The intention is:
> - intended-cfg duplex leaf = "auto" (i.e. operator wants duplex to be
> determined by auto-negotiation)
> - applied-cfg duplex leaf = "auto" (i.e. device will determine duplex by
> auto-negotiation)
> - related derived-state duplex-state leaf = "full" or "half" or
> "unknown" (always represents the actual duplex setting of the interface)
>
> - 'use-dhcp' corner-case: intended config just enables specific derived
> state
> to be used; disjoint data models
>
> Similarly:
> - intended-cfg use-dhcp leaf = "true" (i.e. operator wants DHCP assigned
> IP addresses)
> - applied-cfg use-dhcp leaf = "true" (i.e. system is using DHCP to
> assign IP addresses)
> - related derived-state IP address leaf = A.B.C.D (Primary IP address in
> use for the interface - if any).
>
>
>
> Somebody asked an important question at the interim:
> Is the intent of this group to limit all YANG data models such that
> they conform to 1D? (IMO that is a non-starter)
>
> It is not my intention that my proposed 1D text makes are constraint on
> the structure of YANG data models.
>
>
> IMO requirement 1D presume that the solution involves separate
> objects in the YANG data model for intended and applied states,
> and therefore it is an invalid requirement.
>
>
> That is not the intention of my phrasing, perhaps it needs further
> refinement?
>
> The intention is that a config node has two notional states in the data
> store, intended and applied. The aim is to tightly relate those two
> notional states as to when they are allowed to be the same or different.
>
>
> Only the 2 protocol-based solutions address this issue by using
> the same object identifier no matter which state is being queried.
>
> I don't think that this requirement excludes any of the three solutions
> that have been proposed (or the use of attribute to return intended vs
> applied state metadata).
>
> Thanks,
> Rob
>
>
>
>
>
> Andy
>
> On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <
> <[email protected]>[email protected]> wrote:
>
>> I agree with "e.g." rather than "i.e.". I'm sure there are lots of other
>> examples of situations where intended config and applied config don't match
>> when we consider the variety of systems out there that may use
>> NETCONF/YANG. We should include some of these examples in the draft (in
>> some informational section and have a reference/pointer to them just after
>> the definition).
>>
>> Note that this updated definition for 1.D does not preclude the applied
>> config object from matching the intended *before* it has been applied. Do
>> we need to clarify that with some "conversely" clause or is that clear
>> enough when considering the other requirements ?
>>
>> We should also cleanly define "applied" (and provide illustrative
>> examples of when something is and is not applied). Should that be a
>> separate email thread ?
>>
>> Jason
>>
>>
>> -----Original Message-----
>> From: netmod [mailto:[email protected]] On Behalf Of Robert Wilton
>> Sent: Friday, October 02, 2015 5:24
>> To: Randy Presuhn; [email protected]
>> Subject: Re: [netmod] opstate-reqs issue #1 - Define/Clarify "fully
>> synchronized" in "Requirement 1.D"
>>
>> Hi Randy,
>>
>> On 01/10/2015 23:27, Randy Presuhn wrote:
>> > Hi -
>> >
>> >> From: Robert Wilton < <[email protected]>[email protected]>
>> >> Sent: Oct 1, 2015 10:01 AM
>> >> To: "[email protected]" <[email protected]>
>> >> Subject: [netmod] opstate-reqs issue #1 - Define/Clarify "fully
>> synchronized" in "Requirement 1.D"
>> >>
>> >> To clarify what I failed to eloquently express in the interim meeting.
>> >>
>> >> I propose changing the text for requirement 1.D. This also removes
>> >> the need to define what fully synchronized means.
>> >>
>> >>
>> >> Old text for 1.D
>> >> D. For asynchronous systems, when fully synchronized, the data
>> >> in the applied configuration is the same as the data in the
>> >> intended configuration.
>> >>
>> >>
>> >> Proposed text for 1.D:
>> >> D. When the configuration change for any intended
>> >> configuration leaf has been successfully applied to the
>> >> system (i.e. not failed, nor deferred due to absent
>> hardware)
>> >> then the existence and value of the corresponding applied
>> >> configuration leaf must match the intended configuration
>> >> leaf.
>> > Are "not failed" and "deferred due to absent hardware" the
>> > *only* possibilities? If not, then the "i.e." needs to be replaced
>> > with an "e.g."
>> I'm not sure if it is the only possibility. Two other possible reason
>> might be:
>> - Configuration that cannot be applied because some dependent
>> configuration hasn't been applied. (E.g. if you have configuration where
>> an interface-ref couldn't be fulfilled because the referenced interface
>> configuration hadn't been applied because either it had failed or been
>> deferred due to absent hardware). But perhaps this would be classified as
>> being one of the two cases above?
>> - There is also the case the configuration is currently in the process
>> of being applied.
>>
>> If it is agreed that github issue #2 (i.e. "Is there a requirement to
>> indicate why intended config != applied cfg?") is a valid requirement, and
>> I think that there might have been some support for this in the interim
>> meeting yesterday, then I would hope that the final solution would
>> enumerate the reasons why the applied configuration may not match the
>> intended configuration.
>>
>> As such, changing from i.e. to e.g. seems like a good choice.
>>
>> So also taking into account Martin's suggestion the updated proposed text
>> for 1.D would be:
>>
>> D. When the configuration change for any intended
>> configuration node has been successfully applied to the
>> system (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.
>>
>> Thanks,
>> Rob
>>
>>
>> >
>> > Randy
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > [email protected]
>> > https://www.ietf.org/mailman/listinfo/netmod
>> > .
>> >
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
