Alia
On Aug 14, 2013 1:29 PM, "Joel M. Halpern" <[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]>>> 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> 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
<https://www.ietf.org/mailman/listinfo/i2rs>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
