Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01

["Sterne, Jason (Nokia - CA/Ottawa)" <[e-mail]>]

Hi guys,

This is something that could use further clarification in the draft.  i.e. examples and guidelines of when to create a separate "config false" leaf (vs the more typical case of just having a single "config true" leaf).   There is an example in there currently but I personally found it confusing:

    "An example would be the speed
    of an interface, where the configured value may not be the value that
    is currently used."

I wasn't sure if that example referred to the same issue as you guys are discussing below.  Perhaps as a minimum we could grab some of the details for the example below and incorporate them into the draft ?

Rgds,
Jason

> -----Original Message-----
> From: netmod [mailto:[e-mail]] On Behalf Of Robert Wilton
> Sent: Wednesday, June 14, 2017 17:54
> To: Mahesh Jethanandani <[e-mail]>
> Cc: Xufeng Liu <[e-mail]>; [e-mail]; draft-dsdt-nmda-
> [e-mail]
> Subject: Re: [netmod] Clarification Question on draft-dsdt-nmda-guidelines-01
> 
> 
> 
> On 14/06/2017 16:23, Mahesh Jethanandani wrote:
> >> On Jun 14, 2017, at 8:10 AM, Robert Wilton <[e-mail]> wrote:
> >>
> >> Hi Xufeng,
> >>
> >>
> >> On 14/06/2017 14:01, Xufeng Liu wrote:
> >>> Hi Juergen,
> >>>
> >>> Thanks for the confirmation.
> >>> As for the distinction between applied configuration and operational, I
> think that it has been determined to be useful in some use cases. We can
> create a separate leaf in such a case.
> >> Yes, I think that this is exactly the right approach.
> >>
> >> In the general case, a single leaf for applied configuration and the
> operational value is normally sufficient.
> >>
> >> But in some cases (e.g. where a value could be configured and/or
> negotiated via protocol) then it sometimes useful to both see the input into the
> protocol negotiation and also the resultant output value.
> >>
> >> Here, there is a choice to be made to decide whether the extra config false
> leaf represents the input value into the negotiation, or the output value.  I
> think that the decision probably depends on the protocol semantics, but all
> things being equal, there is a benefit if the configured value and actual
> operational value end up being represented by the same leaf/path (since this in
> the case in the mainline case where extra config false leaves are not required).
> > Another way to look at it is whether the input value is truly different from the
> output value. For example, if the input value is auto-negotiation, a boolean, but
> the output value is a speed of 10/100/1000/10000, a uint32, then a separate
> leaf makes sense.
> Yes, agreed.
> 
> For cases like these (e.g. Ethernet auto-negotiation) a good approach seem to
> be to model the leaf "enabling auto" as a separate leaf from the explicitly
> configured/operational value.
> 
> Thanks,
> Rob
> 
> 
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >>> Regards,
> >>> - Xufeng
> >>>
> >>>> -----Original Message-----
> >>>> From: Juergen Schoenwaelder
> >>>> [mailto:[e-mail]]
> >>>> Sent: Tuesday, June 13, 2017 4:10 PM
> >>>> To: Xufeng Liu <[e-mail]>
> >>>> Cc: [e-mail]; [e-mail]
> >>>> Subject: Re: Clarification Question on
> >>>> draft-dsdt-nmda-guidelines-01
> >>>>
> >>>> Hi,
> >>>>
> >>>> the typical -state tree consists of config false nodes and hence it
> >>>> represents operational state. This is not a transitioning period
> >>>> question, this is how -state trees were designed. Note also that
> >>>> the applied configuration is part of the operational state in NMDA
> >>>> - for config true objects, there is no difference between the
> >>>> applied configuration value and the operationally used value - they are
> the same.
> >>>>
> >>>> /js
> >>>>
> >>>> On Tue, Jun 13, 2017 at 07:53:32PM +0000, Xufeng Liu wrote:
> >>>>> During discussing the adoption of this guidelines, a question came
> >>>>> up w.r.t. the
> >>>> semantics of the non-NMDA "-state" module during the transitioning
> period:
> >>>>> What kind of state do the leaves in the "-state" module represent?
> >>>>> The applied
> >>>> configuration or the actually used operational data?
> >>>>> Since only of the two types can be represented, what is the
> >>>>> guideline to model
> >>>> the other type?
> >>>>> Thanks,
> >>>>> - Xufeng
> >>>> --
> >>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> >>>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> >>>> Fax:   [phone]         <http://www.jacobs-university.de/>
> >>> .
> >>>
> >> _______________________________________________
> >> netmod mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/netmod
> > Mahesh Jethanandani
> > [e-mail]
> >
> >
> >
> > .
> >
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod