I am gradually catching up to emails so I may not have absorbed all the emails I have gone through yetŠ.
Regarding echo config, we agreed in Chicago to remove the echo config based on the fact that implementations of echo are vendor specific. e.g. An implementation which has echo as continuous would likely have echo configuration whereas an implementation which has echo as on-demand may use RPC. There is an example of a vendor augmentation for echo config in Appendix A.1. Regards, Reshad. On 2017-08-01, 12:33 PM, "Jeffrey Haas" <jh...@pfrc.org> 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. > >> > 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. > >> > 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
