I agree that describing clearly the information to be logged is very
important. I not not think it takes either an ABNF or a YANG
description to do that. Just a list of:
The following events are to be logged;
The following information is to be included in log entries.
You could include a note that the internal format of the log entry is
implementation dependent and the reporting format will depend upon the
protocol being used to report the log.
As written I think it will cause many readers to leap to conclusions you
do not intend.
Yours,
Joel
On 6/9/14, 11:29 AM, Joe Marcus Clarke wrote:
On 6/7/14, 8:48 PM, Joel M. Halpern wrote:
The model in section 5.1, and the requiremenets in section 5.2 make good
sense to me.
Given that there already exist high volume log collection protocols,
with their own modeling, it seems that the log itself ought to be the
domain of such systems (syslog et. al.) rather than the domain of I2RS.
Thus I find section 5.5 confusing.
Thanks for the read-through, Joel. The reason we wanted to bring this
up in I2RS is that many times new protocols are built without intrinsic
traceability. This results in implementors choosing their own ways to
implement debugging, logging, etc. Coming from a support background, we
wanted to try and chance that with I2RS.
Thus, section 5.5 is an attempt to model the important bits of the log
so that the diagnostics one gets from I2RS are complete. The specific
on-the-wire formats (syslog, NETCONF notifications, SNMP notifications,
etc.) would certainly be left to those domains. But the fields that
must be logged and what those fields should look like seems to fit
squarely in the domain or I2RS.
Joe
Yours,
Joel
On 6/7/14, 7:47 PM, Joe Marcus Clarke wrote:
This update to i2rs-traceability addresses the comments made by Dean
concerning the Actor ID as well as changes the ABNF model to a YANG
model. The figure has been updated to convey some UML semantics similar
to what was done in the RIB info model.
As always, comments are appreciated.
Joe
===
A new version of I-D, draft-clarke-i2rs-traceability-02.txt
has been successfully submitted by Joe Clarke and posted to the
IETF repository.
Name: draft-clarke-i2rs-traceability
Revision: 02
Title: Interface to the Routing System (I2RS) Traceability:
Framework and Information Model
Document date: 2014-06-07
Group: Individual Submission
Pages: 19
URL:
http://www.ietf.org/internet-drafts/draft-clarke-i2rs-traceability-02.txt
Status: https://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/
Htmlized:
http://tools.ietf.org/html/draft-clarke-i2rs-traceability-02
Diff: http://www.ietf.org/rfcdiff?url2=draft-clarke-i2rs-traceability-02
Abstract:
This document describes a framework for traceability in the
Interface
to the Routing System (I2RS) and information model for that
framework. It specifies the motivation, requirements, use cases,
and
defines an information model for recording interactions between
elements implementing the I2RS protocol. This framework provides a
consistent tracing interface for components implementing the I2RS
architecture to record what was done, by which component, and when.
It aims to improve the management of I2RS implementations, and
can be
used for troubleshooting, auditing, forensics, and accounting
purposes.
Please note that it may take a couple of minutes from the time of
submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
