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

From: "Sterne, Jason (Nokia - CA/Ottawa)" <[email-masked]>
Date: Mon, 17 Jul 2017 09:38:51 +0000

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:[email-masked]] On Behalf Of Robert Wilton
> Sent: Wednesday, June 14, 2017 17:54
> To: Mahesh Jethanandani <[email-masked]>
> Cc: Xufeng Liu <[email-masked]>; [email-masked]; draft-dsdt-nmda-
> [email-masked]
> 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 <[email-masked]> 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:[email-masked]]
> >>>> Sent: Tuesday, June 13, 2017 4:10 PM
> >>>> To: Xufeng Liu <[email-masked]>
> >>>> Cc: [email-masked]; [email-masked]
> >>>> 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: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> >>>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
> >>> .
> >>>
> >> _______________________________________________
> >> netmod mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/netmod
> > Mahesh Jethanandani
> > [email-masked]
> >
> >
> >
> > .
> >
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Mahesh Jethanandani <[email-masked]>
Date: Tue, 18 Jul 2017 09:12:37 +0200

Jason,

> On Jul 17, 2017, at 11:38 AM, Sterne, Jason (Nokia - CA/Ottawa) <[email-masked]> wrote:
> 
> Hi guys,
> 
>    is currently used.”

It turns out that the example I had in mind does not create a separate ‘config false’ leaf. Instead, I see two leafs defined as:

leaf auto-negotiation {
  type boolean {
    description
      “When set to true, the interface will auto negotiate for speed.
       When set to false, a separate leaf called ‘speed’ will define
       the desired speed.”;
  }
}

leaf speed {
  type enumeration {
    enum 10M;
    ….
    enum 10G;
  }
}

Notice, I have not defined speed as a ‘config false’ leaf, because it could be used if auto-negotiation is set to false to manually set the speed of the interface.

But I see the interface name as a ‘config false’ leaf, because the name of the interface is assigned by the system, and cannot be changed by the user.

leaf interface-name {
  config false;
  type string {
    description
      “Name of the interface as assigned by the system. This could 
       include information of which line card the interface is on. 
       Example, GigabitEthernet 0/0/0/0”;
  }
}

Does this help?

>> From: netmod [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Robert Wilton
>> To: Mahesh Jethanandani <[email-masked] <mailto:[email-masked]>>
>> Cc: Xufeng Liu <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; draft-dsdt-nmda-
>> [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[email-masked]