> On Aug 1, 2017, at 9:33 AM, Jeffrey Haas <[email protected]> wrote:
>
> On Tue, Aug 01, 2017 at 08:33:38AM -0700, Mahesh Jethanandani wrote:
>>> I'm ambivalent. This depends really on real world behavior.
>>>
>>> As we saw from some brief googling yesterday on Cisco IOS/IOS-XR docs, that
>>> implementation doesn't appear to expose echo intervals as a separably
>>> configurable item. It did, however, expose a boolean to disable echo.
>>
>> True. But the standard seems to imply the ability to configure echo values
>> separately. Worst case implementations would have to set both the values to
>> be the same.
>
> The protocol does. But that doesn't mean the config model should.
Ok. I have removed the separate configuration values for tx/rx min intervals
for echo model. Now, there is only one set of tx/rx values.
>
>>> This minimally suggests that there should be a "use echo mode" flag.
>>
>> Will add a boolean to enable/disable echo mode.
>
> I think that's a good start.
This is what we have now in client-cfg-parms
container echo-mode {
if-feature echo-mode;
leaf echo-mode-enabled {
type boolean;
default false;
description
"Should be set to true if echo-mode is enabled for this
session. Set to false by default because defining the
feature should not enable echo-mode by default.";
}
}
Yingzhen, there is one other change that you should be aware of. There is no
longer a choice between configuring tx/rx values and a single value for both.
Even if the values are the same for tx and rx, you need to configure each of
them explicitly.
I will be uploading the changes shortly.
Thanks.
>
>>> The remaining homework is to figure out whether we should expose
>>> configuration state for echo directly in this version of the yang.
>>
>> Per NMDA guidelines, unless the configuration state values are different
>> from config, we do not need to model them as separate attributes.
>
> Right. So, again need to check real world implementations.
>
> If it's the case that implementations supporting echo only use a single set
> of the intervals for echo or not, then we only need that in the model.
>
> If it becomes the case that an implementation supports echo intervals
> differently, a vendor *could* augment the model to support such values.
> However, since this is imported via grouping, it means that the augmentation
> has to be done in each module that uses the grouping.
>
> I hate yang grouping augmentation rules. :-P
>
> -- Jeff
Mahesh Jethanandani
[email protected]
