> On 9 Dec 2016, at 12:05, Robert Wilton <[email protected]> wrote: > > > > On 09/12/2016 10:54, Ladislav Lhotka wrote: >>> On 9 Dec 2016, at 11:48, Robert Wilton <[email protected]> wrote: >>> >>> Hi Lada, >>> >>> >>> On 09/12/2016 10:33, Ladislav Lhotka wrote: >>>> Hi Rob, >>>> >>>> I didn't follow the previous discussion closely but a natural solution >>>> seems to be to define a leaf like "debug" - it could be just boolean or >>>> an enumeration of debug levels. And then add the diagnostic >>>> data as an augment that conditionally depends on the value of the >>>> "debug" leaf. >>>> >>>> Would this work? >>> I'm not sure. >>> >>> Historically debug has been separate from configuration. I.e. you wouldn't >>> normally expect debug settings to persist after rebooting the device. >> Yes, good point. So what you can do is to have a "debug" RPC, show "debug" >> value in state data, and still make the augment with diagnostics >> conditionally dependent on the debug leaf. > OK, so this is closer, but still would mean that enabling the debug flag via > RPC would potentially cause all clients to start to see the diagnostics > information (which may break them).
You can add finer granularity by making "debug" into an action on an interface, and then I think it's not a big deal. > > Hence I think that there is a requirement that the diagnostics data is > restricted to only the specific client session that it has been requested > on/enabled on. Then an RPC returning the diagnostics, as Vladimir suggested, might be the best option. Lada > > Thanks, > Rob -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
