Hi Juergen,

On 09/12/2016 11:19, Juergen Schoenwaelder wrote:
On Fri, Dec 09, 2016 at 10:54:14AM +0000, Robert Wilton wrote:
Assuming that diagnostics information was specified for each of N different
protocols on a device.  Then this would seem to mean that every device would
have to install N default NACM deny entries (one for each supported
protocol) to ensure that the device has sensible default operator semantics.
This would seem to be quite a burden on the industry.

A solution that doesn't rely on every server inserting lots of NACM entries
by default seems like a better choice to me.

Did I say that there need to be N?
No, I had extrapolated. :-)

Please can you expand on your proposed solution if using just one NACM entry.


  And why would N hard coded toggles
in data models be simpler and not a burden for the industry?
1. Because by default there is no additional filtering cost to excluding diagnostics data from get/push requests on the operational state datastore. 2. The names of the RPCs could be defined by convention, and hence handled in a generic way. 3. Defining RPCs isn't my preferred solution, but it feels like the most pragmatic one available today. I think that diagnostics is a fundamentally different level of operational state data that may be better served using a separate datastore that sits below the operational state datastore. I.e. it "sees" everything in the operational state datatstore but also contains the extra diagnostics information as well. The diagnostic specific nodes would be marked in the schema, same as config, i2rs, etc, presumably defined in a YANG extension.


  What is
the definition of 'burden for the industry' anyway?
OK, I agree that it was a nebulous term, but my two specific concerns are:
1. Everyone who implements the model also needs to implement a NACM entry to only return the data that 99% of clients are likely to be generally interested in. 2. I am concerned about the server performance overhead of the extra NACM entry/entries for the mainline case. 3. I think that it requires client to know by magic that the diagnostics information isn't returned by default (but if done in a uniform way this could be solved by convention).

Thanks,
Rob


/js


_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to