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.


_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to