[要約] RFC 5424は、シスログプロトコルに関する標準仕様であり、ログメッセージの受け渡しと管理を目的としています。このRFCは、システム管理者や開発者にとって重要な情報源となることが期待されています。
Network Working Group R. Gerhards
Request for Comments: 5424 Adiscon GmbH
Obsoletes: 3164 March 2009
Category: Standards Track
The Syslog Protocol
Syslogプロトコル
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に発効するIETFドキュメントに関連するIETFトラストの法的規定の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
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.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
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.
このドキュメントでは、イベント通知メッセージの伝達に使用されるsyslogプロトコルについて説明します。このプロトコルは階層化されたアーキテクチャを利用しており、syslogメッセージの送信にトランスポートプロトコルをいくつでも使用できます。また、ベンダー固有の拡張機能を構造化された方法で提供できるようにするメッセージ形式も提供します。
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.
このドキュメントは、従来のsyslogの元の設計目標を念頭に置いて作成されています。信頼性と安全性の高いsyslog拡張機能の標準化の取り組みは、Standards-Trackとトランスポートに依存しないRFCの欠如に悩まされているため、新しい階層化された仕様の必要性が生じています。このドキュメントがないと、他の各標準で独自のsyslogパケット形式とトランスポートメカニズムを定義する必要があり、時間が経つと互換性の問題が発生します。このドキュメントは、syslog拡張が構築できる基盤を提供することを目的としています。このレイヤードアーキテクチャアプローチは、コードを各トランスポートに対して1回ではなく、syslog機能ごとに1回書き込むことができる強固な基盤も提供します。
This document obsoletes RFC 3164.
このドキュメントは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
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
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.
このドキュメントでは、syslogの階層型アーキテクチャについて説明します。このアーキテクチャの目標は、各層で簡単に拡張できるようにしながら、メッセージコンテンツをメッセージ転送から分離することです。
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.
このドキュメントでは、syslogメッセージの標準形式について説明し、トランスポートマッピングの概念について概説します。また、構造化されたデータ要素についても説明します。これは、簡単に解析できる構造化された情報を送信するために使用でき、ベンダーの拡張を可能にします。
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.
このドキュメントでは、syslogメッセージの保存形式については説明していません。これは、syslogプロトコルの範囲を超えており、システムの相互運用性には不要です。
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.
このドキュメントは、従来のsyslogの元の設計目標を念頭に置いて作成されています。信頼性と安全性の高いsyslog拡張機能の標準化の取り組みは、Standards-Trackとトランスポートに依存しないRFCの欠如に悩まされているため、新しい階層化された仕様の必要性が生じています。このドキュメントがなければ、他の各規格は独自のsyslogパケット形式とトランスポートメカニズムを定義する必要があり、やがて微妙な互換性の問題が発生します。このドキュメントは、syslog拡張が構築できる基盤を提供することを目的としています。このレイヤードアーキテクチャアプローチは、コードを各トランスポートに対して1回ではなく、syslog機能ごとに1回書き込むことができる強固な基盤も提供します。
This document obsoletes RFC 3164, which is an Informational document describing some implementations found in the field.
このドキュメントはRFC 3164を廃止します。RFC3164は、フィールドで見つかったいくつかの実装を説明する情報ドキュメントです。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
Syslog utilizes three layers:
Syslogは3つの層を利用します。
o "syslog content" is the management information contained in a syslog message.
o 「syslogコンテンツ」は、syslogメッセージに含まれる管理情報です。
o The "syslog application" layer handles generation, interpretation, routing, and storage of syslog messages.
o 「syslogアプリケーション」層は、syslogメッセージの生成、解釈、ルーティング、および格納を処理します。
o The "syslog transport" layer puts messages on the wire and takes them off the wire.
o 「syslogトランスポート」層は、メッセージをネットワークに送信し、ネットワークから削除します。
Certain types of functions are performed at each conceptual layer:
特定のタイプの機能は、各概念層で実行されます。
o An "originator" generates syslog content to be carried in a message.
o 「発信元」は、メッセージで伝達されるsyslogコンテンツを生成します。
o A "collector" gathers syslog content for further analysis.
o 「コレクター」は、さらに分析するためにsyslogコンテンツを収集します。
o A "relay" forwards messages, accepting messages from originators or other relays and sending them to collectors or other relays.
o 「リレー」はメッセージを転送し、発信者または他のリレーからのメッセージを受け入れ、コレクターまたは他のリレーに送信します。
o A "transport sender" passes syslog messages to a specific transport protocol.
o 「トランスポート送信者」は、syslogメッセージを特定のトランスポートプロトコルに渡します。
o A "transport receiver" takes syslog messages from a specific transport protocol.
o 「トランスポートレシーバー」は、特定のトランスポートプロトコルからsyslogメッセージを受け取ります。
Diagram 1 shows the different entities separated by layer.
図1は、レイヤーで区切られたさまざまなエンティティを示しています。
+---------------------+ +---------------------+
| content | | content |
|---------------------| |---------------------|
| syslog application | | syslog application | (originator,
| | | | collector, relay)
|---------------------| |---------------------|
| syslog transport | | syslog transport | (transport sender,
| | | | (transport receiver)
+---------------------+ +---------------------+
^ ^
| |
--------------------------
Diagram 1. Syslog Layers
図1. Syslogレイヤー
The following principles apply to syslog communication:
以下の原則がsyslog通信に適用されます。
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 syslogプロトコルは、メッセージ配信の確認応答を提供しません。一部のトランスポートはステータス情報を提供しますが、概念的には、syslogは純粋なシンプレックス通信プロトコルです。
o Originators and relays may be configured to send the same message to multiple collectors and relays.
o 発信者とリレーは、同じメッセージを複数のコレクタとリレーに送信するように構成できます。
o Originator, relay, and collector functionality may reside on the same system.
o オリジネーター、リレー、コレクターの機能は、同じシステムに常駐できます。
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.
配置シナリオの例を図2に示します。これらの例の他の配置も許容されます。前述のように、次の図では、リレーは受信するメッセージのすべてまたは一部を送信する場合と、内部で生成するメッセージを送信する場合があります。ボックスは、syslog対応のアプリケーションを表します。
+----------+ +---------+
|Originator|---->----|Collector|
+----------+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
+----------+ +-----+ +---------+
+----------+ +-----+ +-----+ +---------+
|Originator|-->--|Relay|-->--..-->--|Relay|-->--|Collector|
+----------+ +-----+ +-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->----|Collector|
| |-+ +-----+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +---------+
|Originator|---->----|Collector|
| |-+ +---------+
+----------+ \
\ +-----+ +---------+
+->--|Relay|---->----|Collector|
+-----+ +---------+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->-------|Collector|
| |-+ +-----+ +---| |
+----------+ \ / +---------+
\ +-----+ /
+->--|Relay|-->--/
+-----+
+----------+ +-----+ +---------+
|Originator|---->----|Relay|---->--------------|Collector|
| |-+ +-----+ +--| |
+----------+ \ / +---------+
\ +------------+ /
\ |+----------+| /
+->-||Relay ||->---/
|+----------|| /
||Originator||->-/
|+----------+|
+------------+
Diagram 2. Some Possible Syslog Deployment Scenarios
図2.考えられるいくつかのSyslog展開シナリオ
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.
このドキュメントでは、トランスポート層プロトコルを指定していません。代わりに、トランスポート層に依存しない方法でsyslogメッセージのフォーマットを記述します。 Syslogトランスポートは他のドキュメントで定義されています。そのようなトランスポートの1つは[RFC5426]で定義されており、従来のUDPトランスポートと一致しています。 UDPトランスポートはこれまでsyslogメッセージの送信に使用されてきたため、このトランスポートは相互運用性を維持するために必要です。
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.
syslogトランスポートプロトコルは、syslogメッセージを故意に変更してはなりません。トランスポートプロトコルがトランスポートセンダーで一時的な変換を実行する必要がある場合、リレーまたはコレクターが発信者またはリレーによって生成されたメッセージの正確なコピーを見ることができるように、トランスポートプロトコルによってこれらの変換を逆にする必要があります。そうしないと、エンドツーエンドの暗号検証（署名など）が破損します。もちろん、送信エラーやその他の問題が原因でメッセージが変更される可能性があります。このような変更に対する保護は、このドキュメントの範囲外です。
All implementations of this specification MUST support a TLS-based transport as described in [RFC5425].
この仕様のすべての実装は、[RFC5425]で説明されているように、TLSベースのトランスポートをサポートする必要があります。
All implementations of this specification SHOULD also support a UDP-based transport as described in [RFC5426].
この仕様のすべての実装は、[RFC5426]で説明されているように、UDPベースのトランスポートもサポートする必要があります（SHOULD）。
It is RECOMMENDED that deployments of this specification use the TLS-based transport.
この仕様のデプロイメントではTLSベースのトランスポートを使用することをお勧めします。
The syslog message has the following ABNF [RFC5234] definition:
syslogメッセージには、次のABNF [RFC5234]定義があります。
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
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 = "-"
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.
syslogメッセージのサイズ制限は、使用中のsyslogトランスポートマッピングによって決まります。それ自体には上限はありません。各トランスポートマッピングは、必要な最小の最大メッセージ長サポートを定義し、最小の最大長は少なくとも480オクテットでなければなりません。
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.
すべてのトランスポートレシーバーは、長さが最大480オクテットのメッセージを受け入れることができる必要があります。すべてのトランスポートレシーバの実装は、長さが最大2048オクテットまでのメッセージを受け入れることができる必要があります（SHOULD）。トランスポートレシーバーは、長さが2048オクテットを超えるメッセージを受信する場合があります。トランスポートレシーバーがサポートするよりも長いメッセージを受信した場合、トランスポートレシーバーはペイロードを切り捨てるべきです（SHOULD）。あるいは、メッセージを破棄してもよい（MAY）。
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.
トランスポートレシーバーがメッセージを切り捨てる場合、切り捨てはメッセージの最後に発生する必要があります。切り捨て後、メッセージに無効なUTF-8エンコーディングまたは無効なSTRUCTURED-DATAが含まれる場合があります。この場合、トランスポートレシーバーはメッセージを破棄するか、または可能な限り処理を試みてもよい（MAY）。
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].
ヘッダーで使用される文字セットは、[RFC5234]で説明されているように、8ビットフィールドの7ビットASCIIである必要があります。これらは、「米国情報交換用標準コード」[ANSI.X3-4.1968]で定義されているASCIIコードです。
The header format is designed to provide some interoperability with older BSD-based syslog. For details on this, see Appendix A.1.
ヘッダー形式は、古いBSDベースのsyslogとの相互運用性を提供するように設計されています。詳細については、付録A.1を参照してください。
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' 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").
PRI部分は3、4、または5文字である必要があり、最初と最後の文字として山括弧で囲まれます。 PRIの部分は、先頭が「<」（「より小」の文字、％d60）で始まり、その後に数字が続き、その後に「>」（「より大」の文字、％d62）が続きます。これらの山括弧内に含まれる数値は優先度値（PRIVAL）と呼ばれ、ファシリティと重大度の両方を表します。優先度の値は、％d48（ "0"の場合）から％d57（ "9"の場合）までの値を使用した1、2、または3つの10進整数（ABNF DIGITS）で構成されます。
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.
ファシリティと重大度の値は規範的ではありませんが、よく使用されます。これらは、情報提供のみを目的として、次の表で説明されています。ファシリティ値は、0から23までの範囲でなければなりません。
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
表1. Syslogメッセージ機能
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.
各メッセージの優先度には、10進数の重大度レベルインジケータもあります。次の表で、これらを数値とともに説明します。重大度の値は、0から7までの範囲でなければなりません。
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
表2. Syslogメッセージの重大度
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.
優先度の値は、最初にファシリティ番号に8を掛けてから、重大度の数値を加算して計算されます。たとえば、緊急度（Severity = 0）のカーネルメッセージ（Facility = 0）の優先度の値は0になります。また、通知の重要度（Severity）の「local use 4」メッセージ（Facility = 20）もあります。 = 5）の優先度値は165です。syslogメッセージのPRIでは、これらの値は山括弧の間にそれぞれ<0>および<165>として配置されます。 「<」の後に「0」の値が続くのは、「0」の優先順位値の場合のみです。それ以外の場合は、先頭の「0」を使用してはなりません。
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].
VERSIONフィールドは、syslogプロトコル仕様のバージョンを示します。 HEADER形式の一部を変更する新しいsyslogプロトコル仕様では、バージョン番号をインクリメントする必要があります。変更には、フィールドの追加または削除、または既存のフィールドの構文またはセマンティクスの変更が含まれます。このドキュメントでは、VERSION値に「1」を使用しています。 [RFC5226]で説明されているように、VERSION値は標準アクションメソッドを介してIANAによって割り当てられます（セクション9.1）。
The TIMESTAMP field is a formalized timestamp derived from [RFC3339].
TIMESTAMPフィールドは[RFC3339]から派生した形式化されたタイムスタンプです。
Whereas [RFC3339] makes allowances for multiple syntaxes, this document imposes further restrictions. The TIMESTAMP value MUST follow these restrictions:
[RFC3339]は複数の構文を考慮していますが、このドキュメントではさらに制限があります。 TIMESTAMP値は、次の制限に従う必要があります。
o The "T" and "Z" characters in this syntax MUST be upper case.
o この構文の「T」および「Z」文字は大文字でなければなりません。
o Usage of the "T" character is REQUIRED.
o 「T」文字の使用は必須です。
o Leap seconds MUST NOT be used.
o うるう秒は使用しないでください。
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.
発信者は、クロックの精度とパフォーマンスが許せば、TIME-SECFRACを含める必要があります（SHOULD）。セクション7.1で説明されている「timeQuality」SD-IDにより、発信者はタイムスタンプの正確さと信頼性を指定できます。
A syslog application MUST use the NILVALUE as TIMESTAMP if the syslog application is incapable of obtaining system time.
syslogアプリケーションがシステム時間を取得できない場合、syslogアプリケーションはNILVALUEをTIMESTAMPとして使用する必要があります。
Example 1
例1
1985-04-12T23:20:50.52Z
1985-04-12T23：20：50.52Z
This represents 20 minutes and 50.52 seconds after the 23rd hour of 12 April 1985 in UTC.
これは、UTCでの1985年4月12日の23時間後の20分50.52秒を表しています。
Example 2
例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).
これは、例1と同じ時間を表しますが、米国東部標準時（夏時間の観測）で表されます。
Example 3
例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.
これは、2003年10月11日の午後10時14分15秒、次の秒の3ミリ秒に相当します。タイムスタンプはUTCです。タイムスタンプはミリ秒の精度を提供します。作成者は実際にはより良い解像度を持っていたかもしれませんが、秒の小数部分に3桁だけを指定してもわかりません。
Example 4
実施例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.
これは、2003年8月24日の午前5時14分15秒、次の秒まで3マイクロ秒に相当します。マイクロ秒の分解能は、TIME-SECFRACの追加の数字によって示されます。タイムスタンプは、現地時間がUTCから-7時間であることを示しています。このタイムスタンプは、夏時間の間に米国太平洋時間帯で作成される場合があります。
Example 5 - An Invalid TIMESTAMP
例5-無効な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.
この例は例4とほぼ同じですが、TIME-SECFRACをナノ秒で指定しています。これにより、TIME-SECFRACが許容される6桁よりも長くなり、無効になります。
The HOSTNAME field identifies the machine that originally sent the syslog message.
HOSTNAMEフィールドは、syslogメッセージを最初に送信したマシンを識別します。
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.
HOSTNAMEフィールドには、発信者のホスト名とドメイン名がSTD 13 [RFC1034]で指定された形式で含まれる必要があります（SHOULD）。この形式は、このドキュメントでは完全修飾ドメイン名（FQDN）と呼ばれています。
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:
実際には、すべてのsyslogアプリケーションがFQDNを提供できるわけではありません。そのため、他の値もHOSTNAMEに存在する場合があります。このドキュメントでは、このような状況で他の値を使用するための規定を作成します。 Syslogアプリケーションは、最も具体的な利用可能な値を最初に提供する必要があります（SHOULD）。 HOSTNAMEフィールドの内容の優先順位は次のとおりです。
1. FQDN
1. FQDN
2. Static IP address
2. 静的IPアドレス
3. hostname
3. ホスト名
4. Dynamic IP address
4. 動的IPアドレス
5. the NILVALUE
5. 準備金
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.
IPv4アドレスを使用する場合は、STD 13 [RFC1035]で使用されているドット付き10進表記の形式にする必要があります。 IPv6アドレスを使用する場合は、[RFC4291]のセクション2.2で説明されている有効なテキスト表現を使用する必要があります。
Syslog applications SHOULD consistently use the same value in the HOSTNAME field for as long as possible.
Syslogアプリケーションは、可能な限り一貫してHOSTNAMEフィールドの同じ値を使用する必要があります（SHOULD）。
The NILVALUE SHOULD only be used when the syslog application has no way to obtain its real hostname. This situation is considered highly unlikely.
NILVALUE SHOULDは、syslogアプリケーションに実際のホスト名を取得する方法がない場合にのみ使用してください。この状況はほとんどあり得ないと考えられています。
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.
APP-NAMEフィールドは、メッセージを発信したデバイスまたはアプリケーションを識別する必要があります（SHOULD）。それはそれ以上のセマンティクスのない文字列です。これは、リレーまたはコレクターでメッセージをフィルタリングするためのものです。
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.
NILVALUEは、syslogアプリケーションがAPP-NAMEを認識していないか、その情報を提供できない場合に使用できます。ローカルポリシーの決定のため、またはデバイス上で情報が利用できないか適用されないため、デバイスがその情報を提供できない可能性があります。
This field MAY be operator-assigned.
このフィールドは、オペレーターが割り当てることができます。
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.
PROCIDはメッセージに含まれる値であり、相互運用可能な意味はありません。ただし、値の変更は、syslogレポートに不連続性があったことを示します。フィールドには特定の構文やセマンティクスはありません。値は実装に依存するか、オペレーターが割り当てます。 NILVALUEは、値が提供されていない場合に使用される場合があります。
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フィールドは、syslogシステムに関連付けられたプロセス名またはプロセスIDを提供するためによく使用されます。 NILVALUEは、プロセスIDが使用できない場合に使用される可能性があります。オペレーティングシステムプロセスIDのない組み込みシステムでは、PROCIDが再起動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は、syslogプロセスIDの変更を検出することにより、ログアナライザーがsyslogレポートの不連続性を検出できるようにします。ただし、再起動されたsyslogプロセスには前のsyslogプロセスと同じプロセスIDが割り当てられる可能性があるため、PROCIDは再起動されたプロセスの信頼できるIDではありません。
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.
PROCIDは、メッセージのグループに属するメッセージを識別するためにも使用できます。たとえば、SMTPメール転送エージェントは、SMTPトランザクションIDをPROCIDに入れることができます。これにより、コレクタまたはリレーは、SMTPトランザクションに基づいてメッセージをグループ化できます。
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.
MSGIDはメッセージのタイプを識別する必要があります（SHOULD）。たとえば、ファイアウォールは、着信TCPトラフィックにMSGID "TCPIN"を使用し、発信TCPトラフィックにMSGID "TCPOUT"を使用する場合があります。同じMSGIDのメッセージは、同じセマンティクスのイベントを反映する必要があります。 MSGID自体は、それ以上のセマンティクスのない文字列です。これは、リレーまたはコレクターでメッセージをフィルタリングするためのものです。
The NILVALUE SHOULD be used when the syslog application does not, or cannot, provide any value.
NILVALUE SHOULDは、syslogアプリケーションが値を提供しない場合、または提供できない場合に使用してください。
This field MAY be operator-assigned.
このフィールドは、オペレーターが割り当てることができます。
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は、明確に定義された、簡単に解析および解釈可能なデータ形式で情報を表現するメカニズムを提供します。複数の使用シナリオがあります。たとえば、syslogメッセージに関するメタ情報や、トラフィックカウンターやIPアドレスなどのアプリケーション固有の情報を表す場合があります。
STRUCTURED-DATA can contain zero, one, or multiple structured data elements, which are referred to as "SD-ELEMENT" in this document.
STRUCTURED-DATAには、0、1、または複数の構造化データ要素を含めることができます。これらは、このドキュメントでは「SD-ELEMENT」と呼ばれます。
In case of zero structured data elements, the STRUCTURED-DATA field MUST contain the NILVALUE.
ゼロの構造化データ要素の場合、STRUCTURED-DATAフィールドには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.
STRUCTURED-DATAで使用される文字セットは、[RFC5234]で説明されているように、8ビットフィールドの7ビットASCIIである必要があります。これらは、「米国情報交換用標準コード」[ANSI.X3-4.1968]で定義されているASCIIコードです。例外は、UTF-8エンコーディングを使用する必要があるPARAM-VALUEフィールド（セクション6.3.3を参照）です。
A collector MAY ignore malformed STRUCTURED-DATA elements. A relay MUST forward malformed STRUCTURED-DATA without any alteration.
コレクターは不正なSTRUCTURED-DATA要素を無視してもよい（MAY）。リレーは、不正な形式のSTRUCTURED-DATAを変更せずに転送する必要があります。
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".
SD-ELEMENTは、名前とパラメーターの名前と値のペアで構成されます。この名前はSD-IDと呼ばれます。名前と値のペアは「SD-PARAM」と呼ばれます。
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.
SD-IDは大文字と小文字が区別され、SD-ELEMENTのタイプと目的を一意に識別します。メッセージ内に同じSD-IDが複数存在することはできません。
There are two formats for SD-ID names:
SD-ID名には2つの形式があります。
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
o アットマーク（ "@"、ABNF％d64）を含まない名前は、BCP26 [RFC5226]で説明されているように、IETFレビューによって割り当てられるように予約されています。現在、これらはセクション7で定義されている名前です。この形式の名前は、IANAに最初に登録された場合にのみ有効です。登録名には、アットマーク（ '@'、ABNF
%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).
％d64）、等号（ '='、ABNF％d61）、右中括弧（ ']'、ABNF％d93）、引用文字（ '"'、ABNF％d34）、空白、または制御文字（ASCIIコード127およびコード32以下）。
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.
o 「ourSDID @ 32473」のように、name @ <private enterprise number>という形式の名前を使用して、誰でも追加のSD-IDを定義できます。アットマークの前の部分の形式は指定されていません。ただし、これらの名前は印刷可能なUS-ASCII文字列である必要があり、アットマーク（ '@'、ABNF％d64）、等号（ '='、ABNF％d61）、右中かっこ（ ']を含めることはできません'、ABNF％d93）、引用文字（' "'、ABNF％d34）、空白、または制御文字。アットマークに続く部分は、セクション7.2.2で指定されているように、民間の企業番号である必要があります。このドキュメント全体で、32473の値はすべてのプライベートエンタープライズ番号に使用されます。この値は、ドキュメントでサンプル番号として使用するためにIANAによって予約されています。実装者は、enterpriseIdパラメータに独自のプライベートエンタープライズ番号を使用する必要があります。ローカルで拡張可能なSD-ID名を作成する。
Each SD-PARAM consists of a name, referred to as PARAM-NAME, and a value, referred to as PARAM-VALUE.
各SD-PARAMは、PARAM-NAMEと呼ばれる名前と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.
PARAM-NAMEでは大文字と小文字が区別されます。 IANAは、すべてのPARAM-NAMEを制御しますが、名前にアットマークが含まれているSD-ID内のものは例外です。 PARAM-NAMEスコープは特定のSD-ID内にあります。したがって、2つの異なるSD-IDに含まれる同じ名前のPARAM-NAME値は同じではありません。
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".
国際文字をサポートするには、PARA-VALUEフィールドをUTF-8を使用してエンコードする必要があります。 syslogアプリケーションは、有効なUTF-8シーケンスを発行してもよい（MAY）。 syslogアプリケーションは、「最短形式」の有効なUTF-8シーケンスを受け入れなければなりません（MUST）。制御文字がPARAM-VALUEに存在する場合、失敗してはなりません。 Syslogアプリケーションは、制御文字を含むメッセージを変更する場合があります（たとえば、値が0のオクテット（USASCII NUL）を4文字の「＃000」に変更します）。 UNICODE TR36 [UNICODE-TR36]のセクション3.1で概説されている理由により、発信者はメッセージを「最短形式」でエンコードする必要があり、コレクタまたはリレーは「非最短形式」でメッセージを解釈してはなりません（MUST NOT）。
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 for control character escaping for consistency with its use for escaping in other parts of the syslog message as well as in traditional syslog.
PARAM-VALUE内では、文字「」（ABNF％d34）、「\」（ABNF％d92）、および「]」（ABNF％d93）をエスケープする必要があります。これは、解析エラーを回避するために必要です。「]」のエスケープ厳密には必要ありませんが、syslogアプリケーションの実装エラーを回避するためにこの仕様で必須です。これらの3つの文字は、それぞれ「\」、「\\」、「\]」としてエスケープする必要があります。バックスラッシュは、syslogメッセージの他の部分や従来の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.
円記号（ '\'）の後に3つの記述された文字のいずれも続かない場合、無効なエスケープシーケンスと見なされます。この場合、バックスラッシュは通常のバックスラッシュとして扱われ、次の文字は通常の文字として扱われる必要があります。したがって、無効なシーケンスを変更してはなりません（MUST）。
An SD-PARAM MAY be repeated multiple times inside an SD-ELEMENT.
SD-PARAMは、SD-ELEMENT内で複数回繰り返すことができます。
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.
SD-IDとPARAM-NAMEを定義したら、これらのオブジェクトの構文とセマンティクスを変更してはなりません（MUST NOT）。既存のオブジェクトへの変更が必要な場合は、新しいSD-IDまたはPARAM-NAMEを作成する必要があり、古いものは変更されないままにする必要があります。オプションのPARAM-NAMEは、既存のSD-IDに追加される場合があります。
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.
このセクションのすべての例は、メッセージの構造化データ部分のみを示しています。例は1行にあると見なされます。このドキュメントでは、読みやすくするために複数行で囲んでいます。各例の後に説明します。
Example 1 - Valid
例1-有効
[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.
この例は、IANAで制御されていないタイプ「exampleSDID @ 32473」のSD-IDを持つ構造化データ要素で、3つのパラメーターがあります。
Example 2 - Valid
例2-有効
[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).
これは1と同じ例ですが、2番目の構造化データ要素が含まれています。構造化データ要素は最初の要素の直後に続くことに注意してください（それらの間にSPはありません）。
Example 3 - Invalid
例3-無効
[exampleSDID@32473 iut="3" eventSource="Application"
eventID="1011"] [examplePriority@32473 class="high"]
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.
これは2とほぼ同じ例ですが、わずかなエラーがあります-2つの構造化データ要素（ "] SP ["）の間にSP文字があります。これは無効です。これにより、STRUCTURED-DATAフィールドが最初の要素の後に終了します。 2番目の要素は、MSGフィールドの一部として解釈されます。
Example 4 - Invalid
例4-無効
[ 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.
この例は2とほぼ同じです。別の微妙なエラーがあります-SP文字は最初のブラケットの後に発生します。構造化データ要素SD-IDは、開始ブラケットの直後に続く必要があるため、SP文字はSTRUCTURED-DATAを無効にします。 syslogアプリケーションは、このメッセージを破棄してもよい（MAY）。
Example 5 - Valid
例5-有効
[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.
例5は有効な例です。これは、架空のIANA割り当てSD-IDを示しています。省略記号は、不足しているコンテンツを示しています。簡潔にするため、この例では省略しています。
The MSG part contains a free-form message that provides information about the event.
MSGパーツには、イベントに関する情報を提供する自由形式のメッセージが含まれています。
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.
MSGで使用される文字セットは、[RFC3629]で指定されているように、UTF-8を使用してエンコードされたUNICODEである必要があります（SHOULD）。 syslogアプリケーションがMSGをUnicodeでエンコードできない場合、他のエンコードを使用できます（MAY）。
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.
syslogアプリケーションは、32（DELを除く従来のUS-ASCII制御文字範囲）未満のオクテット値を回避する必要があります（SHOULD）。これらの値は有効ですが、syslogアプリケーションは受信時にこれらの文字を変更する場合があります。たとえば、それらをエスケープシーケンスに変更する場合があります（たとえば、値0が「\ 0」に変更される場合があります）。 syslogアプリケーションは、他のオクテット値を変更してはなりません（SHOULD NOT）。
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.
syslogアプリケーションがMSGをUTF-8でエンコードする場合、文字列はUnicodeバイトオーダーマスク（BOM）で開始する必要があります。これはUTF-8の場合、ABNF％xEF.BB.BFです。 syslogアプリケーションは「最短形式」でエンコードする必要があり、有効なUTF-8シーケンスを使用することができます（MAY）。
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.
syslogアプリケーションがBOMで始まるMSGを処理していて、MSGに最短形式ではないUTF-8が含まれている場合、[UNICODE-TR36]で概説されている理由により、MSGはUTF-8でエンコードされていると解釈してはなりません（MUST NOT）。セクション3.1。これに関するガイダンスは、付録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.
また、UNICODE TR36 [UNICODE-TR36]によれば、syslogアプリケーションは「非最短形式」のメッセージを解釈してはなりません（MUST NOT）。無効なUTF-8シーケンスを解釈してはならない（MUST NOT）。
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.
次に、有効なsyslogメッセージの例を示します。各例の説明は、その下にあります。例は[RFC3164]の類似の例に基づいており、読者にはおなじみかもしれません。他の方法では印刷できないUnicode BOMは、例では「BOM」として表されます。
Example 1 - with no STRUCTURED-DATA
例1-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.
この例では、VERSIONは1で、Facilityの値は4です。Severityは2です。メッセージは2003年10月11日10:14:15 pm UTC、3ミリ秒後に作成されました。メッセージは、「mymachine.example.com」として自身を識別するホストから発信されました。 APP-NAMEは "su"で、PROCIDは不明です。 MSGIDは「ID47」です。 MSGはUTF-8でエンコードされた「lonvickで「su root」が失敗しました...」です。エンコーディングはBOMによって定義されます。メッセージにSTRUCTURED-DATAがありません。これは、STRUCTURED-DATAフィールドの「-」で示されます。
Example 2 - with no STRUCTURED-DATA
例2-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.
<165> 1 2003-08-24T05：14：15.000003-07：00 192.0.2.1 myproc 8710--%%ドーナツを作る時間です。
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.
この例では、VERSIONは1に戻ります。Facilityは20、重大度は5です。メッセージは2003年8月24日5:14:15 amに作成され、UTCからの-7時間のオフセット、次の秒に3マイクロ秒あります。 HOSTNAMEは「192.0.2.1」であるため、syslogアプリケーションはFQDNを認識せず、代わりにIPv4アドレスの1つを使用しました。 APP-NAMEは「myproc」で、PROCIDは「8710」です（たとえば、これはUNIX PIDの場合があります）。メッセージにSTRUCTURED-DATAがありません。これは、STRUCTURED-DATAフィールドの「-」で示されます。特定のMSGIDはなく、これはMSGIDフィールドの「-」で示されます。
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.
メッセージは「%%ドーナッツを作る時間です。」です。 Unicode BOMがないため、syslogアプリケーションはMSG部分のエンコードを認識しません。
Example 3 - with STRUCTURED-DATA
例3-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...
<165> 1 2003-10-11T22：14：15.003Z mymachine.example.com evntslog-ID47 [exampleSDID @ 32473 iut = "3" eventSource = "Application" eventID = "1011"] BOMAnアプリケーションイベントログエントリ...
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.
この例は、例1に基づいてモデル化されています。ただし、今回は、値が[[exampleSDID @ 32473 iut = "3" eventSource = "Application" eventID = "1011"] "の単一の要素であるSTRUCTURED-DATAが含まれています。 MSG自体は「アプリケーションイベントログエントリ...」です。MSGの最初のBOMはUTF-8エンコーディングを示します。
Example 4 - STRUCTURED-DATA Only
例4-構造化データのみ
<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.
この例は、STRUCTURED-DATAのみを含み、MSG部分を含まないメッセージを示しています。これは有効なメッセージです。
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.
このセクションでは、IANAに登録された初期のSD-IDを定義します。構造化データ要素の定義については、セクション6.3を参照してください。ここで定義されるすべてのSD-IDはオプションです。
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.
以下の一部では、パラメーター値の最大長が定量化されます。これらのケースのそれぞれで、syslogアプリケーションは、有効なUTF-8コードポイントで定義された文字の数を受け取るように準備する必要があります。各文字は最大6オクテットになる可能性があるため、各syslogアプリケーションが文字あたり最大6オクテットを受信できるように準備することをお勧めします。
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 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.
SD-ID「timeQuality」は、システム時間の概念を記述するために発信者が使用する場合があります。このSD-IDは、発信者が信頼できる外部タイムソースと正しく同期されていない場合、またはタイムゾーン情報が正しいかどうかわからない場合に書き込む必要があります。この構造化データ要素の主な用途は、セクション6.2.3で説明されているTIMESTAMPでの信頼レベルに関する情報を提供することです。すべてのパラメーターはオプションです。
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).
「tzKnown」パラメータは、発信者がそのタイムゾーンを知っているかどうかを示します。その場合は、値「1」を使用する必要があります。タイムゾーン情報が不確かな場合は、値「0」を使用する必要があります。発信者がそのタイムゾーンを知っているが、UTCで時間を出力することにした場合、値「1」を使用する必要があります（タイムゾーンがわかっているため）。
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.
「isSynced」パラメータは、オリジネータが信頼できる外部のタイムソース（NTPなど）と同期されているかどうかを示します。発信者が時間同期されている場合、値「1」を使用する必要があります。そうでない場合は、値「0」を使用する必要があります。
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.
「syncAccuracy」パラメータは、発信者がその時刻同期がどれほど正確であると考えるかを示します。これは、同期間隔の間にクロックがオフになる最大マイクロ秒数を表す整数です。
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.
「isSynced」に値「0」を使用する場合、このパラメーターを指定してはなりません（MUST NOT）。 「isSynced」に値「1」が使用されているが、「syncAccuracy」パラメーターが存在しない場合、コレクターまたはリレーは、提供された時刻情報が正確であると見なされるのに十分正確であると想定できます。 「syncAccuracy」パラメータは、発信者が実際に外部のタイムソースの信頼性を知っている場合にのみ記述する必要があります。ほとんどの場合、オペレーターの構成により、この詳細な知識が得られます。
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"]
[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.
この情報により、発信者はその時間情報が信頼できないことを示します。これは、コレクターまたはリレーが、異なる発信者からの複数のメッセージを相関させるためにメッセージで提供されるTIMESTAMPの代わりにローカル時間を使用するためのヒントになる場合があります。
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"]
[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.
この例と前の例の違いは、発信者はその時計が公式の時間の60秒以内に維持されることを期待していることです。したがって、オリジネータがそれが9:00:00であると報告した場合、それは8:59:00より遅くなく、9：01：00です。
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.
SD-ID「origin」は、syslogメッセージの発信元を示すために使用できます。以下のパラメーターを使用できます。すべてのパラメーターはオプションです。
Specifying any of these parameters is primarily an aid to log analyzers and similar applications.
これらのパラメーターのいずれかを指定することは、主にログアナライザーや類似のアプリケーションの助けになります。
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.
「ip」パラメータは、メッセージの発信時に発信者が知っていたIPアドレスを示します。セクション6.2.4で概説されているように、IPアドレスのテキスト表現を含まなければなりません。
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.
このパラメーターを使用して、HOSTNAMEフィールドの内容に加えて、識別情報を提供できます。 HOSTNAMEフィールドにFQDNがまだ含まれているときに、ホストのIPアドレスがメッセージに含まれている場合に特に役立ちます。また、マルチホームホストのすべてのIPアドレスを記述するのにも役立ちます。
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.
発信者が複数のIPアドレスを持っている場合、IPアドレスの1つを「ip」パラメーターにリストするか、単一の「発信元」構造化データ要素に複数の「ip」パラメーターを含めることができます（MAY）。
The "enterpriseId" parameter MUST be a 'SMI Network Management Private Enterprise Code', maintained by IANA, whose prefix is iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). The number that follows MUST be unique and MUST be registered with IANA as per 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.
「enterpriseId」パラメータは、IANAによって維持される「SMIネットワーク管理プライベートエンタープライズコード」である必要があり、そのプレフィックスはiso.org.dod.internet.private.enterprise（1.3.6.1.4.1）です。続く番号は一意でなければならず、RFC 2578 [RFC2578]に従ってIANAに登録する必要があります。企業は、IANAによってその企業に割り当てられたiso.org.dod.internet.private.enterprise。<private enterprise number>サブツリー内の値を割り当てることのみが許可されています。 enterpriseIdには、iso.org.dod.internet.private.enterprise。<private enterprise number>サブツリーからの値のみを含める必要があります。一般に、IANAによって割り当てられたプライベートエンタープライズ番号（単一の番号）のみが必要です。企業は、その企業番号よりも小さいサブ識別子を使用することを決定する場合があります。サブ識別子を使用する場合は、それらをピリオドで区切り、10進数として表す必要があります。その例は「32473.1.2」です。 ID「32473.1.2」は単なる例であり、使用してはならないことに注意してください。 Private Enterprise Numbers（PEN）の完全な最新リストは、IANAによって管理されています。
By specifying a private enterprise number, the vendor allows more specific processing of the message.
民間企業番号を指定することにより、ベンダーはメッセージのより具体的な処理を許可します。
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.
「ソフトウェア」パラメータは、メッセージを生成したソフトウェアを一意に識別します。使用する場合は、特定のベンダーのソフトウェアを識別できるように、「enterpriseId」も指定する必要があります（SHOULD）。 「ソフトウェア」パラメーターは、APP-NAMEヘッダーフィールドと同じではありません。常に生成ソフトウェアの名前を含める必要がありますが、APP-NAMEには、オペレーターが構成した値を含め、他のものを含めることができます。
The "software" parameter is a string. It MUST NOT be longer than 48 characters.
「ソフトウェア」パラメータは文字列です。 48文字を超えてはなりません。
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.
「swVersion」パラメータは、メッセージを生成したソフトウェアのバージョンを一意に識別します。使用する場合は、「software」および「enterpriseId」パラメーターも提供する必要があります（SHOULD）。
The "swVersion" parameter is a string. It MUST NOT be longer than 32 characters.
「swVersion」パラメータは文字列です。 32文字を超えてはなりません。
The following is an example with multiple IP addresses:
以下は、複数のIPアドレスを使用した例です。
[origin ip="192.0.2.1" ip="192.0.2.129"]
[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.
この例では、発信者は2つのIPアドレスがあり、1つは192.0.2.1、もう1つは192.0.2.129であることを示しています。
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.
SD-ID「メタ」は、メッセージに関するメタ情報を提供するために使用される場合があります。以下のパラメーターを使用できます。すべてのパラメーターはオプションです。 「メタ」SD-IDを使用する場合、少なくとも1つのパラメーターを指定する必要があります（SHOULD）。
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.
「sequenceId」パラメータは、発信者が送信のためにsyslogトランスポートにメッセージを送信するシーケンスを追跡します。これは整数であり、syslog関数の開始時に1に設定する必要があり、メッセージごとに最大値2147483647まで増加する必要があります。その値に達した場合、次のメッセージは、sequenceIdが1で送信される必要があります。
The "sysUpTime" parameter MAY be used to include the SNMP "sysUpTime" parameter in the message. Its syntax and semantics are as defined in [RFC3418].
「sysUpTime」パラメータを使用して、SNMP「sysUpTime」パラメータをメッセージに含めることができます。その構文とセマンティクスは、[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".
syslogはSNMP "INTEGER"構文を直接サポートしないため、値は文字 "0"、 "1"、 "2"、 "3"、 "4"のみを使用して10進整数（小数点なし）として表す必要があります、「5」、「6」、「7」、「8」、および「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.
RFC 3418のセマンティクスは「システムのネットワーク管理部分が最後に再初期化されてからの時間（100分の1秒単位）」であることに注意してください。もちろん、これはシステムのSNMP関連の管理部分に関連しており、システムのsyslog関連の管理部分とは異なる場合があります。
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].
「言語」パラメータは、MSG内で使用される自然言語に関する情報を伝えるために、発信者によって指定される場合があります。これが指定されている場合、BCP 47 [RFC4646]で定義されている言語識別子が含まれている必要があります。
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 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.
このドキュメントでは、PARA-VALUEおよびMSGフィールドにUTF-8エンコーディングを使用しています。 UNICODEには多くのセキュリティ問題があります。実装者およびオペレーターは、これらの問題について学ぶためにUNICODE TR36 [UNICODE-TR36]（UTR36）を確認することをお勧めします。このドキュメントは、syslogアプリケーションに「最短形式」のエンコーディングを要求することにより、UTR36で概説されている技術的な問題から保護します。ただし、キャラクターの混乱による視覚的ななりすましは引き続き発生します。このドキュメントでは、ローカルスクリプトが予想され、必要な場所でのみUNICODEを許可することにより、視覚的ななりすましの影響を最小限に抑えようとしています。他のすべてのフィールドでは、US-ASCIIが必要です。また、PARA-VALUEおよびMSGフィールドは、情報を特定するための主要な情報源であってはならず、視覚的ななりすましに関連するリスクがさらに低減されます。
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.
このドキュメントは、MSGまたはPARAM-VALUEの内容に必須の制限を課すものではありません。そのため、NUL文字を含む制御文字を含めることができます（MAY）。
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.
一部のプログラミング言語（特にCおよびC ++）では、NUL文字（ABNF％d00）は伝統的に文字列ターミネーターとして特別な意味を持っています。これらの言語のほとんどの実装は、文字列が最初のNUL文字を超えないことを前提としています。これは主に、サポートするランタイムライブラリの制限です。この制限は、プログラムおよびそれらの言語で記述されたスクリプト言語にしばしば引き継がれます。そのため、NUL文字は慎重に検討し、適切に処理する必要があります。攻撃者は、意図的にNUL文字を含めて、その後に情報を隠すことができます。 NUL文字の不適切な処理により、メッセージ内で送信される暗号チェックサムも無効になる場合があります。
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.
多くの一般的なテキストエディターもこの制限のある言語で記述されています。テキストファイルに書き込むときにNUL文字をエンコードすることをお勧めします。エンコードせずに保存すると、ファイルが読み取れなくなる可能性があります。
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.
最後に、攻撃者が無効なUTF-8シーケンスを使用して、ASCII制御文字を挿入する可能性があります。
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.
この仕様により、syslogアプリケーションは受信した制御文字を再フォーマットできます。特に、制御文字に関連するセキュリティリスクは、この制限の背後にある重要な原動力でした。発信者は、ASCIIおよびUTF8以外のエンコーディングが使用されている場合、受信者がASCII制御文字をフィルタリングしようとしてメッセージを破損する可能性があることをお勧めします。
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.
情報の損失を防ぐために、メッセージはセクション6.1で要求される最小の最大サイズを超えてはなりません。最高のパフォーマンスと信頼性を得るには、メッセージをできるだけ小さくする必要があります。メッセージの先頭にある情報は、サイズが制限されたトランスポートレシーバーによって破棄される可能性が低いため、重要な情報はできるだけメッセージの早い段階に配置する必要があります。
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.
発信者は、syslogメッセージ内のユーザー提供データのサイズを制限する必要があります。そうでない場合、攻撃者は潜在的な弱点を悪用することを期待して大量のデータを提供する可能性があります。
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.
syslogプロトコルには、メッセージの再生を検出するメカニズムはありません。攻撃者は、マシンの通常のアクティビティを示す一連のメッセージを記録する可能性があります。後で、その攻撃者はそのマシンをネットワークから削除し、syslogメッセージをリレーまたはコレクターに再生する可能性があります。 HEADER部分にTIMESTAMPフィールドがあっても、攻撃者はパケットを記録し、パケットを再送信する前に現在の時刻を反映するように変更するだけです。管理者は、受信したメッセージに異常なものを何も見つけない場合があり、それらの受信は、マシンの通常のアクティビティを誤って示します。
Cryptographically signing messages could prevent the alteration of TIMESTAMPs and thus the replay attack.
暗号でメッセージに署名すると、TIMESTAMPの変更を防ぐことができるため、リプレイ攻撃を防ぐことができます。
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.
このドキュメントには配信を保証するメカニズムがなく、基盤となるトランスポートが信頼できない可能性があるため（UDPなど）、一部のメッセージが失われる可能性があります。それらは、ネットワークの輻輳によってドロップされるか、悪意を持って傍受されて破棄される可能性があります。 1つ以上のsyslogメッセージをドロップした結果は判別できません。メッセージが単純なステータスの更新である場合、メッセージが受信されないことが通知されないか、システムオペレーターに不快感を与える可能性があります。一方、メッセージがより重要である場合、管理者は開発中の潜在的に深刻な問題に気付かない可能性があります。不正な活動を隠す方法として、攻撃者がメッセージを傍受して破棄することもあります。
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.
また、syslogの発信元とリレーにレート制限機能を含めることが望ましい場合もあります。これにより、メッセージのバーストが発生した場合の潜在的な輻輳の問題を減らすことができます。
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.
信頼できる配信が常に望ましいとは限りません。信頼性の高い配信とは、リレーまたはコレクターがこれ以上メッセージを受け入れることができない場合、syslogの発信元またはリレーがブロックする必要があることを意味します。一部のオペレーティングシステム、つまりUnix / Linuxでは、syslog発信元またはリレーが優先度の高いシステムプロセス（syslogd）内で実行されます。そのプロセスがブロックすると、システム全体が停止します。 syslogdとDNSサーバーなどの間にデッドロックが発生した場合も同様です。
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.
これらの問題を防ぐために、syslogアプリケーションがブロックした場合にメッセージを意図的に破棄する方法で、信頼性の高い配信を実装できます。この場合の信頼性の高い配信の利点は、syslog発信者またはリレーが意図的にメッセージを破棄し、その事実をリレーまたはコレクターに通知できることです。したがって、リレーまたはコレクターは、何かが失われたという情報を受け取ります。配信の信頼性が低い場合、メッセージは失われただけで、失われたことを示すものはありません。
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.
syslogは無制限の量のデータを生成できるため、UDPには輻輳制御メカニズムがないため、このデータをUDP経由で転送することは一般的に問題があります。トラフィックレートを下げることで輻輳に対応し、同じパスを共有するフロー間の公平性を確立する輻輳制御メカニズムは、インターネットの安定した運用に不可欠です[RFC2914]。これが、syslog TLSトランスポートの実装が必要であり、一般的な使用を推奨する理由です。
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.
Syslog UDPトランスポートをTLSトランスポートの代替として使用できる唯一の環境は、ネットワーク制限がレート制限や容量予約などのトラフィックエンジニアリングメカニズムを通じてUDP syslogトラフィック用に明示的にプロビジョニングされている管理対象ネットワークです。他のすべての環境では、TLSトランスポートを使用する必要があります（SHOULD）。
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.
どの実装でも、発信者またはリレーがメッセージの送信をブロックする必要がある状況が発生する可能性があります。一般的なケースは、内部キューがいっぱいの場合です。これは、syslogアプリケーションのレート制限またはパフォーマンスの低下が原因で発生する可能性があります。いずれの場合でも、メッセージは削除されないことを強くお勧めしますが、メッセージが送信されるまで一時的に保存する必要があります。ただし、それらをドロップする必要がある場合は、発信者またはリレーが重大度の低いメッセージをドロップして、重大度の高いメッセージを優先することをお勧めします。
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.
SEVERITYの数値が小さいメッセージは、数値が大きいメッセージよりも実用的な重大度が高くなります。その状況では、ドロップされるメッセージは単に破棄されるべきです（SHOULD）。 syslogアプリケーションは、メッセージをドロップしたことをコレクターまたはリレーに通知する場合があります。
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.
syslogメッセージは破棄されるだけでなく、送信中に損傷したり、攻撃者が悪意を持ってそれらを変更したりする可能性があります。そのような場合、メッセージの元のコンテンツはコレクターまたはリレーに配信されません。さらに、攻撃者がsyslogメッセージのトランスポート送信者とトランスポート受信者の間に位置している場合、転送中にそれらのメッセージを傍受および変更して、不正なアクティビティを隠すことができる場合があります。
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.
MSG形式に関する厳密なガイドラインはありませんが、ほとんどのsyslogメッセージは、有能な管理者がメッセージを読んでその意味を理解できるはずであるという前提で、人間が読める形式で生成されます。 syslogプロトコルには、送信中のメッセージに機密性を提供するメカニズムがありません。ほとんどの場合、クリアテキストメッセージを渡すことは、ネットワークからパケットを傍受する場合に運用スタッフにメリットがあります。運用スタッフは、メッセージを読み取り、ワイヤーを通過する他のパケットから見られる他のイベントにメッセージを関連付けて、問題を追跡および修正できる場合があります。残念ながら、攻撃者は人間が読めるsyslogメッセージの内容を観察することもできます。その後、攻撃者はそれらのメッセージから得られた知識を使用して、マシンを危険にさらしたり、その他の損害を与えたりする可能性があります。
Operators are advised to use a secure transport mapping to avoid this problem.
オペレーターは、この問題を回避するために、セキュアなトランスポートマッピングを使用することをお勧めします。
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.
メッセージや設定に関する制御情報は配布されないため、メッセージが実際に目的の受信者に送信されるようにするのは、ネットワーク管理者の責任です。 syslogアプリケーションが誤ってsyslogメッセージを誤ったリレーまたはコレクターに送信するように設定されているケースが指摘されています。多くの場合、不注意なリレーまたはコレクターは、syslogメッセージを受信するように構成されておらず、おそらくそれらを破棄します。その他の特定のケースでは、syslogメッセージを受信すると、意図しない受信者に問題が発生することがわかっています。メッセージが目的の受信者に送信されない場合、メッセージを確認または処理できません。
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.
信頼性の高いトランスポートマッピングを使用すると、これらの問題のいくつかを特定するのに役立ちます。たとえば、メッセージを受信するように構成されていないシステムにメッセージが送信される問題を特定できます。メッセージを受け入れている間違ったマシンへのメッセージ送信を識別することはできません。
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.
図2に示すように、コレクターに到達する前に、syslogメッセージを後続のリレーにリレーするようにマシンを構成できます。ある特定のケースでは、管理者は、特定の重大度の値を持つメッセージを互いに転送するように2つのリレーを誤って構成していたことに気付きました。これらのマシンのいずれかがそのタイプのメッセージを受信または生成すると、それを他のリレーに転送します。そのリレーは、次にそれを転送します。このサイクルは、介在するネットワークと2つのデバイスの処理の可用性を低下させました。ネットワーク管理者は、このような死のスパイラルを引き起こさないように注意する必要があります。
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.
ネットワーク管理者は、時間をかけてsyslogコレクターの適切な容量を見積もる必要があります。攻撃者は、コレクタのディスクを偽のメッセージで満たすことにより、サービス拒否攻撃を実行する可能性があります。レコードを循環ファイルに配置することでこれを軽減できますが、管理者が将来レコードを確認できるとは限らないという結果になります。この線に沿って、トランスポートレシーバーには、送信されたメッセージを受信できるネットワークインターフェイスが必要です。
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.
管理者とネットワークプランナーは、発信者、リレー、およびコレクタ間のネットワークパスも批評的に確認する必要があります。生成されたsyslogメッセージは、ネットワークリンクを圧倒してはなりません。
In order to reduce the impact of this issue, using transports with guaranteed delivery is recommended.
この問題の影響を減らすために、配信が保証されたトランスポートを使用することをお勧めします。
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.
他のシステムと同様に、攻撃者は、インフラストラクチャまたはデバイス自体で処理できる以上のメッセージを送信することにより、トランスポートレシーバーを圧倒する可能性があります。実装者は、既知のIPアドレスからのsyslogメッセージのみを受け入れるなど、この脅威を最小限に抑える機能の提供を試みる必要があります。
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.
セクション6.2.2で説明されているように、IANAはVERSION値の「syslogバージョン値」という名前のレジストリを作成しました。 HEADERの任意の部分を変更する新しいsyslogプロトコル仕様では、バージョン番号を増やす必要があります。変更には、フィールドの追加または削除、または既存のフィールドの構文またはセマンティクスの変更が含まれます。
VERSION numbers must be registered via the Standards Action method as described in [RFC5226]. IANA has registered the VERSIONs shown in Table 3 below.
[RFC5226]で説明されているように、VERSION番号は標準アクション方式で登録する必要があります。 IANAは、以下の表3に示すバージョンを登録しています。
VERSION FORMAT 1 Defined in [RFC5424]
VERSION FORMAT 1 [RFC5424]で定義
Table 3. IANA-Registered VERSIONs
表3. IANAに登録されたバージョン
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.
セクション7で説明されているように、IANAは、構造化データID（SD-ID）値と関連するPARAM-NAME値の「syslog構造化データID値」というレジストリを作成しました。
New SD-ID and new PARAM-NAME values must be registered through the IETF Review method as described in [RFC5226].
[RFC5226]で説明されているように、新しいSD-IDと新しいPARAM-NAMEの値は、IETFレビューメソッドを通じて登録する必要があります。
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.
SD-IDとSD-PARAMを定義したら、これらのオブジェクトの構文とセマンティクスを変更してはなりません（MUST NOT）。既存のオブジェクトへの変更が必要な場合は、新しいSD-IDまたはSD-PARAMを作成する必要があり、古いものは変更されないままにする必要があります。
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は登録せず、アットマーク（ABNF％d64）を含む名前を制御しません。
IANA has registered the SD-IDs and PARAM-NAMEs shown in Table 4 below.
IANAは、以下の表4に示すSD-IDとPARAM-NAMEを登録しています。
SD-ID PARAM-NAME timeQuality OPTIONAL tzKnown OPTIONAL isSynced OPTIONAL syncAccuracy OPTIONAL
SD-ID PARAM-NAME timeQuality OPTIONAL tzKnown OPTIONAL isSynced OPTIONAL syncAccuracy OPTIONAL
origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL
origin OPTIONAL ip OPTIONAL enterpriseId OPTIONAL software OPTIONAL swVersion OPTIONAL
meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL
meta OPTIONAL sequenceId OPTIONAL sysUpTime OPTIONAL language OPTIONAL
Table 4. IANA-Registered SD-IDs and their PARAM-NAMEs
表4. IANAに登録されたSD-IDとそのPARAM-NAME
The working group can be contacted via the mailing list:
ワーキンググループは、メーリングリストを介して連絡することができます。
syslog@ietf.org
syslog@ietf.org
The current Chairs of the Working Group may be contacted at:
ワーキンググループの現在の議長は、次の場所で連絡を取ることができます。
Chris Lonvick Cisco Systems EMail: clonvick@cisco.com
Chris Lonvick Cisco Systems EMail：clonvick@cisco.com
David Harrington Huawei Technologies USA EMail: dbharrington@comcast.net
David Harrington Huawei Technologies USA EMail：dbharrington@comcast.net
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.
著者は、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、その他すべてに感謝しますこの提案のさまざまなバージョンについてコメントした他の人々。
[ANSI.X3-4.1968] American National Standards Institute, "USA Code for Information Interchange", ANSI X3.4, 1968.
[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.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[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.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]クライン、G、エド。 C.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、2002年7月。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R。、「簡易ネットワーク管理プロトコル（SNMP）の管理情報ベース（MIB）」、STD 62、RFC 3418、2002年12月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[RFC4646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006.
[RFC4646] Phillips、A。およびM. Davis、「Tags for Identificationing Languages」、BCP 47、RFC 4646、2006年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5425] Fuyou, M., Yuzhi, M., and J. Salowey, "TLS Transport Mapping for Syslog", RFC 5425, March 2009.
[RFC5425] Fuyou、M.、Yuzhi、M.、J。Salowey、「SyslogのTLSトランスポートマッピング」、RFC 5425、2009年3月。
[RFC5426] Okmianski, A., "Transmission of Syslog Messages over UDP", RFC 5426, March 2009.
[RFC5426] Okmianski、A。、「UDPを介したSyslogメッセージの送信」、RFC 5426、2009年3月。
[UNICODE-TR36] Davis, M. and M. Suignard, "UNICODE Security Considerations", July 2005.
[UNICODE-TR36] Davis、M.およびM. Suignard、「UNICODE Security Considerations」、2005年7月。
[RFC3164] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[RFC3164] Lonvick、C。、「The BSD Syslog Protocol」、RFC 3164、2001年8月。
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.
このセクションの情報は、実装者への支援として提供されています。この情報は役立つと考えられていますが、規範的ではありません。そのため、この仕様への準拠を主張するために、実装はそれに従う必要はありません。
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.
BSD syslogは広く使用されていますが、その形式は正式に標準化されたことはありません。 [RFC3164]は観測されたフォーマットを説明しています。これは情報RFCであり、実際には多くの異なる実装があることが示されています。このドキュメントの作成中の調査によると、異なるプラットフォームでの異なるsyslog実装間での共通点はほとんどありません。彼ら全員が同意する唯一のことは、メッセージが「<」PRIVAL ">」で始まるということです。それ以外の場合、レガシーSyslogメッセージは一貫した方法でフォーマットされません。したがって、RFC 3164には、syslogメッセージ内の特定の要素は記述されていません。これは、syslog UDPポート宛のメッセージは、その形式や内容に関係なく、syslogメッセージとして処理する必要があることを示しています。
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.
このドキュメントには、PRI値の構文とセマンティクスが保持されています。これにより、従来のsyslog実装は、この仕様に準拠するsyslogアプリケーションによって生成されたメッセージを適切なビンに入れることができます。
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.
既存のほとんどの実装は、syslogの転送プロトコルとしてUDPをサポートしています。この仕様はUDPトランスポートをサポートしていますが、お勧めしません。必要なTLSサポートの展開をお勧めします。追加の転送プロトコルを使用できます。
RFC 3164 describes relay behavior. This document does not specify relay behavior. This might be done in a separate document.
RFC 3164は、リレーの動作について説明しています。このドキュメントでは、リレーの動作を指定していません。これは別のドキュメントで行われる場合があります。
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.
RFC 3164で説明されているTIMESTAMPは、このドキュメントで指定されているタイムスタンプよりも精度が低くなります。また、年と時間帯の情報もありません。このドキュメントに従ってフォーマットされたメッセージをRFC 3164形式に再フォーマットする必要がある場合は、発信者のローカルタイムゾーンを使用し、タイムゾーン情報と年を削除することをお勧めします。 RFC 3164形式のメッセージが受信され、このドキュメントに準拠するように変換する必要がある場合は、現在の年を追加し、リレーまたはコレクターのタイムゾーンを使用する必要があります。
The HOSTNAME in RFC 3164 is less specific, but this format is still supported in this document as one of the alternate HOSTNAME representations.
RFC 3164のHOSTNAMEはそれほど限定的ではありませんが、この形式はこのドキュメントでは代替HOSTNAME表現の1つとしてサポートされています。
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.
メッセージのMSG部分は、RFC 3164でTAGおよびCONTENTとして説明されています。このドキュメントでは、MSGはRFC 3164でCONTENTと呼ばれていたものです。TAGは現在、ヘッダーの一部ですが、単一のフィールドではありません。タグはAPP-NAME、PROCID、MSGIDに分割されています。これはTAGの使用法に完全に似ているわけではありませんが、ほとんどの場合に同じ機能を提供します。
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.
RFC 3164では、STRUCTURED-DATAは記述されていませんでした。このドキュメントに準拠するメッセージにSTRUCTURED-DATAが含まれていて、RFC 3164に従って再フォーマットする必要がある場合、STRUCTURED-DATAは単にRFC 3164 CONTENT自由形式テキストの一部になります。
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.
一般に、このドキュメントは、簡単に解析できるヘッダーに明確なフィールド分離を提供しようとしますが、従来のBSD syslogは、歴史的に開発され、解析が難しいフィールド分離ルールに悩まされています。
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.
実装者は、セクション6.1で概説されているメッセージサイズの制限に注意し、最も重要なデータをメッセージの早い段階で（最小保証長内で）保持するようにしてください。これにより、メッセージパス上のリレーにあるトランスポートレシーバーがメッセージを切り捨てた場合でも、コレクターまたはリレーがデータを確認できるようになります。
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.
Syslogトランスポートレシーバーが最大480オクテットまでの受信のみをサポートする必要がある理由は、とりわけ、壊れたネットワークでの配信の困難な問題に関係しています。 Syslogメッセージでは、この480オクテットの制限を持つUDPトランスポートマッピングを使用して、セッションのオーバーヘッドとメッセージの断片化を回避できます。問題のあるネットワークでは、1つの単一パケットメッセージが正常に配信される可能性は、2つのメッセージフラグメントが正常に配信される可能性よりも高くなります。したがって、大きいサイズを使用すると、オペレーターが問題に関するいくつかの重要な情報を取得できなくなる可能性があります。一方、小さいメッセージを使用すると、オペレーターにその情報が取得される可能性があります。トラブルシューティングを目的としたメッセージは、480オクテットを超えないようにすることをお勧めします。この点をさらに強化するために、一部のUDP実装は一般に480オクテットを超えるメッセージサイズをサポートしないことも確認されています。この動作は非常にまれであり、問題ではなくなる可能性があります。
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 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.
監査データなど、本質的に長い情報を送信するためにsyslogメッセージが使用される他の使用例があります。メッセージサイズに上限を設けないことにより、syslogアプリケーションを必要なサイズで実装でき、このドキュメントに準拠できます。このような場合、syslogインフラストラクチャのすべてのコンポーネントが必要なメッセージサイズを確実にサポートするようにするのは、オペレーターの責任です。トランスポートマッピングは、準拠するために実装する必要がある特定のメッセージサイズの制限を推奨する場合があります。
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.
実装者は、メッセージの長さがオクテットで指定されていることに注意してください。 UTF-8文字列では、文字の長さとオクテットの長さの間に潜在的に大きな違いがあります。
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.
IPv6 MTUは480の約2.5倍であることに注意する必要があります。したがって、IPv6のみの環境を対象とした実装では、これをより大きな最小サイズと見なす場合があります。
This section describes guidelines for using Severity as outlined in Section 6.2.1.
このセクションでは、セクション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.
すべての実装は、メッセージに最も適切な重大度を割り当てようとする必要があります。最も重要なのは、ソフトウェアのデバッグまたはテストを可能にするように設計されたメッセージに重大度7を割り当てることです。重大度0は、非常に重要度の高いメッセージ（深刻なハードウェア障害や差し迫った電源障害など）のために予約する必要があります。管理者が設定した場合、実装は他の目的で重大度0および7を使用できます。
Because severities are very subjective, a relay or collector should not assume that all originators have the same definition of severity.
重大度は非常に主観的であるため、リレーまたはコレクターは、すべての発信者が同じ重大度の定義を持っていると想定しないでください。
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.
セクション6.2.3で説明されているTIMESTAMPは、小数秒をサポートしています。これは、先行ゼロが小数秒から削除される非常に一般的なコーディングエラーの根拠を提供します。たとえば、TIMESTAMP "2003-10-11T22：13：14.003"は、誤って "2003-10-11T22：13：14.3"と記述される場合があります。これは、実際に意味される3ミリ秒ではなく、300ミリ秒を示します。
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".
名前は、SD-IDやPARAM-NAMEなど、このドキュメントのさまざまな場所で使用されます。このドキュメントでは、一貫して「ラクダの小文字」を使用しています。これにより、各名前は小文字で始まり、埋め込まれた新しい単語はそれぞれ大文字で始まります。ハイフンやその他の区切り文字はありません。この例は「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.
実装では実験的な名前に他の大文字小文字の規則を自由に使用できますが、上記の大文字小文字の規則に従うことをお勧めします。
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.
セクション6.2.3では、NILVALUEは、時間の知識がなくても発信者による使用が許可されています。これは、syslogアプリケーションが時間をまったく認識しない特殊なケースをサポートするために行われます。このようなsyslogアプリケーションが実際に今日のITインフラストラクチャで見つかるかどうかについては、議論の余地があります。ただし、これらのことは実際に存在する可能性があるため、この場合のためにガイドラインを確立する必要があることが議論で示されています。
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.
ただし、基盤となるオペレーティングシステム、プログラミングシステム、およびハードウェアが時計機能をサポートしている場合、実装は有効なTIMESTAMPを発行する必要があります（SHOULD）。システム時刻を取得することが困難な場合でも、適切なTIMESTAMPが発行されます。 NILVALUEは、時間情報を取得することが実際には不可能である場合にのみ使用してください。このルールは、遅延実装の言い訳として使用しないでください。
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.
「0」の値を「tzKnown」（セクション7.1.1）パラメータのデフォルトにすることをお勧めします。これは、管理者がタイムゾーンを明確に構成した後でのみ "1"に変更する必要があります。基になるオペレーティングシステムが正確なタイムゾーン情報を提供する場合、値「1」をデフォルトとして使用できます。それでも、管理者がタイムゾーン情報の正確さを考慮することをお勧めします。
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.
timeQuality SD-ID（セクション7.1）を使用して、正確な誤った印象を作成しないことが重要です。発信者は、これらの境界内にあることが実際にわかっている場合にのみ、特定の精度を示す必要があります。通常、発信者は、オペレーターの構成を通じてこの詳細な知識を得ると想定されています。デフォルトでは、精度は提供されません。
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 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.
このドキュメントでは、SD-PARAMSは常にUTF-8でエンコードする必要があると規定しています。 ASCIIPRINTを含む、MSG部分のメッセージの他のエンコーディングは、この仕様に準拠するデバイスでは許可されていません。ここで対処する必要がある2つのケースがあります。まず、この仕様に準拠したsyslogアプリケーションは、発信者から提供された情報がUTF-8でエンコードされていることを確認できない場合があります。それを確実に判断できない場合、syslogアプリケーションはBOMをMSGに組み込まないことを選択できます。 syslogアプリケーションに、メッセージのコンテンツがUTF-8でエンコードされていることが適切に示されている場合は、BOMを含める必要があります。 2番目のケースでは、syslogリレーが、この仕様に準拠していないデバイスからのメッセージを転送している可能性があります。その場合、受信したメッセージがUTF-8でエンコードされていることが確認されない限り、デバイスにBOMが含まれない可能性があります。
Author's Address
著者のアドレス
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld, BW 97950 Germany
Rainer Gerhards Adiscon GmbH Mozartstrasse 21 Grossrinderfeld、BW 97950 Germany
EMail: rgerhards@adiscon.com