Subject: [i2rs] New Version Notification for draft-clarke-i2rs-traceability-02.txt

From: Joe Marcus Clarke <[email-masked]>
Date: Sat, 07 Jun 2014 19:47:08 -0400

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 07 Jun 2014 20:48:36 -0400

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.

Yours,
Joel

On 6/7/14, 7:47 PM, Joe Marcus Clarke wrote:
> Title:        Interface to the Routing System (I2RS) Traceability:
> Framework and Information Model
> 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:
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Mon, 09 Jun 2014 11:29:48 -0400

>   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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 09 Jun 2014 11:54:38 -0400

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

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 14:30:03 -0400

On Mon, Jun 09, 2014 at 11:29:48AM -0400, Joe Marcus Clarke wrote:
> 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.

FWIW, I find this version of the draft to be much improved.  A few comments:
- The yang module seems to have indentation issues.
- The log-entry-id key should receive a bit of documentation as to whether
  sequence number gaps are permitted. 

While I sympathize with Joel's point that "there are other systems that
provide logging, don't reinvent the wheel", being a relative newcomer to
yang myself I have to wonder if any of those systems provide for this type
of representation.

The usual pain point one has with syslog like services is the issues of
convoluted greps or other free-form parse to extract data from the stream
and the lack of structure.  Being able to know from day one that I can get
at this type of data using an XPath slice is very attractive.

If that kind of functionality is provided in other mechanisms, let's not
reinvent the wheel.  If it isn't, this wheel may be better.

-- Jeff

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jun 2014 15:02:26 -0400

In my personal view, it is clearly outside of our remit to reinvent 
logging, no matter whether we like it or not.
As such, the structural specificity of a YANG model (or ABNF) simply 
does not belong in this document.  The clarity about what fields will be 
logged is needed.

if we focus on the job we need done, we can do it.
If we get into fighting about how logs work, we will create confusion 
for operators without helping ourselves.

Yours,
Joel

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 15:34:34 -0400

> logging, no matter whether we like it or not.

Agreed.  Not in-scope for I2RS currently.

Where would you suggest such work be done?

> does not belong in this document.  The clarity about what fields
> will be logged is needed.

Would you agree that if the yang module is dropped that the info model is
sufficiently clear for I2RS purposes?

-- Jeff

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 10 Jun 2014 15:43:14 -0400

> Agreed.  Not in-scope for I2RS currently.

I want to be very clear that we are not trying to reinvent logging.

What we are trying to do is define _what_ should get logged within the 
I2RS scope.  _How_ that is logged (syslog, NETCONF, SNMP, etc.) is not 
within scope.  We don't want a new log protocol.  What we want is to 
ensure that implementors of I2RS have a model on which to base their 
traceability so that vendor X and vendor Y have consistency for a 
consumer using I2RS (while perhaps allowing for some extensibility down 
the road).

We (the authors) strongly feel there must be some core consistent 
elements of I2RS operations that must be logged, and that is all we are 
trying to define here.

> sufficiently clear for I2RS purposes?

To us, the YANG module simply represents a way to clearly articulate 
what the fields are [syntactically] from the I2RS protocol.  It isn't an 
attempt to discuss overall transmission or on-disk formats.

Joe

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 15:45:06 -0400

Joe,

On Tue, Jun 10, 2014 at 03:43:14PM -0400, Joe Marcus Clarke wrote:
> what the fields are [syntactically] from the I2RS protocol.  It
> isn't an attempt to discuss overall transmission or on-disk formats.

I must admit even as a netconf/yang newbie that the presence of a yang
module with a defined URN does strongly imply something that could be
implemented and retrieved using netconf.

Note that I agree with your point about logging consistency.

-- Jeff

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 21:51:16 +0200

> sufficiently clear for I2RS purposes?

I have been silently following this discussion and I do not have a
strong opinion but I think it might help to understand that

a) NETCONF has a notification mechanism (RFC 5277), and

b) SYSLOG has in its standards-track version support for carrying
   structured data (RFC 5424).

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 10 Jun 2014 15:55:23 -0400

>     structured data (RFC 5424).

Thanks, Juergen.  I was aware, and I feel that once we decide on what 
gets logged, then we can certainly use mechanisms like these down the 
road to answer the "how" question.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 10 Jun 2014 15:58:30 -0400

Yes, I would agree that if the YANG model is dropped the document is 
both useful and sufficiently clear.

Yours,
Joel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jun 2014 22:12:50 +0200

> road to answer the "how" question.

The text in section 4.1 made me believe you were not aware of
structured data in SYSLOG.

   [...] So, while the data contained within the
   syslog message would adhere to this information model, and may be
   consumable by a human operator, it would not be easily parseable by a
   machine.

/js

---

From: Joe Marcus Clarke <[email-masked]>
Date: Tue, 10 Jun 2014 16:14:20 -0400

>     consumable by a human operator, it would not be easily parseable by a

Ah, yes.  Good catch.  That can certainly be restated.  Thanks.

Joe

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 10 Jun 2014 20:42:11 +0000

Joel, Jeff, Juergen - 

As stated, the intent of this draft is to specify in a logging-agnostic manner the minimum mandatory elements for I2RS traceability.  I think we all agree this has real value and I don't view it as an obstacle in getting this work done (IMO in I2RS WG).

It seems the sticking point seems to be around the need for data modeling.  To be clear, there was no intent to constrain or specify a preferred logging format or protocol. In fact, this was intended to be similar to the model used for SIP CLF where a format-agnostic data model (RFC6872) can be accompanied by one or many format-specific specifications (RFC6873 as an example), as deemed necessary by the community.  The original ABNF and subsequent YANG was simply to provide a generic modeling of the mandatory logged elements that were described in the text with only the most minimal constraints possible imposed on character sets, etc based on the I2RS architecture.  This was aimed at providing operation simplicity for implementors.  If this goal is not met or if it is mis-interpreted as anything other than a logging format agnostic model, then it violates our prime directive and we can do one of three things:

1. Add supplementary clarifying text to the data modeling section explaining the intent described above.
2. If YANG is perceived as having more of a NETCONF bias we can go back to ABNF that is perhaps more universally viewed as protocol-agnostic.
3. Remove any data modeling elements from the draft entirely (ABNF or YANG or otherwise).

We're as interested as anyone in making sure this work remains logging format and protocol agnostic, so we will happily comply with the preferred WG direction.  To this point, could we perhaps adopt this work in the I2RS WG (presumably with all modeling removed) as a basis for defining the minimum mandatory elements needed for a traceability model for I2RS?

Thanks,

Gonzalo

On Jun 10, 2014, at 3:58 PM, Joel M. Halpern <[email-masked]> wrote:

> Yes, I would agree that if the YANG model is dropped the document is both useful and sufficiently clear.
> 
> Yours,
> Joel
>

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 10 Jun 2014 17:06:37 -0400

On Tue, Jun 10, 2014 at 08:42:11PM +0000, Gonzalo Salgueiro (gsalguei) wrote:
> We're as interested as anyone in making sure this work remains logging
> format and protocol agnostic, so we will happily comply with the preferred
> WG direction.  To this point, could we perhaps adopt this work in the I2RS
> WG (presumably with all modeling removed) as a basis for defining the
> minimum mandatory elements needed for a traceability model for I2RS?

As I've been telling people much of today in various correspondence, various
adoption calls will be going out shortly.  The traceability draft was one of
the candidates.

-- Jeff

---

From: "Gonzalo Salgueiro (gsalguei)" <[email-masked]>
Date: Tue, 10 Jun 2014 21:07:56 +0000

> adoption calls will be going out shortly.  The traceability draft was one of

Thanks, Jeff.  It would certainly help us from a cat herding perspective ;-)

-G