First, I hear and agree with Juergen's point that this is a second order problem. Still, if there are those interested in working on it and documenting what would be desirable, a bit of discussion isn't a bad thing.
Second, the minimum necessary seems to be an info model describing what should be saved so that the files can be structured. Third, we have the idea of multiple transports and transport channels in I2RS. I don't think I2RS wants to get into the game of file transfer or of reading it out message by message. Perhaps an operation to request the file transfer via a different channel (scp, ftp?) would address both concerns and allow a bit of experimentation with the multiple transport channel idea? Alia On Wed, Aug 14, 2013 at 6:38 PM, Joe Marcus Clarke <[email protected]>wrote: > 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
