On 8/14/13 5:35 PM, Alia Atlas wrote: > I can see having it in a file for displaying or sending - but actually > having the I2RS agent crawl through it to report the data back???
A file/buffer is fine, but will lead to vendor-specific ways of getting at the data. As I read the architecture concerning information collection, I thought this might be very useful information for a Client to collect from the Agent. I know Joel disagrees in favor of syslog. I think syslog is okay, but only if you're receiving messages since the beginning of time (i.e., before a problem is identified). While I very well may be off base here, having the a record of what Clients did what on a particular Agent in a vendor-agnostic way as information to be collected via I2RS seemed reasonable. Joe > > Alia > > > On Wed, Aug 14, 2013 at 4:18 PM, Joe Marcus Clarke <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > >>> <mailto:[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]>> > >>> <mailto:[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> > >>> <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]>> > >>> <mailto:[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> > >>> > >>> > >>> > >>> > > ------------------------------__------------------------------__---------------- > >>> > >>> > >>> > >>> > >>> > >>> _________________________________________________ > >>> i2rs mailing list > >>> [email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > >>> https://www.ietf.org/mailman/__listinfo/i2rs > >>> <https://www.ietf.org/mailman/listinfo/i2rs> > >>> > >>> > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> [email protected] <mailto:[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 <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 > -- 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
