On 8/14/13 1:35 PM, Alia Atlas wrote: > 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...
Yes, that was my point. This would be data that, in my mind, could be queriable via I2RS. Joe > > Alia > > On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <[email protected] > <mailto:[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]> > <mailto:[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> > <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]> > <mailto:[email protected] <mailto:[email protected]>> > > > > ------------------------------__------------------------------__---------------- > > > > > _________________________________________________ > i2rs mailing list > [email protected] <mailto:[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 > -- 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
