On 8/14/13 6:28 PM, Alia Atlas wrote: > Ah - I meant a structured file - so the contents are the written > data-model. Thus, a tool could get the file and parse through it to > find what was desirable. The structured file would be described in the > schema, extensible as always, to provide something better than syslog - > without asking the I2RS agent to add in that file parsing and reading > and such.
Yep, I understood that. I was going a step further and saying that because the I2RS architecture defines this information collection component, the same file could be collected as information. Thus one would always have a vendor-agnostic way to get to the file as well as parse it. At least to me, this notion seems as applicable to the scope as using information collection to get something orthogonal to routing such as CPU utilization. Joe > > Alia > > > On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke <[email protected] > <mailto:[email protected]>> wrote: > > 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]> > > <mailto:[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]>> > > >>> <mailto:[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]>>> > > >>> <mailto:[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> > > >>> <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]>>> > > >>> <mailto:[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]>> > > <mailto:[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]> <mailto:[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> > <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 > > > > > -- > 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]> > > > ---------------------------------------------------------------------------- > > -- 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
