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

[Mahesh Jethanandani <[e-mail]>]

Jason,

> On Jul 17, 2017, at 11:38 AM, Sterne, Jason (Nokia - CA/Ottawa) <[e-mail]> wrote:
> 
> 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.”

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?

> 
> 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] <mailto:[e-mail]>] On Behalf Of Robert Wilton
>> Sent: Wednesday, June 14, 2017 17:54
>> To: Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
>> Cc: Xufeng Liu <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; draft-dsdt-nmda-
>> [e-mail] <mailto:[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] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[e-mail]