Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-traceability-09: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Tue, 03 May 2016 06:22:25 -0700

Benoit Claise has entered the following ballot position for
draft-ietf-i2rs-traceability-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to DISCUSS the following point.
- From
https:/https://tools.ietf.org/html/draft-ietf-i2rs-pub-sub-requirements-06,
section 2.1

       From [i2rs-arch], there are
       references throughout the document beginning in section 6.2. 
Some
       specific examples include:

       ... 

       o  section 6.3 notes that when local config preempts I2RS,
external
          notification might be necessary

What about the local configuration,
https://tools.ietf.org/html/draft-ietf-i2rs-architecture-15#section-6.3 ?
Is this logged? 
>From the client address, it seems that local is not covered. Should it
be?

   Client Address:   This is the network address of the Client that
      connected to the Agent.  For example, this may be an IPv4 or IPv6
      address.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- Syslog rfc5424

Let's make the RFC2119 sentence clear (include the "If", and remove
"example")
Background: last time I checked (about 6 months ago), RFC5424 was not
implemented
OLD:
   If syslog is used for trace log retrieval, then existing logging
   infrastructure and capabilities of syslog [RFC5424] should be
   leveraged without the need to define or extend existing formats.  For
   example, the various fields described in Section 5.2 SHOULD be
   modeled and encoded as Structured Data Elements (referred to as "SD-
   ELEMENT"), as described in Section 6.3.1 of [RFC5424].

NEW:
   If syslog is used for trace log retrieval, then existing logging
   infrastructure and capabilities of syslog [RFC5424] should be
   leveraged without the need to define or extend existing formats.  
   If syslog is used for trace log retrieval, the various fields 
   described in Section 5.2 SHOULD be modeled and encoded as 
   Structured Data Elements (referred to as "SD-
   ELEMENT"), as described in Section 6.3.1 of [RFC5424].

- Out of the 3 methods for trace log retrieval (section 7.4), I was
expecting the pub-sub to be THE method, and was expecting a MUST
requirement.
Background: I just reviewed draft-ietf-i2rs-pub-sub-requirements-06. 
Do I miss anything? 

- Editorial

         PENDING: The request has been receieved and queued for
             processing.

    s/receieved/received 

- Below is Menachem's question, part of his OPS-DIR review:
As section 5.2 is labeled "I2RS Trace Log Mandatory Fields", I am
wondering whether it is allowed to have additional optional fields. For
example an optional "Additional Text" field may be useful, to provide
additional information in certain situations.

---

From: Joe Clarke <[email-masked]>
Date: Tue, 3 May 2016 10:35:47 -0400

> I would like to DISCUSS the following point.

Thanks for your comments, Benoit.  See below.

>>From the client address, it seems that local is not covered. Should it

I am of the opinion that I2Rs-relevant preemptive changes to the running 
datastore should behave like an I2RS Client.  I know this isn't the case 
now.  The current traceability model requires logging to be done by the 
I2RS Agent.  If an I2RS-relevant change to the running datastore is 
passed to the Agent, then the Agent MUST log it.  In this manner I would 
say we should add some text to the description of Client Address that 
makes it clear that the Client can be the network element itself.  What 
about:

"...an IPv4 or IPv6 address.  In the case where changes to the network 
element's running datastore preempt state set by the I2RS Agent, the 
Client Address will be an address of the network element itself."

>    ELEMENT"), as described in Section 6.3.1 of [RFC5424].

Accepted.

> Background: I just reviewed draft-ietf-i2rs-pub-sub-requirements-06.

We can certainly make it a MUST.  When our draft began, pub-sub was just 
getting started.  I personally like having pub-sub as THE method.

>          PENDING: The request has been receieved and queued for

Accepted.

> additional information in certain situations.

It seems a bit nebulous to me.  I know this isn't your comment, but I 
would appreciate an example of additional context one might want to log. 
  I imagine if we added that others might ask, "like what?  In what 
situations?"

Joe

---

From: Benoit Claise <[email-masked]>
Date: Tue, 3 May 2016 16:50:45 +0200

Hi Joe,

Thanks for engaging.
> I am of the opinion that I2Rs-relevant preemptive changes to the 
> running datastore should behave like an I2RS Client.  I know this 
> isn't the case now.
"I'll create a new management interface, and since all changes, ever, 
will come through my new management interface, I won't have any problem!"
You and I heard that story a couple of time in our OPS careers, right 
:-) Did that behavior ever end up as expected?
> The current traceability model requires logging to be done by the I2RS 
> Agent.  If an I2RS-relevant change to the running datastore is passed 
> to the Agent, then the Agent MUST log it.  In this manner I would say 
> we should add some text to the description of Client Address that 
> makes it clear that the Client can be the network element itself.  
> What about:
>
That solves one aspect of the problem.

The fact is that we have multiple management interfaces to manage what 
I2RS care about. At the very minimum two: CLI and the I2RS agent.
The I2RS agent will log what it knows. Obviously, it doesn't know what 
it doesn't know. Assuming that someone uses the CLI, the log will be 
useless.
At the very minimum, we need a big capital letter warning: your log 
might not be as useful as they pretend to be.

> would appreciate an example of additional context one might want to 
> log.  I imagine if we added that others might ask, "like what?  In 
> what situations?"
I let Menachem follow up on this one.

Regards, Benoit

---

From: Joe Clarke <[email-masked]>
Date: Tue, 3 May 2016 11:20:48 -0400

> :-) Did that behavior ever end up as expected?

Of course.  I do everything via SNMP :-).

> might not be as useful as they pretend to be.

Is that warning really required?  Architecturally, the I2RS Agent is 
clearly in the path.  If the I2RS Agent knows about a change (either via 
a northbound Client or the network element preempting state), then it 
logs it.  If a network element chooses not to notify the Agent, then 
like you say, we can't log what we don't know.

If you feel strongly that this be explicitly called out, I think the 
best section might be "Trace Log Creation".  It could be stated that 
preemptive changes outside the I2RS protocol in which the network 
element does not notify the Agent of state will not be logged.

Joe

---

From: Benoit Claise <[email-masked]>
Date: Wed, 4 May 2016 12:11:49 +0200

Joe,
> clearly in the path.  If the I2RS Agent knows about a change (either 
> via a northbound Client or the network element preempting state), then 
> it logs it.  If a network element chooses not to notify the Agent, 
> then like you say, we can't log what we don't know.
The issue is that the I2RS architecture is not really an architecture.
https://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/ballot/#benoit-claise
Anyway ...
> preemptive changes outside the I2RS protocol,
> in which the network element does not notify the Agent of state will 
> not be logged.
Agreed that this is the best we can do. That would solve my DISCUSS. 
Please add "typically local configuration", as this is mentioned in 
different I2RS documents.

Regards, B.

> .

---

From: Joe Clarke <[email-masked]>
Date: Fri, 13 May 2016 11:37:09 -0400

> different I2RS documents.

We just posted rev -10 of the draft, Benoit.  Thanks again for the review.

Joe