Yes, I agree that requiring someyhing like transport mirroring would be unfortunate.
I also don't think that we should be defining required syslog messages. But the interesting question is whether something reasonable could be done for vendor-agnostic traceability... Alia On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <[email protected]> wrote: > These look like things outside of the scope of I2RS> I would not want to > define message mirroring as part of the transport protocol requirements, > for example. > > yours, > Joel > > On 8/14/13 12:39 PM, Alia Atlas wrote: > >> 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] >> <mailto:[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 <tel:%2B1%20%28919%29%20392-**2867> >> c >> i s c o S y s t e m s >> Email: [email protected] <mailto:[email protected]> >> >> ------------------------------**------------------------------** >> ---------------- >> >> >> >> >> ______________________________**_________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/**listinfo/i2rs<https://www.ietf.org/mailman/listinfo/i2rs> >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
