Wes, [snipping a lot of very good commentary that the authors should pay attention to.]
On Tue, Jun 10, 2014 at 03:53:27PM -0400, George, Wes wrote: > >Given the above, what would you suggest? I realize what we want is a way > >to > >troubleshoot, but I'm not sure there can be any specific recommendation > >that > >will span the architectures well enough to be standardized. > WG] Well, I think there???s a valid traceability and troubleshooting > requirement in the form of needing the ability to do verification and > examination of the state and actions taken by I2RS agent(s) without > invoking the agent being examined. We don???t need to be prescriptive on the > format for that information, nor the method for providing that independent > avenue for accessing it, we must only note that it needs to be available. > For example, in a routing element that doesn???t really have a CLI, the > independent method doesn???t have to be via CLI, it could be via a web UI or > some pretty GUI if that???s the other method to manage the device. I mention > CLI as an example because for the most part, the fail-safe method for > interacting with the routing system today is indeed CLI. The traceability draft should hopefully give you the "what was requested" end of the auditing spectrum. (Please comment in that thread, if otherwise.) What I believe you're asking is roughly something like the following text in the architecture draft: X. Operational Considerations In order to facilitate troubleshooting of routing elements implementing I2RS agents, those routing elements should provide for a mechanism to show actively provisioned I2RS state. Note that this information may contain highly sensitive material subject to the Security Considerations of any data models implemented by that Agent and thus must be protected according to those considerations. ? -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
