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

[Adam Roach <[e-mail]>]

On 3/8/18 12:18 PM, Clyde Wildes (cwildes) wrote:
> 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 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