Hi Joe,
Thanks for engaging.
- 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?
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:
"...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."
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.
- 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.
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?"
I let Menachem follow up on this one.
Regards, Benoit
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
