On 8/14/13 1:50 PM, Joel M. Halpern wrote: > Are you asking that the history data itself be readable with I2RS? I > really would not want to go there. Asking "who created the current > state, CLI or specific named I2RS client, might be reasonable.
I am suggesting the history (as well as current state) be readable via I2RS itself. In that manner it could be vendor-agnostic by which traceability can be done. Current state could be understand who installed a route and when (Client identifier and timestamp). But there could be conditions where a Client had a route installed then removed it. If you wanted to correlate a period of bad performance, you would like to be able to query I2RS to see what changed in a particular time frame. Joe > > Yours, > Joel > > On 8/14/13 1:44 PM, Joe Marcus Clarke wrote: >> 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
