text:
RFC5424: The Syslog Protocol
Download in PDF format Download in text format
Related keywords:
(event notification message)
(syslog message)
Network Working Group R. Gerhards Request for Comments: 5424 Adiscon GmbH Obsoletes: 3164 March 2009 Category: Standards Track The Syslog Protocol Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Gerhards Standards Track [Page 1] RFC 5424 The Syslog Protocol March 2009 Abstract This document describes the syslog protocol, which is used to convey event notification messages. This protocol utilizes a layered architecture, which allows the use of any number of transport protocols for transmission of syslog messages. It also provides a message format that allows vendor-specific extensions to be provided in a structured way. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard needs to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature rather than once for each transport. This document obsoletes RFC 3164. Table of Contents 1. Introduction ....................................................4 2. Conventions Used in This Document ...............................4 3. Definitions .....................................................4 4. Basic Principles ................................................5 4.1. Example Deployment Scenarios ...............................6 5. Transport Layer Protocol ........................................7 5.1. Minimum Required Transport Mapping .........................7 6. Syslog Message Format ...........................................8 6.1. Message Length .............................................9 6.2. HEADER .....................................................9 6.2.1. PRI .................................................9 6.2.2. VERSION ............................................11 6.2.3. TIMESTAMP ..........................................11 6.2.4. HOSTNAME ...........................................13 6.2.5. APP-NAME ...........................................14 6.2.6. PROCID .............................................14 6.2.7. MSGID ..............................................14 6.3. STRUCTURED-DATA ...........................................15 6.3.1. SD-ELEMENT .........................................15 6.3.2. SD-ID ..............................................15 6.3.3. SD-PARAM ...........................................16 6.3.4. Change Control .....................................17 6.3.5. Examples ...........................................17 Gerhards Standards Track [Page 2] RFC 5424 The Syslog Protocol March 2009 6.4. MSG .......................................................18 6.5. Examples ..................................................19 7. Structured Data IDs ............................................20 7.1. timeQuality ...............................................20 7.1.1. tzKnown ............................................21 7.1.2. isSynced ...........................................21 7.1.3. syncAccuracy .......................................21 7.1.4. Examples ...........................................21 7.2. origin ....................................................22 7.2.1. ip .................................................22 7.2.2. enterpriseId .......................................22 7.2.3. software ...........................................23 7.2.4. swVersion ..........................................23 7.2.5. Example ............................................23 7.3. meta ......................................................24 7.3.1. sequenceId .........................................24 7.3.2. sysUpTime ..........................................24 7.3.3. language ...........................................24 8. Security Considerations ........................................24 8.1. UNICODE ...................................................24 8.2. Control Characters ........................................25 8.3. Message Truncation ........................................26 8.4. Replay ....................................................26 8.5. Reliable Delivery .........................................26 8.6. Congestion Control ........................................27 8.7. Message Integrity .........................................28 8.8. Message Observation .......................................28 8.9. Inappropriate Configuration ...............................28 8.10. Forwarding Loop ..........................................29 8.11. Load Considerations ......................................29 8.12. Denial of Service ........................................29 9. IANA Considerations ............................................30 9.1. VERSION ...................................................30 9.2. SD-IDs ....................................................30 10. Working Group .................................................31 11. Acknowledgments ...............................................31 12. References ....................................................32 12.1. Normative References .....................................32 12.2. Informative References ...................................33 Appendix A. Implementer Guidelines ...............................34 A.1. Relationship with BSD Syslog ..............................34 A.2. Message Length ............................................35 A.3. Severity Values ..........................................36 A.4. TIME-SECFRAC Precision ....................................36 A.5. Case Convention for Names ................................36 A.6. Syslog Applications Without Knowledge of Time ............37 A.7. Notes on the timeQuality SD-ID ............................37 A.8. UTF-8 Encoding and the BOM ................................37 Gerhards Standards Track [Page 3] RFC 5424 The Syslog Protocol March 2009 1. Introduction This document describes a layered architecture for syslog. The goal of this architecture is to separate message content from message transport while enabling easy extensibility for each layer. This document describes the standard format for syslog messages and outlines the concept of transport mappings. It also describes structured data elements, which can be used to transmit easily parseable, structured information, and allows for vendor extensions. This document does not describe any storage format for syslog messages. It is beyond of the scope of the syslog protocol and is unnecessary for system interoperability. This document has been written with the original design goals for traditional syslog in mind. The need for a new layered specification has arisen because standardization efforts for reliable and secure syslog extensions suffer from the lack of a Standards-Track and transport-independent RFC. Without this document, each other standard would need to define its own syslog packet format and transport mechanism, which over time will introduce subtle compatibility issues. This document tries to provide a foundation that syslog extensions can build on. This layered architecture approach also provides a solid basis that allows code to be written once for each syslog feature instead of once for each transport. This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field. 2. Conventions Used in This Document 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]. 3. Definitions Syslog utilizes three layers: o "syslog content" is the management information contained in a syslog message. o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages. o The "syslog transport" layer puts messages on the wire and takes them off the wire. Gerhards Standards Track [Page 4] RFC 5424 The Syslog Protocol March 2009 Certain types of functions are performed at each conceptual layer: o An "originator" generates syslog content to be carried in a message. o A "collector" gathers syslog content for further analysis. o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays. o A "transport sender" passes syslog messages to a specific transport protocol. o A "transport receiver" takes syslog messages from a specific transport protocol. Diagram 1 shows the different entities separated by layer. +---------------------+ +---------------------+ | content | | content | |---------------------| |---------------------| | syslog application | | syslog application | (originator, | | | | collector, relay) |---------------------| |---------------------| | syslog transport | | syslog transport | (transport sender, | | | | (transport receiver) +---------------------+ +---------------------+ ^ ^ | | -------------------------- Diagram 1. Syslog Layers 4. Basic Principles The following principles apply to syslog communication: o The syslog protocol does not provide acknowledgment of message delivery. Though some transports may provide status information, conceptually, syslog is a pure simplex communications protocol. o Originators and relays may be configured to send the same message to multiple collectors and relays. o Originator, relay, and collector functionality may reside on the same system. Gerhards Standards Track [Page 5] RFC 5424 The Syslog Protocol March 2009 4.1. Example Deployment Scenarios Sample deployment scenarios are shown in Diagram 2. Other arrangements of these examples are also acceptable. As noted, in the following diagram, relays may send all or some of the messages that they receive and also send messages that they generate internally. The boxes represent syslog-enabled applications. +----------+ +---------+ |Originator|---->----|Collector| +----------+ +---------+ +----------+ +-----+ +---------+ |Originator|---->----|Relay|---->----|Collector| +----------+ +-----+ +---------+ +----------+ +-----+ +-----+ +---------+ |Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector| +----------+ +-----+ +-----+ +---------+ +----------+ +-----+ +---------+ |Originator|---->----|Relay|---->----|Collector| | |-+ +-----+ +---------+ +----------+ \ \ +-----+ +---------+ +->--|Relay|---->----|Collector| +-----+ +---------+ +----------+ +---------+ |Originator|---->----|Collector| | |-+ +---------+ +----------+ \ \ +-----+ +---------+ +->--|Relay|---->----|Collector| +-----+ +---------+ +----------+ +-----+ +---------+ |Originator|---->----|Relay|---->-------|Collector| | |-+ +-----+ +---| | +----------+ \ / +---------+ \ +-----+ / +->--|Relay|-->--/ +-----+ Gerhards Standards Track [Page 6] RFC 5424 The Syslog Protocol March 2009 +----------+ +-----+ +---------+ |Originator|---->----|Relay|---->--------------|Collector| | |-+ +-----+ +--| | +----------+ \ / +---------+ \ +------------+ / \ |+----------+| / +->-||Relay ||->---/ |+----------|| / ||Originator||->-/ |+----------+| +------------+ Diagram 2. Some Possible Syslog Deployment Scenarios 5. Transport Layer Protocol This document does not specify any transport layer protocol. Instead, it describes the format of a syslog message in a transport layer independent way. Syslog transports are defined in other documents. One such transport is defined in [RFC5426] and is consistent with the traditional UDP transport. This transport is needed to maintain interoperability as the UDP transport has historically been used for the transmission of syslog messages. Any syslog transport protocol MUST NOT deliberately alter the syslog message. If the transport protocol needs to perform temporary transformations at the transport sender, these transformations MUST be reversed by the transport protocol at the transport receiver so that the relay or collector will see an exact copy of the message generated by the originator or relay. Otherwise, end-to-end cryptographic verifiers (such as signatures) will be broken. Of course, message alteration might occur due to transmission errors or other problems. Guarding against such alterations is not within the scope of this document. 5.1. Minimum Required Transport Mapping All implementations of this specification MUST support a TLS-based transport as described in [RFC5425]. All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426]. It is RECOMMENDED that deployments of this specification use the TLS- based transport. Gerhards Standards Track [Page 7] RFC 5424 The Syslog Protocol March 2009 6. Syslog Message Format The syslog message has the following ABNF [RFC5234] definition: SYSLOG-MSG = HEADER SP STRUCTURED-DATA [SP MSG] HEADER = PRI VERSION SP TIMESTAMP SP HOSTNAME SP APP-NAME SP PROCID SP MSGID PRI = "<" PRIVAL ">" PRIVAL = 1*3DIGIT ; range 0 .. 191 VERSION = NONZERO-DIGIT 0*2DIGIT HOSTNAME = NILVALUE / 1*255PRINTUSASCII APP-NAME = NILVALUE / 1*48PRINTUSASCII PROCID = NILVALUE / 1*128PRINTUSASCII MSGID = NILVALUE / 1*32PRINTUSASCII TIMESTAMP = NILVALUE / FULL-DATE "T" FULL-TIME FULL-DATE = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY DATE-FULLYEAR = 4DIGIT DATE-MONTH = 2DIGIT ; 01-12 DATE-MDAY = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year FULL-TIME = PARTIAL-TIME TIME-OFFSET PARTIAL-TIME = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND [TIME-SECFRAC] TIME-HOUR = 2DIGIT ; 00-23 TIME-MINUTE = 2DIGIT ; 00-59 TIME-SECOND = 2DIGIT ; 00-59 TIME-SECFRAC = "." 1*6DIGIT TIME-OFFSET = "Z" / TIME-NUMOFFSET TIME-NUMOFFSET = ("+" / "-") TIME-HOUR ":" TIME-MINUTE STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT SD-ELEMENT = "[" SD-ID *(SP SD-PARAM) "]" SD-PARAM = PARAM-NAME "=" %d34 PARAM-VALUE %d34 SD-ID = SD-NAME PARAM-NAME = SD-NAME PARAM-VALUE = UTF-8-STRING ; characters '"', '\' and ; ']' MUST be escaped. SD-NAME = 1*32PRINTUSASCII ; except '=', SP, ']', %d34 (") MSG = MSG-ANY / MSG-UTF8 MSG-ANY = *OCTET ; not starting with BOM MSG-UTF8 = BOM UTF-8-STRING BOM = %xEF.BB.BF Gerhards Standards Track [Page 8] RFC 5424 The Syslog Protocol March 2009 UTF-8-STRING = *OCTET ; UTF-8 string as specified ; in RFC 3629 OCTET = %d00-255 SP = %d32 PRINTUSASCII = %d33-126 NONZERO-DIGIT = %d49-57 DIGIT = %d48 / NONZERO-DIGIT NILVALUE = "-" 6.1. Message Length Syslog message size limits are dictated by the syslog transport mapping in use. There is no upper limit per se. Each transport mapping defines the minimum maximum required message length support, and the minimum maximum MUST be at least 480 octets in length. Any transport receiver MUST be able to accept messages of up to and including 480 octets in length. All transport receiver implementations SHOULD be able to accept messages of up to and including 2048 octets in length. Transport receivers MAY receive messages larger than 2048 octets in length. If a transport receiver receives a message with a length larger than it supports, the transport receiver SHOULD truncate the payload. Alternatively, it MAY discard the message. If a transport receiver truncates messages, the truncation MUST occur at the end of the message. After truncation, the message MAY contain invalid UTF-8 encoding or invalid STRUCTURED-DATA. The transport receiver MAY discard the message or MAY try to process as much as possible in this case. 6.2. HEADER The character set used in the HEADER MUST be seven-bit ASCII in an eight-bit field as described in [RFC5234]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1. 6.2.1. PRI The PRI part MUST have three, four, or five characters and will be bound with angle brackets as the first and last characters. The PRI part starts with a leading "<" ('less-than' character, %d60), followed by a number, which is followed by a ">" ('greater-than' Gerhards Standards Track [Page 9] RFC 5424 The Syslog Protocol March 2009 character, %d62). The number contained within these angle brackets is known as the Priority value (PRIVAL) and represents both the Facility and Severity. The Priority value consists of one, two, or three decimal integers (ABNF DIGITS) using values of %d48 (for "0") through %d57 (for "9"). Facility and Severity values are not normative but often used. They are described in the following tables for purely informational purposes. Facility values MUST be in the range of 0 to 23 inclusive. Numerical Facility Code 0 kernel messages 1 user-level messages 2 mail system 3 system daemons 4 security/authorization messages 5 messages generated internally by syslogd 6 line printer subsystem 7 network news subsystem 8 UUCP subsystem 9 clock daemon 10 security/authorization messages 11 FTP daemon 12 NTP subsystem 13 log audit 14 log alert 15 clock daemon (note 2) 16 local use 0 (local0) 17 local use 1 (local1) 18 local use 2 (local2) 19 local use 3 (local3) 20 local use 4 (local4) 21 local use 5 (local5) 22 local use 6 (local6) 23 local use 7 (local7) Table 1. Syslog Message Facilities Each message Priority also has a decimal Severity level indicator. These are described in the following table along with their numerical values. Severity values MUST be in the range of 0 to 7 inclusive. Gerhards Standards Track [Page 10] RFC 5424 The Syslog Protocol March 2009 Numerical Severity Code 0 Emergency: system is unusable 1 Alert: action must be taken immediately 2 Critical: critical conditions 3 Error: error conditions 4 Warning: warning conditions 5 Notice: normal but significant condition 6 Informational: informational messages 7 Debug: debug-level messages Table 2. Syslog Message Severities The Priority value is calculated by first multiplying the Facility number by 8 and then adding the numerical value of the Severity. For example, a kernel message (Facility=0) with a Severity of Emergency (Severity=0) would have a Priority value of 0. Also, a "local use 4" message (Facility=20) with a Severity of Notice (Severity=5) would have a Priority value of 165. In the PRI of a syslog message, these values would be placed between the angle brackets as <0> and <165> respectively. The only time a value of "0" follows the "<" is for the Priority value of "0". Otherwise, leading "0"s MUST NOT be used. 6.2.2. VERSION The VERSION field denotes the version of the syslog protocol specification. The version number MUST be incremented for any new syslog protocol specification that changes any part of the HEADER format. Changes include the addition or removal of fields, or a change of syntax or semantics of existing fields. This document uses a VERSION value of "1". The VERSION values are IANA-assigned (Section 9.1) via the Standards Action method as described in [RFC5226]. 6.2.3. TIMESTAMP The TIMESTAMP field is a formalized timestamp derived from [RFC3339]. Whereas [RFC3339] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions: o The "T" and "Z" characters in this syntax MUST be upper case. o Usage of the "T" character is REQUIRED. o Leap seconds MUST NOT be used. Gerhards Standards Track [Page 11] RFC 5424 The Syslog Protocol March 2009 The originator SHOULD include TIME-SECFRAC if its clock accuracy and performance permit. The "timeQuality" SD-ID described in Section 7.1 allows the originator to specify the accuracy and trustworthiness of the timestamp. A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time. 18.104.22.168. Examples Example 1 1985-04-12T23:20:50.52Z This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC. Example 2 1985-04-12T19:20:50.52-04:00 This represents the same time as in example 1, but expressed in US Eastern Standard Time (observing daylight savings time). Example 3 2003-10-11T22:14:15.003Z This represents 11 October 2003 at 10:14:15pm, 3 milliseconds into the next second. The timestamp is in UTC. The timestamp provides millisecond resolution. The creator may have actually had a better resolution, but providing just three digits for the fractional part of a second does not tell us. Example 4 2003-08-24T05:14:15.000003-07:00 This represents 24 August 2003 at 05:14:15am, 3 microseconds into the next second. The microsecond resolution is indicated by the additional digits in TIME-SECFRAC. The timestamp indicates that its local time is -7 hours from UTC. This timestamp might be created in the US Pacific time zone during daylight savings time. Gerhards Standards Track [Page 12] RFC 5424 The Syslog Protocol March 2009 Example 5 - An Invalid TIMESTAMP 2003-08-24T05:14:15.000000003-07:00 This example is nearly the same as Example 4, but it is specifying TIME-SECFRAC in nanoseconds. This results in TIME-SECFRAC being longer than the allowed 6 digits, which invalidates it. 6.2.4. HOSTNAME The HOSTNAME field identifies the machine that originally sent the syslog message. The HOSTNAME field SHOULD contain the hostname and the domain name of the originator in the format specified in STD 13 [RFC1034]. This format is called a Fully Qualified Domain Name (FQDN) in this document. In practice, not all syslog applications are able to provide an FQDN. As such, other values MAY also be present in HOSTNAME. This document makes provisions for using other values in such situations. A syslog application SHOULD provide the most specific available value first. The order of preference for the contents of the HOSTNAME field is as follows: 1. FQDN 2. Static IP address 3. hostname 4. Dynamic IP address 5. the NILVALUE If an IPv4 address is used, it MUST be in the format of the dotted decimal notation as used in STD 13 [RFC1035]. If an IPv6 address is used, a valid textual representation as described in [RFC4291], Section 2.2, MUST be used. Syslog applications SHOULD consistently use the same value in the HOSTNAME field for as long as possible. The NILVALUE SHOULD only be used when the syslog application has no way to obtain its real hostname. This situation is considered highly unlikely. Gerhards Standards Track [Page 13] RFC 5424 The Syslog Protocol March 2009 6.2.5. APP-NAME The APP-NAME field SHOULD identify the device or application that originated the message. It is a string without further semantics. It is intended for filtering messages on a relay or collector. The NILVALUE MAY be used when the syslog application has no idea of its APP-NAME or cannot provide that information. It may be that a device is unable to provide that information either because of a local policy decision, or because the information is not available, or not applicable, on the device. This field MAY be operator-assigned. 6.2.6. PROCID PROCID is a value that is included in the message, having no interoperable meaning, except that a change in the value indicates there has been a discontinuity in syslog reporting. The field does not have any specific syntax or semantics; the value is implementation-dependent and/or operator-assigned. The NILVALUE MAY be used when no value is provided. The PROCID field is often used to provide the process name or process ID associated with a syslog system. The NILVALUE might be used when a process ID is not available. On an embedded system without any operating system process ID, PROCID might be a reboot ID. PROCID can enable log analyzers to detect discontinuities in syslog reporting by detecting a change in the syslog process ID. However, PROCID is not a reliable identification of a restarted process since the restarted syslog process might be assigned the same process ID as the previous syslog process. PROCID can also be used to identify which messages belong to a group of messages. For example, an SMTP mail transfer agent might put its SMTP transaction ID into PROCID, which would allow the collector or relay to group messages based on the SMTP transaction. 6.2.7. MSGID The MSGID SHOULD identify the type of message. For example, a firewall might use the MSGID "TCPIN" for incoming TCP traffic and the MSGID "TCPOUT" for outgoing TCP traffic. Messages with the same MSGID should reflect events of the same semantics. The MSGID itself is a string without further semantics. It is intended for filtering messages on a relay or collector. Gerhards Standards Track [Page 14] RFC 5424 The Syslog Protocol March 2009 The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value. This field MAY be operator-assigned. 6.3. STRUCTURED-DATA STRUCTURED-DATA provides a mechanism to express information in a well defined, easily parseable and interpretable data format. There are multiple usage scenarios. For example, it may express meta- information about the syslog message or application-specific information such as traffic counters or IP addresses. STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document. In case of zero structured data elements, the STRUCTURED-DATA field MUST contain the NILVALUE. The character set used in STRUCTURED-DATA MUST be seven-bit ASCII in an eight-bit field as described in [RFC5234]. These are the ASCII codes as defined in "USA Standard Code for Information Interchange" [ANSI.X3-4.1968]. An exception is the PARAM-VALUE field (see Section 6.3.3), in which UTF-8 encoding MUST be used. A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration. 6.3.1. SD-ELEMENT An SD-ELEMENT consists of a name and parameter name-value pairs. The name is referred to as SD-ID. The name-value pairs are referred to as "SD-PARAM". 6.3.2. SD-ID SD-IDs are case-sensitive and uniquely identify the type and purpose of the SD-ELEMENT. The same SD-ID MUST NOT exist more than once in a message. There are two formats for SD-ID names: o Names that do not contain an at-sign ("@", ABNF %d64) are reserved to be assigned by IETF Review as described in BCP26 [RFC5226]. Currently, these are the names defined in Section 7. Names of this format are only valid if they are first registered with the IANA. Registered names MUST NOT contain an at-sign ('@', ABNF Gerhards Standards Track [Page 15] RFC 5424 The Syslog Protocol March 2009 %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters (ASCII code 127 and codes 32 or less). o Anyone can define additional SD-IDs using names in the format name@<private enterprise number>, e.g., "ourSDID@32473". The format of the part preceding the at-sign is not specified; however, these names MUST be printable US-ASCII strings, and MUST NOT contain an at-sign ('@', ABNF %d64), an equal-sign ('=', ABNF %d61), a closing brace (']', ABNF %d93), a quote-character ('"', ABNF %d34), whitespace, or control characters. The part following the at-sign MUST be a private enterprise number as specified in Section 7.2.2. Please note that throughout this document the value of 32473 is used for all private enterprise numbers. This value has been reserved by IANA to be used as an example number in documentation. Implementors will need to use their own private enterprise number for the enterpriseId parameter, and when creating locally extensible SD-ID names. 6.3.3. SD-PARAM Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE. PARAM-NAME is case-sensitive. IANA controls all PARAM-NAMEs, with the exception of those in SD-IDs whose names contain an at-sign. The PARAM-NAME scope is within a specific SD-ID. Thus, equally named PARAM-NAME values contained in two different SD-IDs are not the same. To support international characters, the PARAM-VALUE field MUST be encoded using UTF-8. A syslog application MAY issue any valid UTF-8 sequence. A syslog application MUST accept any valid UTF-8 sequence in the "shortest form". It MUST NOT fail if control characters are present in PARAM-VALUE. The syslog application MAY modify messages containing control characters (e.g., by changing an octet with value 0 (USASCII NUL) to the four characters "#000"). For the reasons outlined in UNICODE TR36 [UNICODE-TR36], section 3.1, an originator MUST encode messages in the "shortest form" and a collector or relay MUST NOT interpret messages in the "non-shortest form". Inside PARAM-VALUE, the characters '"' (ABNF %d34), '\' (ABNF %d92), and ']' (ABNF %d93) MUST be escaped. This is necessary to avoid parsing errors. Escaping ']' would not strictly be necessary but is REQUIRED by this specification to avoid syslog application implementation errors. Each of these three characters MUST be escaped as '\"', '\\', and '\]' respectively. The backslash is used Gerhards Standards Track [Page 16] RFC 5424 The Syslog Protocol March 2009 for control character escaping for consistency with its use for escaping in other parts of the syslog message as well as in traditional syslog. A backslash ('\') followed by none of the three described characters is considered an invalid escape sequence. In this case, the backslash MUST be treated as a regular backslash and the following character as a regular character. Thus, the invalid sequence MUST not be altered. An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT. 6.3.4. Change Control Once SD-IDs and PARAM-NAMEs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or PARAM-NAME MUST be created and the old one remain unchanged. OPTIONAL PARAM-NAMEs MAY be added to an existing SD-ID. 6.3.5. Examples All examples in this section show only the structured data part of the message. Examples should be considered to be on one line. They are wrapped on multiple lines in this document for readability purposes. A description is given after each example. Example 1 - Valid [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] This example is a structured data element with a non-IANA controlled SD-ID of type "exampleSDID@32473", which has three parameters. Example 2 - Valid [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"] This is the same example as in 1, but with a second structured data element. Please note that the structured data element immediately follows the first one (there is no SP between them). Example 3 - Invalid [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] [examplePriority@32473 class="high"] Gerhards Standards Track [Page 17] RFC 5424 The Syslog Protocol March 2009 This is nearly the same example as 2, but it has a subtle error -- there is an SP character between the two structured data elements ("]SP["). This is invalid. It will cause the STRUCTURED-DATA field to end after the first element. The second element will be interpreted as part of the MSG field. Example 4 - Invalid [ exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"][examplePriority@32473 class="high"] This example is nearly the same as 2. It has another subtle error -- the SP character occurs after the initial bracket. A structured data element SD-ID MUST immediately follow the beginning bracket, so the SP character invalidates the STRUCTURED-DATA. A syslog application MAY discard this message. Example 5 - Valid [sigSig ver="1" rsID="1234" ... signature="..."] Example 5 is a valid example. It shows a hypothetical IANA-assigned SD-ID. The ellipses denote missing content, which has been left out of this example for brevity. 6.4. MSG The MSG part contains a free-form message that provides information about the event. The character set used in MSG SHOULD be UNICODE, encoded using UTF-8 as specified in [RFC3629]. If the syslog application cannot encode the MSG in Unicode, it MAY use any other encoding. The syslog application SHOULD avoid octet values below 32 (the traditional US-ASCII control character range except DEL). These values are legal, but a syslog application MAY modify these characters upon reception. For example, it might change them into an escape sequence (e.g., value 0 may be changed to "\0"). A syslog application SHOULD NOT modify any other octet values. If a syslog application encodes MSG in UTF-8, the string MUST start with the Unicode byte order mask (BOM), which for UTF-8 is ABNF %xEF.BB.BF. The syslog application MUST encode in the "shortest form" and MAY use any valid UTF-8 sequence. Gerhards Standards Track [Page 18] RFC 5424 The Syslog Protocol March 2009 If a syslog application is processing an MSG starting with a BOM and the MSG contains UTF-8 that is not shortest form, the MSG MUST NOT be interpreted as being encoded in UTF-8, for the reasons outlined in [UNICODE-TR36], Section 3.1. Guidance about this is given in Appendix A.8. Also, according to UNICODE TR36 [UNICODE-TR36], a syslog application MUST NOT interpret messages in the "non-shortest form". It MUST NOT interpret invalid UTF-8 sequences. 6.5. Examples The following are examples of valid syslog messages. A description of each example can be found below it. The examples are based on similar examples from [RFC3164] and may be familiar to readers. The otherwise-unprintable Unicode BOM is represented as "BOM" in the examples. Example 1 - with no STRUCTURED-DATA <34>1 2003-10-11T22:14:15.003Z mymachine.example.com su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8 In this example, the VERSION is 1 and the Facility has the value of 4. The Severity is 2. The message was created on 11 October 2003 at 10:14:15pm UTC, 3 milliseconds into the next second. The message originated from a host that identifies itself as "mymachine.example.com". The APP-NAME is "su" and the PROCID is unknown. The MSGID is "ID47". The MSG is "'su root' failed for lonvick...", encoded in UTF-8. The encoding is defined by the BOM. There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field. Example 2 - with no STRUCTURED-DATA <165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1 myproc 8710 - - %% It's time to make the do-nuts. In this example, the VERSION is again 1. The Facility is 20, the Severity 5. The message was created on 24 August 2003 at 5:14:15am, with a -7 hour offset from UTC, 3 microseconds into the next second. The HOSTNAME is "192.0.2.1", so the syslog application did not know its FQDN and used one of its IPv4 addresses instead. The APP-NAME is "myproc" and the PROCID is "8710" (for example, this could be the UNIX PID). There is no STRUCTURED-DATA present in the message; this is indicated by "-" in the STRUCTURED-DATA field. There is no specific MSGID and this is indicated by the "-" in the MSGID field. Gerhards Standards Track [Page 19] RFC 5424 The Syslog Protocol March 2009 The message is "%% It's time to make the do-nuts.". As the Unicode BOM is missing, the syslog application does not know the encoding of the MSG part. Example 3 - with STRUCTURED-DATA <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"] BOMAn application event log entry... This example is modeled after Example 1. However, this time it contains STRUCTURED-DATA, a single element with the value "[exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"]". The MSG itself is "An application event log entry..." The BOM at the beginning of MSG indicates UTF-8 encoding. Example 4 - STRUCTURED-DATA Only <165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog - ID47 [exampleSDID@32473 iut="3" eventSource= "Application" eventID="1011"][examplePriority@32473 class="high"] This example shows a message with only STRUCTURED-DATA and no MSG part. This is a valid message. 7. Structured Data IDs This section defines the initial IANA-registered SD-IDs. See Section 6.3 for a definition of structured data elements. All SD-IDs defined here are OPTIONAL. In some of the following, a maximum length is quantified for the parameter values. In each of those cases, the syslog application MUST be prepared to receive the number of defined characters in any valid UTF-8 code point. Since each character may be up to 6 octets, it is RECOMMENDED that each syslog application be prepared to receive up to 6 octets per character. 7.1. timeQuality The SD-ID "timeQuality" MAY be used by the originator to describe its notion of system time. This SD-ID SHOULD be written if the originator is not properly synchronized with a reliable external time source or if it does not know whether its time zone information is Gerhards Standards Track [Page 20] RFC 5424 The Syslog Protocol March 2009 correct. The main use of this structured data element is to provide some information on the level of trust it has in the TIMESTAMP described in Section 6.2.3. All parameters are OPTIONAL. 7.1.1. tzKnown The "tzKnown" parameter indicates whether the originator knows its time zone. If it does, the value "1" MUST be used. If the time zone information is in doubt, the value "0" MUST be used. If the originator knows its time zone but decides to emit time in UTC, the value "1" MUST be used (because the time zone is known). 7.1.2. isSynced The "isSynced" parameter indicates whether the originator is synchronized to a reliable external time source, e.g., via NTP. If the originator is time synchronized, the value "1" MUST be used. If not, the value "0" MUST be used. 7.1.3. syncAccuracy The "syncAccuracy" parameter indicates how accurate the originator thinks its time synchronization is. It is an integer describing the maximum number of microseconds that its clock may be off between synchronization intervals. If the value "0" is used for "isSynced", this parameter MUST NOT be specified. If the value "1" is used for "isSynced" but the "syncAccuracy" parameter is absent, a collector or relay can assume that the time information provided is accurate enough to be considered correct. The "syncAccuracy" parameter MUST be written only if the originator actually has knowledge of the reliability of the external time source. In most cases, it will gain this in-depth knowledge through operator configuration. 7.1.4. Examples The following is an example of an originator that does not know its time zone or whether it is being synchronized: [timeQuality tzKnown="0" isSynced="0"] With this information, the originator indicates that its time information is unreliable. This may be a hint for the collector or relay to use its local time instead of the message-provided TIMESTAMP for correlation of multiple messages from different originators. Gerhards Standards Track [Page 21] RFC 5424 The Syslog Protocol March 2009 The following is an example of an originator that knows its time zone and knows that it is properly synchronized to a reliable external source: [timeQuality tzKnown="1" isSynced="1"] The following is an example of an originator that knows both its time zone and that it is externally synchronized. It also knows the accuracy of the external synchronization: [timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"] The difference between this and the previous example is that the originator expects that its clock will be kept within 60 seconds of the official time. Thus, if the originator reports it is 9:00:00, it is no earlier than 8:59:00 and no later then 9:01:00. 7.2. origin The SD-ID "origin" MAY be used to indicate the origin of a syslog message. The following parameters can be used. All parameters are OPTIONAL. Specifying any of these parameters is primarily an aid to log analyzers and similar applications. 7.2.1. ip The "ip" parameter denotes an IP address that the originator knows it had at the time of originating the message. It MUST contain the textual representation of an IP address as outlined in Section 6.2.4. This parameter can be used to provide identifying information in addition to what is present in the HOSTNAME field. It might be especially useful if the host's IP address is included in the message while the HOSTNAME field still contains the FQDN. It is also useful for describing all IP addresses of a multihomed host. If an originator has multiple IP addresses, it MAY either list one of its IP addresses in the "ip" parameter or it MAY include multiple "ip" parameters in a single "origin" structured data element. 7.2.2. enterpriseId The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (22.214.171.124.4.1). The number that follows MUST be unique and MUST be registered with IANA as per Gerhards Standards Track [Page 22] RFC 5424 The Syslog Protocol March 2009 RFC 2578 [RFC2578]. An enterprise is only authorized to assign values within the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree assigned by IANA to that enterprise. The enterpriseId MUST contain only a value from the iso.org.dod.internet.private.enterprise.<private enterprise number> subtree. In general, only the IANA-assigned private enterprise number is needed (a single number). An enterprise might decide to use sub-identifiers below its private enterprise number. If sub- identifiers are used, they MUST be separated by periods and be represented as decimal numbers. An example for that would be "32473.1.2". Please note that the ID "32473.1.2" is just an example and MUST NOT be used. The complete up-to-date list of Private Enterprise Numbers (PEN) is maintained by IANA. By specifying a private enterprise number, the vendor allows more specific processing of the message. 7.2.3. software The "software" parameter uniquely identifies the software that generated the message. If it is used, "enterpriseId" SHOULD also be specified, so that a specific vendor's software can be identified. The "software" parameter is not the same as the APP-NAME header field. It MUST always contain the name of the generating software, whereas APP-NAME can contain anything else, including an operator- configured value. The "software" parameter is a string. It MUST NOT be longer than 48 characters. 7.2.4. swVersion The "swVersion" parameter uniquely identifies the version of the software that generated the message. If it is used, the "software" and "enterpriseId" parameters SHOULD be provided, too. The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters. 7.2.5. Example The following is an example with multiple IP addresses: [origin ip="192.0.2.1" ip="192.0.2.129"] In this example, the originator indicates that it has two IP addresses, one being 192.0.2.1 and the other one being 192.0.2.129. Gerhards Standards Track [Page 23] RFC 5424 The Syslog Protocol March 2009 7.3. meta The SD-ID "meta" MAY be used to provide meta-information about the message. The following parameters can be used. All parameters are OPTIONAL. If the "meta" SD-ID is used, at least one parameter SHOULD be specified. 7.3.1. sequenceId The "sequenceId" parameter tracks the sequence in which the originator submits messages to the syslog transport for sending. It is an integer that MUST be set to 1 when the syslog function is started and MUST be increased with every message up to a maximum value of 2147483647. If that value is reached, the next message MUST be sent with a sequenceId of 1. 7.3.2. sysUpTime The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in [RFC3418]. As syslog does not support the SNMP "INTEGER" syntax directly, the value MUST be represented as a decimal integer (no decimal point) using only the characters "0", "1", "2", "3", "4", "5", "6", "7", "8", and "9". Note that the semantics in RFC 3418 are "The time (in hundredths of a second) since the network management portion of the system was last re-initialized." This of course relates to the SNMP-related management portion of the system, which MAY be different than the syslog-related management portion of the system. 7.3.3. language The "language" parameter MAY be specified by the originator to convey information about the natural language used inside MSG. If it is specified, it MUST contain a language identifier as defined in BCP 47 [RFC4646]. 8. Security Considerations 8.1. UNICODE This document uses UTF-8 encoding for the PARAM-VALUE and MSG fields. There are a number of security issues with UNICODE. Any implementer and operator is advised to review UNICODE TR36 [UNICODE-TR36] (UTR36) to learn about these issues. This document guards against the Gerhards Standards Track [Page 24] RFC 5424 The Syslog Protocol March 2009 technical issues outlined in UTR36 by REQUIRING "shortest form" encoding for syslog applications. However, the visual spoofing due to character confusion still persists. This document tries to minimize the effects of visual spoofing by allowing UNICODE only where local script is expected and needed. In all other fields, US-ASCII is REQUIRED. Also, the PARAM-VALUE and MSG fields should not be the primary source for identifying information, further reducing the risks associated with visual spoofing. 8.2. Control Characters This document does not impose any mandatory restrictions on the MSG or PARAM-VALUE content. As such, they MAY contain control characters, including the NUL character. In some programming languages (most notably C and C++), the NUL character (ABNF %d00) traditionally has a special significance as string terminator. Most implementations of these languages assume that a string will not extend beyond the first NUL character. This is primarily a restriction of the supporting run-time libraries. This restriction is often carried over to programs and script languages written in those languages. As such, NUL characters must be considered with great care and be properly handled. An attacker may deliberately include NUL characters to hide information after them. Incorrect handling of the NUL character may also invalidate cryptographic checksums that are transmitted inside the message. Many popular text editors are also written in languages with this restriction. Encoding NUL characters when writing to text files is advisable. If they are stored without encoding, the file can become unreadable. Other control characters may also be problematic. For example, an attacker may deliberately include backspace characters to render parts of the log message unreadable. Similar issues exist for almost all control characters. Finally, invalid UTF-8 sequences may be used by an attacker to inject ASCII control characters. This specification permits a syslog application to reformat control characters received. Among others, the security risks associated with control characters were an important driving force behind this restriction. Originators are advised that if any encoding other than ASCII and UTF8 are used, the receiver may corrupt the message in an attempt to filter ASCII control characters. Gerhards Standards Track [Page 25] RFC 5424 The Syslog Protocol March 2009 8.3. Message Truncation Message truncation can be misused by an attacker to hide vital log information. Messages over the minimum supported size may be discarded or truncated by the transport receiver. As such, vital log information may be lost. In order to prevent information loss, messages should not be longer than the minimum maximum size required by Section 6.1. For best performance and reliability, messages should be as small as possible. Important information should be placed as early in the message as possible because information at the beginning of the message is less likely to be discarded by a size-limited transport receiver. An originator should limit the size of any user-supplied data within a syslog message. If it does not, an attacker may provide large data in hopes of exploiting a potential weakness. 8.4. Replay There is no mechanism in the syslog protocol to detect message replay. An attacker may record a set of messages that indicate normal activity of a machine. At a later time, that attacker may remove that machine from the network and replay the syslog messages to the relay or collector. Even with the TIMESTAMP field in the HEADER part, an attacker may record the packets and could simply modify them to reflect the current time before retransmitting them. The administrators may find nothing unusual in the received messages, and their receipt would falsely indicate normal activity of the machine. Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack. 8.5. Reliable Delivery Because there is no mechanism described within this document to ensure delivery, and the underlying transport may be unreliable (e.g., UDP), some messages may be lost. They may either be dropped through network congestion, or they may be maliciously intercepted and discarded. The consequences of dropping one or more syslog messages cannot be determined. If the messages are simple status updates, then their non-receipt may not be noticed or may cause an annoyance for the system operators. On the other hand, if the messages are more critical, then the administrators may not become aware of a developing and potentially serious problem. Messages may also be intercepted and discarded by an attacker as a way to hide unauthorized activities. Gerhards Standards Track [Page 26] RFC 5424 The Syslog Protocol March 2009 It may also be desirable to include rate-limiting features in syslog originators and relays. This can reduce potential congestion problems when message bursts happen. Reliable delivery may not always be desirable. Reliable delivery means that the syslog originator or relay must block when the relay or collector is not able to accept any more messages. In some operating systems, namely Unix/Linux, the syslog originator or relay runs inside a high-priority system process (syslogd). If that process blocks, the system at large comes to a stand-still. The same occurs if there is a deadlock situation between syslogd and e.g., the DNS server. To prevent these problems, reliable delivery can be implemented in a way that intentionally discards messages when the syslog application would otherwise block. The advantage of reliable delivery in this case is that the syslog originator or relay knowingly discards the message and is able to notify the relay or collector about that fact. So the relay or collector receives the information that something is lost. With unreliable delivery, the message would simply be lost without any indication that loss occurred. 8.6. Congestion Control Because syslog can generate unlimited amounts of data, transferring this data over UDP is generally problematic, because UDP lacks congestion control mechanisms. Congestion control mechanisms that respond to congestion by reducing traffic rates and establish a degree of fairness between flows that share the same path are vital to the stable operation of the Internet [RFC2914]. This is why the syslog TLS transport is REQUIRED to implement and RECOMMENDED for general use. The only environments where the syslog UDP transport MAY be used as an alternative to the TLS transport are managed networks, where the network path has been explicitly provisioned for UDP syslog traffic through traffic engineering mechanisms, such as rate limiting or capacity reservations. In all other environments, the TLS transport SHOULD be used. In any implementation, the situation may arise in which an originator or relay would need to block sending messages. A common case is when an internal queue is full. This might happen due to rate-limiting or slow performance of the syslog application. In any event, it is highly RECOMMENDED that no messages be dropped but that they should be temporarily stored until they can be transmitted. However, if they must be dropped, it is RECOMMENDED that the originator or relay drop messages of lower severity in favor of higher severity messages. Gerhards Standards Track [Page 27] RFC 5424 The Syslog Protocol March 2009 Messages with a lower numerical SEVERITY value have a higher practical severity than those with a numerically higher value. In that situation, the messages that are to be dropped SHOULD simply be discarded. The syslog application may notify a collector or relay about the fact that it has dropped messages. 8.7. Message Integrity Besides being discarded, syslog messages may be damaged in transit, or an attacker may maliciously modify them. In such cases, the original contents of the message will not be delivered to the collector or relay. Additionally, if an attacker is positioned between the transport sender and transport receiver of syslog messages, they may be able to intercept and modify those messages while in-transit to hide unauthorized activities. 8.8. Message Observation While there are no strict guidelines pertaining to the MSG format, most syslog messages are generated in human-readable form with the assumption that capable administrators should be able to read them and understand their meaning. The syslog protocol does not have mechanisms to provide confidentiality for the messages in transit. In most cases, passing clear-text messages is a benefit to the operations staff if they are sniffing the packets from the wire. The operations staff may be able to read the messages and associate them with other events seen from other packets crossing the wire to track down and correct problems. Unfortunately, an attacker may also be able to observe the human-readable contents of syslog messages. The attacker may then use the knowledge gained from those messages to compromise a machine or do other damage. Operators are advised to use a secure transport mapping to avoid this problem. 8.9. Inappropriate Configuration Because there is no control information distributed about any messages or configurations, it is wholly the responsibility of the network administrator to ensure that the messages are actually going to the intended recipients. Cases have been noted where syslog applications were inadvertently configured to send syslog messages to the wrong relays or collectors. In many cases, the inadvertent relays or collectors may not be configured to receive syslog messages and will probably discard them. In certain other cases, the receipt of syslog messages has been known to cause problems for the unintended recipient. If messages are not going to the intended recipient, then they cannot be reviewed or processed. Gerhards Standards Track [Page 28] RFC 5424 The Syslog Protocol March 2009 Using a reliable transport mapping can help identify some of these problems. For example, it can identify a problem where a message is being sent to a system that is not configured to receive messages. It cannot identify sending messages to a wrong machine that is accepting messages. 8.10. Forwarding Loop As shown in Diagram 2, machines may be configured to relay syslog messages to subsequent relays before reaching a collector. In one particular case, an administrator found that he had mistakenly configured two relays to forward messages with certain SEVERITY values to each other. When either of these machines either received or generated that type of message, it would forward it to the other relay. That relay would, in turn, forward it back. This cycle did cause degradation to the intervening network as well as to the processing availability on the two devices. Network administrators must take care not to cause such a death spiral. 8.11. Load Considerations Network administrators must take the time to estimate the appropriate capacity of the syslog collector. An attacker may perform a Denial of Service attack by filling the disk of the collector with false messages. Placing the records in a circular file may alleviate this but has the consequence of not ensuring that an administrator will be able to review the records in the future. Along this line, a transport receiver must have a network interface capable of receiving the messages sent to it. Administrators and network planners must also critically review the network paths between the originators, the relays, and the collectors. Generated syslog messages should not overwhelm any of the network links. In order to reduce the impact of this issue, using transports with guaranteed delivery is recommended. 8.12. Denial of Service As with any system, an attacker may just overwhelm a transport receiver by sending more messages to it than can be handled by the infrastructure or the device itself. Implementers should attempt to provide features that minimize this threat, such as only accepting syslog messages from known IP addresses. Gerhards Standards Track [Page 29] RFC 5424 The Syslog Protocol March 2009 9. IANA Considerations 9.1. VERSION IANA has created a registry entitled "syslog Version Values" of VERSION values as described in Section 6.2.2. Version numbers MUST be incremented for any new syslog protocol specification that changes any part of the HEADER. Changes include addition or removal of fields or a change of syntax or semantics of existing fields. VERSION numbers must be registered via the Standards Action method as described in [RFC5226]. IANA has registered the VERSIONs shown in Table 3 below. VERSION FORMAT 1 Defined in [RFC5424] Table 3. IANA-Registered VERSIONs 9.2. SD-IDs IANA has created a registry entitled "syslog Structured Data ID Values" of Structured Data ID (SD-ID) values together with their associated PARAM-NAME values as described in Section 7. New SD-ID and new PARAM-NAME values must be registered through the IETF Review method as described in [RFC5226]. Once SD-IDs and SD-PARAMs are defined, syntax and semantics of these objects MUST NOT be altered. Should a change to an existing object be desired, a new SD-ID or SD-PARAM MUST be created and the old one remain unchanged. A provision is made here for locally extensible names. The IANA will not register, and will not control names with the at-sign (ABNF %d64) in them. IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below. SD-ID PARAM-NAME timeQuality OPTIONAL tzKnown OPTIONAL isSynced OPTIONAL syncAccuracy OPTIONAL Gerhards Standards Track [Page 30] RFC 5424 The Syslog Protocol March 2009 origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs 10. Working Group The working group can be contacted via the mailing list: firstname.lastname@example.com The current Chairs of the Working Group may be contacted at: Chris Lonvick Cisco Systems EMail: firstname.lastname@example.com David Harrington Huawei Technologies USA EMail: email@example.com 11. Acknowledgments The authors wish to thank Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso, and all the other people who commented on various versions of this proposal. Gerhards Standards Track [Page 31] RFC 5424 The Syslog Protocol March 2009 12. References 12.1. Normative References [ANSI.X3-4.1968] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002. [RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. Gerhards Standards Track [Page 32] RFC 5424 The Syslog Protocol March 2009 [RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS Transport Mapping for Syslog", RFC 5425, March 2009. [RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009. [UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security Considerations", July 2005. 12.2. Informative References [RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001. Gerhards Standards Track [Page 33] RFC 5424 The Syslog Protocol March 2009 Appendix A. Implementer Guidelines Information in this section is given as an aid to implementers. While this information is considered to be helpful, it is not normative. As such, an implementation is NOT REQUIRED to follow it in order to claim compliance to this specification. A.1. Relationship with BSD Syslog While BSD syslog is in widespread use, its format has never been formally standardized. [RFC3164] describes observed formats. It is an Informational RFC, and practice shows that there are many different implementations. Research during creation of this document showed that there is very little in common between different syslog implementations on different platforms. The only thing that all of them agree upon is that messages start with "<" PRIVAL ">". Other than that, legacy syslog messages are not formatted in a consistent way. Consequently, RFC 3164 describes no specific elements inside a syslog message. It states that any message destined to the syslog UDP port must be treated as a syslog message, no matter what its format or content is. This document retains the PRI value syntax and semantics. This will allow legacy syslog implementations to put messages generated by syslog applications compliant to this specification into the right bins. Most existing implementations support UDP as the transport protocol for syslog. This specification supports UDP transport, but does not recommend it. Deployment of the required TLS support is recommended. Additional transport protocols may be used. RFC 3164 describes relay behavior. This document does not specify relay behavior. This might be done in a separate document. The TIMESTAMP described in RFC 3164 offers less precision than the timestamp specified in this document. It also lacks the year and time zone information. If a message formatted according to this document needs to be reformatted to be in RFC 3164 format, it is suggested that the originator's local time zone be used, and the time zone information and the year be dropped. If an RFC 3164 formatted message is received and must be transformed to be compliant to this document, the current year should be added and the time zone of the relay or collector MAY be used. The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations. Gerhards Standards Track [Page 34] RFC 5424 The Syslog Protocol March 2009 The MSG part of the message is described as TAG and CONTENT in RFC 3164. In this document, MSG is what was called CONTENT in RFC 3164. The TAG is now part of the header, but not as a single field. The TAG has been split into APP-NAME, PROCID, and MSGID. This does not totally resemble the usage of TAG, but provides the same functionality for most of the cases. In RFC 3164, STRUCTURED-DATA was not described. If a message compliant with this document contains STRUCTURED-DATA and must be reformatted according to RFC 3164, the STRUCTURED-DATA simply becomes part of the RFC 3164 CONTENT free-form text. In general, this document tries to provide an easily parseable header with clear field separations, whereas traditional BSD syslog suffers from some historically developed, hard to parse field separation rules. A.2. Message Length Implementers should note the message size limitations outlined in Section 6.1 and try to keep the most important data early in the message (within the minimum guaranteed length). This ensures the data will be seen by the collector or relay even if a transport receiver at a relay on the message path truncates the message. The reason syslog transport receivers need only support receiving up to and including 480 octets has, among other things, to do with difficult delivery problems in a broken network. Syslog messages may use a UDP transport mapping with this 480 octet restriction to avoid session overhead and message fragmentation. In a network with problems, the likelihood of getting one single-packet message delivered successfully is higher than getting two message fragments delivered successfully. Therefore, using a larger size may prevent the operator from getting some critical information about the problem, whereas using small messages might get that information to the operator. It is recommended that messages intended for troubleshooting purposes should not be larger than 480 octets. To further strengthen this point, it has also been observed that some UDP implementations generally do not support message sizes of more than 480 octets. This behavior is very rare and may no longer be an issue. There are other use cases where syslog messages are used to transmit inherently lengthy information, e.g., audit data. By not enforcing any upper limit on the message size, syslog applications can be implemented with any size needed and still be compliant with this document. In such cases, it is the operator's responsibility to Gerhards Standards Track [Page 35] RFC 5424 The Syslog Protocol March 2009 ensure that all components in a syslog infrastructure support the required message sizes. Transport mappings may recommend specific message size limits that must be implemented to be compliant. Implementers are reminded that the message length is specified in octets. There is a potentially large difference between the length in characters and the length in octets for UTF-8 strings. It must be noted that the IPv6 MTU is about 2.5 times 480. An implementation targeted towards an IPv6-only environment might thus assume this as a larger minimum size. A.3. Severity Values This section describes guidelines for using Severity as outlined in Section 6.2.1. All implementations should try to assign the most appropriate severity to their message. Most importantly, messages designed to enable debugging or testing of software should be assigned Severity 7. Severity 0 should be reserved for messages of very high importance (like serious hardware failures or imminent power failure). An implementation may use Severities 0 and 7 for other purposes if this is configured by the administrator. Because severities are very subjective, a relay or collector should not assume that all originators have the same definition of severity. A.4. TIME-SECFRAC Precision The TIMESTAMP described in Section 6.2.3 supports fractional seconds. This provides grounds for a very common coding error, where leading zeros are removed from the fractional seconds. For example, the TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as "2003-10-11T22:13:14.3". This would indicate 300 milliseconds instead of the 3 milliseconds actually meant. A.5. Case Convention for Names Names are used at various places in this document, for example for SD-IDs and PARAM-NAMEs. This document uses "lower camel case" consistently. With that, each name begins with a lower case letter and each new embedded word starts with an upper case letter, with no hyphen or other delimiter. An example of this is "timeQuality". While an implementation is free to use any other case convention for experimental names, it is suggested that the case convention outlined above is followed. Gerhards Standards Track [Page 36] RFC 5424 The Syslog Protocol March 2009 A.6. Syslog Applications Without Knowledge of Time In Section 6.2.3, the NILVALUE has been allowed for usage by originators without knowledge of time. This is done to support a special case when a syslog application is not aware of time at all. It can be argued whether such a syslog application can actually be found in today's IT infrastructure. However, discussion has indicated that those things may exist in practice and as such there should be a guideline established for this case. However, an implementation SHOULD emit a valid TIMESTAMP if the underlying operating system, programming system, and hardware supports a clock function. A proper TIMESTAMP should be emitted even if it is difficult to obtain the system time. The NILVALUE should only be used when it is actually impossible to obtain time information. This rule should not be used as an excuse for lazy implementations. A.7. Notes on the timeQuality SD-ID It is recommended that the value of "0" be the default for the "tzKnown" (Section 7.1.1) parameter. It should only be changed to "1" after the administrator has specifically configured the time zone. The value "1" may be used as the default if the underlying operating system provides accurate time zone information. It is still advised that the administrator consider the correctness of the time zone information. It is important not to create a false impression of accuracy with the timeQuality SD-ID (Section 7.1). An originator should only indicate a given accuracy if it actually knows it is within these bounds. It is generally assumed that the originator gains this in-depth knowledge through operator configuration. By default, an accuracy should not be provided. A.8. UTF-8 Encoding and the BOM This document specifies that SD-PARAMS must always be encoded in UTF-8. Other encodings of the message in the MSG portion, including ASCIIPRINT, are not permitted by a device conforming to this specification. There are two cases that need to be addressed here. First, a syslog application conforming to this specification may not be able to ascertain that the information given to it from an originator is encoded in UTF-8. If it cannot determine that with certainty, the syslog application may choose to not incorporate the BOM in the MSG. If the syslog application has a good indication that the content of the message is encoded in UTF-8, then it should include the BOM. In the second case, a syslog relay may be Gerhards Standards Track [Page 37] RFC 5424 The Syslog Protocol March 2009 forwarding a message from a device that does not conform to this specification. In that case, the device would likely not include the BOM unless it has ascertained that the received message was encoded in UTF-8. Author's Address Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany EMail: firstname.lastname@example.com Gerhards Standards Track [Page 38]


text:
The LifeKeeper with Oracle installation and configuration procedure differs slightly for replicated storage systems and shared stored systems. We have created separate sections in this document for each type of storage configuration in an effort to clarify the installation and configuration process.
For the most efficient setup, perform the following tasks to create an Oracle database instance first on the primary server and then on the secondary server.
Important Considerations
- When working on a particular server, switch the communication resource on that particular server, e.g. if working on the backup server, the communication resource should be switched to the backup server.
- The resource hierarchy will be preserved on an upgrade
- Only one SID is supported per Oracle Home directory
- Special consideration is required when the Oracle Home is not installed to the same LifeKeeper protected volume as the database (SID). If Oracle Home is installed on a different shared or replicated volume, that volume must be LifeKeeper protected and manually added as a dependent resource in the Oracle resource hierarchy. If Oracle Home is not installed on a LifeKeeper protected volume no changes are necessary.
- Use Windows disk management tools to configure the disk resources and the volumes. Use Oracle tools, e.g. Net Manager, to configure network protocols

subset: commoncrawl


text:
If this is your domain name, please visit this page to see how to register it as DNS zone into your account.
Note: If you already have registered the DNS zone for your domain name, please wait for DNS propagation. Your web site will be displayed soon. It may take few minutes.
* Do you know what the CAA record is?
Suggested article: What is CAA record?
The Certification Authority Authorization or CAA record is a type of DNS record. It specifies who can issue a certificate for the specific domain. It could be set for one or more certificate issuers.
The key components of the CAA resource record are:
When you are creating a CAA record, you can decide if it is responsible for the whole domain or just for a particular hostname. You can set the values for example.com, and it will automatically apply for subdomain.example.com.
Do you want to know more about DNS CAA records? Go ahead and click here!


text:
My newest "Office Hours" column is up at Library Journal:
Not all students are ready to take this on. Some can only operate within the constraints of their own limited assumptions of what library work is. To conclude last semester, my LIS701 class walked a local labyrinth, as Pink describes, to engage the left brain and free the right to explore new ideas. "Think about your professional practice," I said before the walk. "What can you do to encourage the heart of your library users?"
I caught up with one of the students from that class, Tara Wood, and asked her what she thought about it. "I think that it is just as easy for students to fall into a certain 'comfort zone' as it is for librarians. We get used to coming to class, listening to lectures, writing papers, etc., but these are not always the best methods for learning. At first, we all felt a little silly walking the labyrinth, but by the end we felt differently…. [I felt] a sense of clearing out the 'junk' in my mind and being able to focus."
What are your heretical thoughts about libraries and LIS education? Personally, I never give exams and focus instead on writing and personal reflection about the practice of librarianship. The strongest student papers are usually those with a personal slant that tell a story as a means to show comprehension of course material.
I've received some good feedback, including this from Nann Blaine Hilyard, director of the Zion-Benton Public Library in Zion, IL:
Michael's closing paragraph recalls something that Lawrence Clark Powell wrote: "A good librarian is not a social scientist, a documentalist, a retrievalist, or an automaton. A good librarian is a librarian: a person with good health and warm heart, trained by study and seasoned by experience to catalyze books and people."
Nann let me know the quote is posted in the ZBPL staff area and is most probably from "Books in My Baggage." I think it's beautiful.


text:
Here we go again.
Hot on the heels of the Jenny Kwan expense scandal comes BC Speaker of the House Linda Reid with her own rendition of the hit song " It's not wrong, it's within the rules".
When asked if she would do it again, did she say no?
No she said she would have the conversation with audits to see if the practice would remain the same!
She doesn't get it!
The sense of entitlement is disgusting and both she and the people that put her in the job should be ashamed.
This is her second go around in the expense trough with the first being the $48,000 touch screen computer terminal.
Linda Reid should do the right thing and step down, resign and leave politics.
If she doesn't her colleagues ought to shame her into leaving starting with the Premier.
This is a reflection on her government.
Does nobody in the provincial elected house take taxpayers money seriously?
When will it stop?


text:
The security risks of virtualization
Virtualization security is a topic that often goes undiscussed on the Internet, and you may even think it's a non-issue because of this. However, like the rest of your technology, a virtualized infrastructure must be secured. To help keep yours protected, here are some of the security risks involved with virtualization and how you can go about mitigating them.
Security risks of virtualization
Complex infrastructure - much like the topic of virtualization itself, the infrastructure of a virtualization solution can oftentimes be confusing to small businesses. The extra layers of infrastructure complexity added by virtualization can make it more difficult to spot anomalies and unusual events happening in your virtual machines and network.
Dynamic design - the design of a virtualized environment is dynamic by nature and constantly changing. Unlike adding physical equipment, which is a bit of an event as you make room for it in your office and install it, the addition of virtual machines can go almost completely unnoticed as they're created in a matter of minutes and aren't visible in your workspace. The danger here is the age old adage, "out of sight out of mind." And if you add too many, they can easily become difficult to manage and secure, creating security holes in the process.
Quick moving workloads - as your virtualized infrastructure grows, there will come a time when you need to move workloads from one machine to another. While this may sound harmless enough, the real issue is that your virtual machines will likely require different levels of security. And when you're juggling multiple workloads over multiple virtual machines, you may accidentally move mission critical workloads to a machine with a low level security, creating a security hole in the process.
How to mitigate risks
While these three risks may sound alarming, they can all be mitigated. The key behind effectively securing your virtual machines all comes down to process. Put some thought into your security processes and then implement them. Here are a few areas to cover:
Organization - decide how and where to separate your test, development and production virtual machines.
Audit - develop a system to regularly audit your virtual machine security. Whenever possible, use tools to automate your security checks, balances and processes.
Patches - Perform regular security patch maintenance, and create a schedule to ensure your patches are up-to-date for all virtual machines.
Overflow management - When you have so many virtual machines they're hard to track, you need a system in place to monitor them. So be aware of what each virtual machine is used for, and manage it accordingly. While doing this, find ways to consolidate machines whenever possible and get rid of the ones under utilized.
Responsibility - to ensure the security of your virtual machines doesn't slip through the cracks, designate one IT technician or manager to be responsible for it.
If you prioritize security of your virtual machines and properly manage them, security can truly be a non-issue. If you'd like additional assistance with your virtualized infrastructure or would like to implement a new virtualization solution, give us a call today.
Published with permission from TechAdvisory.org. Source.


text:
In someways regular life has gone on for Syrian President Bashar Assad and his family.
Despite the fact that over the past year, his government has led a bloody offensive that's killed more than 7,500 of his own people, the Syrian dictator still shopped for music and clothes as well as shared jokes and videos with friends.
That's according to a cache of emails intercepted by Assad's opposition and handed over to The Guardian, which verified the authenticity of some emails but was unable to verify all of them. They report:
"The documents, which emerge on the first anniversary of the rebellion that has seen more than 8,000 Syrians killed, paint a portrait of a first family remarkably insulated from the mounting crisis and continuing to enjoy a luxurious lifestyle.
"They appear to show the president's wife spending thousands of dollars over the internet for designer goods while he swaps entertaining internet links on his iPad and downloads music from iTunes.
"As the world watched in horror at the brutal suppression of protests across the country and many Syrians faced food shortages and other hardships, Mrs Assad spent more than £10,000 on candlesticks, tables and chandeliers from Paris and instructed an aide to order a fondue set from Amazon."
The emails also show that Assad directly commanded the attacks on Homs and that he was also very involved in the media strategy to blunt the criticism of the crackdown.
Perhaps the most interesting emails are those exchanged between Assad's wife Asma and Qatar emir's daughter, Mayassa al-Thani.
Thani communicated often with Asma but the communication chilled, the Guardian reports, after Thani sent this email on Jan. 30:
"Just been following the latest developments in Syria ... in all honesty – looking at the tide of history and the escalation of recent events – we've seen two results – leaders stepping down and getting political asylum or leaders being brutally attacked. I honestly think this is a good opportunity to leave and re-start a normal life. I only pray that you will convince the president to take this an opportunity to exit without having to face charges. The region needs to stabilise, but not more than you need peace of mind. I am sure you have many places to turn to, including Doha."
The Guardianhas full coverage of coverage of the emails here.
Copyright 2020 NPR. To see more, visit https://www.npr.org.


text:
Physicists on experiments at the Large Hadron Collider announced today that they have observed a new particle. Whether the particle has the properties of the predicted Higgs boson remains to be seen.
UCI scientists played a key role in today's findings. Professor Andrew Lankford is the deputy director of the ATLAS experiment, one of the LHC's four particle detectors. The UCI team – composed of eight faculty members and many postdoctoral researchers and staff -- joined hundreds of scientists and graduate students from American institutions to play important roles in the search for the Higgs at the LHC. More than 1,700 people from U.S. institutions – including 89 American universities and seven U.S. Department of Energy (DOE) national laboratories – helped design, build and operate the LHC accelerator and its four particle detectors. The United States, through DOE's Office of Science and the National Science Foundation, provides support for research and detector operations at the LHC and also supplies computing for the ATLAS and CMS experiments.
The results announced today are labeled preliminary. They are based on data collected in 2011 and 2012, with the 2012 data still under analysis. A more complete picture of today's observations will emerge later this year after the LHC provides the experiments with more data.
The new particle is in the mass region around 125-126 GeV. Publication of the analyses shown today is expected around the end of July.
"I congratulate the thousands of scientists around the globe for their outstanding work in searching for the Higgs boson," said U.S. Secretary of Energy Steven Chu. "Today's announcement on the latest results of this search shows the benefits of sustained investments in basic science by governments around the world. Scientists have been looking for the Higgs particle for more than two decades; these results help validate the Standard Model used by scientists to explain the nature of matter."
The CMS and ATLAS experiments in December announced seeing tantalizing hints of a new particle in their hunt for the Higgs, the missing piece in the Standard Model of particle physics. Since resuming data-taking in March 2012, the CMS and ATLAS experiments have more than doubled their collected data. The statistical significance of the earlier hints has grown.
"What has been announced today could not have been accomplished without the cooperation of scientists and nations throughout the world in seeking an understanding of the fundamental laws of nature," said Ed Seidel, NSF's assistant director for the Mathematical and Physical Sciences. "If the particle announced today at CERN is confirmed to be the Higgs boson, this represents a keystone in our knowledge of the elementary forces and particles that exist in our universe."
Scientists on experiments at the LHC announced their latest results at a seminar at the home of the LHC, the CERN particle physics laboratory on the border of Switzerland and France. Physicists from across the United States gathered at laboratories and universities in the middle of the night to watch a live-stream of the seminar online. The vast majority of U.S. scientists participate in the LHC experiments from their home institutions, remotely accessing and analyzing the data through high-capacity networks and grid computing.
Scientists will give more detailed presentations about the results this week at the biannual International Conference on High Energy Physics, held this year in Melbourne, Australia.
The Standard Model of particle physics has proven to explain correctly the elementary particles and forces of nature through more than four decades of experimental tests. But it cannot, without the Higgs boson, explain how most of these particles acquire their mass, a key ingredient in the formation of our universe.
Scientists proposed in 1964 the existence of a new particle, now known as the Higgs boson, whose coupling with other particles would determine their mass. Experiments at the LEP collider at CERN and the Tevatron collider at the Department of Energy's Fermilab have searched for the Higgs boson, but it has eluded discovery. Only now, after decades of developments in accelerator and detector technology and computing – not to mention advancements in the understanding of the rest of the Standard Model – are scientists approaching the moment of knowing whether the Higgs was the right solution to this problem.
"What we are observing is very likely a new particle with very large mass that would have to be a boson," said University of California Santa Barbara physicist Joe Incandela, spokesperson of the CMS experiment. "This is potentially an historic and very profound step forward in our understanding of the underlying structure of our universe. "
When protons collide in the Large Hadron Collider, their energy can convert into mass, often creating short-lived particles. These particles quickly decay into pairs of lighter, more stable particles that scientists can record with their detectors.
Theoretical physicists have predicted the rate at which the Higgs boson will be produced in high-energy proton-proton collisions at the LHC and also how it decays into certain combinations of observable particles. Experimental physicists at the ATLAS and CMS experiments have been studying the collisions and have observed a new particle. They will need to collect more data and run further analysis to determine its properties.
"If the new particle is determined to be the Higgs, attention will turn to a new set of important questions," said University of California Irvine physicist Andy Lankford, deputy spokesperson of ATLAS. "Is this a Standard Model Higgs, or is it a variant that indicates new physics and other new particles?"
Discovery of the Higgs – or another new particle – would represent only the first step into a new realm of understanding of the world around us.
School of Physical Sciences


text:
Not one to make travel goals, I did make one when coming to Spain: visit all 17 autonomous communities at least once before going home. While Madrid, Barcelona and Seville are the stars of the tourist dollar show (and my hard-earned euros, let's not kid around here), I am a champion for Spain's little-known towns and regions. Having a global view of this country has come through living in Andalucía, working in Galicia and studying in Castilla y León, plus extensive travel throughout Spain.
I was fascinated with the Basque Country from my time studying abroad. Our shared bedroom was sparse, but had a detailed map of Spain plastered onto the wall, and I'd usually stare it before taking my siesta. Just north of Castilla y León lay a land where Zs and Xs and Ks seemed to make up all of the towns and cities, and once I began modern culture classes at the Universidad de Valladolid, I realized how different Spain was from region to region.
I jumped at the chance to visit regal San Sebastián and hip Bilbao during a long weekend, traveling five hours north by train. The arid meseta – experiencing a drought that summer – gave way to the lush gardens of Vitoria and rolling hills. I noticed the roofs slanted because of the rain. The words on shops and billboards became illegible. Tapas were served on bread.
Toto, we're not in Spain anymore.
Name: País Vasco in castellano, Euskadi in Basque and Pays Basque in French
Population: 2.17 million
Provinces: Three; Álava in the south, Bizkaia on the Bay of Biscay and Guipúzkoa. There are rather three regional capitals cities: Vitoria-Gasteiz, Bilbao and Donostia, though Vitoria is the legislative powerhouse of the comunidad.
When: 3rd of 17, June 2005
About Euskadi: Located in the Biscay Bay basin and featuring mountains, plains and beach, Euskadi packs a lot of punch for a small region. Quaint fishing villages sidle up to industrial cities, and the mix of sea-mountains-plains make it an attractive pocket of Spain for outdoor enthusiasts.
Anyone who has studied Spanish will know that there are two co-official langauges in Euskadi: Castillian Spanish and Basque. After centuries of repression and intense waves of immigration, the language is making a comeback and cries for independence from Spain are becoming louder.
But I'm ahead of myself.
The Basque people have traits that are untraceable to other ethnic groups, and their language shares no common roots with other European tongues. These indigenous people have long inhabited what is now the Basque region, which makes up the northeast part of Spain and southwest of France (St Jean de Luz and Biarritz are worth day trips!).
Though their exact origin is hotly debated, the Basque are said to come from the Vascon tribes that lived at the foothills of the Pyrenees mountains. For centuries they were left unattacked by the various groups that passed through the Iberian penninsula until finally falling to Castillian forces in the 16th Century.
After years of linguistic and cultural freedom, the constraints put on the vascos from the Spanish crown were surprisingly minimal until the Carlist Wars of the 19th Century, and Franco's rise to power after the Spanish Civil War meant that euskera was banned and the region lost all of its self-governing rights in an attempt to homogenize Spain.
Two decades later, the Basque Separatist group, Euskadi Ta Astatasuna (ETA) was formed, and over 800 people have been killed in terrorist plots – a friend of my aunt's father among them. After numerous ceasefires and resurgences, the group announced a definitive end to armed activity in 2011.
In the modern age, Bilbao has drawn the attention of economists for somehow sidestepping the financial crisis, and for a millennia old people, vascos are rather forward-thinking.
Must sees: Euskadi's three major towns are definite visits: San Sabastián/Donostia's quaint old quarter boasts more pintxos bars than residents and its Bahía de la Concha is one of Spain's most photographed beaches (and that's not to mention the surfing or its world-famous film festival); Bilbao/Bilbo is home to the Guggenheim and a prosperous industrial city; Vitoria-Gasteiz is famous for its parks and gardens and is the administrative capital of the autonomous community.
Further afield lie charming fishing villages and hamlets like Lekeitio or Hondarribia, the jaw-dropping hike to San Juan de Guazalugatxe and Guernika, a city made famous for its role in Nazi bombings and immortalized in a Picasso painting of the same name.
Gastronomy is also a top draw to the region, with four of the top 20 restaurants in the world found here. Pintxos – small, generally seafood-based tapas served atop bread – are the north's equivalent of tapas. Revelers take part in bar crawls called txikiteo, often imbibing in a sparkling white wine called txacoli or Alavese wines, which form part of the D.O. La Rioja.
Culturally speaking, Basque have their own traditions of Santa Claus, throw enormous parties and have long traditions of Basque strength sports. Local lore pervades daily life and, like Navarra, it's a place where cultural roots have held firm throughout centuries.
Finally, a note on the weather: it's not very reliable, particularly in Bilbao and San Sebastián.
My take: There was some truth to my initial observations of Euskadi, but as someone who was clueless about Spanish history and hadn't even been to Madrid, were largely wrong. I traveled north a few years later with a friend, far more interested in what the region had to offer and more acutely aware of the differences between the Basques and the rest of Spain – and in far more than just language.
Andalucía and País Vasco couldn't be more different, as evidenced in the hugely popular film Ocho Apellidos Vascos, in which a sevillano de pura cepa falls for a vasca on her bachelorette weekend in Sevilla. Rafa is as sevillano as they get, and follows Amaia up to her small town hidden deep within Euskadi, trying to win her – and her father's – heart.
The film is a bit over the top, of course, but highlights how regionalism is still a big thing in Spain, and no one embraces it like the vascos. The main cities just feel like they're not as Spanish as Madrid or Seville or Salamanca. Its citizens have darker features and seem to carry themselves differently. Food is a big deal, as is surfing, Athletic and txacoli from what I've gathered.
Suffice to say, I'm keen to travel back to País Vasco as soon as possible.
Have you ever been to País Vasco? What do you like (or not) about it? Check out the blogs Christine in Spain, a Thing With Wor(l)ds and Como Perderse en España for excellent insight into life in the region!
Want more Spain? Andalucía | Aragón | Asturias | Islas Baleares | Islas Canarias | Cantabria | Castilla y León | Castilla-La Mancha | Cataluña | Extremadura | Galicia | La Rioja | Madrid | Murcia | Navarra


text:
E al doilea an in care sunt MVP pe C# in ROmania – asa ca o sa imi pun pe blog chestia asta. M-am gindit ca primul an e din intimplare –acum se pare ca da, fac niste chestii bine pentru care primesc laude …
Asa ca o sa imi pun si poza si aprecierea – ca sa ma simt bine …
Thursday, April 01, 2010
Re: Andrei Ignat, Most Valuable Professional, Visual C#
To whom it may concern,
It is with great pride we announce that Andrei Ignat has been awarded as a Microsoft® Most Valuable Professional
(MVP) for 4/1/2010 – 4/1/2011. The Microsoft MVP Award is an annual award that recognizes exceptional
technology community leaders worldwide who actively share their high quality, real world expertise with users and
Microsoft. All of us at Microsoft recognize and appreciate Andrei's extraordinary contributions and want to take this
opportunity to share our appreciation with you.
With fewer than 5,000 awardees worldwide, Microsoft MVPs represent a highly select group of experts. MVPs
share a deep commitment to community and a willingness to help others. They represent the diversity of today's
technical communities. MVPs are present in over 90 countries, spanning more than 30 languages, and over 90
Microsoft technologies. MVPs share a passion for technology, a willingness to help others, and a commitment to
community. These are the qualities that make MVPs exceptional community leaders. MVPs' efforts enhance
people's lives and contribute to our industry's success in many ways. By sharing their knowledge and experiences,
and providing objective feedback, they help people solve problems and discover new capabilities every day. MVPs
are technology's best and brightest, and we are honored to welcome Andrei as one of them.
To recognize the contributions they make, MVPs from around the world have the opportunity to meet Microsoft
executives, network with peers, and position themselves as technical community leaders. This is accomplished
through speaking engagements, one on one customer event participation and technical content development.
MVPs also receive early access to technology through a variety of programs offered by Microsoft, which keeps
them on the cutting edge of the software and hardware industry.
As a recipient of this year's Microsoft MVP award, Andrei joins an exceptional group of individuals from around the
world who have demonstrated a willingness to reach out, share their technical expertise with others and help
individuals maximize their use of technology.
Rich Kaplan
Corporate Vice President
Customer and Partner Advocacy
Microsoft Corporation