Jason,
> On Jul 17, 2017, at 11:38 AM, Sterne, Jason (Nokia - CA/Ottawa)
> <[email protected]> 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:[email protected]
>> <mailto:[email protected]>] On Behalf Of Robert Wilton
>> Sent: Wednesday, June 14, 2017 17:54
>> To: Mahesh Jethanandani <[email protected]
>> <mailto:[email protected]>>
>> Cc: Xufeng Liu <[email protected] <mailto:[email protected]>>;
>> [email protected] <mailto:[email protected]>; draft-dsdt-nmda-
>> [email protected] <mailto:[email protected]>
>> 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 protected]> 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 protected]]
>>>>>> Sent: Tuesday, June 13, 2017 4:10 PM
>>>>>> To: Xufeng Liu <[email protected]>
>>>>>> Cc: [email protected]; [email protected]
>>>>>> 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 protected]
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> Mahesh Jethanandani
>>> [email protected]
>>>
>>>
>>>
>>> .
>>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/netmod
>> <https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
[email protected]
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
