Hi Joe, I certainly agree that keeping logs of the APIs done and their results or, perhaps, having the ability to mirror the requests and responses to a collector would be useful.
With CLI, I agree that this is frequently done with syslog today - which then necessitates vendor-specific code to scrape through. What would be a meaningful accountability framework that would be appropriate and, hopefully, not require vendor-specific screen-scraping? Completely off the top of my head, I can see the following ideas: (a) mirror all (or a meaningful subset) messages in/out to a collector that then stores/sorts/logs the information (b) Define an accountability information model that defines what should be stored and have it stored in the canonical form required by the selected data-model. Perhaps mandate it be stored in a file for acquisition? Have the ability to read it? and I'm sure that there are many others... I do think this is an important area and it could use some good discussion (and even a draft or a section to go into the architecture). Alia On Wed, Aug 14, 2013 at 12:29 PM, Joe Marcus Clarke <[email protected]>wrote: > On 8/14/13 12:11 PM, Alia Atlas wrote: > > [Alia] I think that (1) belongs in the architecture. I agree that it is > > important - but I feel that the problem-statement part is covered in the > > Multi-Headed Control. > > (2) is mostly covered in "Secure Control". I did add "Such > > communications must also have its integrity protected." since we hadn't > > mentioned integrity but just authentication and authorization. > > For (3), I'm not sure what aspects specifically apply to I2RS... We > > have authentication and authorization and, in the architecture, tracking > > of state written. What knobs or functionality are you looking for in > > accounting? > > I'll comment here, and I'm sure Carlos will chime in with anything I > miss or if he sees things differently. > > Coming from a services/support mindset, accountability from a tracing > point of view is important. I would like to see a history of actions > performed, the client that performed them, when the actions were > performed (with very granular timestamps), and the result code. > > Forgive me for using a vendor reference here (as an example), but in > Cisco IOS we have the buffer of CLI commands executed and syslog > messages generated. This buffer is very useful when it comes to tracing > a crash back to potential triggers. As we look to incorporate our own > APIs, we want to provide the same kind of history log to try and tie API > calls back to potential problems on the device. > > With I2RS in particular, while crashes are certainly possible, being > able to look back at operations and correlate problems like packet loss, > service interruption, performance deviations, etc. will be vital from a > troubleshooting standpoint. > > Joe > > -- > Joe Marcus Clarke, CCIE #5384, | | > SCJP, SCSA, SCNA, SCSECA, VCP ||||| ||||| > Distinguished Services Engineer ..:|||||||||::|||||||||:.. > Phone: +1 (919) 392-2867 c i s c o S y s t e m s > Email: [email protected] > > > ---------------------------------------------------------------------------- >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
