RFC3195 日本語訳
3195 Reliable Delivery for syslog. D. New, M. Rose. November 2001. (Format: TXT=60960 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. New
Request for Comments: 3195 M. Rose
Category: Standards Track Dover Beach Consulting, Inc.
November 2001
コメントを求めるワーキンググループのD.の新しい要求をネットワークでつないでください: 3195年のM.バラカテゴリ: Inc.2001年11月に相談する標準化過程ドーヴァービーチ
Reliable Delivery for syslog
syslogのための信頼できるDelivery
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
Abstract
要約
The BSD Syslog Protocol describes a number of service options related to propagating event messages. This memo describes two mappings of the syslog protocol to TCP connections, both useful for reliable delivery of event messages. The first provides a trivial mapping maximizing backward compatibility. The second provides a more complete mapping. Both provide a degree of robustness and security in message delivery that is unavailable to the usual UDP-based syslog protocol, by providing encryption and authentication over a connection-oriented protocol.
BSD Syslogプロトコルはイベントメッセージを伝播すると関連する多くのサービスオプションについて説明します。 このメモはともにイベントメッセージの信頼できる配信の役に立つTCP接続にsyslogプロトコルに関する2つのマッピングについて説明します。 1番目は後方の互換性を最大にする些細なマッピングを提供します。 2番目は、より完全なマッピングを提供します。 両方が普通のUDPベースのsyslogプロトコルを入手できないメッセージ配送における1段階の丈夫さとセキュリティを提供します、接続指向のプロトコルの上に暗号化と認証を提供することによって。
New & Rose Standards Track [Page 1] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[1ページ]RFC3195Reliable Delivery
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The RAW Profile . . . . . . . . . . . . . . . . . . . . . . 7
3.1 RAW Profile Overview . . . . . . . . . . . . . . . . . . . . 7
3.2 RAW Profile Identification and Initialization . . . . . . . 9
3.3 RAW Profile Message Syntax . . . . . . . . . . . . . . . . . 10
3.4 RAW Profile Message Semantics . . . . . . . . . . . . . . . 10
4. The COOKED Profile . . . . . . . . . . . . . . . . . . . . . 11
4.1 COOKED Profile Overview . . . . . . . . . . . . . . . . . . 11
4.2 COOKED Profile Identification and Initialization . . . . . . 11
4.3 COOKED Profile Message Syntax . . . . . . . . . . . . . . . 11
4.4 COOKED Profile Message Semantics . . . . . . . . . . . . . . 12
4.4.1 The IAM Element . . . . . . . . . . . . . . . . . . . . . . 12
4.4.2 The ENTRY Element . . . . . . . . . . . . . . . . . . . . . 14
4.4.3 The PATH Element . . . . . . . . . . . . . . . . . . . . . . 19
5. Additional Provisioning . . . . . . . . . . . . . . . . . . 25
5.1 Message Authenticity . . . . . . . . . . . . . . . . . . . . 25
5.2 Message Replay . . . . . . . . . . . . . . . . . . . . . . . 25
5.3 Message Integrity . . . . . . . . . . . . . . . . . . . . . 25
5.4 Message Observation . . . . . . . . . . . . . . . . . . . . 26
5.5 Summary of Recommended Practices . . . . . . . . . . . . . . 26
6. Initial Registrations . . . . . . . . . . . . . . . . . . . 27
6.1 Registration: The RAW Profile . . . . . . . . . . . . . . . 27
6.2 Registration: The COOKED Profile . . . . . . . . . . . . . . 27
7. The syslog DTD . . . . . . . . . . . . . . . . . . . . . . . 28
8. Reply Codes . . . . . . . . . . . . . . . . . . . . . . . . 32
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 33
9.1 Registration: BEEP Profiles . . . . . . . . . . . . . . . . 33
9.2 Registration: The System (Well-Known) TCP port number for
syslog-conn . . . . . . . . . . . . . . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . 34
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 36
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 3 2。 モデル. . . . . . . . . . . . . . . . . . . . . . . . . 4 3。 生のプロフィール. . . . . . . . . . . . . . . . . . . . . . 7 3.1の生のプロフィール概観. . . . . . . . . . . . . . . . . . . . 7 3.2生のプロフィール識別と初期設定. . . . . . . 9 3.3の生のプロフィールメッセージ構文. . . . . . . . . . . . . . . . . 10 3.4の生のプロフィールメッセージ意味論. . . . . . . . . . . . . . . 10 4。 煮えている煮えているプロフィール識別と初期設定. . . . . . 11 4.3が料理したプロフィール概観. . . . . . . . . . . . . . . . . . 11 4.2が料理されたプロフィール. . . . . . . . . . . . . . . . . . . . . 11 4.1はメッセージ構文. . . . . . . . . . . . . . . 11 4の輪郭を描きます; 4がプロフィールメッセージ意味論を料理した、.124.4、.1、IAM要素、.124.4、.2、エントリー要素、.144.4、.3、経路要素. . . . . . . . . . . . . . . . . . . . . . 19 5 推奨案. . . . . . . . . . . . . . 26 6の追加食糧を供給. . . . . . . . . . . . . . . . . . 25 5.1するメッセージの信憑性. . . . . . . . . . . . . . . . . . . . 25 5.2メッセージ再生. . . . . . . . . . . . . . . . . . . . . . . 25 5.3メッセージの保全. . . . . . . . . . . . . . . . . . . . . 25 5.4メッセージ観測. . . . . . . . . . . . . . . . . . . . 26 5.5概要。 登録証明書. . . . . . . . . . . . . . . . . . . 27 6.1登録に頭文字をつけてください: 生のプロフィール. . . . . . . . . . . . . . . 27 6.2登録: 煮えているプロフィール. . . . . . . . . . . . . . 27 7。 syslog DTD. . . . . . . . . . . . . . . . . . . . . . . 28 8。 回答コード. . . . . . . . . . . . . . . . . . . . . . . . 32 9。 IANA問題. . . . . . . . . . . . . . . . . . . . 33 9.1登録: プロフィール. . . . . . . . . . . . . . . . 33 9.2登録を鳴らしてください: System(よく知っている)TCPはsyslog-コン.33 10の数を移植します。 セキュリティ問題. . . . . . . . . . . . . . . . . . 34 11。 承認. . . . . . . . . . . . . . . . . . . . . . 34 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 34作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 35の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 36
New & Rose Standards Track [Page 2] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[2ページ]RFC3195Reliable Delivery
1. Introduction
1. 序論
The syslog protocol [1] presents a spectrum of service options for provisioning an event-based logging service over a network. Each option has associated benefits and costs. Accordingly, the choice as to what combination of options is provisioned is both an engineering and administrative decision. This memo describes how to realize the syslog protocol when reliable delivery is selected as a required service. It is beyond the scope of this memo to argue for, or against, the use of reliable delivery for the syslog protocol.
syslogプロトコル[1]はイベントベースの伐採サービスオーバーに食糧を供給するためのサービスオプションのスペクトルにネットワークを提示します。 各オプションは利益とコストを関連づけました。 それに従って、オプションのどんな組み合わせが食糧を供給されるかに関する選択は工学と管理的意思決定の両方です。 このメモは信頼できる配信が必要なサービスとして選定されるとき、syslogプロトコルがわかる方法を説明します。 それは使用を支持して、または、信頼できる配信のsyslogプロトコルの使用に対して論争するこのメモの範囲を超えています。
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 [2].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
New & Rose Standards Track [Page 3] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[3ページ]RFC3195Reliable Delivery
2. The Model
2. モデル
The syslog service supports three roles of operation: device, relay, and collector.
syslogサービスは操作の3つの役割を支持します: 装置、リレー、およびコレクタ。
Devices and collectors act as sources and sinks, respectively, of syslog entries. In the simplest case, only a device and collector are present. E.g.,
装置とコレクタはソースと流し台としてそれぞれsyslogエントリーを務めます。 最も簡単な場合では、装置とコレクタだけが出席しています。 例えば
+--------+ +-----------+
| Device | -----> | Collector |
+--------+ +-----------+
+--------+ +-----------+ | 装置| ----->| コレクタ| +--------+ +-----------+
The relationship between devices and collectors is potentially many- to-many. I.e., a device might communicate with many collectors; similarly, a collector might communicate with many devices.
装置とコレクタとの関係が潜在的に多い、-、多く すなわち、装置は多くのコレクタとコミュニケートするかもしれません。 同様に、コレクタは多くの装置とコミュニケートするかもしれません。
A relay operates in both modes, accepting syslog entries from devices and other relays and forwarding those entries to collectors and other relays.
リレーは両方のモードで作動します、装置と、他のリレーとそれらのエントリーを進めるのからコレクタと他のリレーまでのsyslogエントリーを受け入れて。
For example,
例えば
+--------+ +-------+ +-------+ +-----------+
| Device | ---> | Relay | -...-> | Relay | ---> | Collector |
+--------+ +-------+ +-------+ +-----------+
+--------+ +-------+ +-------+ +-----------+ | 装置| --->| リレー| -...->| リレー| --->| コレクタ| +--------+ +-------+ +-------+ +-----------+
As shown, more than one relay may be present between any particular device and collector.
示されるように、1個以上のリレーがどんな特定の装置とコレクタの間にも存在しているかもしれません。
A relay may be necessary for administrative reasons. For example, a relay might run as an application proxy on a firewall. Also, there might be one relay per company department, which authenticates all the devices in the department, and which in turn authenticates itself to a company-wide collector.
リレーが管理理由に必要であるかもしれません。 例えば、リレーはアプリケーションプロキシとしてファイアウォールの上に動くかもしれません。 また、会社の部あたり1個のリレーがあるかもしれません。(それは、部ですべての装置を認証して、順番に会社の全体のコレクタにそれ自体を認証します)。
A relay can also serve to filter messages. For example, one relay may collect the syslog information from an entire web server farm, summarizing hit counts for report generation, forwarding "page not found" messages (indicating a possible broken link) to a collector that presents it to the webmaster, and sending more urgent messages (such as hardware failure reports) to a collector that gateways them to a pager. A relay may also be used to convert formats from a device's output to a collector's input.
また、リレーは、メッセージをフィルターにかけるのに役立つことができます。 例えば、1個のリレーが全体のウェブサーバー・ファームからsyslog情報を集めるかもしれません、レポート作成のためにヒット数をまとめて、「見つけられなかったページ」メッセージ(可能なリンク切れを示す)をウェブマスターにそれを提示するコレクタに転送して、より緊急のメッセージ(ハードウェア異常報告書などの)にコレクタへのそのゲートウェイを送って。ポケットベルへのそれら。 また、リレーは、装置の出力からコレクタの入力まで形式を変換するのに使用されるかもしれません。
It should be noted that a role of device, relay, or collector is relevant only to a particular BEEP channel (q.v., below). A single server can serve as a device, a relay, and a collector, all at once,
装置、リレー、またはコレクタの役割が特定のBEEPチャンネル(以下のq.v.)だけに関連していることに注意されるべきです。 ただ一つのサーバは装置、リレー、およびコレクタとして一気に機能できます。
New & Rose Standards Track [Page 4] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[4ページ]RFC3195Reliable Delivery
if so configured. It can even serve as a relay and a collector to the same device at the same time using different BEEP channels over the same connection-oriented session; this might be useful to collect status yet relay urgent error messages.
そうだとすれば、構成されています。 それはリレーとコレクタとして同時に同じ接続指向のセッションの間、異なったBEEPチャンネルを使用することで同じ装置に機能さえできます。 これは、状態を集めますが、緊急のエラーメッセージをリレーするために役に立つかもしれません。
To provide reliable delivery when realizing the syslog protocol, this memo defines two BEEP profiles. BEEP [3] is a generic application protocol framework for connection-oriented, asynchronous interactions. Within BEEP, features such as authentication, privacy, and reliability through retransmission are provided. There are two profiles defined in this memo:
syslogプロトコルがわかるとき、信頼できる配信を提供するために、このメモは2個のBEEPプロフィールを定義します。 BEEP[3]は接続指向の、そして、非同期な相互作用のための一般的適用プロトコル枠組みです。 BEEPの中では、「再-トランスミッション」を通した認証や、プライバシーや、信頼性などの特徴を提供します。 このメモで定義された2個のプロフィールがあります:
o The RAW profile is designed to provide a high-performance, low-
impact footprint, using essentially the same format as the
existing UDP-based syslog service.
o RAWプロフィールは高い性能の、そして、低い衝撃足跡を提供するように設計されています、本質的には既存のUDPベースのsyslogサービスと同じ形式を使用して。
o The COOKED profile is designed to provide a structured entry
format, in which individual entries are acknowledged (either
positively or negatively).
o COOKEDプロフィールは、構造化された入力フォーマットを提供するように設計されています。(そこでは、個人出場者が承諾されます(明確か否定的に))。
Note that both profiles run over BEEP. BEEP defines "transport mappings," specifying how BEEP messages are carried over the underlying transport technologies. At the time of this writing, only one such transport is defined, in [4], which specifies BEEP over TCP. All transport mappings are required to support enough reliability and sequencing to allow all BEEP messages on a given channel to be delivered reliably and in order. Hence, both the RAW and COOKED profile provide reliable delivery of their messages.
両方のプロフィールがBEEPをひくことに注意してください。 BEEPメッセージがどう基本的な輸送技術に伝えられるかを指定して、BEEPは「輸送マッピング」を定義します。 この書くこと時点で、そのような輸送の1つだけが[4]で定義されます。([4]はTCPの上でBEEPを指定します)。 すべての輸送マッピングが、与えられたチャンネルに関するすべてのBEEPメッセージが確かと注文を果たされるのを許す十分な信頼性と配列を支持するのに必要です。 したがって、RAWとCOOKEDが輪郭を描く両方がそれらのメッセージの信頼できる配信を提供します。
The choice of profile is independent of the operational roles discussed above.
プロフィールの選択は上で議論した操作上の役割から独立しています。
For example, in
例えば、コネ
+--------+ +-------+ +-----------+
| Device | -----> | Relay | -----> | Collector |
+--------+ +-------+ +-----------+
+--------+ +-------+ +-----------+ | 装置| ----->| リレー| ----->| コレクタ| +--------+ +-------+ +-----------+
the device-to-relay link could be configured to use the RAW profile, while the relay-to-collector link could be configured to use the COOKED profile. (For example, the relay may be parsing the RAW syslog messages from the device, knowing the details of their formats, before passing them to a more generic collector.) Indeed, the same device may use different profiles, depending on the collector to which it is sending entries.
RAWプロフィールを使用するために装置からリレーへのリンクを構成できました、COOKEDプロフィールを使用するためにリレーからコレクタへのリンクを構成できましたが。 (例えば、リレーは装置からのRAW syslogメッセージを分析しているかもしれません、それらの形式の詳細を知っていて、より一般的なコレクタにそれらを渡す前に。) 本当に、それがエントリーを送るコレクタに頼っていて、同じ装置は異なったプロフィールを使用するかもしれません。
New & Rose Standards Track [Page 5] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[5ページ]RFC3195Reliable Delivery
Devices and relays MAY discover relays and collectors via the DNS SRV algorithm [5]. If so configured, the service used is "syslog" and the protocol used is "tcp". This allows for central administration of addressing, fallback for failed relays and collectors, and static load balancing. Security policies and hardware configurations may be such that device configuration is more secure than the DNS server. Hardware devices may be of such limited resources that DNS SRV access is inappropriate. Firewalls and other restrictive routing mechanisms may need to be dealt with before a reliable syslog connection can be established. In these cases, DNS might not be the most appropriate configuration mechanism.
装置とリレーはDNS SRVアルゴリズム[5]でリレーとコレクタを発見するかもしれません。 そのように構成されるなら、利用されたサービスは"syslog"です、そして、使用されるプロトコルは"tcp"です。 これは失敗したリレー、コレクタ、および静荷重バランスをとることに関してアドレシング、後退の中央の管理を考慮します。 装置構成は、安全保障政策とハードウェア・コンフィギュレーションがそのようなものであるかもしれないので、DNSサーバより安全です。ハードウェアデバイスはDNS SRVアクセスが不適当であるくらいの限りある資源のものであるかもしれません。 ファイアウォールと他の制限しているルーティングメカニズムは、頼もしいsyslog接続を確立できる前に対処される必要があるかもしれません。 これらの場合では、DNSは最も適切な構成メカニズムでないかもしれません。
New & Rose Standards Track [Page 6] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[6ページ]RFC3195Reliable Delivery
3. The RAW Profile
3. 生のプロフィール
3.1 RAW Profile Overview
3.1 生のプロフィール概観
The RAW profile is designed for minimal implementation effort, high efficiency, and backwards compatibility. It is appropriate especially in cases where legacy syslog processing will be applied.
RAWプロフィールは最小限の器具の努力、高性能、および遅れている互換性のために設計されています。 それは特に遺産syslog処理が適用される場合で適切です。
It should be noted that even though the RAW profile uses the same format for message payloads as the UDP version of syslog uses, delivery is reliable. The RAW syslog profile is a profile of BEEP [3], and BEEP guarantees ordered reliable delivery of messages within each individual channel.
RAWプロフィールがメッセージペイロードにsyslog用途のUDPバージョンとして同じ形式を使用しますが、配送が信頼できることに注意されるべきです。 RAW syslogプロフィールはBEEP[3]のプロフィールです、そして、BEEP保証はそれぞれの独特のチャンネルの中にメッセージの信頼できる配信を命令しました。
When the profile is started, no piggyback data is supplied. All BEEP messages in the RAW profile are specified as having a MIME Content- Type [6] of application/octet-stream. Once the channel is open, the listener (not the initiator) sends a MSG message indicating it is ready to act as a syslog sink. (Refer to [3]'s Section 2.1 for a discussion of roles that a BEEP peer may perform, including definitions of the terms "listener", "initiator", "client", and "server".)
プロフィールが始動される、いいえはいつデータを背負います。供給します。 MIME Contentに八重奏アプリケーション/流れの[6]をタイプさせるとRAWプロフィールのすべてのBEEPメッセージが指定されます。 チャンネルがいったんオープンになると、リスナー(創始者でない)はMSGメッセージにそれがsyslog流し台として機能する準備ができているのを示させます。 (役割の議論のためのBEEP同輩が実行するかもしれないセクション2.1であり、「リスナー」という用語、「創始者」、「クライアント」、および「サーバ」の定義を含んでいて、[3]を参照してください。)
The initiator uses ANS replies to supply one or more syslog entries in the current UDP format, as specified in [1]'s Section 3. When the initiator has no more entries to send, it finishes with a NUL reply and closes the channel.
創始者は1つを供給するのにANS回答を使用するか、現在のUDPのエントリーが[1]で指定されるようにフォーマットするより多くのsyslogによるセクション3です。 創始者に送らないそれ以上のエントリーが全くあるとき、それは、NUL回答で終わって、チャンネルを閉じます。
An example might appear as follows:
例は以下の通りに見えるかもしれません:
L: <wait for incoming connection>
I: <establish connection>
L: RPY 0 0 . 0 201
L: Content-type: application/beep+xml
L:
L: <greeting>
L: <profile
L: uri='http://xml.resource.org/profiles/syslog/COOKED' />
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: </greeting>
L: END
I: RPY 0 0 . 0 52
I: Content-type: application/beep+xml
I:
I: <greeting />
I: END
I: MSG 0 1 . 52 133
I: Content-type: application/beep+xml
L: 接続要求>Iのための<待ち: <は接続>Lを設立します: RPY0 0.0201、L: 文書内容: + アプリケーション/ビープ音xml L: L: <挨拶>L: <プロフィールL: uriは' http://xml.resource.org/profiles/syslog/COOKED '/>Lと等しいです: <プロフィールuriは' http://xml.resource.org/profiles/syslog/RAW '/>Lと等しいです: </挨拶>L: 終わりI: RPY0 0.052、私: 文書内容: + アプリケーション/ビープ音xml I: 私: <挨拶/>I: 終わりI: エムエスジー0 1.52133、私: 文書内容: アプリケーション/ビープ音+xml
New & Rose Standards Track [Page 7] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[7ページ]RFC3195Reliable Delivery
I:
I: <start number='1'>
I: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
I: </start>
I: END
L: RPY 0 1 . 201 100
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/RAW' />
L: END
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 61 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.END
I: ANS 1 0 . 61 58 1
I:
I: <29>Oct 27 13:22:15 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
L: MSG 0 3 . 301 70
L: Content-Type: application/beep+xml
L:
L: <close number='1' code='200' />
L: END
I: RPY 0 3 . 185 46
I: Content-Type: application/beep+xml
I:
I: <ok />
I: END
I: MSG 0 4 . 231 72
I: Content-Type: application/beep+xml
I:
I: <close number='0' code='200' />
I: END
L: RPY 0 4 . 371 46
L: Content-type: application/beep+xml
L:
L: <ok />
L: END
L: <closes connection>
I: <closes connection>
L: <awaits next connection>
私: 私: <スタート番号は'1'>Iと等しいです:、' ' http://xml.resource.org/profiles/syslog/RAW '/><プロフィールuri=I: </スタート>I: 終わりL: RPY0 1.201 100、L: 文書内容: + アプリケーション/ビープ音xml L: L: <プロフィールuriは' http://xml.resource.org/profiles/syslog/RAW '/>Lと等しいです: 終わりL: エムエスジー1 0.050、L: L: 主要なサービス。 これは録音ではありません。 L: 終わりI: ANS1 0.0610、私: 私: <29>10月の27 13:21:08ダクト工事imxpd[141]: 加熱emergency.END I: ANS1 0.61 581、私: 私: <29>10月の27 13:22:15ダクト工事imxpd[141]: Tuttle.END Iに連絡してください: NUL1 0.1190、私: 終わりL: エムエスジー0 3.30170、L: コンテントタイプ: + アプリケーション/ビープ音xml L: L: '1'<の近い番号=コードは'200'/>Lと等しいです: 終わりI: RPY0 3.18546、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <OK/>I: 終わりI: エムエスジー0 4.23172、私: コンテントタイプ: + アプリケーション/ビープ音xml I: 私: <の近い番号は'200'/>'0'コード=Iと等しいです: 終わりL: RPY0 4.37146、L: 文書内容: + アプリケーション/ビープ音xml L: L: <OK/>L: 終わりL: <は接続>のために私を閉じます: <は接続>Lを閉じます: <は次の接続>を待ちます。
New & Rose Standards Track [Page 8] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[8ページ]RFC3195Reliable Delivery
Here we see a BEEP session established, followed by the use of the RAW profile. The initiator is a device, while the listener is a collector. The initiator opens the channel, but the listener sends the first MSG. This allows the initiator to send any number of ANS replies carrying syslog event messages. The initiator sends a NUL reply to indicate it is finished. Upon receiving the NUL, the listener closes the RAW channel. The initiator has the choice of closing the entire BEEP session or opening a new syslog channel (RAW or COOKED) for more transfers. In this example, the initiator chooses to close the entire BEEP session.
ここで、私たちは、RAWプロフィールの使用があとに続いていて、BEEPセッションが確立されるのを見ます。 創始者は装置ですが、リスナーはコレクタです。 創始者はチャンネルを開けますが、リスナーは最初のMSGを送ります。 これで、創始者は、いろいろなANS回答がsyslogイベントメッセージを伝えるのを送ることができます。 創始者は、それが終わっているのを示すためにNUL回答を送ります。 NULを受けると、リスナーはRAWチャンネルを閉じます。 創始者には、より多くの転送のために、全体のBEEPセッションを終えるか、または新しいsyslogチャンネル(RAWかCOOKED)を開けることの選択があります。 この例では、創始者は、全体のBEEPセッションを終えるのを選びます。
The overhead for one ANS frame is about thirty octets, once the initial handshakes have been exchanged. If this overhead is too high, then messages are likely being generated at a high rate. In this case, multiple syslog messages can be aggregated into a single ANS frame, each separated by a CRLF sequence from the preceding. The final message still MUST NOT end with a CRLF.
いったん初期の握手を交換すると、1個のANSフレームへのオーバーヘッドはおよそ30の八重奏です。 このオーバーヘッドが高過ぎるなら、メッセージは、高価で発生しながら、ありそうです。 この場合、複数のsyslogメッセージを単一のANSフレーム(CRLF系列によって先行と切り離されたそれぞれ)に集めることができます。 最終的なメッセージはCRLFと共にまだ終わってはいけません。
For example,
例えば
L: MSG 1 0 . 0 50
L:
L: Central Services. This has not been a recording.
L: END
I: ANS 1 0 . 0 119 0
I:
I: <29>Oct 27 13:21:08 ductwork imxpd[141]: Heating emergency.
I: <29>Oct 27 13:21:09 ductwork imxpd[141]: Contact Tuttle.END
I: NUL 1 0 . 119 0
I: END
L: エムエスジー1 0.050、L: L: 主要なサービス。 これは録音ではありません。 L: 終わりI: ANS1 0.01190、私: 私: <29>10月の27 13:21:08ダクト工事imxpd[141]: 加熱非常時。 私: <29>10月の27 13:21:09ダクト工事imxpd[141]: Tuttle.END Iに連絡してください: NUL1 0.1190、私: 終わり
3.2 RAW Profile Identification and Initialization
3.2 生のプロフィール識別と初期設定
The RAW syslog profile is identified as
プロフィールが特定されるRAW syslog
http://xml.resource.org/profiles/syslog/RAW
http://xml.resource.org/profiles/syslog/RAW
in the BEEP "profile" element during channel creation.
チャンネル創造の間のBEEP「プロフィール」要素で。
No data is piggybacked during channel creation.
データは全くチャンネル創造の間、背負われません。
New & Rose Standards Track [Page 9] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[9ページ]RFC3195Reliable Delivery
3.3 RAW Profile Message Syntax
3.3の生のプロフィールメッセージ構文
All BEEP messages in this profile have a MIME content-type of application/octet-stream. The listener's first BEEP message is ignored and indeed may be empty except for headers; hence, any syntax is acceptable.
このプロフィールのすべてのBEEPメッセージには、MIMEの満足しているタイプの八重奏アプリケーション/流れがあります。 リスナーの最初のBEEPメッセージは、無視されて、本当に、ヘッダーを除いて、空であるかもしれません。 したがって、どんな構文も許容できます。
The ANS replies the initiator sends in response MUST be formatted according to Section 4 of [1]. In particular, If the receiver is acting as a relay, then it MUST follow the rules as laid out in Section 4.2.2 of [1].
[1]のセクション4によると、創始者が応答で送るANS回答をフォーマットしなければなりません。 特に受信機がリレー([1]についてセクション4.2.2で広げられて、それが約束を守らなければならないその時)として機能させているIf。
If multiple syslog messages are included in a single ANS reply, each is separated from the preceding with a CRLF. There is no ending delimiter, but each syslog event message body length MUST be 1024 bytes or less, excluding BEEP framing overhead. Note that there MUST NOT be a CRLF between the text of the final syslog event message and the "END" marking the trailer of the BEEP frame.
複数のsyslogメッセージがただ一つのANS回答に含まれていると、それぞれがCRLFとの先行と切り離されます。 終わりのデリミタが全くありませんが、それぞれのsyslogイベントメッセージボディーの長さは1024バイト以下でなければなりません、BEEP縁どりオーバーヘッドを除いて。 最終的なsyslogイベントメッセージのテキストと「終わり」マークの間のCRLFがビープ音フレームのトレーラであったに違いないならそこでそれに注意してください。
3.4 RAW Profile Message Semantics
3.4 生のプロフィールメッセージ意味論
The listener's opening BEEP MSG message has no semantics. (It is a good place to put in an identifying greeting.) The initiator's ANS replies MUST specify a facility, severity, and textual message, as described in [1].
リスナーの初めのBEEP MSGメッセージには、意味論が全くありません。 (それは特定挨拶を入れる良い場所です。) 創始者のANS回答は[1]で説明されるように施設、厳しさ、および原文のメッセージを指定しなければなりません。
New & Rose Standards Track [Page 10] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[10ページ]RFC3195Reliable Delivery
4. The COOKED Profile
4. 煮えているプロフィール
4.1 COOKED Profile Overview
4.1 煮えているプロフィール概観
The COOKED profile is designed for new implementations of syslog protocol handlers. It provides a much finer grain of information tagging, allowing a better degree of automation in processing. Naturally, it includes more overhead as well in support of this.
COOKEDプロフィールはsyslogプロトコル操作者の新しい実現のために設計されています。 処理における、より良い度のオートメーションを許容して、それは情報タグ付けのはるかにすばらしい粒を提供します。 当然、それはこれを支持してまた、より多くのオーバーヘッドを含んでいます。
The COOKED profile supports three elements of interest:
COOKEDプロフィールは興味がある3つの要素を支えます:
o The "iam" element identifies the sender to the receiver, allowing
each peer to name itself for the other, and specifying the roles
(device, relay, or collector) each is taking on.
o "iam"要素は受信機に送付者を特定します、各同輩がそれ自体をもう片方にちなんで命名するのを許容して、それぞれが引き受けている役割(装置、リレー、またはコレクタ)を指定して。
o The "entry" element provides a parsed version of the syslog entry,
with the various fields of interest broken out.
o 「エントリー」要素は多岐が興味があった状態で広げられたsyslogエントリーの分析されたバージョンを提供します。
o The "path" element identifies a list of relays through which a
tagged collection of "entry" elements has passed, along with a set
of flags indicating what assurances of security have been in
effect throughout its delivery.
o 「経路」要素は「エントリー」要素のタグ付けをされた収集に合格したリレーのリストを特定します、セキュリティのどんな保証が配送の間中有効であるかを示す1セットの旗と共に。
4.2 COOKED Profile Identification and Initialization
4.2 煮えているプロフィール識別と初期設定
The COOKED syslog profile is identified as
プロフィールが特定されるCOOKED syslog
http://xml.resource.org/profiles/syslog/COOKED
http://xml.resource.org/profiles/syslog/COOKED
in the BEEP "profile" element during channel creation.
チャンネル創造の間のBEEP「プロフィール」要素で。
During channel creation, the corresponding "profile" element in the BEEP "start" element may contain an "iam" element. If channel creation is successful, then before sending the corresponding reply, the BEEP peer processes the "iam" element and includes the resulting response in the reply. This response will be an "ok" element or an "error" element. The choice of which element is returned is dependent on local provisioning of the recipient. Including an "iam" in the initial "start" element has exactly the same semantics as passing it as the first MSG message on the channel.
チャンネル創造の間、BEEP「始め」要素の対応する「プロフィール」要素は"iam"要素を含むかもしれません。 チャンネル創造がうまくいくなら、対応する回答を送る前に、BEEP同輩は、"iam"要素を処理して、回答における結果として起こる応答を入れます。 この応答は、「間違いありません、な」要素か「誤り」要素になるでしょう。 選択はどの要素が返されるかを受取人の地方の食糧を供給することに依存しています。 初期の「始め」要素に"iam"を含むのにおいて、まさにチャンネルに関する最初のMSGメッセージとしてそれを通過するのと同じ意味論があります。
4.3 COOKED Profile Message Syntax
4.3の煮えているプロフィールメッセージ構文
All BEEP messages in this profile have a MIME Content-Type [6] of application/beep+xml. The syntax of the individual elements is specified in Section 7.
このプロフィールのすべてのBEEPメッセージには、アプリケーション/ビープ音+xmlのMIMEコンテントタイプ[6]があります。 個々の要素の構文はセクション7で指定されます。
New & Rose Standards Track [Page 11] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[11ページ]RFC3195Reliable Delivery
4.4 COOKED Profile Message Semantics
4.4 煮えているプロフィールメッセージ意味論
Initiators issue two elements: "iam" and "entry", each using a "MSG" message. The listener issues "ok" in "RPY" messages and "error" in "ERR" messages. (See [3]'s Section 2.3.1 for the definitions of the "error" and "ok" elements.)
創始者は2つの要素を発行します: それぞれ「エムエスジー」メッセージを使用する"iam"と「エントリー。」 リスナーは「間違えてください」で"RPY"メッセージと「誤り」で「OKに」メッセージを発行します。 ([3]がセクション2.3 「誤り」の定義のための.1と「間違いありません、な」要素であることを確実にしてください。)
4.4.1 The IAM Element
4.4.1 IAM要素
The "iam" element serves to identify a device, relay, or collector at one end of the BEEP channel to the device, relay, or collector at the other end of the channel. The "iam" element includes the type of peer (device, relay, or collector), the fully qualified domain name of the peer, and an IP address of the peer. (The IP address chosen SHOULD be the IP address associated with the underlying transport protocol carrying the channel.) The character data of the element is free-form human-readable text. It may be used to further identify the peer, such as by describing the physical location of the machine.
"iam"要素は、チャンネルのもう一方の端で装置、リレー、またはコレクタのBEEPチャンネルの片端で装置、リレー、またはコレクタを特定するのに役立ちます。 "iam"要素は同輩(装置、リレー、またはコレクタ)のタイプ、同輩の完全修飾ドメイン名、および同輩のIPアドレスを含んでいます。 (SHOULDがIPがアドレスであったなら選ばれたIPアドレスはチャンネルを運ぶ基本的なトランスポート・プロトコルと交際しました。) 要素に関するキャラクタデータは自由形式の人間読み込み可能なテキストです。 さらに同輩を特定するのはマシンの物理的な位置について説明するのなどように使用されているかもしれません。
An "iam" element may be sent by the initiator of the channel at any time. The listener responds to an "iam" element with an "ok" (indicating acceptance), or an "error" (indicating rejection). The identity and role in effect is specified by the most recent "iam" answered with an "ok".
"iam"要素はいつでも、チャンネルの創始者によって送られるかもしれません。 リスナーは「OK」(承認を示す)、または「誤り」に従った"iam"要素まで応じます(拒絶を示して)。 事実上、アイデンティティと役割は「OK」で答えられた最新の"iam"によって指定されます。
An "iam" could be rejected (with an "error" element) by the listener if the privacy or authentication that has been negotiated is inadequate or if the authenticated user does not have authorization to serve in the specified role. It is expected that most installations will require an "iam" from the peer before accepting any "entry" messages.
交渉されたプライバシーか認証が不十分であるか、または認証されたユーザに指定された役割に役立つ認可がないなら、"iam"はリスナーによって拒絶されるかもしれません(「誤り」要素で)。 どんな「エントリー」メッセージも受け入れる前にほとんどのインストールが同輩から"iam"を必要とすると予想されます。
New & Rose Standards Track [Page 12] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[12ページ]RFC3195Reliable Delivery
For example, a successful creation might look like this:
例えば、うまくいっている創造はこれに似るかもしれません:
I: MSG 0 10 . 1832 259
I: Content-type: application/beep+xml
I:
I: <start number='1'>
I: <profile
I: uri='http://xml.resource.org/profiles/syslog/COOKED'>
I: <![CDATA[ <iam fqdn='lowry.example.com' ip='10.0.0.27'
I: type='device'/> ]]>
I: </profile>
I: </start>
L: END
L: RPY 0 10 . 704 138
L: Content-type: application/beep+xml
L:
L: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
L: <![CDATA[ <ok /> ]]>
L: </profile>
L: END
私: エムエスジー0 10、.1832259、私: 文書内容: + アプリケーション/ビープ音xml I: 私: <スタート番号は'1'>Iと等しいです:、' <プロフィールI: ' http://xml.resource.org/profiles/syslog/COOKED 'uri=>I:、' '<[CDATA['lowry.example.com'ip=10.0年.0の.27'<iam fqdn=I: タイプ='装置'/>]]!>I: </プロフィール>I: </スタート>L: 終わりL: RPY0 10、.704 138、L: 文書内容: + アプリケーション/ビープ音xml L: L: ' http://xml.resource.org/profiles/syslog/COOKED '<プロフィールuri=>L:、' <[CDATA[<OK/>]]!>L: </プロフィール>L: 終わり
A creation with an embedded "iam" that fails might look like this:
失敗する埋め込まれた"iam"との創造はこれに似るかもしれません:
C: MSG 0 12 . 1832 259
C: Content-type: application/beep+xml
C:
C: <start number='1'>
C: <profile
C: uri='http://xml.resource.org/profiles/syslog/COOKED'>
C: <![CDATA[ <iam fqdn='tuttle.example.com' ip='10.0.0.29'
C: type='relay'/> ]]>
C: </profile>
C: </start>
C: END
S: RPY 0 12 . 704 241
S: Content-type: application/beep+xml
S:
S: <profile uri='http://xml.resource.org/profiles/syslog/COOKED'>
S: <![CDATA[
S: <error code='535'>User 'buttle.example.com' not allowed
S: to "iam" for 'tuttle.example.com'</error> ]]>
S: </profile>
S: END
C: エムエスジー、0 12 .1832259C: 文書内容: アプリケーション/ビープ音+xml C: C: <スタート番号は'1'>Cと等しいです:、' <プロフィールC: uriは' http://xml.resource.org/profiles/syslog/COOKED '>Cと等しいです:、' '<[CDATA[<iam fqdnは'tuttle.example.com'ipと= '10.0年.0の.29C等しいです: ='リレー'/>をタイプする]]!>C: </プロフィール>C: </スタート>C: 終わりS: RPY、0 12 .704 241秒間: 文書内容: + アプリケーション/ビープ音xml S: S: ' http://xml.resource.org/profiles/syslog/COOKED '<プロフィールuri=>S:、' <[CDATA[S: <エラーコードはSが許容されなかった'535'>User'buttle.example.com'と等しいです:'tuttle.example.com'</誤り>のために"iamする"であることのための ]]!>S:、' </プロフィール>S: 終わり
In this case, the error code indicates that the user "buttle.example.com" has logged in via some SASL profile, but the syslog COOKED profile implementation is claiming to be "tuttle.example.com", a mismatch that the server is disallowing.
この場合、エラーコードは、ユーザ"buttle.example.com"が、あるSASLプロフィールを通してログインしたのを示しますが、syslog COOKEDプロフィール実現は、"tuttle.example.com"(サーバが禁じているミスマッチ)であると主張しています。
New & Rose Standards Track [Page 13] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[13ページ]RFC3195Reliable Delivery
4.4.2 The ENTRY Element
4.4.2 エントリー要素
The "entry" element carries the details of a single syslog entry. The attributes of an "entry" element include "facility", "severity", "timestamp", "hostname", and "tag". "Facility" and "severity" have the semantics defined in [1]'s 4.1. The other attributes have the semantics as in Sections 4.2.1 and 4.2.3 of [1]. An "entry" element can also contain a "pathID" attribute, described below.
「エントリー」要素は単一のsyslogエントリーの詳細を運びます。 「エントリー」要素の属性は「施設」、「厳しさ」、「タイムスタンプ」、「ホスト名」、および「タグ」を含んでいます。 「施設」と「厳しさ」はそうしました。[1]で定義された意味論による4.1です。 意味論がセクション4.2.1と4.2のように他の属性にあります。.3 [1]について。 また、「エントリー」要素は以下で説明された"pathID"属性を含むことができます。
If the client is a relay, the "entry" SHOULD also contain the attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP address of the device that originally created the entry. These attributes may be added by either the relay or the originating device. If possible, the device SHOULD add these entries, referring to the interface most closely associated with the syslog entry. Before a relay forwards an entry from a device that does not carry these attributes, it SHOULD add them based on the "iam" element it has received from the device, or based on the underlying transport connection address. A relay MUST NOT add these fields if they are missing and an "iam" element on the channel has indicated that messages are coming from another relay.
If the client is a relay, the "entry" SHOULD also contain the attributes "deviceFQDN" and "deviceIP", specifying the FQDN and IP address of the device that originally created the entry. These attributes may be added by either the relay or the originating device. If possible, the device SHOULD add these entries, referring to the interface most closely associated with the syslog entry. Before a relay forwards an entry from a device that does not carry these attributes, it SHOULD add them based on the "iam" element it has received from the device, or based on the underlying transport connection address. A relay MUST NOT add these fields if they are missing and an "iam" element on the channel has indicated that messages are coming from another relay.
The "pathID" attribute indicates the path over which this entry has travelled, from device through relays to the final collector. Syntactically, its value is a string of digits that must match the "pathID" attribute of a "path" element sent earlier over the current channel. Semantically, it indicates that the list of relays and flags indicated in that earlier "path" element apply to this "entry" element.
The "pathID" attribute indicates the path over which this entry has travelled, from device through relays to the final collector. Syntactically, its value is a string of digits that must match the "pathID" attribute of a "path" element sent earlier over the current channel. Semantically, it indicates that the list of relays and flags indicated in that earlier "path" element apply to this "entry" element.
The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1].
The character data for the element is the unstructured syslog event message being logged. If the original device delivers the message for the first time via the COOKED profile, it may have any structure inside the CDATA. However, for maximum compatibility, the device SHOULD format the CDATA of the message in accordance with Sections 4.2.1 through 4.2.3 of [1].
New & Rose Standards Track [Page 14] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 14] RFC 3195 Reliable Delivery for syslog November 2001
In the message is being relayed, "tag" SHOULD be those of the original device generating the entry (unless the device cannot supply a tag). The "timestamp" SHOULD be that of the original entry generation time, rather than the time the entry was passed outward from the relay. The "hostname" SHOULD be the host name or IP address by which the device knows itself; this MUST follow the rules established in Sections 4.2.1 through 4.2.3 of [1]. The original contents of the syslog message MUST be preserved in the CDATA of the "entry" element; this includes preservation of exact content during translation from the UDP or RAW formats. In particular, the timestamps MUST NOT be rewritten in the CDATA of the "entry" element, the tag MUST NOT be removed from the CDATA even if presented in the "entry" attributes as well, and so on.
In the message is being relayed, "tag" SHOULD be those of the original device generating the entry (unless the device cannot supply a tag). The "timestamp" SHOULD be that of the original entry generation time, rather than the time the entry was passed outward from the relay. The "hostname" SHOULD be the host name or IP address by which the device knows itself; this MUST follow the rules established in Sections 4.2.1 through 4.2.3 of [1]. The original contents of the syslog message MUST be preserved in the CDATA of the "entry" element; this includes preservation of exact content during translation from the UDP or RAW formats. In particular, the timestamps MUST NOT be rewritten in the CDATA of the "entry" element, the tag MUST NOT be removed from the CDATA even if presented in the "entry" attributes as well, and so on.
To be consistent with the spirit of [1], a relay receiving a message that does not contain a valid priority, timestamp or hostname will follow the same general rules as described in section 4.2.2 of [1] while including the exact contents of the received syslog packet as the CDATA. The values of the facility and severity will be construed to be 8 and 6 respectively and will be placed into the appropriate attributes of the "entry" element. The hostname will be the name of the device as it is known to the relay and will also be inserted into the "entry" element's attributes. The timestamp would be set to the received time, inserted only into the attributes of the "entry" element. As an example, consider this message received on UDP port 514 and interpreted as a traditional syslog message, assuming the underlying IP source address is that of the "pipeworks" machine:
To be consistent with the spirit of [1], a relay receiving a message that does not contain a valid priority, timestamp or hostname will follow the same general rules as described in section 4.2.2 of [1] while including the exact contents of the received syslog packet as the CDATA. The values of the facility and severity will be construed to be 8 and 6 respectively and will be placed into the appropriate attributes of the "entry" element. The hostname will be the name of the device as it is known to the relay and will also be inserted into the "entry" element's attributes. The timestamp would be set to the received time, inserted only into the attributes of the "entry" element. As an example, consider this message received on UDP port 514 and interpreted as a traditional syslog message, assuming the underlying IP source address is that of the "pipeworks" machine:
<.....eeeek!
<.....eeeek!
To be relayed, it must be modified as follows:
To be relayed, it must be modified as follows:
C: MSG 1 0 . 2079 156
C: Content-Type: application/beep+xml
C:
C: <entry facility='8' severity='6'
C: hostname='pipeworks'
C: timestamp='Oct 31 23:59:59'
C: ><.....eeeek!</entry>
C: END
S: RPY 1 0 . 933 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2079 156 C: Content-Type: application/beep+xml C: C: <entry facility='8' severity='6' C: hostname='pipeworks' C: timestamp='Oct 31 23:59:59' C: ><.....eeeek!</entry> C: END S: RPY 1 0 . 933 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
New & Rose Standards Track [Page 15] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 15] RFC 3195 Reliable Delivery for syslog November 2001
As another example, consider a message being received that does not properly adhere to the conventions described in Section 4.2.2 of [1]. In particular, the timestamp has a year, making it a nonstandard format:
As another example, consider a message being received that does not properly adhere to the conventions described in Section 4.2.2 of [1]. In particular, the timestamp has a year, making it a nonstandard format:
<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
<166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!
This would be relayed as follows:
This would be relayed as follows:
C: MSG 1 0 . 2235 242
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:04'
C: ><166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 978 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2235 242 C: Content-Type: application/beep+xml C: C: <entry facility='160' severity='6' C: hostname='bomb' C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83' C: timestamp='Oct 22 01:00:04' C: ><166> 1990 Oct 22 01:00:00 bomb tick[0]: BOOM!</entry> C: END S: RPY 1 0 . 978 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
Note that the tag value was not readily apparent from the received message (due to the failed parsing of the timestamp), so it was not included in the "entry" element.
Note that the tag value was not readily apparent from the received message (due to the failed parsing of the timestamp), so it was not included in the "entry" element.
It is explicitly permitted for a relay to parse raw messages in a more sophisticated way, but all implementations MUST be able to parse messages presented in the format described in [1]. A more sophisticated relay could have recognized the year and completely parsed out the correct time, tag, and hostname, but such additional parsing capability is OPTIONAL.
It is explicitly permitted for a relay to parse raw messages in a more sophisticated way, but all implementations MUST be able to parse messages presented in the format described in [1]. A more sophisticated relay could have recognized the year and completely parsed out the correct time, tag, and hostname, but such additional parsing capability is OPTIONAL.
Consider the following example, in contrast:
Consider the following example, in contrast:
<166> Oct 22 01:00:00 bomb tick[0]: BOOM!
<166> Oct 22 01:00:00 bomb tick[0]: BOOM!
New & Rose Standards Track [Page 16] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 16] RFC 3195 Reliable Delivery for syslog November 2001
This conformant message would be relayed as follows:
This conformant message would be relayed as follows:
C: MSG 1 0 . 2477 248
C: Content-Type: application/beep+xml
C:
C: <entry facility='160' severity='6'
C: hostname='bomb'
C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83'
C: timestamp='Oct 22 01:00:00' tag='tick'
C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry>
C: END
S: RPY 1 0 . 1023 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2477 248 C: Content-Type: application/beep+xml C: C: <entry facility='160' severity='6' C: hostname='bomb' C: deviceFQDN='bomb.terrorist.net' deviceIP='10.0.0.83' C: timestamp='Oct 22 01:00:00' tag='tick' C: ><166> Oct 22 01:00:00 bomb tick[0]: BOOM!</entry> C: END S: RPY 1 0 . 1023 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
In this case, the tag is detected and the timestamp represents the message generation time rather than the message reception time.
In this case, the tag is detected and the timestamp represents the message generation time rather than the message reception time.
Finally, the "entry" element may also contain an "xml:lang" attribute, indicating the language in which the CDATA content of the tag is presented, as described in [7].
Finally, the "entry" element may also contain an "xml:lang" attribute, indicating the language in which the CDATA content of the tag is presented, as described in [7].
The "entry" element is answered with either an empty "ok" element if everything was successful, or a standard "error" element if there was a problem. An "entry" element can be rejected if no "iam" element has been accepted by the listener. It can also be rejected if the user authenticated on the BEEP session (if any) does not have the authority to generate (as a device) or relay that entry. An error is also possible if the "pathID" attribute refers to an unknown (or rejected) "path" element.
The "entry" element is answered with either an empty "ok" element if everything was successful, or a standard "error" element if there was a problem. An "entry" element can be rejected if no "iam" element has been accepted by the listener. It can also be rejected if the user authenticated on the BEEP session (if any) does not have the authority to generate (as a device) or relay that entry. An error is also possible if the "pathID" attribute refers to an unknown (or rejected) "path" element.
New & Rose Standards Track [Page 17] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 17] RFC 3195 Reliable Delivery for syslog November 2001
A successful exchange of an "entry" element may look like this:
A successful exchange of an "entry" element may look like this:
C: MSG 1 0 . 2725 173
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Jan 26 15:16:17'
C: hostname='pipework' tag='imxp'>
C: No 27B/6 available</entry>
C: END
S: RPY 1 0 . 1068 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 1 0 . 2725 173 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Jan 26 15:16:17' C: hostname='pipework' tag='imxp'> C: No 27B/6 available</entry> C: END S: RPY 1 0 . 1068 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
Here, the device IP address and FQDN are taken from the "iam" element, if any, or from the underlying connection information.
Here, the device IP address and FQDN are taken from the "iam" element, if any, or from the underlying connection information.
An example where an "entry" element is rejected with an "error" element:
An example where an "entry" element is rejected with an "error" element:
C: MSG 1 2 . 2898 223
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15'
C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83'
C: tag='imxpd'>
C: Replacement device found in nostril.
C: </entry>
C: END
S: ERR 1 2 . 1113 111
S: Content-Type: application/beep+xml
S:
S: <error code='554'>Not allowed to relay for
S: jack.example.net</error>
S: END
C: MSG 1 2 . 2898 223 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' timestamp='Jan 02 13:22:15' C: deviceFQDN='jack.example.net' deviceIP='10.0.0.83' C: tag='imxpd'> C: Replacement device found in nostril. C: </entry> C: END S: ERR 1 2 . 1113 111 S: Content-Type: application/beep+xml S: S: <error code='554'>Not allowed to relay for S: jack.example.net</error> S: END
Here, the client attempts to relay an entry on behalf of jack.example.com, but the entry is refused by the collector for administrative reasons. This may occur, for example, if lowry.example.com is in a different department than jack.example.com.
Here, the client attempts to relay an entry on behalf of jack.example.com, but the entry is refused by the collector for administrative reasons. This may occur, for example, if lowry.example.com is in a different department than jack.example.com.
New & Rose Standards Track [Page 18] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 18] RFC 3195 Reliable Delivery for syslog November 2001
4.4.3 The PATH Element
4.4.3 The PATH Element
The "path" element serves to describe a list of the relays through which that element has passed, along with a set of flags that indicate the properties that all links from the device to the relay have shared in common. Each "path" element contains either another "path" element or is empty. An empty "path" element identifies a device, while a "path" element with a nested "path" element identifies a relay. Each "path" element names a FQDN and IP address of the interface that sent the element. Each "path" element also names a FQDN and IP address for the interface that received the element. Each "path" element also carries a "linkprops" attribute, specifying the properties of the link it describes.
The "path" element serves to describe a list of the relays through which that element has passed, along with a set of flags that indicate the properties that all links from the device to the relay have shared in common. Each "path" element contains either another "path" element or is empty. An empty "path" element identifies a device, while a "path" element with a nested "path" element identifies a relay. Each "path" element names a FQDN and IP address of the interface that sent the element. Each "path" element also names a FQDN and IP address for the interface that received the element. Each "path" element also carries a "linkprops" attribute, specifying the properties of the link it describes.
Each "path" element has a "pathID" attribute which must be unique for all "path" elements sent on this channel since its inception. Syntactically, the "pathID" attribute is a string of digits. Semantically, it serves to identify one "path" element out of many, and it serves to link a "path" element with one or more "entry" elements. Any "pathID" attribute is unrelated to any "pathID" attribute in nested "path" elements or on other channels.
Each "path" element has a "pathID" attribute which must be unique for all "path" elements sent on this channel since its inception. Syntactically, the "pathID" attribute is a string of digits. Semantically, it serves to identify one "path" element out of many, and it serves to link a "path" element with one or more "entry" elements. Any "pathID" attribute is unrelated to any "pathID" attribute in nested "path" elements or on other channels.
Each "path" element has a "fromFQDN" attribute and an "fromIP" attribute. The "fromFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was sent. (The "fromFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "fromIP" attribute MUST be the IP address of the interface over which the "path" element was sent.
Each "path" element has a "fromFQDN" attribute and an "fromIP" attribute. The "fromFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was sent. (The "fromFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "fromIP" attribute MUST be the IP address of the interface over which the "path" element was sent.
Each "path" element has a "toFQDN" attribute and an "toIP" attribute. The "toFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was received. (The "toFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "toIP" attribute MUST be the IP address of the interface over which the "path" element was received.
Each "path" element has a "toFQDN" attribute and an "toIP" attribute. The "toFQDN" attribute SHOULD be the fully qualified domain name of the interface over which the "path" element was received. (The "toFQDN" can be omitted if that interface has no DNS entry.) Similarly, the "toIP" attribute MUST be the IP address of the interface over which the "path" element was received.
Finally, each "path" element carries a "linkprops" attribute. This is syntactically a string of individual characters, each indicating one property of the channel over which this "path" element is being carried. Note that outer "path" elements may have stronger guarantees than inner "path" elements; care should be taken in the interpretation of flags. The semantics of each possible character in this string are as follows:
Finally, each "path" element carries a "linkprops" attribute. This is syntactically a string of individual characters, each indicating one property of the channel over which this "path" element is being carried. Note that outer "path" elements may have stronger guarantees than inner "path" elements; care should be taken in the interpretation of flags. The semantics of each possible character in this string are as follows:
New & Rose Standards Track [Page 19] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 19] RFC 3195 Reliable Delivery for syslog November 2001
o: When present, "o" (lower-case letter "o") indicates that weak
privacy has been negotiated over this link, weakly protecting from
observation the content of entries associated with this "path"
element. (Weak privacy is encryption with less than 80 bits of
key.)
o: When present, "o" (lower-case letter "o") indicates that weak privacy has been negotiated over this link, weakly protecting from observation the content of entries associated with this "path" element. (Weak privacy is encryption with less than 80 bits of key.)
O: When present, "O" (upper-case letter "O") indicates that strong
privacy has been negotiated over this link, strongly protecting
from observation the content of entries associated with this
"path" element. (Strong privacy is encryption with 80 bits or
more of key, or a transfer mechanism that is otherwise impossible
to eavesdrop upon.)
O: When present, "O" (upper-case letter "O") indicates that strong privacy has been negotiated over this link, strongly protecting from observation the content of entries associated with this "path" element. (Strong privacy is encryption with 80 bits or more of key, or a transfer mechanism that is otherwise impossible to eavesdrop upon.)
U: When present, "U" indicates that a valid user has been
authenticated (via SASL or TLS) and an "iam" element has been
accepted.
U: When present, "U" indicates that a valid user has been authenticated (via SASL or TLS) and an "iam" element has been accepted.
A: When present, "A" indicates that this link has been protected by
an authentication layer, authenticating the source of every
"entry" associated with this path.
A: When present, "A" indicates that this link has been protected by an authentication layer, authenticating the source of every "entry" associated with this path.
R: When present, "R" indicates that this link has been protected
against message replay.
R: When present, "R" indicates that this link has been protected against message replay.
I: When present, "I" indicates that this link has been protected
against modifications of messages in passing. ("I" stands for
message Integrity.)
I: When present, "I" indicates that this link has been protected against modifications of messages in passing. ("I" stands for message Integrity.)
L: When present, "L" indicates that this link has been protected
against loss of messages. That is, this is a reliable delivery
link.
L: When present, "L" indicates that this link has been protected against loss of messages. That is, this is a reliable delivery link.
D: When present, "D" indicates that the "from" side of this link is a
device. If this is not present on the innermost "path" element,
"entry" elements associated with this path have not been carried
by the COOKED profile for their entire lifetime.
D: When present, "D" indicates that the "from" side of this link is a device. If this is not present on the innermost "path" element, "entry" elements associated with this path have not been carried by the COOKED profile for their entire lifetime.
Upon receiving a "path" element, the peer MUST perform the following checks:
Upon receiving a "path" element, the peer MUST perform the following checks:
o The "fromFQDN" and "fromIP" must match the underlying transport
connection.
o The "fromFQDN" and "fromIP" must match the underlying transport connection.
o The flags in the "linkprops" attribute must match the attributes
of the session.
o The flags in the "linkprops" attribute must match the attributes of the session.
o The "toFQDN" and "toIP" must match the underlying transport
connection.
o The "toFQDN" and "toIP" must match the underlying transport connection.
New & Rose Standards Track [Page 20] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 20] RFC 3195 Reliable Delivery for syslog November 2001
o The "pathID" attribute must be unique with respect to all other
"path" elements received on this channel.
o The "pathID" attribute must be unique with respect to all other "path" elements received on this channel.
If all these checks pass, the "path" element is accepted with an "ok" element. Otherwise, an "error" element is generated with an appropriate code. In addition, if any of the nested "path" elements refer to the machine receiving the element, it may indicate a routing loop in the configuration for the so-identified path, and appropriate measures should be taken.
If all these checks pass, the "path" element is accepted with an "ok" element. Otherwise, an "error" element is generated with an appropriate code. In addition, if any of the nested "path" elements refer to the machine receiving the element, it may indicate a routing loop in the configuration for the so-identified path, and appropriate measures should be taken.
If the peer receiving an "entry" element is receiving it directly from a device via either syslog-conn profile, and the device has not generated a "path" element, the receiver may itself generate an appropriate "path" element, either to be recorded in the logs (if this peer is a collector) or passed to the next peer (if this peer is a relay). If a peer receives a syslog message via UDP, it may optionally generate an appropriate "peer" element based on any cryptographic information provided in the message itself.
If the peer receiving an "entry" element is receiving it directly from a device via either syslog-conn profile, and the device has not generated a "path" element, the receiver may itself generate an appropriate "path" element, either to be recorded in the logs (if this peer is a collector) or passed to the next peer (if this peer is a relay). If a peer receives a syslog message via UDP, it may optionally generate an appropriate "peer" element based on any cryptographic information provided in the message itself.
When a peer receives a "path" element, it remembers it for future use. A collector will store it in the log for later reference. A relay will remember it. When an "entry" arrives referencing the received "path" element, and that entry needs to be forwarded to another relay or collector, and no appropriate "path" element has already been generated, an appropriate "path" element is generated and sent over the outbound channel before the entry is forwarded. An appropriate "path" element is created by taking the received "path" element, wrapping it in a new "path" element with the appropriate attributes, and assigning it a new "pathID" attribute. When future "entry" elements arrive with the same incoming "pathID" attribute, and they need to be forwarded to a channel over which an appropriate "pathID" attribute has already been sent, only the "pathID" attribute of the "entry" element needs to be rewritten to refer to the "path" element on the outgoing channel.
When a peer receives a "path" element, it remembers it for future use. A collector will store it in the log for later reference. A relay will remember it. When an "entry" arrives referencing the received "path" element, and that entry needs to be forwarded to another relay or collector, and no appropriate "path" element has already been generated, an appropriate "path" element is generated and sent over the outbound channel before the entry is forwarded. An appropriate "path" element is created by taking the received "path" element, wrapping it in a new "path" element with the appropriate attributes, and assigning it a new "pathID" attribute. When future "entry" elements arrive with the same incoming "pathID" attribute, and they need to be forwarded to a channel over which an appropriate "pathID" attribute has already been sent, only the "pathID" attribute of the "entry" element needs to be rewritten to refer to the "path" element on the outgoing channel.
It should be noted that the majority of the complexity in managing "path" elements arises only in relays. In particular, devices never need to generate "path" elements and collectors need only verify them, log them, and possibly use them in displays and reports. Collectors do not need to generate "path" elements or rewrite "entry" elements. Hence, only in complex configurations (where they are most useful) do complex "path" configurations occur.
It should be noted that the majority of the complexity in managing "path" elements arises only in relays. In particular, devices never need to generate "path" elements and collectors need only verify them, log them, and possibly use them in displays and reports. Collectors do not need to generate "path" elements or rewrite "entry" elements. Hence, only in complex configurations (where they are most useful) do complex "path" configurations occur.
New & Rose Standards Track [Page 21] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 21] RFC 3195 Reliable Delivery for syslog November 2001
For example, here is a path element sent from lowry.records.example.com to kurtzman.records.example.com. It indicates that entries from lowry to kurtzman tagged with pathID='173' originated from screen.lowry.records.example.com. It indicates that screen.lowry.records.example.com is believed by lowry.records.example.com to be the originating device, and that entries over this path are delivered without loss and without modification, although messages might be replayed or observed. The link between lowry and kurtzman, however, avoids replay attacks, lost messages, and modifications to messages. While screen.lowry.records.example.com has not authenticated itself to lowry.records.example.com, lowry claims to have authenticated itself to kurtzman.
For example, here is a path element sent from lowry.records.example.com to kurtzman.records.example.com. It indicates that entries from lowry to kurtzman tagged with pathID='173' originated from screen.lowry.records.example.com. It indicates that screen.lowry.records.example.com is believed by lowry.records.example.com to be the originating device, and that entries over this path are delivered without loss and without modification, although messages might be replayed or observed. The link between lowry and kurtzman, however, avoids replay attacks, lost messages, and modifications to messages. While screen.lowry.records.example.com has not authenticated itself to lowry.records.example.com, lowry claims to have authenticated itself to kurtzman.
C: MSG 2 1 . 3121 426
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path>
C: </path>
C: END
S: ERR 2 1 . 1224 114
S: Content-type: application/beep+xml
S:
S: <error code='530'>linkprops includes 'U'
S: but no 'iam' received</error>
S: END
C: MSG 2 1 . 3121 426 C: Content-type: application/beep+xml C: C: <path fromFQDN='lowry.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='kurtzman.records.example.com' C: toIP='10.0.0.51' C: linkprops='ULRI' C: pathID='173'> C: <path fromFQDN='screen.lowry.records.example.com' C: fromIP='10.0.0.47' C: toFQDN='lowry.records.example.com' C: toIP='10.0.0.50' C: linkprops='DLI' C: pathID='24'> C: </path> C: </path> C: END S: ERR 2 1 . 1224 114 S: Content-type: application/beep+xml S: S: <error code='530'>linkprops includes 'U' S: but no 'iam' received</error> S: END
However, kurtzman.records.example.com rejects the "path" element, since the "linkprops" attribute claims that lowry has authenticated itself, but kurtzman disagrees, not having received an "iam" element.
However, kurtzman.records.example.com rejects the "path" element, since the "linkprops" attribute claims that lowry has authenticated itself, but kurtzman disagrees, not having received an "iam" element.
New & Rose Standards Track [Page 22] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 22] RFC 3195 Reliable Delivery for syslog November 2001
In a second example, this "path" element informs collector.example.com that the records department's firewall will be forwarding "entry" elements with a "pathID" attribute whose value is "17". These "entry" elements will be coming in on the "10.0.0.2" interface of the firewall, to be forwarded out the "134.130.74.56" interface of the firewall. The final hop has all possible guarantees, although the entries transferred within the records department (behind the firewall) may have been observed in passing.
In a second example, this "path" element informs collector.example.com that the records department's firewall will be forwarding "entry" elements with a "pathID" attribute whose value is "17". These "entry" elements will be coming in on the "10.0.0.2" interface of the firewall, to be forwarded out the "134.130.74.56" interface of the firewall. The final hop has all possible guarantees, although the entries transferred within the records department (behind the firewall) may have been observed in passing.
C: MSG 2 2 . 3547 813
C: Content-type: application/beep+xml
C:
C: <path fromFQDN='fwall.records.example.com'
C: fromIP='134.130.74.56'
C: toFQDN='collector.example.com'
C: toIP='134.130.74.12'
C: linkprops='OUARIL'
C: pathID='17'>
C: <path fromFQDN='kurtzman.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='fwall.records.example.com'
C: toIP='10.0.0.2'
C: linkprops='ULRI'
C: pathID='120'>
C: <path fromFQDN='lowry.records.example.com'
C: fromIP='10.0.0.50'
C: toFQDN='kurtzman.records.example.com'
C: toIP='10.0.0.51'
C: linkprops='ULRI'
C: pathID='173'>
C: <path fromFQDN='screen.lowry.records.example.com'
C: fromIP='10.0.0.47'
C: toFQDN='lowry.records.example.com'
C: toIP='10.0.0.50'
C: linkprops='DLI'
C: pathID='24'>
C: </path></path></path></path>
C: END
S: RPY 2 2 . 1338 45
S: Content-type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 2 2 . 3547 813 C: Content-type: application/beep+xml C: C: <path fromFQDN='fwall.records.example.com' C: fromIP='134.130.74.56' C: toFQDN='collector.example.com' C: toIP='134.130.74.12' C: linkprops='OUARIL' C: pathID='17'> C: <path fromFQDN='kurtzman.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='fwall.records.example.com' C: toIP='10.0.0.2' C: linkprops='ULRI' C: pathID='120'> C: <path fromFQDN='lowry.records.example.com' C: fromIP='10.0.0.50' C: toFQDN='kurtzman.records.example.com' C: toIP='10.0.0.51' C: linkprops='ULRI' C: pathID='173'> C: <path fromFQDN='screen.lowry.records.example.com' C: fromIP='10.0.0.47' C: toFQDN='lowry.records.example.com' C: toIP='10.0.0.50' C: linkprops='DLI' C: pathID='24'> C: </path></path></path></path> C: END S: RPY 2 2 . 1338 45 S: Content-type: application/beep+xml S: S: <ok/> S: END
New & Rose Standards Track [Page 23] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 23] RFC 3195 Reliable Delivery for syslog November 2001
As a final example, an "entry" element from Lowry's screen arrives at the firewall. The "path" attribute is rewritten, and it is forwarded on to the collector.
As a final example, an "entry" element from Lowry's screen arrives at the firewall. The "path" attribute is rewritten, and it is forwarded on to the collector.
The entry arrives on the 10.0.0.2 interface:
The entry arrives on the 10.0.0.2 interface:
C: MSG 2 3 . 4360 250
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='173'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 2 3 . 1383 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 2 3 . 4360 250 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Oct 27 13:24:12' C: deviceFQDN='screen.lowry.records.example.com' C: deviceIP='10.0.0.47' C: pathID='173' C: tag='dvd'> C: Job paused - Boss watching. C: </entry> C: END S: RPY 2 3 . 1383 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
It is forwarded out the 134.130.74.56 interface:
It is forwarded out the 134.130.74.56 interface:
C: MSG 7 9 . 9375 276
C: Content-Type: application/beep+xml
C:
C: <entry facility='24' severity='5'
C: timestamp='Oct 27 13:24:12'
C: deviceFQDN='screen.lowry.records.example.com'
C: deviceIP='10.0.0.47'
C: pathID='17'
C: tag='dvd'>
C: Job paused - Boss watching.
C: </entry>
C: END
S: RPY 7 9 . 338 45
S: Content-Type: application/beep+xml
S:
S: <ok/>
S: END
C: MSG 7 9 . 9375 276 C: Content-Type: application/beep+xml C: C: <entry facility='24' severity='5' C: timestamp='Oct 27 13:24:12' C: deviceFQDN='screen.lowry.records.example.com' C: deviceIP='10.0.0.47' C: pathID='17' C: tag='dvd'> C: Job paused - Boss watching. C: </entry> C: END S: RPY 7 9 . 338 45 S: Content-Type: application/beep+xml S: S: <ok/> S: END
A discussion of the wisdom of configuring Lowry's machine to forward such messages via Kurtzman's machine is beyond the scope of this document.
A discussion of the wisdom of configuring Lowry's machine to forward such messages via Kurtzman's machine is beyond the scope of this document.
New & Rose Standards Track [Page 24] RFC 3195 Reliable Delivery for syslog November 2001
New & Rose Standards Track [Page 24] RFC 3195 Reliable Delivery for syslog November 2001
5. Additional Provisioning
5. Additional Provisioning
In more advanced configurations, syslog devices, relays, and collectors can be configured to support various delivery priorities. Multiple channels running the same profile can be opened between two peers, with higher priority syslog messages routed to a channel that is given more bandwidth. Such provisioning is a local matter.
In more advanced configurations, syslog devices, relays, and collectors can be configured to support various delivery priorities. Multiple channels running the same profile can be opened between two peers, with higher priority syslog messages routed to a channel that is given more bandwidth. Such provisioning is a local matter.
syslog [1] discusses a number of reasons why privacy and authentication of syslog entry messages may be important in a networked computing environment. The nature of BEEP allows for convenient layering of authentication and privacy over any BEEP channel.
syslog [1] discusses a number of reasons why privacy and authentication of syslog entry messages may be important in a networked computing environment. The nature of BEEP allows for convenient layering of authentication and privacy over any BEEP channel.
5.1 Message Authenticity
5.1 Message Authenticity
Section 6.2 of [1] discusses the dangers of unauthenticated syslog entries. To prevent inauthentic syslog event messages from being accepted, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
Section 6.2 of [1] discusses the dangers of unauthenticated syslog entries. To prevent inauthentic syslog event messages from being accepted, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
If provisioned for message authentication, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
If provisioned for message authentication, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
5.2 Message Replay
5.2 Message Replay
Section 6.3.4 of [1] discusses the dangers of syslog message replay. To prevent syslog event messages from being replayed, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
Section 6.3.4 of [1] discusses the dangers of syslog message replay. To prevent syslog event messages from being replayed, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
If provisioned to detect message replay, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
If provisioned to detect message replay, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
5.3 Message Integrity
5.3 メッセージの保全
Section 6.5 of [1] discusses the dangers of syslog event messages being maliciously altered by an attacker. To prevent messages from being altered, configure syslog peers to require the use of a strong authentication technology for the BEEP session.
[1]のセクション6.5は攻撃者によって陰湿に変更されるsyslogイベントメッセージという危険について論じます。 メッセージが変更されるのを防ぐには、syslogが強い認証技術のBEEPセッションの使用を必要とするようにじっと見るのを構成してください。
If provisioned to protect message integrity, implementations SHOULD use SASL mechanism DIGEST-MD5 [8] to provision this service.
メッセージの保全を保護するために食糧を供給されるなら、実現SHOULDはSASLメカニズムDIGEST-MD5[8]をこれが修理する支給に使用します。
New & Rose Standards Track [Page 25] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[25ページ]RFC3195Reliable Delivery
5.4 Message Observation
5.4 メッセージ観測
Section 6.6 of [1] discusses the dangers (and benefits) of syslog messages being visible at intermediate points along the transmission path between device and collector. To prevent messages from being viewed by an attacker, configure syslog peers to require the use of a transport security profile for the BEEP session. (However, other traffic characteristics, e.g., volume and timing of transmissions, remain observable.)
[1]のセクション6.6は装置とコレクタの間のトランスミッション経路に沿って中間的ポイントで目に見えるsyslogメッセージの危険(そして、利益)について論じます。 メッセージが攻撃者によって見られるのを防ぐには、syslogが輸送セキュリティプロフィールのBEEPセッションの使用を必要とするようにじっと見るのを構成してください。 (しかしながら、他の交通の特性(トランスミッションの例えば、ボリュームとタイミング)は、観察可能なままで残っています。)
If provisioned to secure messages against unauthorized observation, implementations SHOULD use the TLS profile [3] to provision this service. The cipher algorithm used SHOULD be TLS_RSA_WITH_3DES_EDE_CBC_SHA.
食糧を供給されるなら、権限のない観測、実現SHOULD使用に対してメッセージを保証するために、TLSは[3] 支給に対するこのサービスの輪郭を描きます。 暗号アルゴリズムは_TLS_RSA_WITH_3DESがEDE_CBC_SHAであったならSHOULDを使用しました。
5.5 Summary of Recommended Practices
5.5 推奨案の概要
For the indicated protections, implementations SHOULD be configured to use the indicated mechanisms:
保護、実現SHOULDが示されたメカニズムを使用するために構成されるのを示します:
Desired Protection SHOULD tune using
------------------ -----------------
Authentication http://iana.org/beep/SASL/DIGEST-MD5
+ Replay http://iana.org/beep/SASL/DIGEST-MD5
+ Integrity http://iana.org/beep/SASL/DIGEST-MD5
+ Observation http://iana.org/beep/TLS
必要なProtection SHOULD旋律使用------------------ ----------------- 認証 http://iana.org/beep/SASL/DIGEST-MD5 +再生 http://iana.org/beep/SASL/DIGEST-MD5 +保全 http://iana.org/beep/SASL/DIGEST-MD5 +観測 http://iana.org/beep/TLS
BEEP peer identities used for authentication SHOULD correspond to the FQDN of the initiating peer. That is, a relay running on relay.example.com should use a "user ID" of "relay.example.com" within the SASL authentication profiles, as well as in the FQDN of the "iam" element.
認証SHOULDが開始のFQDNに対応しているので、使用されるBEEP同輩のアイデンティティはじっと見ます。 すなわち、relay.example.comの上で作業するリレーはSASL認証プロフィール以内と"iam"要素のFQDNで"relay.example.com"の「ユーザID」を使用するはずです。
New & Rose Standards Track [Page 26] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[26ページ]RFC3195Reliable Delivery
6. Initial Registrations
6. 初期の登録証明書
6.1 Registration: The RAW Profile
6.1登録: 生のプロフィール
Profile Identification: http://xml.resource.org/profiles/syslog/RAW
識別の輪郭を描いてください: http://xml.resource.org/profiles/syslog/RAW
Messages exchanged during Channel Creation: None
メッセージはChannel Creationの間、交換しました: なし
Messages starting one-to-one exchanges: Anything
始めが1〜1に以下を交換するというメッセージ 何でも
Messages in positive replies: None
積極的な返事におけるメッセージ: なし
Messages in negative replies: None
否定的な返事におけるメッセージ: なし
Messages in one-to-many exchanges: Anything
多くへの1回の交換におけるメッセージ: 何でも
Message Syntax: See Section 3.3
メッセージ構文: セクション3.3を見てください。
Message Semantics: See Section 3.4
メッセージ意味論: セクション3.4を見てください。
Contact Information: See the "Authors' Addresses" section of this
memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
6.2 Registration: The COOKED Profile
6.2登録: 煮えているプロフィール
Profile Identification:
http://xml.resource.org/profiles/syslog/COOKED
識別の輪郭を描いてください: http://xml.resource.org/profiles/syslog/COOKED
Messages exchanged during Channel Creation: iam
メッセージはChannel Creationの間、交換しました: iam
Messages starting one-to-one exchanges: iam, entry, path
始めが1〜1に以下を交換するというメッセージ iam、エントリー、経路
Messages in positive replies: ok
積極的な返事におけるメッセージ: OK
Messages in negative replies: error
否定的な返事におけるメッセージ: 誤り
Messages in one-to-many exchanges: None
多くへの1回の交換におけるメッセージ: なし
Message Syntax: See Section 4.3
メッセージ構文: セクション4.3を見てください。
Message Semantics: See Section 4.4
メッセージ意味論: セクション4.4を見てください。
Contact Information: See the "Authors' Addresses" section of this
memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
New & Rose Standards Track [Page 27] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[27ページ]RFC3195Reliable Delivery
7. The syslog DTD
7. syslog DTD
The following is the DTD defining the valid elements for the syslog over BEEP mapping.
↓これはBEEPマッピングの上のsyslogのために有効な要素を定義するDTDです。
<!--
DTD for syslog over BEEP, as of 2000-10-10
<!--2000年10月10日現在BEEPの上のsyslogのためのDTD
Refer to this DTD as:
このDTDを以下を参照してください。
<!ENTITY % SYSLOG PUBLIC "-//Blocks//DTD SYSLOGRELIABLE//EN" "">
%SYSLOG;
-->
<!実体%SYSLOG公共の「-//Blocks//DTD SYSLOGRELIABLE//アン」、「「>%SYSLOG」 -->。
<!--
Contents
<!--コンテンツ
Overview
概観
Includes
Profile Summaries
Entity Definitions
プロフィール概要実体定義を含んでいます。
Operations
iam
entry
path
-->
操作iamエントリー経路-->。
<!--
Overview
<!--概観
Syslog packets delivered via BEEP
BEEPを通して届けられたSyslogパケット
-->
-->。
<!-- Includes -->
<!--インクルード-->。
<!ENTITY % BEEP PUBLIC "-//Blocks//DTD BEEP//EN"
"">
%BEEP;
<!実体%が公共の「-//Blocks//DTDビープ音//アン」を鳴らす、「「>%は鳴ります」。
New & Rose Standards Track [Page 28] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[28ページ]RFC3195Reliable Delivery
<!--
Profile summaries
<!--プロフィール概要
BEEP profile SYSLOG-RAW
BEEPプロフィールSYSLOG-RAW
role MSG ANS ERR
==== === === ===
L text text text
役割のMSG ANS ERR==== === === === Lテキストテキストテキスト
BEEP profile SYSLOG-COOKED
BEEPプロフィールSYSLOG-COOKED
role MSG RPY ERR
==== === === ===
I or L iam ok error
I or L entry ok error
I or L path ok error
役割のMSG RPY ERR==== === === === 私、L iamの間違いない誤りI、LエントリーOK誤りIまたはL経路OK誤り
-->
-->。
<!--
Entity Definitions
<!--実体定義
entity syntax/reference example
====== ================ =======
a fully qualified domain name
FQDN See [RFC-1034] www.example.com
実体構文/参照の例====== ================ ======= 完全修飾ドメイン名FQDN See[RFC-1034]www.example.com
a dotted-quad IP address
IP 1*3DIGIT "." 1*3DIGIT "."
1*3DIGIT "." 1*3DIGIT
10.0.0.27
a syslog facility
FACILITY See [1]
1*3DIGIT 80
「点を打たされた回路IPアドレスIP1*3DIGIT」、」 「1*3DIGIT」、」 「1*3DIGIT」、」 1 syslog施設FACILITY See[1]1*3DIGIT80あたり*3DIGIT10.0.0.27
a syslog severity
SEVERITY See [1]
DIGIT 4
syslog厳しさSEVERITY See[1]DIGIT4
a timestamp See [1] Jan 03 18:43:12
TIMESTAMP
タイムスタンプSee[1]1月の03 18: 43:12TIMESTAMP
an identifying integer
IDINT 1*DIGIT 1027
特定整数IDINT1*DIGIT1027
-->
-->。
New & Rose Standards Track [Page 29] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[29ページ]RFC3195Reliable Delivery
<!ENTITY % FQDN "CDATA"> <!ENTITY % IP "CDATA"> <!ENTITY % FACILITY "CDATA"> <!ENTITY % SEVERITY "CDATA"> <!ENTITY % TIMESTAMP "CDATA"> <!ENTITY % IDINT "CDATA">
<!実体%FQDN、「CDATA、「><!実体%IP、「CDATA、「><!実体%施設、「CDATA、「><!実体%の厳しさ、「CDATA、「><!実体%タイムスタンプ、「CDATA「><!実体%IDINT」CDATA">"
<!--
The iam element declares the role and identity of the peer
issuing it. The contents of the element may include human-readable
informative text, such as the physical location of the computer
issuing the "iam".
<!--iam要素はそれを発行する同輩の役割とアイデンティティを宣言します。 要素のコンテンツは人間読み込み可能な有益なテキストを含むかもしれません、"iam"を発行するコンピュータの物理的な位置などのように。
-->
-->。
<!ELEMENT iam (#PCDATA)>
<!ATTLIST iam
fqdn %FQDN; #REQUIRED
ip %IP; #REQUIRED
type (device|relay|collector) #REQUIRED>
<!ELEMENT iam(#PCDATA)><!ATTLIST iam fqdn%FQDN。 #REQUIRED ip%IP。 #REQUIREDは(装置|リレー|コレクタ)#REQUIRED>をタイプします。
<!--
The entry element conveys a single syslog message.
-->
<!--エントリー要素はただ一つのsyslogメッセージを伝えます。 -->。
<!ELEMENT entry (#PCDATA)>
<!ATTLIST entry
xml:lang %LANG; "i-default"
facility %FACILITY; #REQUIRED
severity %SEVERITY; #REQUIRED
timestamp %TIMESTAMP; #IMPLIED
tag %ATEXT; #IMPLIED
deviceFQDN %FQDN; #IMPLIED
deviceIP %IP; #IMPLIED
pathID %IDINT; #IMPLIED>
<!ELEMENTエントリー(#PCDATA)><!ATTLISTエントリーxml: lang%ラング。 「i-デフォルト」施設%FACILITY。 #REQUIRED厳しさ%SEVERITY。 #REQUIREDタイムスタンプ%TIMESTAMP。 #IMPLIEDは%ATEXTにタグ付けをします。 #deviceFQDN%FQDNは含意しました。 #暗示しているdeviceIP%IP。 #pathID%IDINTは含意しました。 #暗示している>。
New & Rose Standards Track [Page 30] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[30ページ]RFC3195Reliable Delivery
<!--
The path element conveys a list of relays through which
entries have passed.
-->
<!--経路要素はエントリーが通り過ぎたリレーのリストを伝えます。 -->。
<!ELEMENT path (path?)>
<!ATTLIST path
pathID %IDINT; #REQUIRED
fromFQDN %FQDN; #IMPLIED
fromIP %IP; #REQUIRED
toFQDN %FQDN; #IMPLIED
toIP %IP; #REQUIRED
linkprops %ATEXT; #REQUIRED>
<!ELEMENT経路(経路?)><!ATTLIST経路pathID%IDINT。 #fromFQDN%FQDNが必要でした。 #暗示しているfromIP%IP。 #toFQDN%FQDNが必要でした。 #暗示しているtoIP%IP。 #REQUIRED linkprops%ATEXT。 #必要な>。
<!-- End of DTD -->
<!--DTDの終わり-->。
New & Rose Standards Track [Page 31] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[31ページ]RFC3195Reliable Delivery
8. Reply Codes
8. 回答コード
The following error codes are used in the protocol:
以下のエラーコードはプロトコルに使用されます:
code meaning ==== ======= 200 success
コード意味==== ======= 200 成功
421 service not available
利用可能でない421サービス
451 requested action aborted
(e.g., local error in processing)
451は、動作が中止になったよう要求しました。(例えば、処理における地方の誤り)
454 temporary authentication failure
454 一時的な認証失敗
500 general syntax error
(e.g., poorly-formed XML)
500の一般的な構文エラー(例えば、不十分に形成されたXML)
501 syntax error in parameters
(e.g., non-valid XML)
パラメタの501構文エラー(例えば、有効な非XML)
504 parameter not implemented
実行されなかった504パラメタ
530 authentication required
530 認証が必要です。
534 authentication mechanism insufficient
(e.g., too weak, sequence exhausted, etc.)
534認証機構不十分です。(例えば、弱過ぎて、系列疲れ果てているなど)
535 authentication failure
535 認証失敗
537 action not authorized for user
537 ユーザのために認可されなかった動作
538 authentication mechanism requires encryption
538 認証機構は暗号化を必要とします。
550 requested action not taken
(e.g., no requested profiles are acceptable)
550 取られなかった要求された行動(例えば、どんな要求されたプロフィールも許容できません)
553 parameter invalid
553パラメタ病人
554 transaction failed
(e.g., policy violation)
554 取引は失敗しました。(例えば、方針違反)
New & Rose Standards Track [Page 32] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[32ページ]RFC3195Reliable Delivery
9. IANA Considerations
9. IANA問題
9.1 Registration: BEEP Profiles
9.1登録: ビープ音プロフィール
The IANA registers the profiles specified in Section 6, and selects IANA-specific URIs "http://iana.org/beep/SYSLOG/RAW" and "http://iana.org/beep/SYSLOG/COOKED".
IANAはセクション6で指定されたプロフィールを登録して、IANA特有のURI" http://iana.org/beep/SYSLOG/RAW "と" http://iana.org/beep/SYSLOG/COOKED "を選択します。
9.2 Registration: The System (Well-Known) TCP port number for syslog-
conn
9.2登録: syslogコンのためのSystem(よく知っている)TCPポートナンバー
A single well-known port (601) is allocated to syslog-conn. In-band negotiation determines whether COOKED or RAW syslog-conn is in use.
ただ一つのウェルノウンポート(601)をsyslog-コンに割り当てます。 バンドにおける交渉は、COOKEDかRAW syslog-コンが使用中であるかどうか決定します。
Protocol Number: TCP
数について議定書の中で述べてください: TCP
Message Formats, Types, Opcodes, and Sequences: See Section 3.3 and
Section 4.4.
メッセージ・フォーマット、タイプ、Opcodes、および系列: セクション3.3とセクション4.4を見てください。
Functions: See Section 3.4 and Section 4.4.
機能: セクション3.4とセクション4.4を見てください。
Use of Broadcast/Multicast: none
放送/マルチキャストの使用: なし
Proposed Name: Reliable syslog service
提案された名前: 信頼できるsyslogサービス
Short name: syslog-conn
省略名: syslog-コン
Contact Information: See the "Authors' Addresses" section of this
memo
問い合わせ先: このメモの「作者のアドレス」セクションを見てください。
New & Rose Standards Track [Page 33] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[33ページ]RFC3195Reliable Delivery
10. Security Considerations
10. セキュリティ問題
Consult Section 6 of [1] for a discussion of security issues for the syslog service. In addition, since the RAW and COOKED profiles are defined using the BEEP framework, consult [3]'s Section 8 for a discussion of BEEP-specific security issues.
syslogサービスのために安全保障問題の議論のための[1]のセクション6に相談してください。 RAWとCOOKEDプロフィールが添加BEEP枠組みを使用することで定義されるので、相談してください。BEEP特有の安全保障問題の議論のための[3]によるセクション8です。
BEEP is used to provide communication security but not object integrity. In other words, the messages "on the wire" can be protected, but a compromised device may undetectably generate incorrect messages, and relays and collectors can modify, insert, or delete messages undetectably. Other techniques must be used to assure that such compromises are detectable.
BEEPは、物の保全ではなく、コミュニケーションセキュリティを提供するのに使用されます。 言い換えれば、「ワイヤ」というメッセージを保護できますが、妥協している装置が不正確なメッセージをundetectablyに発生させるかもしれなくて、リレーとコレクタは、メッセージundetectablyを変更するか、挿入するか、または削除できます。 そのような妥協が検出可能であることを保証するのに他のテクニックを使用しなければなりません。
11. Acknowledgements
11. 承認
The authors gratefully acknowledge the contributions of Christopher Calabrese, Keith McCloghrie, Balazs Scheidler, and David Waitzman.
作者は感謝してクリストファー・カラブレーゼ、キースMcCloghrie、バラージュScheidler、およびデヴィッドWaitzmanの貢献を承諾します。
12. References
12. 参照
[1] Lonvick, C., "The BSD Syslog Protocol", RFC 3164, August 2001.
[1]Lonvick、2001年8月のC.、「BSD Syslogプロトコル」RFC3164。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[3] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
[4] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, March
2001.
[4] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[5]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[7]、BCP47、RFC3066、2001年1月。
[8] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
Mechanism", RFC 2831, May 2000.
[8] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。
New & Rose Standards Track [Page 34] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[34ページ]RFC3195Reliable Delivery
Authors' Addresses
作者のアドレス
Darren New 5390 Caminito Exquisito San Diego, CA 92130 US
ダーレン・新しい5390Caminito Exquisitoカリフォルニア92130サンディエゴ(米国)
Phone: +1 858 350 9733 EMail: dnew@san.rr.com
以下に電話をしてください。 +1 9733年の858 350メール: dnew@san.rr.com
Marshall T. Rose Dover Beach Consulting, Inc. POB 255268 Sacramento, CA 95865-5268 US
Inc.POB255268サクラメント、カリフォルニア95865-5268米国に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 916 483 8878 EMail: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 8878年の916 483メール: mrose@dbc.mtview.ca.us
New & Rose Standards Track [Page 35] RFC 3195 Reliable Delivery for syslog November 2001
syslog2001年11月のための新しい、そして、ローズStandards Track[35ページ]RFC3195Reliable Delivery
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
New & Rose Standards Track [Page 36]
新しい、そして、ローズ標準化過程[36ページ]
一覧
スポンサーリンク
