On 5/3/16 09:22, Benoit Claise wrote:
I would like to DISCUSS the following point.
Thanks for your comments, Benoit. See below.
- 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. 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."
- 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].
Accepted.
- 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?
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.
- Editorial
PENDING: The request has been receieved and queued for
processing.
s/receieved/received
Accepted.
- 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?"
Joe
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
