Subject: [netmod] Adam Roach's No Objection on draft-ietf-netmod-syslog-model-23: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Thu, 08 Mar 2018 00:18:55 -0800

Adam Roach has entered the following ballot position for
draft-ietf-netmod-syslog-model-23: No Objection

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-netmod-syslog-model/

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

One quick comment on the model for the console:

            +--rw console! {console-action}?
            |  +--rw facility-filter
            |  |  +--rw facility-list* [facility severity]
            |  |     +--rw facility            union
            |  |     +--rw severity            union
            |  |     +--rw advanced-compare {select-adv-compare}?
            |  |        +--rw compare?   enumeration
            |  |        +--rw action?    enumeration
            |  +--rw pattern-match?     string {select-match}?

Syslog can be (and frequently is) configured to log to "console" on a
non-default tty. It's not clear from this model how this would be configured or
indicated. Is the assumption here that all non-default-console tty logging
would be handled by the "file" portion of the tree? If so, it would be worth
indicating so explicitly, and noting that such an approach is limited to those
systems that present ttys as a part of the filesystem. Alternately, it might
make sense to add a tty field to the "console" subtree to report/configure this
value.

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Thu, 8 Mar 2018 18:18:48 +0000

Adam,

An earlier version of the model (draft-ietf-netmod-syslog-model-08 and prior) included “terminal” as a syslog destination which addresses your requirement below:

            +--rw terminal {terminal-action}?
            |  +--rw all-terminals!
            |  |  +--rw log-selector
            |  |     +--rw (selector-facility)
            |  |     |  +--:(no-log-facility)
            |  |     |  |  +--rw no-facilities?   empty
            |  |     |  +--:(log-facility)
            |  |     |     +--rw log-facility* [facility]
            |  |     |        +--rw facility             union
            |  |     |        +--rw severity             union
            |  |     |        +--rw severity-operator?   enumeration {selector-sevop-config}?
            |  |     +--rw pattern-match?   string {selector-match-config}?
            |  +--rw terminal* [name] {terminal-facility-user-logging-config}?
            |     +--rw name            string
            |     +--rw log-selector
            |        +--rw (selector-facility)
            |        |  +--:(no-log-facility)
            |        |  |  +--rw no-facilities?   empty
            |        |  +--:(log-facility)
            |        |     +--rw log-facility* [facility]
            |        |        +--rw facility             union
            |        |        +--rw severity             union
            |        |        +--rw severity-operator?   enumeration {selector-sevop-config}?
            |        +--rw pattern-match?   string {selector-match-config}?

A consensus of the group was that it was best to remove this destination in the model as a simplification, and that vendors that supported same could add it back through an augmentation.

Thanks,

Clyde

On 3/8/18, 12:19 AM, "Adam Roach" <[email-masked]> wrote:

---

From: Adam Roach <[email-masked]>
Date: Thu, 8 Mar 2018 19:27:02 -0600

> A consensus of the group was that it was best to remove this destination in the model as a simplification, and that vendors that supported same could add it back through an augmentation.

Thanks for the history -- that's useful to know. I don't have any desire 
to re-open a settled issue, so please don't read my response as a 
request to go back to the older, more complex model.

My concern now is that the unstated assumption above isn't indicated in 
the document; and absent such a treatment, I fear that some vendors may 
do what you expect (extend the model), while some may do what I 
mentioned (expect terminal syslog output to be provisioned via a special 
filesystem node using the "file" subtree). This ambiguity doesn't seem 
ideal.

I would suggest that the document have text specifically indicating that 
terminal output with requirements more complex than the console subtree 
currently provides are expected to be supported via vendor extensions 
rather than handled via the file subtree.

/a

---

From: Benoit Claise <[email-masked]>
Date: Fri, 9 Mar 2018 15:09:39 +0100

On 3/9/2018 2:27 AM, Adam Roach wrote:
>> An earlier version of the model (draft-ietf-netmod-syslog-model-08 
>> and prior) included “terminal” as a syslog destination which 
>> addresses your requirement below:
>>
>> A consensus of the group was that it was best to remove this 
>> destination in the model as a simplification, and that vendors that 
>> supported same could add it back through an augmentation.
>
> Thanks for the history -- that's useful to know. I don't have any 
> desire to re-open a settled issue, so please don't read my response as 
> a request to go back to the older, more complex model.
>
> My concern now is that the unstated assumption above isn't indicated 
> in the document; and absent such a treatment, I fear that some vendors 
> may do what you expect (extend the model), while some may do what I 
> mentioned (expect terminal syslog output to be provisioned via a 
> special filesystem node using the "file" subtree). This ambiguity 
> doesn't seem ideal.
>
> I would suggest that the document have text specifically indicating 
> that terminal output with requirements more complex than the console 
> subtree currently provides are expected to be supported via vendor 
> extensions rather than handled via the file subtree.
That makes sense.

Regards, B.
> .

---

From: "Clyde Wildes (cwildes)" <[email-masked]>
Date: Wed, 14 Mar 2018 21:02:11 +0000

Adam,

A new draft will be published soon that addresses your concern and I have used your wording.

Thanks,

Clyde

On 3/9/18, 6:09 AM, "Benoit Claise (bclaise)" <[email-masked]> wrote:

    That makes sense.
    
    Regards, B.