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]>> 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> 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
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
