--- 1/draft-ietf-netmod-syslog-model-07.txt 2016-05-10 14:16:01.623930753 -0700 +++ 2/draft-ietf-netmod-syslog-model-08.txt 2016-05-10 14:16:01.687932359 -0700 @@ -1,18 +1,18 @@ NETMOD WG C. Wildes, Ed. Internet-Draft K. Koushik, Ed. Intended status: Standards Track Cisco Systems Inc. -Expires: September 21, 2016 March 20, 2016 +Expires: November 11, 2016 May 10, 2016 SYSLOG YANG Model - draft-ietf-netmod-syslog-model-07 + draft-ietf-netmod-syslog-model-08 Abstract This document describes a data model for the Syslog protocol which is used to convey event notification messages. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. @@ -20,21 +20,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 21, 2016. + This Internet-Draft will expire on November 11, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -43,32 +43,34 @@ include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 3. Design of the SYSLOG Model . . . . . . . . . . . . . . . . . 3 - 3.1. SYSLOG Module . . . . . . . . . . . . . . . . . . . . . . 6 + 3.1. SYSLOG Module . . . . . . . . . . . . . . . . . . . . . . 5 4. SYSLOG YANG Models . . . . . . . . . . . . . . . . . . . . . 9 4.1. SYSLOG-TYPES Module . . . . . . . . . . . . . . . . . . . 9 - 4.2. Syslog Module . . . . . . . . . . . . . . . . . . . . . . 15 + 4.2. Syslog Module . . . . . . . . . . . . . . . . . . . . . . 14 4.3. A Syslog Example . . . . . . . . . . . . . . . . . . . . 29 - 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Normative References . . . . . . . . . . . . . . . . . . 32 8.2. Informative References . . . . . . . . . . . . . . . . . 33 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 + Appendix A. Implementor Guidelines . . . . . . . . . . . . . . . 33 + A.1. Extending Facilities . . . . . . . . . . . . . . . . . . 33 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 1. Introduction Operating systems, processes and applications generate messages indicating their own status or the occurrence of events. These messages are useful for managing and/or debugging the network and its services. The BSD Syslog protocol is a widely adopted protocol that is used for transmission and processing of the messages. Since each process, application and operating system was written @@ -80,21 +82,21 @@ Essentially, a Syslog process receives messages (from the kernel, processes, applications or other Syslog processes) and processes those. The processing involves logging to a local file, displaying on console, user terminal, and/or relaying to syslog processes on other machines. The processing is determined by the "facility" that originated the message and the "severity" assigned to the message by the facility. We are using definitions of Syslog protocol from [RFC5424] in this - draft. + RFC. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Problem Statement This document defines a YANG [RFC6020] configuration data model that @@ -113,65 +115,29 @@ 3. Design of the SYSLOG Model The syslog model was designed by comparing various syslog features implemented by various vendors' in different implementations. This draft addresses the common leafs between implementations and creates a common model, which can be augmented with proprietary features, if necessary. The base model is designed to be very simple for maximum flexibility. - Many vendors extend the list of facilities available for logging in - their implementation. Here is an example that shows how additional - facilities could be added to the list of available facilities (in - this case two facilities are added): - - module vendor-syslog-types { - namespace "urn:vendor:params:xml:ns:yang:vendor-syslog-types"; - prefix vendor-syslogtypes; - - import ietf-syslog-types { - prefix syslogtypes; - } - - organization "Vendor, Inc."; - contact - "Vendor, Inc. - Customer Service - - E-mail: syslog-yang@vendor.com"; - - description - "This module contains a collection of vendor-sprecific YANG type - definitions for SYSLOG."; - - revision 2016-03-20 { - description - "Version 1.0"; - reference - "Vendor SYSLOG Types: SYSLOG YANG Model"; - } - - identity vendor_specific_type_1 { - base syslogtypes:syslog-facility; - } - - identity vendor_specific_type_2 { - base syslogtypes:syslog-facility; - } - } - Syslog consists of message originators, and message distributors. The following digram shows syslog messages flowing from a message originator, to message distributors where suppression filtering can take place. + Many vendors extend the list of facilities available for logging in + their implementation. An example is included in Extending Facilities + (Appendix A.1). + Message Originators +-------------+ +-------------+ +-------------+ +-------------+ | Various | | OS | | | | Remote | | Components | | Kernel | | Line Cards | | Servers | +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ +-------------+ | SNMP | | Interface | | Standby | | Syslog | | Events | | Events | | Supervisor | | Itself | +-------------+ +-------------+ +-------------+ +-------------+ @@ -181,37 +147,40 @@ | | | | +-----------+------------+--------------+ | | | | v v v | Message Distributors | +----------+ +----------+ +----------+ | | | | Log | | Log | | - | Console | | Buffer(s)| | File(s) | | + | Console | | Buffer | | File(s) | | +----------+ +----------+ +----------+ | | +-------------+-------------+ | | | v v v +----------------+ +-----------+ +-----------+ |Remote Relay(s)/| | | |User | |Collectors(s) | |Terminal(s)| |Sessions(s)| +----------------+ +-----------+ +-----------+ + The leaves in the base syslog model log-input-transports container + correspond to remote message originators or remote message relays. + The leaves in the base syslog model log-actions container correspond to each message distributor: console - log buffer(s) + log buffer log file(s) remote relay(s)/collector(s) terminal(s) user session(s). Optional features are used to specified functionality that is present in specific vendor configurations. 3.1. SYSLOG Module @@ -253,62 +222,77 @@ is the name of the type for leafs and leaf-lists If the type is a leafref, the type is printed as "-> TARGET", where TARGET is either the leafref path, with prefixed removed if possible. is the list of features this node depends on, printed within curly brackets and a question mark "{...}?" module: ietf-syslog +--rw syslog + +--rw log-input-transports {syslog-relay}? + | +--rw receiver* [name] + | +--rw name string + | +--rw (transport) + | | +--:(tcp) + | | | +--rw tcp + | | | +--rw address? inet:host + | | | +--rw port? inet:port-number + | | +--:(udp) + | | | +--rw udp + | | | +--rw address? inet:host + | | | +--rw port? inet:port-number + | | +--:(tls) + | | +--rw tls + | | +--rw address? inet:host + | | +--rw port? inet:port-number + | +--rw structured-data? boolean {structured-data}? + | +--rw syslog-sign! {signed-messages}? +--rw log-actions - +--rw console! {console-action}? + +--rw console! | +--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 buffer {buffer-action}? - | +--rw log-buffer* [name] - | +--rw name string + | | +--rw compare-op? enumeration {select-sev-compare}? + | +--rw pattern-match? string {select-match}? + +--rw buffer | +--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 compare-op? enumeration {select-sev-compare}? + | | +--rw pattern-match? string {select-match}? | +--rw buffer-size-bytes? uint64 {buffer-limit-bytes}? - | +--rw buffer-size-messages? uint64 {buffer-limit-messages}? - | +--rw structured-data? boolean {structured-data-config}? + | +--rw structured-data? boolean {structured-data}? +--rw file | +--rw log-file* [name] | +--rw name inet:uri | +--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 structured-data? boolean {structured-data-config}? + | | | +--rw compare-op? enumeration {select-sev-compare}? + | | +--rw pattern-match? string {select-match}? + | +--rw structured-data? boolean {structured-data}? | +--rw file-archive | +--rw number-of-files? uint32 {file-limit-size}? | +--rw max-file-size? uint64 {file-limit-size}? | +--rw rollover? uint32 {file-limit-duration}? | +--rw retention? uint16 {file-limit-duration}? +--rw remote | +--rw destination* [name] | +--rw name string | +--rw (transport) | | +--:(tcp) @@ -324,81 +308,81 @@ | | +--rw address? inet:host | | +--rw port? inet:port-number | +--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 compare-op? enumeration {select-sev-compare}? + | | +--rw pattern-match? string {select-match}? | +--rw destination-facility? identityref | +--rw source-interface? if:interface-ref - | +--rw structured-data? boolean {structured-data-config}? - | +--rw syslog-sign! {signed-messages-config}? + | +--rw structured-data? boolean {structured-data}? + | +--rw syslog-sign! {signed-messages}? | +--rw cert-initial-repeat uint16 | +--rw cert-resend-delay uint16 | +--rw cert-resend-count uint16 | +--rw sig-max-delay uint16 | +--rw sig-number-resends uint16 | +--rw sig-resend-delay uint16 | +--rw sig-resend-count uint16 - +--rw terminal {terminal-action}? + +--rw terminal | +--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 compare-op? enumeration {select-sev-compare}? + | | +--rw pattern-match? string {select-match}? + | +--rw terminal* [name] {terminal-facility-device-logging}? | +--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}? - +--rw session {session-action}? + | | +--rw compare-op? enumeration {select-sev-compare}? + | +--rw pattern-match? string {select-match}? + +--rw session +--rw all-users! | +--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 user* [name] {session-facility-user-logging-config}? + | | +--rw compare-op? enumeration {select-sev-compare}? + | +--rw pattern-match? string {select-match}? + +--rw user* [name] {session-facility-user-logging}? +--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}? + | +--rw compare-op? enumeration {select-sev-compare}? + +--rw pattern-match? string {select-match}? 4. SYSLOG YANG Models 4.1. SYSLOG-TYPES Module file "ietf-syslog-types.yang" module ietf-syslog-types { namespace "urn:ietf:params:xml:ns:yang:ietf-syslog-types"; prefix syslogtypes; @@ -419,30 +403,29 @@ Editor: Kiran Agrahara Sreenivasa Editor: Clyde Wildes "; description "This module contains a collection of YANG type definitions for SYSLOG. - Copyright (c) 2015 IETF Trust and the persons identified as + Copyright (c) 2016 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Simplified BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info). - The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC XXXX (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; reference @@ -441,26 +424,25 @@ 'OPTIONAL' in the module text are to be interpreted as described in RFC 2119 (http://tools.ietf.org/html/rfc2119). This version of this YANG module is part of RFC XXXX (http://tools.ietf.org/html/rfcXXXX); see the RFC itself for full legal notices."; reference "RFC 5424: The Syslog Protocol"; - revision 2016-03-20{ + revision 2016-05-10 { description "Initial Revision"; reference "RFC XXXX: SYSLOG YANG Model"; - } typedef severity { type enumeration { enum "emergency" { value 0; description "Emergency Level Msg"; } enum "alert" { @@ -1419,35 +1403,36 @@ 5. Acknowledgements The authors wish to thank the following who commented on versions 01 through 06 of this proposal: - Martin Bjorklund - Jim Gibson - Jeffrey Haas - John Heasley - Giles Heron - Lisa Huang - Jeffrey K Lange - Jan Lindblad - Chris Lonvick - Tom Petch - Juergen Schoenwaelder - Jason Sterne - Peter Van Horne - Bert Wijnen - Aleksandr Zhdankin + Martin Bjorklund + Jim Gibson + Jeffrey Haas + John Heasley + Giles Heron + Lisa Huang + Mahesh Jethanandani + Jeffrey K Lange + Jan Lindblad + Chris Lonvick + Tom Petch + Juergen Schoenwaelder + Jason Sterne + Peter Van Horne + Bert Wijnen + Aleksandr Zhdankin 6. IANA Considerations This document registers two URIs in the IETF XML registry [RFC3688]. Following the format in RFC 3688, the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-syslog-types @@ -1469,21 +1455,23 @@ Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. This document registers a YANG module in the YANG Module Names registry [RFC6020]. name: ietf-syslog namespace: urn:ietf:params:xml:ns:yang:ietf-syslog - prefix: ietf-syslog reference: RFC XXXX + prefix: ietf-syslog + + reference: RFC XXXX 7. Security Considerations The YANG module defined in this memo is designed to be accessed via the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the secure transport layer and the mandatory-to-implement secure transport is SSH [RFC6242]. The NETCONF access control model [RFC6536] provides the means to restrict access for particular NETCONF users to a pre-configured subset of all available NETCONF protocol operations and content. @@ -1538,20 +1526,64 @@ [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . +Appendix A. Implementor Guidelines + +A.1. Extending Facilities + + Many vendors extend the list of facilities available for logging in + their implementation. Here is an example that shows how additional + facilities could be added to the list of available facilities (in + this case two facilities are added): + + module vendor-syslog-types-example { + namespace "urn:vendor:params:xml:ns:yang:vendor-syslog-types"; + prefix vendor-syslogtypes; + + import ietf-syslog-types { + prefix syslogtypes; + } + + organization "Vendor, Inc."; + contact + "Vendor, Inc. + Customer Service + + E-mail: syslog-yang@vendor.com"; + + description + "This module contains a collection of vendor-sprecific YANG type + definitions for SYSLOG."; + + revision 2016-03-20 { + description + "Version 1.0"; + reference + "Vendor SYSLOG Types: SYSLOG YANG Model"; + } + + identity vendor_specific_type_1 { + base syslogtypes:syslog-facility; + } + + identity vendor_specific_type_2 { + base syslogtypes:syslog-facility; + } + } + Authors' Addresses Clyde Wildes (editor) Cisco Systems Inc. 170 West Tasman Drive San Jose, CA 95134 US Phone: +1 408 527-2672 Email: cwildes@cisco.com