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.
Alia On Wed, Aug 14, 2013 at 5:46 PM, Joe Marcus Clarke <[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]>> 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
