Tom, In the latest draft I have removed an action, some features and shortened more names.
I think that we are close to the minimum functionality that should be specified. Thanks, Clyde On 5/28/16, 4:36 AM, "t.petch" <ie...@btconnect.com> wrote: ><inline briefly> >Tom Petch > > >----- Original Message ----- >From: "Sterne, Jason (Nokia - CA)" <jason.ste...@nokia.com> >Sent: Friday, May 27, 2016 8:30 PM > >> Hi Clyde, >> >> I was a bit surprised to see the receiver/server side config in here >(log-input-transports). That seems to be a somewhat significant change >in scope. I thought the focus of this was more on the generation & >distribution. Do many implementations have functionality that maps to >this log-input-transports ? In any case the pyang tree has >log-input-transports but it doesn't seem to be down in the actual model >itself. But I'd be inclined to just remove this from the model. Maybe >Mahesh has some thoughts here (I didn't see a posting about this in the >mailing list). >> >> I agree there are multiple implementations of console, buffer and >session logs. But maybe 'terminal' should be removed or an if-feature ? >I'm not sure that one is so widespread (not in JUNOS, not in SR OS). >> >> Buffer-limit-messages and having multiple log buffers are both >supported by Nokia SR OS. I would think that both of those would have >support in other logging implementations as well. I'm not sure if Tom >P. was really concluding that there are no implementations of these in >his email. Do we have multiple examples of implementations that limit >log buffers using bytes ? >> > >My comment was more on the complexity that results from having so many >options. Other models are worse - some of the routing ones I find >unintelligible as a result - but I raised the issue on this model >because it is being discussed on this list where (almost) all the >expertise in these matters resides to see if anyone else would bite. > >I believe we will regret this complexity some years down the line but >see no way of forestalling this:-( > >I don't have direct knowledge of whether or not this feature is >widespread. > >Tom Petch > >> Buffer-limit-messages would be easy to do as an augmentation but >making the log-buffer a list is probably something we should just do >from the start. That is also consistent with all the other types of >actions (except console of course). The use case for multiple log >buffers is that you might sort/filter different types of log events into >different circular buffers (i.e. have one for really critical log >events, etc) for viewing on the node. >> >> Regards, >> Jason >> >> -----Original Message----- >> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of EXT Clyde >Wildes (cwildes) >> Sent: Tuesday, May 10, 2016 17:23 >> To: netmod@ietf.org >> Subject: Re: [netmod] I-D Action: >draft-ietf-netmod-syslog-model-08.txt >> >> Hi, >> >> This update to the draft-ietf-netmod-syslog-model-08 incorporates the >changes listed below based on feedback received. >> >> An additional revision to this draft will be necessary to finalize TLS >configuration leaves once the ietf-tls-client-server-model that the >NETCONF WG plans to spin out of the netconf-server-model draft is >available. >> >> Changes from feedback from Mahesh J: >> - added support for configuring a syslog server >> >> Changes from feedback from Tom P.: >> - removed four features for log action leaves console, buffer, >terminal and session since they are implemented by multiple vendors. >Lack of support for these actions can be indicated using a deviation. >> - removed feature buffer-limit-messages since implementation by any >vendor is unknown >> - renamed feature terminal-facility-user-logging-config to >terminal-facility-device-logging to shorten the name and to clarify >> - renamed feature session-facility-user-logging-config to >session-facility-user-logging to shorten the name >> - renamed feature selector-sevop-config to feature select-sev-compare >to shorten the name >> - renamed feature selector-match-config to feature select-match to >shorten the name >> - renamed feature structured-data-config to feature structured-data to >shorten the name >> - renamed feature signed-messages-config to feature signed-messages to >shorten the name >> - removed the log-buffer list and name from log-action buffer since im >plementation by any vendor is unknown >> - removed the word draft from section 1 >> - updated the copyright dates and the revision dates in the models >> - moved the example to an Appendix >> - removed e-mail addresses from the acknowledgement section >> >> Changes from feedback from Benoit: >> - rename module vendor-syslog-types to module >vendor-syslog-types-example >> >> >> Thanks, >> >> Kiran and Clyde >> >> >> >> >> On 5/10/16, 2:14 PM, "netmod on behalf of internet-dra...@ietf.org" ><netmod-boun...@ietf.org on behalf of internet-dra...@ietf.org> wrote: >> >> > >> >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >> >This draft is a work item of the NETCONF Data Modeling Language of >the IETF. >> > >> > Title : SYSLOG YANG Model >> > Authors : Clyde Wildes >> > Kiran Koushik >> > Filename : draft-ietf-netmod-syslog-model-08.txt >> > Pages : 35 >> > Date : 2016-05-10 >> > >> >Abstract: >> > This document describes a data model for the Syslog protocol which >is >> > used to convey event notification messages. >> > >> > >> >The IETF datatracker status page for this draft is: >> >https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ >> > >> >There's also a htmlized version available at: >> >https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-08 >> > >> >A diff from the previous version is available at: >> >https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-08 >> > >> > >> >Please note that it may take a couple of minutes from the time of >> >submission until the htmlized version and diff are available at >tools.ietf.org. >> > >> >Internet-Drafts are also available by anonymous FTP at: >> >ftp://ftp.ietf.org/internet-drafts/ >> > >> >_______________________________________________ >> >netmod mailing list >> >netmod@ietf.org >> >https://www.ietf.org/mailman/listinfo/netmod >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
