Hi, Lots of improvement. Just some minor details I noticed...
SYSLOG-MSG field: RFC 5424 is mentioned in the 2nd usage, not the first. Should be a citation -- SYSLOG-MSG field [RFC5424] Page header says 'Abbreviated Title' (the template placeholder text). I suggest 'Syslog Management' (consistent with RFC 8022) p5: The severity is one of syslogtypes:severity perhaps: The severity is one of: type "syslogtypes:severity" Actions are to log perhaps: Actions are used to log Andy On Tue, Feb 21, 2017 at 1:28 PM, Kent Watsen <[email protected]> wrote: > Thanks for the update you Clyde! > > > > Alex/Andy, since this update was made per comments you made during Last > Call, can you please confirm that it does indeed address your concerns, and > doesn't add any new ones? > > > > Thanks, > > Kent > > > > On 2/14/17, 8:31 AM, "netmod on behalf of Clyde Wildes (cwildes)" < > [email protected] on behalf of [email protected]> wrote: > > > > Hi, > > > > I just posted draft-ietf-netmod-syslog-model-12 which addresses the > concerns that Alex and Andy raised in their review of draft 11. > > > > Changes from draft 11 to draft 12 can be seen at this link: > > https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-syslog- > model-11&url2=draft-ietf-netmod-syslog-model-12&difftype=--hwdiff > > > > Please review and comment. > > > > Thanks, > > > > Clyde > > > > *From: *"Clyde Wildes (cwildes)" <[email protected]> > *Date: *Wednesday, January 11, 2017 at 2:54 PM > *To: *Andy Bierman <[email protected]> > *Cc: *Alex Campbell <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > Any > > > > My comments inline as [clyde2]… > > > > *From: *Andy Bierman <[email protected]> > *Date: *Saturday, December 31, 2016 at 8:24 AM > *To: *"Clyde Wildes (cwildes)" <[email protected]> > *Cc: *Alex Campbell <[email protected]>, "[email protected]" < > [email protected]> > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > > > > > On Fri, Dec 30, 2016 at 10:16 AM, Clyde Wildes (cwildes) < > [email protected]> wrote: > > Hi Andy, > > > > Thanks for taking the time to review the model. > > > > My comments are inline as [clyde]… > > > > *From: *netmod <[email protected]> on behalf of Andy Bierman < > [email protected]> > *Date: *Tuesday, December 27, 2016 at 3:04 PM > *To: *Alex Campbell <[email protected]> > *Cc: *"[email protected]" <[email protected]> > *Subject: *Re: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > > > Hi, > > > > I am also considering an implementation. > > I share the same concerns that Alex has brought up. > > > > Some detailed comments: > > > > 1) /syslog/actions: seems like everything is in this container. > > Why is it needed? Seems like it could be removed as it serves no purpose > > > > [clyde] Although this model is currently designated as config only, we > could add operational data and rpc leaves in the future. The actions > container is to future-proof the model. > > > > 2) 8 features: the granularity seems wrong. The main container for each > section > > should have its own if-feature > > /console > > /buffer > > /file > > /remote > > > > [clyde] We have gone back and forth on this…some have complained that > there are too many features. I will be happy to add a feature for each > action. Note that we studied the implementation of each action by six > vendors including Linux and opted to not add features for actions > implemented by at least 3 vendors. Vendors not implementing an action could > create a deviation. > > > > > > I prefer 1 mandatory-to-implement and a minimal number of additional > options. > > > > /console > > /file > > /remote > > > > These are all mandatory-to-implement.. > > IMO only /file should be mandatory-to-implement. > > > > [clyde2] I will remove the buffer and session actions in the next draft > and will make the remaining three features. > > > > > > 3) What is the 'buffer' container for? > > How is the internal memory accessed by the client? > > > > [clyde] buffer is implemented by vendors typically for routers capable of > generating many syslog messages in event-storm bursts. Logging to memory > (aka buffer) allows the preservation of syslog messages which might > otherwise be lost. > > > > > > > > IMO it should be removed from the draft. > > We certainly have changed the IETF NM focus. > > In SNMP-land we routinely left the configuration out of scope > > and standardized the monitoring. Now we are standardizing > > the configuration and leaving the monitoring out of scope? > > I prefer complete standard solutions only. > > > > There is no standard way to access the /console either. > > Since the console provides "show log" I really do not see a need for > > /buffer at all. > > > > [clyde2] The buffer action will be removed. > > A “show log” command is used to access the buffers. As this model is > current designed as a configuration only model, there is no operational > leaves for show log, or rpc leaves for clear log. > > > > 4) selector-facility: Seems like no-facilities servers the same purpose > > as an empty facility-list. The choice is not needed; just use the > facility-list > > > > [clyde] This was changed as a result of Alex’s feedback – please see my > response to him. The model will be changed to the following: > > > > container selector { > > description > > "This container describes the log selector parameters > > for syslog."; > > list facility-list { > > key facility; > > description > > "This list describes a collection of syslog > > facilities and severities."; > > leaf facility { > > type union { > > type identityref { > > base syslogtypes:syslog-facility; > > } > > type enumeration { > > enum all { > > description > > "This enum describes the case where all > > facilities are requested."; > > } > > } > > } > > description > > "The leaf uniquely identifies a syslog facility."; > > } > > uses log-severity; > > } > > leaf pattern-match { > > if-feature select-match; > > type string; > > description > > "This leaf desribes a Posix 1003.2 regular expression > > string that can be used to select a syslog message for > > logging. The match is performed on the RFC 5424 > > SYSLOG-MSG field."; > > } > > > > > > 5) pattern-match: > > > > leaf pattern-match { > > if-feature select-match; > > type string; > > description > > "This leaf desribes a Posix 1003.2 regular expression > > string that can be used to select a syslog message for > > logging. The match is performed on the RFC 5424 > > SYSLOG-MSG field."; > > } > > > > The field SYSLOG-MSG is referenced but never defined or listed in > the terminology section. > > > > [clyde] This will be fixed in the next draft. > > > > 6) how are the syslog-facility identities mapped to SYSLOG messages? > > 6a) how to distinguish acme:foo-facility from example:foo-facility in a > SYSLOG message? > > > > [clyde] I do not understand your question. The current implementation of > facilities was designed with the help of several Yang Doctors. The > requirement is to support the facilities as called out in RFC 5424 as well > as vendor specific facilities that can be added through augmentation. > Vendor specific facilities are not meant to be used across multiple vendor > implementations. > > > > > > > > The filter is based on an identityref, which is a module-qualified name, > > e.g., acme:foo-facility and example:foo-facility are different entities. > > In the syslog message, only the string foo-facility will be present. > > The draft claims to provide extensible facilities,(see A.1) but it only > > seems to work if the identities do not contain any duplicates. > > > > > > [clyde2] In my experience looking at multiple vendor implementations I did > not see any duplicates. If you have a suggestion on another way to extend > facilities, I am all ears. > > > > 7) source-interface: what if the server does not let a source interface be > used and instead > > normal routing determines the source interface (this leaf is very > router-centric) > > > > [clyde] source-interface is optional. If not specified normal routing flow > would be used. > > > > 8) signing-options: are these widely deployed on all routers and Linux > hosts? > > > > [clyde] Alex Clemm asked that we include syslog signing-options. This is > implemented by at least Linux rsyslog. > > > > 9) logrotate: there are several features related to log file cleanup > allowing lots of > > server variability and forces the client to support all the options. > Can't this be simplified > > and all the micro-behavior YANG features removed? > > > > [clyde] This was designed by merging the requirements from several > vendors. All of the variants specified are with if-feature so that the > client does not have to support all options. > > > > > > There seems to be some procedures implied by these YANG objects, > > but it is not specified. > > > > The 4 different methods (each with its own feature), are in a container. > > Since container 'file-rotation' is in list 'log-file', the rotation variant > > can be different for every file. Is this really how implementations work? > > > > [clyde2] We consolidated the requirements from multiple vendors. > > > > Juniper log file archiving is available via a global setting or on an > individual file – both number of files and file size are supported. See > https://www.juniper.net/documentation/en_US/junos12.3/ > information-products/topic-collections/syslog-messages/ > index.html?jd0e921.html > > > > Cisco log file archiving is specified for an individual file. File size > and optionally a hard code maximum number of bytes set aside for logging or > a percent of total disk space available for logging may be specified. > > http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/esm/ > command/esm-cr-book/esm-cr-a1.html#wp8708534740 > > > > Alcatel-Lucent log file archiving is specified for an individual file and > supports rollover in minutes and retention in hours. > > https://infoproducts.alcatel-lucent.com/html/0_add-h-f/93- > 0071-10-01/7750_SR_OS_System_Management_Guide/Logcli.html#1038301 > > > > The server is free to support from none to all of the archiving features > (note: they are specified as features). > > > > > > Also, the different parameters in this container can interact if the server > > supports more than 1 feature. The draft does not say anything about > > combining them. > > > > E.g.: > > > > leaf number-of-files { > > if-feature file-limit-size; > > type uint32; > > description > > "This leaf specifies the maximum number of log > > files retained. Specify 1 for implementations > > that only support one log file."; > > } > > > > How does the client know if the server only supports 1 file or not? > > This should really be revisions, since these files are per log-file list > entry. > > > > [clyde2] Make the default 1? > > > > If only 1 revision of the log-file is retained, then the meaning of the > other > > leafs is unclear. If there is only 1 log-file revision, then what happens > > if the max-file-size # of megabytes, rollover # of minutes, or retention # > of hours > > is reached? Does syslog monitoring stop for the log-file entry? > > > > [clyde2] If one log-file is specified and max-file-size is specified, the > single file is overwritten when max-file-size limit is encountered. > > > > How does the client access different revisions of the log file? Or even > list them? > > How does the client know the current size of lifetime of the log-file > > They do not have names. Is it assumed they will be the log-file/name field > > appended with ".1", ".2", etc.? > > > > [clyde2] There is no attempt to support oper data in this model. > > > > > > Thanks, > > > > Clyde > > 10) numeric limits: there is some odd usage of YANG types; some limits are > uint64, some uint32, > > some uint16. Seems like uint32 is sufficient > > > > [clyde] The signing-options counts are as per the syslog-sign spec (RFC > 5848) which is uint16. I will make all others uint32 except for the buffer > size limit which I will leave at unit64. > > > > Result: > > <seven signing-options counters> uint16 > > buffer-limit-bytes uint64 > > buffer-limit-messages uint32 (was formally uint64) > > number-of-files uint32 > > max-file-size uint32 (was formally uint64) > > rollover unit32 > > retention unit32 (was formally uint16) > > > > > > Thanks, > > > > Clyde > > > > > > > > > > > > Andy > > > > > > Andy > > > > > > On Tue, Dec 13, 2016 at 8:16 PM, Alex Campbell <[email protected]> > wrote: > > I am considering to implement the data model in this draft. > > I have reviewed this draft and found the following issues. In > approximately decreasing order of severity: > > * In the "selector-facility" choice statement the cases have misleading > names - the case where no facility is matched is named "facility", and the > case where specific facilities are matched is named "name". I suggest > "no-facilities" and "specified-facilities", or similar. > > * I disagree with the premise of the "no-facilities" case, which is that > it can be used to disable a log action, according to the description: > > description > "This case specifies no facilities will match when > comparing the syslog message facility. This is a > method that can be used to effectively disable a > particular log-action (buffer, file, etc)."; > > If an administrator wants to disable a log action they should do it by > either removing it from the configuration, or by setting an "enabled" leaf > to false. > With that in mind, there is no reason for the "no-facilities" case to > exist. > > * What is the behaviour of a selector if neither "no-facilities" nor > "facility-list" is present? > * In the "selector" grouping it is not clear how the facility and pattern > conditions are combined to decide whether a message is selected. > Must they both match the message, or is it sufficient for either one to > match the message? > * Not all servers have a console; there should be a feature to indicate > whether logging to the console is supported. > * Likewise, not all servers may support logging to user sessions. > * Likewise, not all servers may support a user-accessible filesystem. > * RFC 5424 states that the severity and protocol values are not normative. > * It's not clear to me why this needs to be split into two modules. Is it > so that other modules can define logging parameters but still be usable on > a device without syslog? > * "log-severity" defines a severity filter, not a severity, so its name is > misleading. > * Perhaps the "severity" type and the facility identities should have > "reference" statements referring to RFC 5424, rather than referring to it > in the description. > * In section "8.2", "admisintrator" is a typo. > > I assume that the means of accessing the memory buffer and log files are > out of scope of this data model. > > Alex > > ________________________________________ > From: netmod <[email protected]> on behalf of Kent Watsen < > [email protected]> > Sent: Wednesday, 14 December 2016 2:01 p.m. > To: [email protected] > Subject: [netmod] WG Last Call for draft-ietf-netmod-syslog-model-11 > > This is a notice to start a two-week NETMOD WG last call for the document: > > A YANG Data Model for Syslog Configuration > https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-11 > > Please indicate your support or concerns by Tuesday, December 27, 2016. > > We are particularly interested in statements of the form: > * I have reviewed this draft and found no issues. > * I have reviewed this draft and found the following issues: ... > > As well as: > * I have implemented the data model in this draft. > * I am implementing the data model in this draft. > * I am considering to implement the data model in this draft. > * I am not considering to implement the data model in this draft. > > Thank you, > NETMOD WG Chairs > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
