RFC4744 日本語訳

Network Working Group                                            E. Lear
Request for Comments: 4744                                 Cisco Systems
Category: Standards Track                                     K. Crozier
                                                           December 2006

コメントを求めるワーキンググループE.リア要求をネットワークでつないでください: 4744年のシスコシステムズカテゴリ: 標準化過程K.牧杖2006年12月

                    Using the NETCONF Protocol over
             the Blocks Extensible Exchange Protocol (BEEP)

NETCONFを使用して、広げることができる交換プロトコルについてブロックの上議定書の中で述べてください。(ビープ音)

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(2006)。

Abstract

要約

   This document specifies an application protocol mapping for the
   Network Configuration Protocol (NETCONF) over the Blocks Extensible
   Exchange Protocol (BEEP).

このドキュメントはNetwork Configurationのために、Blocks Extensible Exchangeプロトコル(BEEP)の上でプロトコル(NETCONF)を写像するアプリケーション・プロトコルを指定します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. Why BEEP? ..................................................2
   2. BEEP Transport Mapping ..........................................2
      2.1. NETCONF Session Establishment ..............................2
      2.2. Starting a Channel for NETCONF .............................4
      2.3. NETCONF Session Usage ......................................5
      2.4. NETCONF Session Teardown ...................................5
      2.5. BEEP Profile for NETCONF ...................................6
   3. Security Considerations .........................................6
   4. IANA Considerations .............................................7
   5. Acknowledgments .................................................7
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8

1. 序論…2 1.1. なぜ鳴りますか? ..................................................2 2. 輸送マッピングを鳴らしてください…2 2.1. NETCONFセッション設立…2 2.2. NETCONFのためにチャンネルを始動します…4 2.3. NETCONFセッション用法…5 2.4. NETCONFセッション分解…5 2.5. NETCONFのためのプロフィールを鳴らしてください…6 3. セキュリティ問題…6 4. IANA問題…7 5. 承認…7 6. 参照…8 6.1. 標準の参照…8 6.2. 有益な参照…8

Lear & Crozier              Standards Track                     [Page 1]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[1ページ]。

1.  Introduction

1. 序論

   The NETCONF protocol [1] defines a simple mechanism through which a
   network device can be managed.  NETCONF is designed to be usable over
   a variety of application protocols.  This document specifies an
   application protocol mapping for NETCONF over the Blocks Extensible
   Exchange Protocol (BEEP) [7].

NETCONFプロトコル[1]はネットワークデバイスに対処できる簡単なメカニズムを定義します。 NETCONFは、さまざまなアプリケーション・プロトコルの上で使用可能になるように設計されています。 このドキュメントはBlocks Extensible Exchangeプロトコル(BEEP)[7]の上でNETCONFのためのアプリケーション・プロトコルマッピングを指定します。

   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]で説明されるように本書では解釈されることであるべきですか?

1.1.  Why BEEP?

1.1. なぜ鳴りますか?

   Use of BEEP is natural as an application protocol for transport of
   XML.  As a peer-to-peer protocol, BEEP provides an easy way to
   implement NETCONF, no matter which side of the connection was the
   initiator.  This "bidirectionality" allows for either manager or
   agent to initiate a connection.  This is particularly important to
   support large numbers of intermittently connected devices, as well as
   those devices that must reverse the management connection in the face
   of firewalls and network address translators (NATs).

BEEPの使用はXMLの輸送のためのアプリケーション・プロトコルとして当然です。 ピアツーピアプロトコルとして、BEEPはNETCONFを実装する簡単な方法を提供します、接続のどの側面が創始者であったかとしても。 この「双方向性」は、マネージャかエージェントのどちらかが接続を開始するのを許容します。 これは多くの断続的に接続されたデバイスを支えるために特に重要です、ファイアウォールとネットワークアドレス変換機構(NATs)に直面して管理接続を逆にしなければならないそれらのデバイスと同様に。

   BEEP makes use of the Simple Authentication and Security Layer (SASL)
   [3].  The SASL profile used by BEEP allows for a simple and direct
   mapping to the existing security model for command line interface
   (CLI), while Transport Layer Security (TLS) [4] provides a strong,
   well-tested encryption mechanism with either server or server and
   client-side authentication.

BEEPはSimple AuthenticationとSecurity Layer(SASL)[3]を利用します。 BEEPによって使用されたSASLプロフィールは既存の機密保護モデルにとってコマンドラインインタフェース(CLI)に簡単でダイレクトなマッピングを考慮します、Transport Layer Security(TLS)[4]はサーバかサーバのどちらかとクライアントサイド認証に強くて、よくテストされた暗号化メカニズムを提供しますが。

2.  BEEP Transport Mapping

2. ビープ音輸送マッピング

   All NETCONF over BEEP implementations MUST implement the profile and
   functional mapping between NETCONF and BEEP as described below.

BEEP実装の上のすべてのNETCONFが以下で説明されるようにNETCONFとBEEPの間のプロフィールと機能的マッピングを実装しなければなりません。

   For purposes of this document, a manager is a NETCONF client, and an
   agent is a NETCONF server.  Use of client/server language in BEEP is
   avoided because of the common notion that in networking clients
   connect to servers.

このドキュメントの目的のために、マネージャはNETCONFクライアントです、そして、エージェントはNETCONFサーバです。BEEPにおけるクライアント/サーバ言語の使用はネットワークでは、クライアントがサーバに接続するという一般的な概念で避けられます。

2.1.  NETCONF Session Establishment

2.1. NETCONFセッション設立

   Managers may be either BEEP listeners or initiators.  Similarly,
   agents may be either listeners or initiators.  To establish a
   connection, the initiator connects to the listener on TCP port 831.
   Thus, the initial exchange takes place without regard to whether a
   manager or the agent is the initiator.  After the transport
   connection is established, as greetings are exchanged, they SHOULD

マネージャは、BEEPリスナーか創始者のどちらかであるかもしれません。 同様に、エージェントは、リスナーか創始者のどちらかであるかもしれません。 取引関係を築くために、創始者はTCPポート831の上のリスナーに接します。 したがって、初期の交換は関係なしでマネージャかエージェントが創始者であるかどうかに起こります。 輸送の後に、挨拶を交換するとき、接続を確立して、それらはSHOULDです。

Lear & Crozier              Standards Track                     [Page 2]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[2ページ]。

   each announce their support for TLS and optionally SASL.  Once BEEP
   greeting messages are exchanged, if TLS is to be used and available
   by both parties, the listener STARTs a channel with the TLS profile.

それぞれが任意に彼らのTLSのサポートを発表します。SASL。 TLSが双方で中古であって、利用可能であるつもりであるなら、かつて、BEEPあいさつメッセージを交換して、リスナーSTARTsはTLSプロフィールがあるチャンネルです。

   Once TLS has been started, a new BEEP greeting message is sent by
   both initiator and listener, as required by the BEEP RFC.

TLSがいったん始動されると、新しいBEEPあいさつメッセージは必要に応じて創始者とリスナーの両方によってBEEP RFCによって送られます。

   After all BEEP greeting messages are exchanged in order for roles to
   be clear, the agent MUST advertise the NETCONF profile.  The manager
   MUST NOT advertise the NETCONF profile.  If the agent side of the
   communication (either initiator or listener) receives a BEEP
   <greeting> element that contains the NETCONF profile, it MUST close
   the connection.  Similarly, if neither side issues a NETCONF profile
   it is equally an error, and the listener MUST close the connection.

役割が明確であるようにすべてのBEEPあいさつメッセージを交換した後に、エージェントはNETCONFプロフィールの広告を出さなければなりません。 マネージャはNETCONFプロフィールの広告を出してはいけません。 コミュニケーション(創始者かリスナーのどちらか)のエージェント側がNETCONFプロフィールを含むBEEP<挨拶>要素を受け取るなら、それは接続を終えなければなりません。 同様に、等しく、誤り、およびリスナーはどちらの副次的な問題a NETCONFプロフィールであるなら終えなければなりません。接続を終えてください。

   At this point, if SASL is desired, the initiator starts a BEEP
   channel to perform a SASL exchange to authenticate itself.  Upon
   completion of authentication the channel is closed.  That is, the
   channel is exclusively used to authenticate.

ここに、SASLが望まれているなら、創始者は、それ自体を認証するためにSASL交換を実行するためにBEEPチャンネルを始動します。 認証の完成のときに、チャンネルは閉じられます。 すなわち、チャンネルは認証するのにおいて排他的に使用されています。

   Examples of both TLS and SASL profiles can be found in [7].

[7]でTLSとSASLプロフィールの両方に関する例を見つけることができます。

   It is anticipated that the SASL PLAIN mechanism will be heavily used
   in conjunction with TLS [5].  In such cases, in accordance with RFC
   2595 the PLAIN mechanism MUST NOT be advertised in the first BEEP
   <greeting>, but only in the one following a successful TLS
   negotiation.  This applies only if TLS and SASL PLAIN mechanisms are
   both to be used.  To avoid risk of eavesdropping, the SASL PLAIN
   mechanism MUST NOT be used over unencrypted channels.  More specifics
   about the use of SASL and TLS are mentioned in Security
   Considerations below.

SASL PLAINメカニズムが大いにTLS[5]に関連して使用されると予期されます。 そのような場合、RFC2595によると、うまくいっているTLS交渉に続いて、ものだけでPLAINメカニズムの広告を出してはいけません。 これはTLSである場合にだけ適用されます、そして、SASL PLAINメカニズムはともに使用されることです。 盗聴の危険を避けるために、非暗号化されたチャンネルの上にSASL PLAINメカニズムを使用してはいけません。 SASLとTLSの使用に関する、より多くの詳細が以下のSecurity Considerationsで言及されます。

   Once authentication has occurred, there is no need to distinguish
   between initiator and listener.  We now distinguish between manager
   and agent, and it is assumed that each knows its role in the
   conversation.

認証がいったん起こると、創始者とリスナーを見分ける必要は全くありません。 私たちは現在マネージャとエージェントを見分けます、そして、それぞれが会話における役割を知っていると思われます。

Lear & Crozier              Standards Track                     [Page 3]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[3ページ]。

2.2.  Starting a Channel for NETCONF

2.2. NETCONFのためにチャンネルを始動します。

   The manager now establishes a new channel and specifies the single
   NETCONF profile.  For example:

マネージャは、現在、新しいチャンネルを確立して、単一のNETCONFプロフィールを指定します。 例えば:

         (M = Manager; A = Agent)

(Mはマネージャと等しいです; =エージェント)

         M: MSG 0 1 . 10 48 118
         M: Content-type: application/beep+xml
         M:
         M: <start number="1">
         M:   <profile uri="http://iana.org/beep/netconf" />
         M: </start>
         M: END
         A: RPY 0 1 . 38 87
         A: Content-Type: application/beep+xml
         A:
         A: <profile uri="http://iana.org/beep/netconf" />
         A: END

M: エムエスジー0 1.10 48118M: 文書内容: アプリケーション/ビープ音+xml M: M: <スタート番号が等しい、「1インチの>M:」 <プロフィールuriは" http://iana.org/beep/netconf "/>Mと等しいです: </スタート>M: 終わりA: RPY0 1.38 87、A: コンテントタイプ: アプリケーション/ビープ音+xml A: A: <プロフィールuriは" http://iana.org/beep/netconf "/>A:と等しいです。 終わり

   At this point, we are ready to proceed on BEEP channel 1 with NETCONF
   operations.

ここに、私たちはBEEPチャンネル1の上にNETCONF操作で続く準備ができています。

   NETCONF messages are transmitted with a Content-type header set to
   "text/xml".

NETCONFメッセージは文書内容ヘッダーセットで「テキスト/xml」に送られます。

   Next the manager and the agent exchange NETCONF <hello> elements on
   the new channel so that each side learns the other's capabilities.
   This occurs through a MSG.  Each side will then respond positively.
   The following example is adapted from [1] Section 8.1:

次に、マネージャとエージェントはNETCONF<を交換します。こんにちは、新しさの要素がチャネルを開設する>によって、それぞれの側はもう片方の能力を学びます。 これはMSGを通して起こります。 そして、それぞれの側は明確に応じるでしょう。 以下の例は[1] セクション8.1から適合させられます:

       A: MSG 1 0 . 0 457
       A: Content-type: application/beep+xml
       A:
       A: <?xml version='1.0' encoding="UTF-8"?>
       A: <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       A:   <capabilities>
       A:     <capability>
       A:       urn:ietf:params:netconf:base:1.0
       A:     </capability>
       A:     <capability>
       A:       urn:ietf:params:netconf:capability:startup:1.0
       A:     </capability>
       A:     <capability>
       A:       http://example.net/router/2.3/core#myfeature
       A:     </capability>
       A:   </capabilities>

A: エムエスジー1 0.0457、A: 文書内容: アプリケーション/ビープ音+xml A: A: <?xmlバージョン= '1.0'=をコード化することでの「UTF-8インチ?」>A: <、こんにちは、xmlns=「つぼ:ietf:params: xml:ナノ秒:netconf:ベース:1インチの>A:」 <能力>A: <能力>A: つぼ:ietf:params:netconf:ベース: 1.0 A: </能力>A: <能力>A: つぼ:ietf:params:netconf:能力:始動:1.0、A: </能力>A: <能力>A: http://example.net/router/2.3/core#myfeature A: </能力>A: </能力>。

Lear & Crozier              Standards Track                     [Page 4]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[4ページ]。

       A:   <session-id>4</session-id>
       A: </hello>
       A: END

A: <セッションイド>4</セッション-イド>A: こんにちは、</>A: 終わり

       M: RPY 1 0 . 0 0
       M: END

M: RPY1 0.0 0M: 終わり

   Future NETCONF capabilities may require additional BEEP channels.
   When such capabilities are defined, a BEEP mapping must be defined as
   well.

将来のNETCONF能力は追加BEEPチャンネルを必要とするかもしれません。 そのような能力が定義されるとき、また、BEEPマッピングを定義しなければなりません。

   At this point, the NETCONF session is established, and capabilities
   have been exchanged.

ここに、NETCONFセッションを確立します、そして、能力を交換しました。

2.3.  NETCONF Session Usage

2.3. NETCONFセッション用法

   Nearly all NETCONF operations are executed through the <rpc> element.
   To issue a remote procedure call (RPC), the manager transmits on the
   operational channel a BEEP MSG containing the RPC and its arguments.
   In accordance with the BEEP standard, RPC requests may be split
   across multiple BEEP frames.

ほとんどすべてのNETCONF操作が<rpc>要素を通して実行されます。 遠隔手続き呼び出し(RPC)を発行するために、マネージャは操作上のチャンネルでRPCとその議論を含むBEEP MSGを伝えます。 BEEP規格によると、RPC要求は複数のBEEPフレームの向こう側に分けられるかもしれません。

   Once received and processed, the agent responds with BEEP RPY
   messages on the same channel with the response to the RPC.  In
   accordance with the BEEP standard, responses may be split across
   multiple BEEP frames.

いったん受け取られて、処理されると、エージェントはRPCへの応答がある同じチャンネルに関するBEEP RPYメッセージで応じます。 BEEP規格によると、応答は複数のBEEPフレームの向こう側に分けられるかもしれません。

2.4.  NETCONF Session Teardown

2.4. NETCONFセッション分解

   Upon receipt of <close-session> from the manager, once the agent has
   completed all RPCs, it will close BEEP channel 0.  When an agent
   needs to initiate a close, it will do so by closing BEEP channel 0.
   Although not required to do so, the agent should allow for a
   reasonable period for a manager to release an existing lock prior to
   initiating a close.  Once the agent has closed channel 0, all locks
   are released, and each side follows teardown procedures as specified
   in [8].  Having received a BEEP close or having sent <close-session>,
   a manager MUST NOT send further requests.  If there are additional
   activities due to expanded capabilities, they MUST cease in an
   orderly manner and should be properly described in the capability
   mapping.

マネージャからの<の厳密なセッションの>を受け取り次第、エージェントがいったんすべてのRPCsを完成すると、それはBEEPチャンネル0を閉じるでしょう。 エージェントが、閉鎖を開始する必要があると、それは、BEEPチャンネル0を閉じることによって、そうするでしょう。 そうするのが必要ではありませんが、閉鎖を開始する前にマネージャが既存の錠をリリースするように、エージェントは相当期間を考慮するべきです。 エージェントがいったんチャンネル0を閉じると、すべての錠がリリースされます、そして、それぞれの側は[8]の指定されるとしての分解手順に従います。 近くでBEEPを受けたか、または<の厳密なセッションの>を送ったので、マネージャはさらなる要求を送ってはいけません。 拡張能力による追加活動があれば、それらは、整然とやまなければならなくて、能力マッピングで適切に説明されるべきです。

Lear & Crozier              Standards Track                     [Page 5]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[5ページ]。

2.5.  BEEP Profile for NETCONF

2.5. NETCONFのためのビープ音プロフィール

   Profile Identification: http://iana.org/beep/netconf

識別の輪郭を描いてください: http://iana.org/beep/netconf

   Messages exchanged during Channel Creation: not applicable

メッセージはChannel Creationの間、交換しました: 適切でない

   Messages starting one-to-one exchanges: "hello", "rpc", "rpc-reply"

始めが1〜1に以下を交換するというメッセージ 「こんにちは」、"rpc"、「rpc回答」

   Messages in positive replies: "rpc-reply"

積極的な返事におけるメッセージ: 「rpc-回答」

   Messages in negative replies: "rpc-reply"

否定的な返事におけるメッセージ: 「rpc-回答」

   Messages in one-to-many exchanges: none

多くへの1回の交換におけるメッセージ: なし

   Message syntax: [1]

メッセージ構文: [1]

   Message semantics: [1]

メッセージ意味論: [1]

   Contact Information: See the "Author's Address" section of this memo.

問い合わせ先: このメモの「作者のアドレス」セクションを見てください。

3.  Security Considerations

3. セキュリティ問題

   Configuration information is by its very nature sensitive.  Its
   transmission in the clear and without integrity checking leaves
   devices open to classic so-called "person-in-the-middle" attacks.
   Configuration information often times contains passwords, user names,
   service descriptions, and topological information, all of which are
   sensitive.  A NETCONF application protocol, therefore, must minimally
   support options for both confidentiality and authentication.

設定情報はまさにその本質から機密です。 明確と保全の照合のないトランスミッションはデバイスを古典的ないわゆる「中央の人」攻撃に開かれているままにします。 しばしば回がパスワード、ユーザ名、サービス記述、および位相的な情報を含んでいるという設定情報。そのすべてが敏感です。 したがって、NETCONFアプリケーション・プロトコルは秘密性と認証の両方のためのオプションを最少量でサポートしなければなりません。

   The BEEP mapping described in this document addresses both
   confidentiality and authentication in a flexible manner through the
   use of TLS and SASL profiles.  Confidentiality is provided via the
   TLS profile and is used as discussed above.  In addition, the server
   certificate shall serve as the server's authentication to the client.
   The client MUST be prepared to recognize and validate a server
   certificate and SHOULD by default reject invalid certificates.

本書では説明されたBEEPマッピングはTLSとSASLプロフィールの使用を通してフレキシブルな態度で秘密性と認証の両方を扱います。 秘密性は、TLSプロフィールを通して提供されて、上で議論するように使用されています。 さらに、サーバ証明書はサーバの認証としてクライアントにサービスされるものとします。 クライアントは、サーバ証明書を認識して、有効にする用意ができていなければなりません、そして、SHOULDはデフォルトで無効の証明書を拒絶します。

   In order to validate a certificate, the client must be able to access
   a trust anchor.  While such validation methods are beyond the scope
   of this document, they will depend on the type of device and
   circumstance.  Both the implementor and the administrator are
   cautioned to be aware of any circular dependencies that various
   methods may introduce.  For instance, Online Certificate Status
   Protocol (OCSP) servers may not be available in a network cold-start
   scenario and would be ill-advised for core routers to depend on to
   receive configuration at boot.

証明書を有効にするために、クライアントは信頼アンカーにアクセスできなければなりません。 そのような合法化メソッドがこのドキュメントの範囲を超えている間、それらはデバイスと状況のタイプに頼るでしょう。 作成者と管理者の両方が様々なメソッドが導入するどんな円形の依存も意識していると警告されます。 例えば、Online Certificate Statusプロトコル(OCSP)サーバは、ネットワークコールドスタートシナリオで利用可能でないかもしれなく、構成を受けるためによるコアルータに、ブーツであさはかでしょう。

Lear & Crozier              Standards Track                     [Page 6]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[6ページ]。

   For client-side authentication, there are several options.  The
   client MAY provide a certificate during the initiation phase of TLS,
   in which case the subject of that certificate shall be considered
   principle for authentication purposes.  Once again, server
   implementors should be aware of any interdependencies that could be
   created through protocols used to validate trust anchors.

クライアントサイド認証のために、いくつかのオプションがあります。 クライアントはTLSの起因過程の間、証明書を前提とするかもしれません、その場合、その証明書の対象は認証目的のための原則であると考えられるものとします。 もう一度、サーバ作成者は信頼アンカーを有効にするのに使用されるプロトコルを通して作成できたどんな相互依存性も意識しているべきです。

   TLS endpoints may be authorized based on subject name or certificate
   authority (CA), depending on circumstances.  For instance, it would
   be unwise for a core Internet router to allow a netconf agent
   connection simply based on a valid certificate signed by a common CA,
   but not unreasonable to allow a connection from an agent with a
   particular distinguished name.  On the other hand, it might be
   desirable for enterprises to trust certificates signed by CAs of
   their network operations team.

事情によって、TLS終点は対象の名前か認証局(カリフォルニア)に基づいて認可されるかもしれません。 例えば、コアインターネットルータが単に一般的なカリフォルニアによって署名された有効な証明書に基づくnetconfエージェント接続を許すように賢明でないのですが、特定の分類名でエージェントから接続を許すのは、無理でないでしょう。 他方では、企業が彼らのネットワーク操作チームのCAsによって署名された証明書を信じるのは、望ましいかもしれません。

   In the case where the client has not authenticated through TLS, the
   server SHOULD advertise one or more SASL profiles, from which the
   client will choose.  In the singular case where TLS is established,
   the minimum profile MAY be PLAIN.  Otherwise, implementations MUST
   support the DIGEST-MD5 profile as described in [6], and they MAY
   support other profiles such as the One-Time Password (OTP) mechanism
   [10].

クライアントがTLS、サーバを通してSHOULDを認証していない場合では、1個以上のSASLプロフィールの広告を出してください。(クライアントはプロフィールから選ぶでしょう)。 TLSが設立されるまれな場合では、最小のプロフィールはPLAINであるかもしれません。 さもなければ、実装は[6]で説明されるようにDIGEST-MD5プロフィールを支えなければなりません、そして、それらはOne-時間Password(OTP)メカニズム[10]などの他のプロフィールを支えるかもしれません。

   Different environments may well allow different rights prior to and
   then after authentication.  An authorization model is not specified
   in this document.  When an operation is not properly authorized, then
   a simple rpc-error containing "permission denied" is sufficient.
   Note that authorization information may be exchanged in the form of
   configuration information, which is all the more reason to ensure the
   security of the connection.

異なった環境は認証の前とそして、認証の後にたぶん異なった権利を許容するでしょう。 承認モデルは本書では指定されません。 操作が適切に認可されないと、「否定された許可」を含む簡単なrpc-誤りは十分です。 承認情報が接続のセキュリティを確実にするすべての、より多くの理由である設定情報の形で交換されるかもしれないことに注意してください。

4.  IANA Considerations

4. IANA問題

   IANA assigned TCP port (831) for NETCONF over BEEP.

IANAはNETCONFのためのTCPポート(831)をBEEPの上に割り当てました。

5.  Acknowledgments

5. 承認

   This work is the product of the NETCONF IETF working group, and many
   people have contributed to the NETCONF discussion.  Most notably, Rob
   Ens, Phil Schafer, Andy Bierman, Wes Hardiger, Ted Goddard, and
   Margaret Wasserman all contributed in some fashion to this work,
   which was originally to be found in the NETCONF base protocol
   specification.  Thanks also to Weijing Chen, Keith Allen, Juergen
   Schoenwaelder, Marshall Rose, and Eamon O'Tuathail for their very
   constructive participation.  The authors would also like to thank
   Elwyn Davies for his constructive review.

この仕事はNETCONF IETFワーキンググループの製品です、そして、多くの人々がNETCONF議論に貢献しました。 最も著しく、ロブEns、フィル・シェッフル、アンディBierman、ウェスHardiger、テッド・ゴダード、およびマーガレット・ワッサーマンは元々NETCONFベースプロトコル仕様で見つけられることであったこの仕事への何らかのファッションですべて貢献しました。 また、彼らの非常に建設的な参加をWeijingチェン、キース・アレン、ユルゲンSchoenwaelder、マーシャル・ローズ、およびEamon O'Tuathailをありがとうございます。 また、作者は彼の建設的なレビューについてElwynデイヴィースに感謝したがっています。

Lear & Crozier              Standards Track                     [Page 7]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[7ページ]。

6.  References

6. 参照

6.1.  Normative References

6.1. 引用規格

   [1]  Enns, R., Ed., "NETCONF Configuration Protocol", RFC 4741,
        December 2006.

[1] エンス、R.、エド、「NETCONF構成プロトコル」、RFC4741、12月2006日

   [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]  Melnikov, A. and K. Zeilenga, "Simple Authentication and
        Security Layer (SASL)", RFC 4422, June 2006.

[3] メリニコフとA.とK.Zeilenga、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、2006年6月。

   [4]  Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
        Protocol Version 1.1", RFC 4346, April 2006.

[4] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [5]  Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595,
        June 1999.

[5] ニューマン、C.、「IMAP、POP3、およびACAPとTLSを使用します」、RFC2595、1999年6月。

   [6]  Leach, P. and C. Newman, "Using Digest Authentication as a SASL
        Mechanism", RFC 2831, May 2000.

[6] リーチ、P.、およびC.ニューマン(「SASLメカニズムとしてダイジェスト認証を使用します」、RFC2831)は2000がそうするかもしれません。

   [7]  Rose, M., "The Blocks Extensible Exchange Protocol Core",
        RFC 3080, March 2001.

[7] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。

   [8]  Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081,
        March 2001.

[8] M. ローズ、RFC3081、「TCPへのビープ音コアを写像すること」での3月2001日

6.2.  Informative References

6.2. 有益な参照

   [9]   Sperberg-McQueen, C., Paoli, J., Maler, E., and T. Bray,
         "Extensible Markup Language (XML) 1.0 (Second Edition)", World
         Wide Web Consortium, First Edition,
         http://www.w3.org/TR/2000/REC-xml-20001006, October 2000.

[9] Sperberg-マックィーン、C.、パオリ、J.、Maler、E.、およびT.は、「拡張マークアップ言語(XML)1.0(第2版)」をいななかせます、ワールドワイドウェブコンソーシアム、最初の版、 http://www.w3.org/TR/2000/REC-xml-20001006 、2000年10月。

   [10]  Newman, C., "The One-Time-Password SASL Mechanism", RFC 2444,
         October 1998.

[10] ニューマン、C.、「1つの時間パスワードSASLメカニズム」、RFC2444、1998年10月。

Lear & Crozier              Standards Track                     [Page 8]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[8ページ]。

Authors' Addresses

作者のアドレス

   Eliot Lear
   Cisco Systems
   Glatt-com
   CH-8301 Glattzentrum, Zurich
   CH

エリオットリアシスコシステムズグラット-com CH-8301 Glattzentrum、チューリッヒCH

   EMail: lear@cisco.com

メール: lear@cisco.com

   Ken Crozier

ケンCrozier

   EMail: ken.crozier@gmail.com

メール: ken.crozier@gmail.com

Lear & Crozier              Standards Track                     [Page 9]

RFC 4744                   NETCONF over BEEP               December 2006

リアと牧杖規格は2006年12月にビープ音の上でRFC4744NETCONFを追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2006).

IETFが信じる著作権(C)(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST,
   AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、IETF信頼、「そのままで」という基礎と貢献者の上で提供していて、そして、インターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Lear & Crozier              Standards Track                    [Page 10]

リアと牧杖標準化過程[10ページ]