Hi,
What about the data models that do not follow 1D?
- templates: the intended data model and applied data model are disjoint
- 'auto-duplex' corner-case: the intended and applied leaf are the same,
but they
will never have the same value
- 'use-dhcp' corner-case: intended config just enables specific derived
state
to be used; disjoint data models
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)
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.
Only the 2 protocol-based solutions address this issue by using
the same object identifier no matter which state is being queried.
Andy
On Fri, Oct 2, 2015 at 10:44 AM, Sterne, Jason (Jason) <
[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]>
> >> 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
