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

[Benoit Claise <[e-mail]>]

On 3/9/2018 2:27 AM, Adam Roach wrote:
> 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.
That makes sense.

Regards, B.
>
> /a
>
> .
>