RFC4682 日本語訳
4682 Multimedia Terminal Adapter (MTA) Management Information Base forPacketCable- and IPCablecom-Compliant Devices. E. Nechamkin, J-F.Mule. December 2006. (Format: TXT=137373 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Nechamkin
Request for Comments: 4682 Broadcom Corp.
Category: Standards Track J-F. Mule
CableLabs
December 2006
Nechamkinがコメントのために要求するワーキンググループE.をネットワークでつないでください: 4682年のBroadcom社のカテゴリ: 規格はJ-Fを追跡します。 ラバCableLabs2006年12月
Multimedia Terminal Adapter (MTA) Management Information Base
for PacketCable- and IPCablecom-Compliant Devices
PacketCableとIPCablecom対応することのデバイスのためのマルチメディア端末アダプター(MTA)管理情報ベース
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 memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines a basic set of managed objects for Simple Network Management Protocol (SNMP)-based management of PacketCable- and IPCablecom-compliant Multimedia Terminal Adapter devices.
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それはPacketCableとIPCablecom対応することのMultimediaティーエーデバイスのSimple Network Managementのプロトコルの(SNMP)を拠点とする管理のために基本的なセットの管理オブジェクトを定義します。
Table of Contents
目次
1. The Internet-Standard Management Framework ......................2
2. Terminology .....................................................2
3. Introduction ....................................................4
3.1. Structure of the MTA MIB ...................................5
3.2. pktcMtaDevBase .............................................5
3.3. pktcMtaDevServer ...........................................6
3.4. pktcMtaDevSecurity .........................................6
3.5. Relationship between MIB Objects in the MTA MIB ............7
3.6. Secure Software Download ...................................8
3.7. X.509 Certificates Dependencies ............................8
4. Definitions .....................................................9
5. Acknowledgements ...............................................52
6. Security Considerations ........................................52
7. IANA Considerations ............................................55
8. Normative References ...........................................55
9. Informative References .........................................57
1. インターネット標準の管理フレームワーク…2 2. 用語…2 3. 序論…4 3.1. MTA MIBの構造…5 3.2pktcMtaDevBase…5 3.3pktcMtaDevServer…6 3.4pktcMtaDevSecurity…6 3.5. MTA MIBのMIBオブジェクトの間の関係…7 3.6. ソフトウェアがダウンロードであると機密保護してください…8 3.7. X.509証明書の依存…8 4. 定義…9 5. 承認…52 6. セキュリティ問題…52 7. IANA問題…55 8. 標準の参照…55 9. 有益な参照…57
Nechamkin & Mule Standards Track [Page 1] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[1ページ]。
1. The Internet-Standard Management Framework
1. インターネット標準の管理フレームワーク
For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410].
現在のインターネット標準のManagement Frameworkについて説明するドキュメントの詳細な概要について、RFC3410[RFC3410]のセクション7を参照してください。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 一般に、MIBオブジェクトはSimple Network Managementプロトコル(SNMP)を通してアクセスされます。 MIBのオブジェクトは、Management情報(SMI)のStructureで定義されたメカニズムを使用することで定義されます。 このメモはSTD58とRFC2578[RFC2578]とSTD58とRFC2579[RFC2579]とSTD58RFC2580[RFC2580]で説明されるSMIv2に対応であるMIBモジュールを指定します。
2. Terminology
2. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL", when used in the guidelines in this memo, are to be interpreted as described in RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTはこのメモによるガイドラインで使用されるとRFC2119[RFC2119]で説明されるように解釈されることであるべきですか?
The terms "MIB module" and "information module" are used interchangeably in this memo. As used here, both terms refer to any of the three types of information modules defined in Section 3 of RFC 2578 [RFC2578].
用語「MIBモジュール」と「情報モジュール」はこのメモで互換性を持って使用されます。 ここで同じくらい使用されていて、両方の用語はRFC2578[RFC2578]のセクション3で定義された3つのタイプの情報モジュールのいずれにも言及します。
Some of the terms used in this memo are defined below. Some additional terms are also defined in the PacketCable MTA Device Provisioning Specification [PKT-SP-PROV] and the PacketCable Security Specification [PKT-SP-SEC].
このメモで使用される用語のいくつかが以下で定義されます。 また、いくつかの追加用語がPacketCable MTA Device Provisioning Specification[PKT-SP-PROV]とPacketCable Security Specification[PKT-SP-SEC]で定義されます。
DOCSIS The CableLabs(R) Certified(TM) Cable Modem project, also known as DOCSIS(R) (Data over Cable Service Interface Specification), defines interface requirements for cable modems involved in high-speed data distribution over cable television system networks. DOCSIS also refers to the ITU-T J.112 recommendation, Annex B, for cable modem systems [ITU-T-J112].
公認された(TM)ケーブルModemが映し出すまた、DOCSIS(R)(Cable Service Interface Specificationの上のデータ)として知られているDOCSISのCableLabs(R)はケーブルテレビ体系網の上の高速データ分配にかかわるケーブルモデムのためのインターフェース要件を定義します。 また、DOCSISはケーブルモデムシステム[ITU-T-J112]についてITU-T J.112推薦、Annex Bについて言及します。
Cable Modem A Cable Modem (CM) acts as a data transport agent used to transfer call management and voice data packets over a DOCSIS-compliant cable system.
データ伝送エージェントが以前はよく移す予定であったとき、ケーブルModem A Cable Modem(CM)条例は、DOCSIS対応することのケーブルシステムの上に管理と声をデータ・パケットと呼びます。
Multimedia Terminal Adapter A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom- compliant device providing telephony services over a cable or hybrid
マルチメディアティーエーA Multimediaティーエー(MTA)はケーブルかハイブリッドの上に電話サービスを供給するPacketCableかIPCablecom対応することのデバイスです。
Nechamkin & Mule Standards Track [Page 2] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[2ページ]。
system used to deliver video signals to a community. It contains an interface to endpoints, a network interface, CODECs, and all signaling and encapsulation functions required for Voice over IP transport, call signaling, and Quality of Service signaling. An MTA can be an embedded or a standalone device. An Embedded MTA (E-MTA) is an MTA device containing an embedded DOCSIS Cable Modem. A Standalone MTA (S-MTA) is an MTA device separated from the DOCSIS cable modem by non-DOCSIS Message Access Control (MAC) interface (e.g., Ethernet, USB).
システムは以前はよくビデオ信号を共同体に提供していました。 シグナリング、およびServiceシグナリングのQualityは、それは終点にインタフェースを含んでいます、とネットワーク・インターフェース、CODECs、すべてのシグナリング、およびカプセル化機能がボイス・オーバー IP輸送のために必要としたと呼びます。 MTAは埋め込まれるかaスタンドアロンデバイスであるかもしれません。 Embedded MTA(E- MTA)は埋め込まれたDOCSIS Cable Modemを含むMTAデバイスです。 Standalone MTA(S-MTA)は非DOCSIS Message Access Control(MAC)インタフェース(例えば、イーサネット、USB)によってDOCSISケーブルモデムと切り離されたMTAデバイスです。
Endpoint An endpoint or MTA endpoint is a standard RJ-11 telephony physical port located on the MTA and used for attaching the telephone device to the MTA.
終点An終点かMTA終点がMTAにMTAに見つけられていて、電話デバイスを取り付けるのに使用される標準のRJ-11電話物理的なポートです。
X.509 Certificate A X.509 certificate is an Internet X.509 Public Key Infrastructure certificate developed as part of the ITU-T X.500 Directory recommendations. It is defined in RFC 3280 [RFC3280] and RFC 4630 [RFC4630].
X.509が証明するX.509証明書AはITU-T X.500ディレクトリ推薦の一部として開発されたインターネットX.509公開鍵暗号基盤証明書です。 それはRFC3280[RFC3280]とRFC4630[RFC4630]で定義されます。
Voice over IP Voice over IP (VoIP) is a technology providing the means to transfer digitized packets with voice information over IP networks.
ボイス・オーバー IPボイス・オーバー IP(VoIP)はIPネットワークの上でデジタル化しているパケットを移す手段に声の情報を提供する技術です。
Public Key Certificate A Public Key Certificate (also known as a Digital Certificate) is a binding between an entity's public key and one or more attributes relating to its identity.
公共のKey Certificate A Public Key Certificate(また、Digital Certificateとして、知られている)はアイデンティティに関連する実体の公開鍵と1つ以上の属性の間の結合です。
DHCP The Dynamic Host Configuration Protocol (DHCP) is defined by RFC 2131 [RFC2131]. In addition, commonly used DHCP options are defined in RFC 2132 [RFC2132]. Additional DHCP options used by PacketCable and IPCablecom MTAs can be found in the CableLabs Client Configuration DHCP specifications, RFC 3495 [RFC3495] and RFC 3594 [RFC3594].
DHCP Dynamic Host Configuration Protocol(DHCP)はRFC2131[RFC2131]によって定義されます。 さらに、一般的に使用されたDHCPオプションはRFC2132[RFC2132]で定義されます。 CableLabs Client Configuration DHCP仕様、RFC3495[RFC3495]、およびRFC3594[RFC3594]でPacketCableとIPCablecom MTAsによって使用された追加DHCPオプションは見つけることができます。
TFTP The Trivial File Transfer Protocol (TFTP) is defined by RFC 1350 [RFC1350].
TFTPトリビアル・ファイル転送プロトコル(TFTP)はRFC1350[RFC1350]によって定義されます。
HTTP The Hypertext Transfer Protocol (HTTP/1.1) is defined by RFC 2616 [RFC2616].
HTTP、ハイパーテキストTransferプロトコル(HTTP/1.1)はRFC2616[RFC2616]によって定義されます。
Call Management Server A Call Management Server (CMS) is an element of the PacketCable network infrastructure that controls audio connections between MTAs.
呼び出しManagement Server A Call Management Server(CMS)はMTAsの間のオーディオ接続を監督するPacketCableネットワークインフラの要素です。
Nechamkin & Mule Standards Track [Page 3] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[3ページ]。
CODEC, COder-DECoder A Coder-DECoder is a hardware or software component used in audio/video systems to convert an analog signal to digital, and then (possibly) to compress it so that lower bandwidth telecommunications channels can be used. The signal is decompressed and converted (decoded) back to analog output by a compatible CODEC at the receiving end.
CODEC、COder-DECoder A Coder-DECoderは低い帯域幅テレコミュニケーションチャンネルを使用できるようにそれを圧縮するのに(ことによるとアナログ信号をデジタルに変換するオーディオ/ビデオシステム、および次に、)使用されるハードウェアかソフトウェアコンポーネントです。 信号は、犠牲者のコンパチブルCODECによってアナログ出力に減圧されて、変換して戻されます(解読されます)。
Operations Systems Support An Operations Systems Support system (OSS) is a system of back office software components used for fault, configuration, accounting, performance, and security management working in interaction with each other and providing the operations support in deployed PacketCable systems.
操作Systems Support An Operations Systems Supportシステム(OSS)は欠点、構成、会計、性能、互いとの相互作用で利くセキュリティ管理、および操作が配布しているPacketCableシステムでサポートする提供に使用されるバック・オフィスソフトウェアコンポーネントのシステムです。
Key Distribution Center A Key Distribution Center (KDC) is an element of the OSS systems functioning as a Kerberos Security Server, providing mutual authentication of the various components of the PacketCable system (e.g., mutual authentication between an MTA and a CMS, or between an MTA and the Provisioning Server).
主要なDistributionセンターA Key Distributionセンター(KDC)はケルベロスSecurity Serverとして機能するOSSシステムの原理です、PacketCableシステム(例えば、MTAとCMSか、MTAとProvisioning Serverの間の互いの認証)の様々な部品の互いの認証を提供して。
Security Association A Security Association (SA) is a one-way relationship between a sender and a receiver offering security services on the communication flow.
セキュリティAssociation A Security Association(SA)はコミュニケーション流動に対してはセキュリティー・サービスを提供する送付者と受信機との一方向関係です。
3. Introduction
3. 序論
This MIB module provides a set of objects required for the management of PacketCable, ETSI, and ITU-T IPCablecom compliant MTA devices. The MTA MIB module is intended to supersede various MTA MIB modules from which it is partly derived:
このMIBモジュールはPacketCable、ETSI、およびITU-T IPCablecom対応することのMTAデバイスの管理に必要である1セットのオブジェクトを提供します。 MTA MIBモジュールがそれが一部引き出される様々なMTA MIBモジュールに取って代わることを意図します:
- The PacketCable 1.0 MTA MIB Specification [PKT-SP-MIB-MTA].
- PacketCable1.0MTA MIB仕様[PKT-SP-MIB-MTA]。
- The ITU-T IPCablecom MTA MIB requirements [ITU-T-J168].
- ITU-T IPCablecom MTA MIB要件[ITU-T-J168]。
- The ETSI MTA MIB [ETSITS101909-8]. The ETSI MTA MIB requirements
also refer to various signal characteristics defined in
[EN300001], Chapter 3, titled 'Ringing Signal Characteristics',
and [EN300659-1].
- ETSI MTA MIB[ETSITS101909-8]。 また、ETSI MTA MIB要件は[EN300001]、'Signal Characteristicsを鳴らします'と題をつけられた第3章、および[EN300659-1]で定義された様々な信号の特性について言及します。
Several normative and informative references are used to help define MTA MIB objects. As a convention, wherever PacketCable and IPCablecom requirements are equivalent, the PacketCable reference is used in the object REFERENCE clause. IPCablecom-compliant MTA devices MUST use the equivalent IPCablecom references.
いくつかの規範的で有益な参照が、MTA MIBオブジェクトを定義するのを助けるのに使用されます。 コンベンションとして、PacketCable参照はオブジェクトREFERENCE節でどこでも、PacketCableとIPCablecom要件が同等であるところでは、使用されます。 IPCablecom対応することのMTAデバイスは同等なIPCablecom参照を使用しなければなりません。
Nechamkin & Mule Standards Track [Page 4] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[4ページ]。
3.1. Structure of the MTA MIB
3.1. MTA MIBの構造
The MTA MIB module is identified by pktcIetfMtaMib and is structured in three object groups:
MTA MIBモジュールは、pktcIetfMtaMibによって特定されて、3つのオブジェクトグループで構造化されます:
- pktcMtaDevBase defines the management information pertinent to the
MTA device itself.
- pktcMtaDevBaseはMTAデバイス自体に適切な経営情報を定義します。
- pktcMtaDevServer defines the management information pertinent to
the provisioning back office servers.
- pktcMtaDevServerは食糧を供給しているバック・オフィスサーバに適切な経営情報を定義します。
- pktcMtaDevSecurity defines the management information pertinent to
the PacketCable and IPCablecom security mechanisms.
- pktcMtaDevSecurityはPacketCableに適切な経営情報とIPCablecomセキュリティー対策を定義します。
The first two object groups, pktcMtaDevBase and pktcMtaDevServer, contain only scalar information objects describing the corresponding characteristics of the MTA device and back office servers.
最初の2つのオブジェクトグループ(pktcMtaDevBaseとpktcMtaDevServer)が、MTAデバイスとバック・オフィスサーバの対応する特性について説明するスカラの情報オブジェクトだけを含みます。
The third group, pktcMtaDevSecurity, contains two tables controlling the logical associations between KDC realms and Application Servers (CMS and Provisioning Server). The rows in the various tables of the MTA MIB module can be created automatically (e.g., by the device according to the current state information), or they can be created by the management station, depending on the operational situation. The tables defined in the MTA MIB module may have a mixture of both types of rows.
3番目のグループ(pktcMtaDevSecurity)はKDC分野の間の論理的な協会を制御する2個のテーブルとApplication Servers(CMSとProvisioning Server)を含みます。 自動的(例えば、現状情報に従ったデバイスで)にMTA MIBモジュールの様々なテーブルの行を作成できますか、または管理局でそれらを作成できます、操作上の状況によって。 MTA MIBモジュールで定義されたテーブルは両方のタイプの行の混合物を持っているかもしれません。
3.2. pktcMtaDevBase
3.2. pktcMtaDevBase
This object group contains the management information related to the MTA device itself. It also contains some objects used to control the MTA state. Some highlights are as follows:
このオブジェクトグループはMTAデバイス自体に関連する経営情報を含みます。 また、それはMTA状態を制御するのに使用されるいくつかのオブジェクトを含んでいます。 いくつかのハイライトは以下の通りです:
- pktcMtaDevSerialNumber. This object contains the MTA Serial
Number.
- pktcMtaDevSerialNumber。 このオブジェクトはMTA Serial Numberを含んでいます。
- pktcMtaDevEndPntCount. This object contains the number of
endpoints present in the managed MTA.
- pktcMtaDevEndPntCount。 このオブジェクトは管理されたMTAの現在の終点の数を含んでいます。
- pktcMtaDevProvisioningState. This object contains the information
describing the completion state of the MTA initialization process.
- pktcMtaDevProvisioningState。 このオブジェクトはMTA初期化プロセスの完成状態について説明する情報を含んでいます。
- pktcMtaDevEnabled. This object controls the administrative state
of the MTA endpoints and allows operators to enable or disable
telephony services on the device.
- pktcMtaDevEnabled。 このオブジェクトは、MTA終点の管理状態を制御して、オペレータがデバイスで電話サービスを可能にするか、または無効にするのを許容します。
- pktcMtaDevResetNow. This object is used to instruct the MTA to
reset.
- pktcMtaDevResetNow。 このオブジェクトは、リセットへのMTAを命令するのに使用されます。
Nechamkin & Mule Standards Track [Page 5] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[5ページ]。
3.3. pktcMtaDevServer
3.3. pktcMtaDevServer
This object group contains the management information describing the back office servers and the parameters related to the communication timers. It also includes some objects controlling the initial MTA interaction with the Provisioning Server.
このオブジェクトグループはバック・オフィスサーバについて説明する経営情報とコミュニケーションタイマに関連するパラメタを含みます。 また、それはProvisioning Serverとの初期のMTA相互作用を制御するいくつかのオブジェクトを含んでいます。
Some highlights are as follows:
いくつかのハイライトは以下の通りです:
- pktcMtaDevServerDhcp1. This object contains the IP address of the
primary DHCP server designated for the MTA provisioning.
- pktcMtaDevServerDhcp1。 このオブジェクトはMTAの食糧を供給するために指定されたプライマリDHCPサーバのIPアドレスを含んでいます。
- pktcMtaDevServerDhcp2. This object contains the IP address of the
secondary DHCP server designated for the MTA provisioning.
- pktcMtaDevServerDhcp2。 このオブジェクトはMTAの食糧を供給するために指定されたセカンダリDHCPサーバのIPアドレスを含んでいます。
- pktcMtaDevServerDns1. This object contains the IP address of the
primary DNS used by the managed MTA to resolve the Fully Qualified
Domain Name (FQDN) and IP addresses.
- pktcMtaDevServerDns1。 このオブジェクトはFully Qualified Domain Name(FQDN)とIPアドレスを決議するのに管理されたMTAによって使用されたプライマリDNSのIPアドレスを含んでいます。
- pktcMtaDevServerDns2. This object contains the IP address of the
secondary DNS used by the managed MTA to resolve the FQDN and IP
addresses.
- pktcMtaDevServerDns2。 このオブジェクトはFQDNとIPアドレスを決議するのに管理されたMTAによって使用されたセカンダリDNSのIPアドレスを含んでいます。
- pktcMtaDevConfigFile. This object contains the name of the
provisioning configuration file the managed MTA must download from
the Provisioning Server.
- pktcMtaDevConfigFile。 このオブジェクトは管理されたMTAがProvisioning Serverからダウンロードしなければならない食糧を供給する構成ファイルの名前を含んでいます。
- pktcMtaDevProvConfigHash. This object contains the hash value of
the MTA configuration file calculated over its content. When the
managed MTA downloads the file, it authenticates the configuration
file using the hash value provided in this object.
- pktcMtaDevProvConfigHash。 このオブジェクトは内容に関して計算されたMTA構成ファイルのハッシュ値を含んでいます。 管理されたMTAがファイルをダウンロードするとき、それは、このオブジェクトに提供されたハッシュ値を使用することで構成ファイルを認証します。
3.4. pktcMtaDevSecurity
3.4. pktcMtaDevSecurity
This object group contains the management information describing the security-related characteristics of the managed MTA. It contains two tables describing logical dependencies and parameters necessary to establish Security Associations between the MTA and other Application Servers (back office components and CMSes). The CMS table (pktcMtaDevCmsTable) and the realm table (pktcMtaDevRealmTable) are used for managing the MTA signaling security. The realm table defines the CMS domains. The CMS table defines the CMS within the domains. Each MTA endpoint is associated with one CMS at any given time.
このオブジェクトグループは管理されたMTAのセキュリティ関連の特性について説明する経営情報を含みます。 それはMTAと他のApplication Servers(バック・オフィスのコンポーネントとCMSes)の間にSecurity Associationsを証明するのに必要な論理的な依存とパラメタについて説明する2個のテーブルを含んでいます。 CMSテーブル(pktcMtaDevCmsTable)と分野テーブル(pktcMtaDevRealmTable)は、MTAシグナリングセキュリティを管理するのに使用されます。 分野テーブルはCMSドメインを定義します。 CMSテーブルはドメインの中でCMSを定義します。 それぞれのMTA終点はその時々で1CMSに関連しています。
Nechamkin & Mule Standards Track [Page 6] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[6ページ]。
The two tables in this object group are as follows:
このオブジェクトグループにおける2個のテーブルは以下の通りです:
- pktcMtaDevRealmTable. This table is used in conjunction with any
Application Server that communicates securely with the managed MTA
(CMS or Provisioning Server).
- pktcMtaDevRealmTable。 このテーブルはしっかりと管理されたMTA(CMSかProvisioning Server)とコミュニケートするどんなApplication Serverに関連して使用されます。
- pktcMtaDevCmsTable. This table contains the parameters describing
the SA establishment between the MTA and CMSes.
- pktcMtaDevCmsTable。 このテーブルはMTAとCMSesの間のSA設立について説明するパラメタを含んでいます。
3.5. Relationship between MIB Objects in the MTA MIB
3.5. MTA MIBのMIBオブジェクトの間の関係
This section clarifies the relationship between various MTA MIB objects with respect to the role they play in the process of establishing Security Associations.
このセクションはSecurity Associationsを設立することの途中にそれらが果たす役割に関して様々なMTA MIBオブジェクトの間の関係をはっきりさせます。
The process of Security Association establishment between an MTA and Application Servers is described in the PacketCable Security Specification [PKT-SP-SEC]. In particular, an MTA communicates with 2 types of back office Application Servers: Call Management Servers and Provisioning Servers.
MTAとApplication Serversの間のSecurity Association設立のプロセスはPacketCable Security Specification[PKT-SP-SEC]で説明されます。 特に、MTAはバック・オフィスApplication Serversの2つのタイプとコミュニケートします: 管理をサーバとサーバに食糧を供給すると呼んでください。
The SA establishment process consists of two steps:
SA設立プロセスは以下の2ステップから成ります:
a. Authentication Server Exchange (AS-exchange). This step provides
mutual authentication between the parties; i.e., between an MTA
and an Authentication Server. The process of AS-exchange is
defined by a number of parameters grouped per each realm. These
parameters are gathered in the Realm Table (pktcMtaDevRealmTable).
The Realm Table is indexed by the Index Counter and contains
conceptual column with the Kerberos realm name.
a。 認証サーバ交換(交換としての)。 このステップは互いの認証をパーティーの間に提供します。 すなわち、MTAとAuthentication Serverの間では. AS-交換のプロセスは各分野単位で分類された多くのパラメタによって定義されます。 これらのパラメタはRealm Table(pktcMtaDevRealmTable)に集められます。 Realm TableはIndex Counterによって索引をつけられて、ケルベロス分野名で概念的なコラムを含んでいます。
b. Application server exchange (AP-exchange). This step allows for
the establishment of Security Associations between authenticated
parties. The CMS table (pktcMtaDevCmsTable) contains the
parameters for the AP-exchange process between an MTA and a CMS.
The CMS table is indexed by the Index Counter and contains the CMS
FQDN (the conceptual column pktcMtaDevCmsFqdn). Each row contains
the Kerberos realm name associated with each CMS FQDN. This
allows for each CMS to exist in a different Kerberos realm.
b。 アプリケーション・サーバー交換(AP-交換)。 このステップは認証されたパーティーの間のSecurity Associationsの設立を考慮します。 CMSテーブル(pktcMtaDevCmsTable)はAP-交換プロセスのためにMTAとCMSの間にパラメタを含んでいます。CMSテーブルは、Index Counterによって索引をつけられて、CMS FQDN(概念的なコラムpktcMtaDevCmsFqdn)を含んでいます。 各行は各CMS FQDNに関連しているケルベロス分野名を含んでいます。 これは、各CMSが異なったケルベロス分野に存在するのを許容します。
The MTA MIB module also contains a group of scalar MIB objects in the server group (pktcMtaDevServer). These objects define various parameters for the AP-exchange process between an MTA and the Provisioning Server. These objects are:
また、MTA MIBモジュールはサーバグループ(pktcMtaDevServer)にスカラのMIBオブジェクトのグループを含みます。 これらのオブジェクトはMTAとProvisioning Serverの間のAP-交換プロセスのための様々なパラメタを定義します。これらの目的は以下の通りです。
- pktcMtaDevProvUnsolicitedKeyMaxTimeout,
- pktcMtaDevProvUnsolicitedKeyMaxTimeout
- pktcMtaDevProvUnsolicitedKeyNomTimeout,
- pktcMtaDevProvUnsolicitedKeyNomTimeout
Nechamkin & Mule Standards Track [Page 7] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[7ページ]。
- pktcMtaDevProvUnsolicitedKeyMaxRetries, and
- pktcMtaDevProvUnsolicitedKeyMaxRetries
- pktcMtaDevProvSolicitedKeyTimeout.
- pktcMtaDevProvSolicitedKeyTimeout。
3.6. Secure Software Download
3.6. 安全なソフトウェアダウンロード
E-MTAs are embedded with DOCSIS 1.1 cable modems. E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements.
電子MTAsは1.1がモデムに電報を打つDOCSISと共に埋め込まれています。DOCSIS要件に従って、電子MTAsはCable Modemに彼らのソフトウェアをアップグレードさせます。
Although E-MTAs have their software upgraded by the Cable Modem according to the DOCSIS requirements, S-MTAs implement a specific mechanism for Secure Software Download. This provides a means to verify the code upgrade using Code Verification Certificates and is modeled after the DOCSIS mechanism implemented in Cable Modems. This is the reason why the MTA MIB and the S-MTA compliance modules also rely on two MIB object groups:
DOCSIS要件に従って、E-MTAsはCable Modemに彼らのソフトウェアをアップグレードさせますが、S-MTAsはSecure Software Downloadのために特定のメカニズムを実装します。 これは、Code Verification Certificatesを使用することでコードアップグレードについて確かめる手段を供給して、Cable Modemsで実装されたDOCSISメカニズムに倣われます。またMTA MIBとS-MTA承諾モジュールが2つのMIBオブジェクトグループを当てにする理由です:
- docsBpi2CodeDownloadGroup, defined in the IETF BPI Plus MIB module
(DOCS-IETF-BPI2-MIB [RFC4131]).
- IETF BPI Plus MIBモジュール(DOCS-IETF-BPI2-MIB[RFC4131])で定義されたdocsBpi2CodeDownloadGroup。
- docsDevSoftwareGroupV2, defined in the IETF Cable Devicev2 MIB
module (DOCS-CABLE-DEVICE-MIB [RFC4639]).
- IETF Cable Devicev2 MIBモジュール(DOCS-CABLE-DEVICE-MIB[RFC4639])で定義されたdocsDevSoftwareGroupV2。
3.7. X.509 Certificates Dependencies
3.7. X.509証明書の依存
As specified in the PacketCable Security Specification [PKT-SP-SEC], E-MTAs must use the authentication mechanism based on the X.509 Public Key Infrastructure Certificates, as defined in RFC 3280 [RFC3280] and RFC 4630 [RFC4630].
PacketCable Security Specification[PKT-SP-SEC]で指定されるように、E-MTAsはX.509公開鍵暗号基盤Certificatesに基づく認証機構を使用しなければなりません、RFC3280[RFC3280]とRFC4630[RFC4630]で定義されるように。
The value of the pktcMtaDevRealmOrgName MIB object should contain the X.509 organization name attribute of the Telephony Service Provider certificate (OrganizationName). X.509 attributes are defined using UTF-8 string encoding [RFC3629, RFC3280, and RFC4630].
pktcMtaDevRealmOrgName MIBオブジェクトの値は属性というTelephony Service Provider証明書(OrganizationName)のX.509組織名を含むべきです。 X.509属性は、UTF-8ストリングコード化[RFC3629、RFC3280、およびRFC4630]を使用することで定義されます。
Note that UTF-8 encoded characters can be encoded as sequences of 1 to 6 octets, assuming that code points as high as 0x7ffffffff might be used ([RFC3629]). Subsequent versions of Unicode and ISO 10646 have limited the upper bound to 0x10ffff ([RFC3629]). Consequently, the current version of UTF-8, defined in RFC 3629, does not require more than four octets to encode a valid code point.
1〜6つの八重奏の系列としてUTF-8がキャラクタをコード化したというメモをコード化できます、コードが0x7ffffffffが使用されるかもしれないのと([RFC3629])同じくらい高く指すと仮定して。 ユニコードとISO10646のその後のバージョンは上限を0x10ffff([RFC3629])に制限しました。 その結果、RFC3629で定義されたUTF-8の最新版は、有効なコード・ポイントをコード化するために4つ以上の八重奏を必要としません。
Nechamkin & Mule Standards Track [Page 8] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[8ページ]。
4. Definitions
4. 定義
The MIB module below makes references and citations to [RFC868], [RFC3280], [RFC4630], and [RFC3617].
以下のMIBモジュールは参照と引用を[RFC868]、[RFC3280]、[RFC4630]、および[RFC3617]にします。
PKTC-IETF-MTA-MIB DEFINITIONS ::= BEGIN
PKTC-IETF-MTA-MIB定義:、:= 始まってください。
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
OBJECT-IDENTITY,
Unsigned32,
Counter32,
NOTIFICATION-TYPE,
mib-2
FROM SNMPv2-SMI -- [RFC2578]
TEXTUAL-CONVENTION,
RowStatus,
TruthValue
FROM SNMPv2-TC -- [RFC2579]
OBJECT-GROUP,
MODULE-COMPLIANCE,
NOTIFICATION-GROUP
FROM SNMPv2-CONF -- [RFC2580]
InetAddressType,
InetAddress
FROM INET-ADDRESS-MIB -- [RFC4001]
sysDescr
FROM SNMPv2-MIB -- [RFC3418]
SnmpAdminString
FROM SNMP-FRAMEWORK-MIB -- [RFC3411]
docsDevSoftwareGroupV2
FROM DOCS-CABLE-DEVICE-MIB -- [RFC4639]
DocsX509ASN1DEREncodedCertificate,
docsBpi2CodeDownloadGroup
FROM DOCS-IETF-BPI2-MIB -- [RFC4131]
LongUtf8String
FROM SYSAPPL-MIB -- [RFC2287]
ifPhysAddress
FROM IF-MIB; -- [RFC2863]
IMPORTS MODULE-IDENTITY、OBJECT-TYPE、OBJECT-IDENTITY、Unsigned32、Counter32、NOTIFICATION-TYPE、mib-2 FROM SNMPv2-SMI--RFC2578 TEXTUAL-CONVENTION、RowStatus、TruthValue FROM SNMPv2-TC--RFC2579 OBJECT-GROUP、MODULE-COMPLIANCE、NOTIFICATION-GROUP FROM SNMPv2-CONF--RFC2580 InetAddressType(InetAddress FROM INET-ADDRESS-MIB); SNMPv2-MIB--DOCS-IETF-BPI2-MIBからのSNMPフレームワークMIB--DOCSケーブルデバイスMIBからのRFC3411 docsDevSoftwareGroupV2--RFC4639 DocsX509ASN1DEREncodedCertificateからのRFC3418 SnmpAdminString、docsBpi2CodeDownloadGroup--SYSAPPL-MIBからのRFC4131 LongUtf8StringからのRFC4001 sysDescr--、RFC2287 ifPhysAddress、-、MIB、。 -- [RFC2863]
pktcIetfMtaMib MODULE-IDENTITY
LAST-UPDATED "200609180000Z" -- September 18, 2006
ORGANIZATION "IETF IP over Cable Data Network Working Group"
CONTACT-INFO
"Eugene Nechamkin
Broadcom Corporation,
200-13711 International Place,
pktcIetfMtaMibモジュールアイデンティティ最終更新日の"200609180000Z"--「ユージンNechamkin Broadcom社、200-13711の国際場所」という2006年9月18日組織「ケーブルデータ網作業部会の上のIETF IP」コンタクトインフォメーション
Nechamkin & Mule Standards Track [Page 9] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[9ページ]。
Richmond, BC, V6V 2Z8
CANADA
Phone: +1 604 233 8500
Email: enechamkin@broadcom.com
リッチモンド、紀元前、V6V 2Z8カナダ電話: +1 8500年の604 233メール: enechamkin@broadcom.com
Jean-Francois Mule
Cable Television Laboratories, Inc.
858 Coal Creek Circle
Louisville, CO 80027-9750
U.S.A.
Phone: +1 303 661 9100
Email: jf.mule@cablelabs.com
ジャン・フランソワラバケーブルテレビ研究所Inc.858石炭クリーク円のルイビル、CO80027-9750米国電話: +1 9100年の303 661メール: jf.mule@cablelabs.com
IETF IPCDN Working Group
General Discussion: ipcdn@ietf.org
Subscribe: http://www.ietf.org/mailman/listinfo/ipcdn
Archive: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn
Co-Chair: Jean-Francois Mule, jf.mule@cablelabs.com
Co-Chair: Richard Woundy, Richard_Woundy@cable.comcast.com"
IETF IPCDNワーキンググループ一般議論: ipcdn@ietf.org は申し込まれます: http://www.ietf.org/mailman/listinfo/ipcdn アーカイブ: ftp://ftp.ietf.org/ietf-mail-archive/ipcdn 共同議長: ジャン・フランソワMule、 jf.mule@cablelabs.com 共同議長: 「リチャードWoundy、 Richard_Woundy@cable.comcast.com 」
DESCRIPTION
"This MIB module defines the basic management object
for the Multimedia Terminal Adapter devices compliant
with PacketCable and IPCablecom requirements.
記述、「このMIBモジュールはPacketCableに伴う対応することのMultimediaティーエーデバイスとIPCablecom要件のために基本的な管理オブジェクトを定義します」。
Copyright (C) The IETF Trust (2006). This version of
this MIB module is part of RFC 4682; see the RFC itself for
full legal notices."
IETFが信じる著作権(C)(2006)。 このMIBモジュールのこのバージョンはRFC4682の一部です。 「完全な法定の通知に関してRFC自身を見てください。」
REVISION "200609180000Z" -- September 18, 2006
改正"200609180000Z"--2006年9月18日
DESCRIPTION
"Initial version, published as RFC 4682."
「初期のバージョンであって、RFC4682として発行された」記述。
::= { mib-2 140 }
::= mib-2 140
-- Textual Conventions
-- 原文のコンベンション
PktcMtaDevProvEncryptAlg ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
" This textual convention defines various types of the
encryption algorithms used for the encryption of the MTA
configuration file. The description of the encryption
algorithm for each enumerated value is as follows:
PktcMtaDevProvEncryptAlg:、:= TEXTUAL-CONVENTION STATUSの現在の記述、「この原文のコンベンションはMTA構成ファイルの暗号化に使用される暗号化アルゴリズムの様々なタイプを定義します」。 それぞれが値を列挙したので、暗号化アルゴリズムの記述は以下の通りです:
'none(0)' no encryption is used,
'des64CbcMode(1)' DES 64-bit key in CBC mode,
'なにも、(0) 'どんな暗号化も使用されていなくて、CBCモードで'des64CbcMode(1)'DESは64ビットのキーです。
Nechamkin & Mule Standards Track [Page 10] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[10ページ]。
't3Des192CbcMode(2)' 3DES 192-bit key in CBC mode,
'aes128CbcMode(3)' AES 128-bit key in CBC mode,
'aes256CbcMode(4)' AES 256-bit key in CBC mode."
SYNTAX INTEGER {
none (0),
des64CbcMode (1),
t3Des192CbcMode (2),
aes128CbcMode (3),
aes256CbcMode (4)
}
「CBCモードによる't3Des192CbcMode(2)'3DESの192ビットのキー、CBCモードによる'aes128CbcMode(3)'AESの128ビットのキー、CBCモードによる'aes256CbcMode(4)'AESの256ビットのキー。」 構文整数なにも、(0)、des64CbcMode(1)、t3Des192CbcMode(2)、aes128CbcMode(3)、aes256CbcMode(4)
--================================================================= -- The MTA MIB module only supports a single Provisioning Server. --=================================================================
--================================================================= -- MTA MIBモジュールが独身のProvisioning Serverをサポートするだけである、--=================================================================
pktcMtaNotification OBJECT IDENTIFIER ::= { pktcIetfMtaMib 0 }
pktcMtaMibObjects OBJECT IDENTIFIER ::= { pktcIetfMtaMib 1 }
pktcMtaDevBase OBJECT IDENTIFIER ::= { pktcMtaMibObjects 1 }
pktcMtaDevServer OBJECT IDENTIFIER ::= { pktcMtaMibObjects 2 }
pktcMtaDevSecurity OBJECT IDENTIFIER ::= { pktcMtaMibObjects 3 }
pktcMtaDevErrors OBJECT IDENTIFIER ::= { pktcMtaMibObjects 4 }
pktcMtaConformance OBJECT IDENTIFIER ::= { pktcIetfMtaMib 2 }
pktcMtaNotificationオブジェクト識別子:、:= pktcIetfMtaMib0pktcMtaMibObjectsオブジェクト識別子:、:= pktcIetfMtaMib1pktcMtaDevBaseオブジェクト識別子:、:= pktcMtaMibObjects1pktcMtaDevServerオブジェクト識別子:、:= pktcMtaMibObjects2pktcMtaDevSecurityオブジェクト識別子:、:= pktcMtaMibObjects3pktcMtaDevErrorsオブジェクト識別子:、:= pktcMtaMibObjects4pktcMtaConformanceオブジェクト識別子:、:= pktcIetfMtaMib2
-- -- The following pktcMtaDevBase group describes the base MTA objects --
-- -- 以下のpktcMtaDevBaseグループはベースMTAオブジェクトについて説明します--
pktcMtaDevResetNow OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object controls the MTA software reset.
Reading this object always returns 'false'. Setting this
object to 'true' causes the device to reset immediately
and the following actions to occur:
1. All connections (if present) are flushed locally.
2. All current actions such as ringing immediately
terminate.
3. Requests for signaling notifications, such as
notification based on digit map recognition, are
flushed.
4. All endpoints are disabled.
5. The provisioning flow is started at step MTA-1.
If a value is written into an instance of
pktcMtaDevResetNow, the agent MUST NOT retain the supplied
value across MTA re-initializations or reboots."
REFERENCE
pktcMtaDevResetNow OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「このオブジェクトはMTAソフトウェアリセットを制御すること」をSTATUSの現在の記述に読書して書きます。 このオブジェクトを読むのは'虚偽'いつも戻ります。 '本当に'このオブジェクトを設定するのに、すぐにリセットするデバイスと以下の動作は起こります: 1. すべての接続(存在しているなら)が局所的に洗い流されます。 2. すぐに鳴ることなどの現在のすべての動作が終わります。 3. ケタ地図認識に基づく通知などのシグナリング通知に関する要求は紅潮しています。 4. すべての終点が障害があります。 5. 食糧を供給する流動はステップMTA-1で始められます。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevResetNowのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 参照
Nechamkin & Mule Standards Track [Page 11] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[11ページ]。
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 1 }
「仕様に食糧を供給するPacketCable MTAデバイス。」 ::= pktcMtaDevBase1
pktcMtaDevSerialNumber OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object specifies the manufacturer's serial
number of this MTA. The value of this object MUST be
identical to the value specified in DHCP option 43,
sub-option 4. The list of sub-options for DHCP option
43 are defined in the PacketCable MTA Device
Provisioning Specification."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 2 }
pktcMtaDevSerialNumber OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このMTAの製造番号を指定これが反対するします」。 このオブジェクトの値はDHCPオプション43、サブオプション4で指定された値と同じであるに違いありません。 「DHCPオプション43のためのサブオプションのリストはPacketCable MTA Device Provisioning Specificationで定義されます。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 ::= pktcMtaDevBase2
pktcMtaDevSwCurrentVers OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object identifies the software version currently
operating in the MTA.
The MTA MUST return a string descriptive of the current
software load. This object should use the syntax
defined by the individual vendor to identify the software
version. The data presented in this object MUST be
identical to the software version information contained
in the 'sysDescr' MIB object of the MTA. The value of
this object MUST be identical to the value specified in
DHCP option 43, sub-option 6. The list of sub-options for
DHCP option 43 are defined in the PacketCable MTA Device
Provisioning Specification."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
pktcMtaDevSwCurrentVers OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「現在MTAで作動するソフトウェアバージョンを特定これが反対するします」。 MTA MUSTは現在のソフトウェア負荷で描写的であるストリングを返します。 このオブジェクトはソフトウェアバージョンを特定するために個々のベンダーによって定義された構文を使用するはずです。 このオブジェクトに提示されたデータはMTAの'sysDescr'MIBオブジェクトに含まれたソフトウェアバージョン情報と同じであるに違いありません。 このオブジェクトの値はDHCPオプション43、サブオプション6で指定された値と同じであるに違いありません。 「DHCPオプション43のためのサブオプションのリストはPacketCable MTA Device Provisioning Specificationで定義されます。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。
::= { pktcMtaDevBase 3 }
::= pktcMtaDevBase3
pktcMtaDevFQDN OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Fully Qualified Domain Name for
this MTA. The MTA FQDN is used to uniquely identify the
device to the PacketCable back office elements."
pktcMtaDevFQDN OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このMTAのためのFully Qualified Domain Nameを含これが反対するしています」。 「MTA FQDNは唯一PacketCableバック・オフィス要素にデバイスを特定するのに使用されます。」
Nechamkin & Mule Standards Track [Page 12] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[12ページ]。
::= { pktcMtaDevBase 4 }
::= pktcMtaDevBase4
pktcMtaDevEndPntCount OBJECT-TYPE
SYNTAX Unsigned32 (1..255)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the number of physical endpoints for
this MTA."
::= { pktcMtaDevBase 5 }
pktcMtaDevEndPntCount OBJECT-TYPE SYNTAX Unsigned32(1 .255)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「このMTAのための物理的な終点の数を含これが反対するしています」。 ::= pktcMtaDevBase5
pktcMtaDevEnabled OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the MTA Admin Status of this device.
If this object is set to 'true', the MTA is
administratively enabled, and the MTA MUST be able to
interact with the PacketCable entities, such as CMS,
Provisioning Server, KDC, and other MTAs and MGs on all
PacketCable interfaces.
If this object is set to 'false', the MTA is
administratively disabled, and the MTA MUST perform the
following actions for all endpoints:
- Shut down all media sessions, if present.
- Shut down Network Control Signaling (NCS)
signaling by following the Restart in
Progress procedures in the PacketCable NCS
specification.
The MTA must execute all actions required to
enable or disable the telephony services for all
endpoints immediately upon receipt of an SNMP SET
operation.
pktcMtaDevEnabled OBJECT-TYPE SYNTAX TruthValueマックス-ACCESSは「このオブジェクトはこのデバイスのMTA Admin Statusを含んでいること」をSTATUSの現在の記述に読書して書きます。 このオブジェクトが'本当に'設定されるなら、MTAは行政上可能にされてMTA MUSTです。PacketCable実体と対話できてください、すべてのPacketCableインタフェースのCMSや、Provisioning Serverや、KDCや、他のMTAsやMGsなどのように。 このオブジェクトが'誤っていること'に設定されるなら、MTAは行政上無効にされます、そして、MTA MUSTはすべての終点のための以下の動作を実行します: - 存在しているなら、すべてのメディアセッションに停止してください。 - PacketCable NCS仕様によるProgress手順でRestartに続くことによって合図して、Network Control Signaling(NCS)を止めてください。 MTAはすぐSNMP SET操作を受け取り次第すべての終点のための電話サービスを可能にするか、または無効にするのに必要であるすべての動作を実行しなければなりません。
Additionally, the MTA MUST maintain the SNMP Interface
for management and also the SNMP Key management interface.
Also, the MTA MUST NOT continue Kerberized key management
with CMSes until this object is set to 'true'.
Note: MTAs MUST renew the CMS Kerberos tickets according
to the PacketCable Security or IPCablecom Specification.
If a value is written into an instance of
pktcMtaDevEnabled, the agent MUST NOT retain the supplied
value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification;
PacketCable Network-Based Call Signaling Protocol
さらに、MTA MUSTは管理とSNMP Key管理インタフェースにもSNMP Interfaceを維持します。 また、MTA MUST NOTは'本当に'CMSesとのこのオブジェクトが設定されるまでのKerberizedかぎ管理を続けています。 以下に注意してください。 PacketCable SecurityかIPCablecom Specificationに応じて、MTAsはCMSケルベロスチケットを取り替えなければなりません。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevEnabledのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 PacketCableセキュリティ仕様。 PacketCableのネットワークベースの呼び出しシグナリングプロトコル
Nechamkin & Mule Standards Track [Page 13] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[13ページ]。
Specification."
::= { pktcMtaDevBase 6 }
「仕様。」 ::= pktcMtaDevBase6
pktcMtaDevTypeIdentifier OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object provides the MTA device type identifier. The
value of this object must be a copy of the DHCP option 60
value exchanged between the MTA and the DHCP server. The
DHCP option 60 value contains an ASCII-encoded string
identifying capabilities of the MTA as defined in the
PacketCable MTA Device Provisioning Specification."
REFERENCE
" RFC 2132, DHCP Options and BOOTP Vendor Extensions;
PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 7 }
「このオブジェクトはMTA装置タイプ識別子を提供する」pktcMtaDevTypeIdentifier OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 このオブジェクトの値は60値がMTAとDHCPサーバの間で交換したDHCPオプションのコピーでなければなりません。「DHCPオプション60値はPacketCable MTA Device Provisioning Specificationで定義されるようにMTAの能力を特定するASCIIによってコード化されたストリングを含んでいます。」 「RFC2132、DHCPオプション、およびBOOTPベンダー拡張子」という参照。 「仕様に食糧を供給するPacketCable MTAデバイス。」 ::= pktcMtaDevBase7
pktcMtaDevProvisioningState OBJECT-TYPE
SYNTAX INTEGER {
pass (1),
inProgress (2),
failConfigFileError (3),
passWithWarnings (4),
passWithIncompleteParsing (5),
failureInternalError (6),
failureOtherReason (7)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates the completion state of the MTA
device provisioning process.
pktcMtaDevProvisioningState OBJECT-TYPE SYNTAX INTEGERはfailConfigFileError(3)、passWithWarnings(4)、passWithIncompleteParsing(5)、failureInternalError(6)、failureOtherReason(7)を(1)、inProgress(2)に通過します。マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「プロセスに食糧を供給するMTAデバイスの完成状態を示これが反対するします」。
pass:
If the configuration file could be parsed successfully
and the MTA is able to reflect the same in its
MIB, the MTA MUST return the value 'pass'.
以下を通過してください。 首尾よく構成ファイルを分析できて、MTAがMIBで同じように反射できるなら、MTA MUSTは値の'パス'を返します。
inProgress:
If the MTA is in the process of being provisioned,
the MTA MUST return the value 'inProgress'.
inProgress: 食糧を供給されることの途中にMTAがあるなら、MTA MUSTは値の'inProgress'を返します。
failConfigFileError:
If the configuration file was in error due to incorrect
values in the mandatory parameters, the MTA MUST reject
the configuration file, and the MTA MUST return the value
failConfigFileError: 構成ファイルが義務的なパラメタの不正確な値のために間違っていて、MTA MUSTが構成ファイルを拒絶して、MTA MUSTが値を返すなら
Nechamkin & Mule Standards Track [Page 14] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[14ページ]。
'failConfigFileError'.
'failConfigFileError'。
passWithWarnings:
If the configuration file had proper values for all the
mandatory parameters but has errors in any of the optional
parameters (this includes any vendor-specific Object
Identifiers (OIDs) that are incorrect or not known
to the MTA), the MTA MUST return the value
'passWithWarnings'.
passWithWarnings: 構成ファイルがすべての義務的なパラメタのために固有値を持っていますが、任意のパラメタのどれかに誤りを持っているなら(これは少しの不正確であるかMTAにおいて、知られていないベンダー特有のObject Identifiers(OIDs)も含んでいます)、MTA MUSTは値の'passWithWarnings'を返します。
passWithIncompleteParsing:
If the configuration file is valid but the MTA cannot
reflect the same in its configuration (for example, too
many entries caused memory exhaustion), it must accept
the CMS configuration entries related, and the MTA MUST
return the value 'passWithIncompleteParsing'.
passWithIncompleteParsing: 構成ファイルが有効ですが、MTAが構成では同じように反射できないなら(例えば、あまりに多くのエントリーがメモリ疲労困憊を引き起こしました)、エントリーが関係づけたCMS構成を受け入れなければなりません、そして、MTA MUSTは値の'passWithIncompleteParsing'を返します。
failureInternalError:
If the configuration file cannot be parsed due to an
Internal error, the MTA MUST return the value
'failureInternalError'.
failureInternalError: Internal誤りのため構成ファイルを分析できないなら、MTA MUSTは値の'failureInternalError'を返します。
failureOtherReason:
If the MTA cannot accept the configuration file for any
other reason than the ones stated above, the MTA MUST
return the value 'failureOtherReason'.
failureOtherReason: MTAが上に述べられたものよりいかなる他の理由でも構成ファイルを受け入れることができないなら、MTA MUSTは値の'failureOtherReason'を返します。
When a final SNMP INFORM is sent as part of Step 25 of the
MTA Provisioning process, this parameter is also included
in the final INFORM message."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevBase 8 }
「また、MTA ProvisioningプロセスのStep25の一部として最終的なSNMP INFORMを送るとき、最終的なINFORMメッセージにこのパラメタを含んでいます。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 ::= pktcMtaDevBase8
pktcMtaDevHttpAccess OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates whether the HTTP protocol is
supported for the MTA configuration file transfer."
::= { pktcMtaDevBase 9 }
「HTTPプロトコルがMTA構成ファイル転送のためにサポートされるか否かに関係なく、このオブジェクトは示す」pktcMtaDevHttpAccess OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= pktcMtaDevBase9
pktcMtaDevProvisioningTimer OBJECT-TYPE
SYNTAX Unsigned32 (0..30)
UNITS "minutes"
MAX-ACCESS read-write
STATUS current
pktcMtaDevProvisioningTimer OBJECT-TYPE SYNTAX Unsigned32(0 .30)UNITS「数分」マックス-ACCESSはSTATUSに電流を読書して書きます。
Nechamkin & Mule Standards Track [Page 15] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[15ページ]。
DESCRIPTION
" This object defines the time interval for the provisioning
flow to complete. The MTA MUST finish all provisioning
operations starting from the moment when an MTA receives
its DHCP ACK and ending at the moment when the MTA
downloads its configuration file (e.g., MTA5 to MTA23)
within the period of time set by this object.
Failure to comply with this condition constitutes
a provisioning flow failure. If the object is set to 0,
the MTA MUST ignore the provisioning timer condition.
If a value is written into an instance of
pktcMtaDevProvisioningTimer, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
DEFVAL {10}
::= {pktcMtaDevBase 10}
「食糧を供給する流動が完成するように、このオブジェクトは時間間隔を定義する」記述。 MTA MUSTは、MTAがMTAが期間セットの中でこのオブジェクトで、構成ファイル(例えば、MTA23へのMTA5)をダウンロードする瞬間にそのDHCP ACKと結末を受ける瞬間から始める操作にすべて食糧を供給し終えます。 この状態に従わない場合、食糧を供給している流れ失敗を構成します。 オブジェクトが0に設定されるなら、MTA MUSTは食糧を供給しているタイマ状態を無視します。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevProvisioningTimerのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 DEFVAL10:、:= pktcMtaDevBase10
pktcMtaDevProvisioningCounter OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object counts the number of times the
provisioning cycle has looped through step MTA-1."
::= {pktcMtaDevBase 11}
pktcMtaDevProvisioningCounter OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「食糧を供給するサイクルがステップMTA-1を通して輪にした回数を数えこれが反対するします」。 ::= pktcMtaDevBase11
pktcMtaDevErrorOidsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table contains the list of configuration errors or
warnings the MTA encountered when parsing the
configuration file it received from the Provisioning
Server.
For each error, an entry is created in this table,
containing the configuration parameters the MTA rejected
and the associated reason (e.g., wrong or unknown OID,
inappropriate object values). If the MTA
did not report a provisioning state of 'pass(1)' in
the pktcMtaDevProvisioningState object, this table MUST be
populated for each error or warning instance. Even if
different parameters share the same error type (e.g., all
realm name configuration parameters are invalid), all
observed errors or warnings must be reported as
different instances. Errors are placed into the table in
no particular order. The table MUST be cleared each time
このテーブルはそれがProvisioning Serverから受け取った構成ファイルを分析するときMTAが遭遇した構成誤りか警告のリストを含んでいます。pktcMtaDevErrorOidsTable OBJECT-TYPEのSYNTAX SEQUENCE OF PktcMtaDevErrorOidsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「各誤りにおいて、エントリーはこのテーブルで作成されます、MTAが拒絶した設定パラメータと関連理由(例えば、間違ったか未知のOID、不適当なオブジェクト値)を含んでいて」。 MTAがpktcMtaDevProvisioningStateオブジェクトで'パス(1)'の食糧を供給する状態を報告しなかったなら、それぞれの誤りか警告インスタンスのためにこのテーブルに居住しなければなりません。 異なったパラメタが同じ誤りタイプを共有しても(例えばすべての分野名前設定パラメータが無効です)、すべてが、異なったインスタンスとして誤りか警告を報告しなければならないのを観測しました。 誤りは特に決まった順番でなくテーブルに置かれます。 その都度、テーブルをきれいにしなければなりません。
Nechamkin & Mule Standards Track [Page 16] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[16ページ]。
the MTA reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= {pktcMtaDevBase 12 }
「MTAはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 ::= pktcMtaDevBase12
pktcMtaDevErrorOidsEntry OBJECT-TYPE
SYNTAX PktcMtaDevErrorOidsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This entry contains the necessary information the MTA MUST
attempt to provide in case of configuration file errors or
warnings."
INDEX { pktcMtaDevErrorOidIndex }
::= {pktcMtaDevErrorOidsTable 1}
「このエントリーは構成ファイル誤りか警告の場合に提供するためにMTA MUSTが試みる必要事項を含む」pktcMtaDevErrorOidsEntry OBJECT-TYPE SYNTAX PktcMtaDevErrorOidsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述。 pktcMtaDevErrorOidIndexに索引をつけてください:、:= pktcMtaDevErrorOidsTable1
PktcMtaDevErrorOidsEntry ::= SEQUENCE {
pktcMtaDevErrorOidIndex Unsigned32,
pktcMtaDevErrorOid SnmpAdminString,
pktcMtaDevErrorValue SnmpAdminString,
pktcMtaDevErrorReason SnmpAdminString
}
PktcMtaDevErrorOidsEntry:、:= 系列pktcMtaDevErrorOidIndex Unsigned32、pktcMtaDevErrorOid SnmpAdminString、pktcMtaDevErrorValue SnmpAdminString、pktcMtaDevErrorReason SnmpAdminString
pktcMtaDevErrorOidIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..1024)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object is the index of the MTA configuration error
table. It is an integer value that starts at value '1'
and is incremented for each encountered configuration
file error or warning.
pktcMtaDevErrorOidIndex OBJECT-TYPE SYNTAX Unsigned32(1 .1024)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「これが、反対するMTA構成誤りテーブルのインデックスです」。 それは値'1'で始まって、各遭遇している構成ファイル誤りか警告のために増加される整数値です。
The maximum number of errors or warnings that can be
recorded in the pktcMtaDevErrorOidsTable is set to 1024 as
a configuration file is usually validated by operators
before deployment. Given the possible number of
configuration parameter assignments in the MTA
configuration file, 1024 is perceived as a sufficient
limit even with future extensions.
構成ファイルが展開の前にオペレータによって通常有効にされるとき、pktcMtaDevErrorOidsTableに記録できる誤りか警告の最大数は1024に設定されます。 考えて、MTA構成ファイルの設定パラメータ課題の可能な数、1024は十分な限界として今後の拡大を伴って知覚されます。
If the number of the errors in the configuration file
exceeds 1024, all errors beyond the 1024th one MUST
be ignored and not be reflected in the
pktcMtaDevErrorOidsTable."
「構成ファイルの誤りの数が1024を超えているなら、1024番目のものを超えたすべての誤りを無視されて、pktcMtaDevErrorOidsTableに反映しなければならないというわけではありません。」
::= {pktcMtaDevErrorOidsEntry 1}
::= pktcMtaDevErrorOidsEntry1
Nechamkin & Mule Standards Track [Page 17] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[17ページ]。
pktcMtaDevErrorOid OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a human readable representation
(character string) of the OID corresponding to the
configuration file parameter that caused the particular
error.
For example, if the value of the pktcMtaDevEnabled object
in the configuration file caused an error, then this
object instance will contain the human-readable string of
'1.3.6.1.2.1.140.1.1.6.0'.
If the MTA generated an error because it was not able
to recognize a particular OID, then this object
instance would contain an empty value (zero-length
string).
For example, if the value of an OID in the configuration
file was interpreted by the MTA as being 1.2.3.4.5, and if
the MTA was not able to recognize this OID as a valid one,
this object instance will contain a zero-length string.
pktcMtaDevErrorOid OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「特別の誤りを引き起こした構成ファイルパラメタに対応するOIDの人間の読み込み可能な表現(文字列)を含これが反対するしています」。 例えば、構成ファイルのpktcMtaDevEnabledオブジェクトの値が誤りを引き起こしたなら、このオブジェクトインスタンスは'1.3の人間読み込み可能なストリングを含むでしょう。.6 .1 .2 .1 .140 .1 .1 .6 .0'。 特定のOIDを認識できなかったのでMTAがエラーを起こすなら、このオブジェクトインスタンスは空の値(ゼロ長ストリング)を含んでいるでしょうに。 構成ファイルのOIDの値が例えば存在1.2.3としてMTAによって解釈された、.4、.5、MTAが、このOIDが有効なものであると認めることができなかったと、このオブジェクトインスタンスはゼロ長ストリングを含むでしょう。
If the number of errors in the configuration file exceeds
1024, then for all subsequent errors, the
pktcMtaDevErrorOid of the table's 1024th entry MUST
contain a human-readable representation of the
pktcMtaDevErrorsTooManyErrors object; i.e., the string
'1.3.6.1.2.1.140.1.1.4.1.0'.
Note that the syntax of this object is SnmpAdminString
instead of OBJECT IDENTIFIER because the object value may
not be a valid OID due to human or configuration tool
encoding errors."
構成ファイルのエラー回数が1024を超えているなら、すべてのその後の誤りによって、テーブルの1024番目のエントリーのpktcMtaDevErrorOidはpktcMtaDevErrorsTooManyErrorsオブジェクトの人間読み込み可能な表現を含まなければなりません。 '1.3を結んでください。すなわち、.6 .1 .2 .1 .140 .1 .1 .4 .1 .0'。 「誤りをコード化する人間か構成ツールのためオブジェクト値が有効なOIDでないかもしれないのでこのオブジェクトの構文がOBJECT IDENTIFIERの代わりにSnmpAdminStringであることに注意してください。」
::= {pktcMtaDevErrorOidsEntry 2}
::= pktcMtaDevErrorOidsEntry2
pktcMtaDevErrorValue OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the value of the OID corresponding to
the configuration file parameter that caused the error.
If the MTA cannot recognize the OID of the
configuration parameter causing the error, then this
object instance contains the OID itself as interpreted
by the MTA in human-readable representation.
If the MTA can recognize the OID but generate an error due
to a wrong value of the parameter, then the object
pktcMtaDevErrorValue OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「誤りを引き起こした構成ファイルパラメタに対応するOIDの値を含これが反対するしています」。 MTAが誤りを引き起こす設定パラメータのOIDを認識できないなら、人間読み込み可能な表現でMTAによって解釈されるようにこのオブジェクトインスタンスはOID自身を含んでいます。 MTAが次に、パラメタの間違った値、オブジェクトのためOIDを認識しますが、エラーを起こすことができるなら
Nechamkin & Mule Standards Track [Page 18] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[18ページ]。
instance contains the erroneous value of the parameter as
read from the configuration file.
In both cases, the value of this object must be
represented in human-readable form as a character string.
For example, if the value of the pktcMtaDevEnabled object
in the configuration file was 3 (invalid value), then the
pktcMtaDevErrorValue object instance will contain the
human-readable (string) representation of value '3'.
Similarly, if the OID in the configuration file has been
interpreted by the MTA as being 1.2.3.4.5 and the MTA
cannot recognize this OID as a valid one, then this
pktcMtaDevErrorValue object instance will contain human
readable (string) representation of value '1.2.3.4.5'.
インスタンスは構成ファイルから読まれるようにパラメタの誤った値を含んでいます。 どちらの場合も、文字列として人間読み込み可能なフォームにこのオブジェクトの値を表さなければなりません。 例えば、構成ファイルのpktcMtaDevEnabledオブジェクトの値が3(無効の値)であったなら、pktcMtaDevErrorValueオブジェクトインスタンスは価値'3'の人間読み込み可能な(ストリング)表現を含むでしょう。 構成ファイルのOIDが存在1.2.3としてMTAによって解釈されたなら、同様に、例証する.5とMTAが、認めることができない有効なものとしてのこのOID、当時のこのpktcMtaDevErrorValueが意志を反対させる.4が価値の人間の読み込み可能な(ストリング)表現を含んでいます。'1.2 .3 .4 .5'。
If the number of errors in the configuration file exceeds
1024, then for all subsequent errors, the
pktcMtaDevErrorValue of the table's 1024th entry MUST
contain a human-readable representation of the
pktcMtaDevErrorsTooManyErrors object; i.e., the string
'1.3.6.1.2.1.140.1.1.4.1.0'."
構成ファイルのエラー回数が1024を超えているなら、すべてのその後の誤りによって、テーブルの1024番目のエントリーのpktcMtaDevErrorValueはpktcMtaDevErrorsTooManyErrorsオブジェクトの人間読み込み可能な表現を含まなければなりません。 「すなわち、ストリング'1.3.6、.1、.2、.1、.140、.1、.1、.4、.1、.0、'」
::= {pktcMtaDevErrorOidsEntry 3}
::= pktcMtaDevErrorOidsEntry3
pktcMtaDevErrorReason OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object indicates the reason for the error or warning,
as per the MTA's interpretation, in human-readable form.
For example:
'VALUE NOT IN RANGE', 'VALUE DOES NOT MATCH TYPE',
'UNSUPPORTED VALUE', 'LAST 4 BITS MUST BE SET TO ZERO',
'OUT OF MEMORY - CANNOT STORE'.
This object may also contain vendor specific errors for
private vendor OIDs and any proprietary error codes or
messages that can help diagnose configuration errors.
pktcMtaDevErrorReason OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「人間読み込み可能なフォームで誤りの理由かMTAの解釈に従って警告を示これが反対するします」。 例えば: '値は、NOTマッチタイプ、メモリから'値のNOT IN範囲'ように''サポートされない値'、'ベスト4ビットをゼロに設定'でなければならない'--保存しない、' また、このオブジェクトは構成誤りを診断するのを助けることができるどんな私設のベンダーOIDsのためのベンダーの特定の誤りと独占エラーコードやメッセージも含むかもしれません。
If the number of errors in the configuration file exceeds
1024, then for all subsequent errors, the
pktcMtaDevErrorReason of the table's 1024th entry MUST
contain a human-readable string indicating the reason
for an error; for example,
'Too many errors in the configuration file'."
::= {pktcMtaDevErrorOidsEntry 4}
構成ファイルのエラー回数が1024を超えているなら、すべてのその後の誤りによって、テーブルの1024番目のエントリーのpktcMtaDevErrorReasonは誤りの理由を示す人間読み込み可能なストリングを含まなければなりません。 「例えば、'構成ファイルにおけるあまりに多くの誤り'。」 ::= pktcMtaDevErrorOidsEntry4
-- -- The following group describes server access and parameters used
-- -- 以下のグループはアクセスとパラメタが使用したサーバについて説明します。
Nechamkin & Mule Standards Track [Page 19] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[19ページ]。
-- for the initial MTA provisioning and bootstrapping phases. --
-- フェーズに食糧を供給して、独力で進む初期のMTAのために。 --
pktcMtaDevDhcpServerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet address type for the
PacketCable DHCP servers specified in MTA MIB."
DEFVAL { ipv4 }
::= { pktcMtaDevServer 1}
pktcMtaDevDhcpServerAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA MIBで指定されたPacketCable DHCPサーバのためのインターネット・アドレスタイプを含これが反対するしています」。 DEFVAL ipv4:、:= pktcMtaDevServer1
pktcMtaDevServerDhcp1 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet Address of the primary
DHCP server the MTA uses during provisioning.
The type of this address is determined by the value of
the pktcMtaDevDhcpServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the primary DHCP
server. It is provided by the CM to the MTA via the DHCP
option code 122, sub-option 1, as defined in RFC 3495.
pktcMtaDevServerDhcp1 OBJECT-TYPE SYNTAX InetAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTAが食糧を供給している間に使用するプライマリDHCPサーバのインターネットAddressを含これが反対するしています」。 このアドレスのタイプはpktcMtaDevDhcpServerAddressTypeオブジェクトの値で決定します。 後者に値の'ipv4(1)'があるとき、このオブジェクトはプライマリDHCPサーバのIPアドレスを含んでいます。CMでDHCPオプションコード122、サブオプション1でそれをMTAに提供します、RFC3495で定義されるように。
The behavior of this object when the value of
pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)'
is not presently specified, but it may be specified
in future versions of this MIB module.
If this object is of value
0.0.0.0, the MTA MUST stop all provisioning
attempts, as well as all other activities.
If this object is of value 255.255.255.255, it means
that there was no preference given for the primary
DHCP server, and, the MTA must follow the logic of
RFC2131, and the value of DHCP option 122,
sub-option 2, must be ignored."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2131, Dynamic Host Configuration Protocol;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 2 }
現在、'ipv4(1)'を除いて、pktcMtaDevDhcpServerAddressTypeの値があるとき、このオブジェクトの動きは指定されませんが、それはこのMIBモジュールの将来のバージョンで指定されるかもしれません。 このオブジェクトで価値がある、0.0、.0、.0、MTA MUST停止が試みにすべて食糧を供給して、他のすべての活動と同じくらい良いです。 「このオブジェクトで価値がある、255.255、.255、.255、プライマリDHCPサーバのために与えられた優先が全くなかったことを意味して、MTAがRFC2131の論理に従わなければならなくて、DHCPオプション122の値(サブオプション2)を無視しなければならない、」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 RFC2131、ダイナミックなホスト構成プロトコル。 「RFC3495、CableLabsクライアント構成のためのDHCPオプション。」 ::= pktcMtaDevServer2
pktcMtaDevServerDhcp2 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-only
pktcMtaDevServerDhcp2 OBJECT-TYPE SYNTAX InetAddressマックス-ACCESS書き込み禁止
Nechamkin & Mule Standards Track [Page 20] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[20ページ]。
STATUS current
DESCRIPTION
" This object contains the Internet Address of the secondary
DHCP server the MTA uses during provisioning.
The type of this address is determined by the value of
the pktcMtaDevDhcpServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the secondary DHCP
server. It is provided by the CM to the MTA via the DHCP
option code 122, sub-option 2, as defined in RFC 3495.
STATUSの現在の記述は「MTAが食糧を供給している間に使用するセカンダリDHCPサーバのインターネットAddressを含これが反対するしています」。 このアドレスのタイプはpktcMtaDevDhcpServerAddressTypeオブジェクトの値で決定します。 後者に値の'ipv4(1)'があるとき、このオブジェクトはセカンダリDHCPサーバのIPアドレスを含んでいます。CMでDHCPオプションコード122、サブオプション2でそれをMTAに提供します、RFC3495で定義されるように。
The behavior of this object when the value of
pktcMtaDevDhcpServerAddressType is other than 'ipv4(1)'
is not presently specified, but it may be specified
in future versions of this MIB module.
If there was no secondary DHCP server provided in DHCP
Option 122, sub-option 2, this object must return the value
0.0.0.0."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 3 }
現在、'ipv4(1)'を除いて、pktcMtaDevDhcpServerAddressTypeの値があるとき、このオブジェクトの動きは指定されませんが、それはこのMIBモジュールの将来のバージョンで指定されるかもしれません。 「あったなら、どんなセカンダリDHCPサーバもDHCP Option122、サブオプション2、このオブジェクトが値0.0の.0を返さなければならないコネに.0を提供しませんでした。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「RFC3495、CableLabsクライアント構成のためのDHCPオプション。」 ::= pktcMtaDevServer3
pktcMtaDevDnsServerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet address type for the
PacketCable DNS servers specified in MTA MIB."
DEFVAL { ipv4 }
::= { pktcMtaDevServer 4}
pktcMtaDevDnsServerAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA MIBで指定されたPacketCable DNSサーバのためのインターネット・アドレスタイプを含これが反対するしています」。 DEFVAL ipv4:、:= pktcMtaDevServer4
pktcMtaDevServerDns1 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the IP Address of the primary
DNS server to be used by the MTA. The type of this address
is determined by the value of the
pktcMtaDevDnsServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the primary DNS server.
As defined in RFC 2132, PacketCable-compliant MTAs receive
the IP addresses of the DNS Servers in DHCP option 6.
The behavior of this object when the value of
pktcMtaDevDnsServerAddressType is other than 'ipv4(1)'
pktcMtaDevServerDns1 OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「このオブジェクトはMTAによって使用されるべきプライマリDNSサーバのIP Addressを含んでいること」をSTATUSの現在の記述に読書して書きます。 このアドレスのタイプはpktcMtaDevDnsServerAddressTypeオブジェクトの値で決定します。 後者に値の'ipv4(1)'があるとき、このオブジェクトはプライマリDNSサーバのIPアドレスを含んでいます。RFC2132で定義されるように、PacketCable対応することのMTAsはDHCPオプション6でDNS ServersのIPアドレスを受け取ります。 'ipv4(1)'を除いて、pktcMtaDevDnsServerAddressTypeの値があるときのこのオブジェクトの動き
Nechamkin & Mule Standards Track [Page 21] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[21ページ]。
is not presently specified, but it may be specified
in future versions of this MIB module.
If a value is written into an instance of
pktcMtaDevServerDns1, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 5 }
現在指定されていなくて、このMIBモジュールの将来のバージョンでそれだけを指定してもよいです。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevServerDns1のインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「RFC2132、DHCPオプション、およびBOOTPベンダー拡張子。」 ::= pktcMtaDevServer5
pktcMtaDevServerDns2 OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the IP Address of the secondary
DNS server to be used by the MTA. The type of this address
is determined by the value of the
pktcMtaDevDnsServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the secondary DNS
server. As defined in RFC 2132, PacketCable-compliant MTAs
receive the IP addresses of the DNS Servers in DHCP
option 6.
The behavior of this object when the value of
pktcMtaDevDnsServerAddressType is other than 'ipv4(1)'
is not presently specified, but it may be specified
in future versions of this MIB module.
If a value is written into an instance of
pktcMtaDevServerDns2, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 6 }
pktcMtaDevServerDns2 OBJECT-TYPE SYNTAX InetAddressマックス-ACCESSは「このオブジェクトはMTAによって使用されるべきセカンダリDNSサーバのIP Addressを含んでいること」をSTATUSの現在の記述に読書して書きます。 このアドレスのタイプはpktcMtaDevDnsServerAddressTypeオブジェクトの値で決定します。 後者に値の'ipv4(1)'があるとき、このオブジェクトはセカンダリDNSサーバのIPアドレスを含んでいます。RFC2132で定義されるように、PacketCable対応することのMTAsはDHCPオプション6でDNS ServersのIPアドレスを受け取ります。 現在、'ipv4(1)'を除いて、pktcMtaDevDnsServerAddressTypeの値があるとき、このオブジェクトの動きは指定されませんが、それはこのMIBモジュールの将来のバージョンで指定されるかもしれません。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevServerDns2のインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「RFC2132、DHCPオプション、およびBOOTPベンダー拡張子。」 ::= pktcMtaDevServer6
pktcMtaDevTimeServerAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the Internet address type for the
PacketCable Time servers specified in MTA MIB."
DEFVAL { ipv4 }
::= { pktcMtaDevServer 7}
pktcMtaDevTimeServerAddressType OBJECT-TYPE SYNTAX InetAddressTypeのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA MIBで指定されたPacketCable Timeサーバのためのインターネット・アドレスタイプを含これが反対するしています」。 DEFVAL ipv4:、:= pktcMtaDevServer7
pktcMtaDevTimeServer OBJECT-TYPE
SYNTAX InetAddress
pktcMtaDevTimeServerオブジェクト・タイプ構文InetAddress
Nechamkin & Mule Standards Track [Page 22] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[22ページ]。
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the Internet Address of the Time
Server used by an S-MTA for Time Synchronization. The type
of this address is determined by the value of the
pktcMtaDevTimeServerAddressType object.
When the latter has the value 'ipv4(1)', this object
contains the IP address of the Time Server used for Time
Synchronization.
In the case of an S-MTA, this object must be
populated with a value other than 0.0.0.0 as obtained
from DHCP option 4. The protocol by which the time of day
MUST be retrieved is defined in RFC 868.
In the case of an E-MTA, this object must contain a
value of 0.0.0.0 if the address type is 'ipv4(1)' since
an E-MTA does not use the Time Protocol for time
synchronization (an E-MTA uses the time retrieved by the
DOCSIS cable modem).
The behavior of this object when the value of
pktcMtaDevTimeServerAddressType is other than 'ipv4(1)'
is not presently specified, but it may be specified in
future versions of this MIB module.
If a value is written into an instance of
pktcMtaDevTimeServer, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" RFC 868, Time Protocol;
RFC 2131, Dynamic Host Configuration Protocol;
RFC 2132, DHCP Options and BOOTP Vendor Extensions."
::= { pktcMtaDevServer 8}
マックス-ACCESSは「このオブジェクトはTime SynchronizationにS-MTAによって使用されたTime ServerのインターネットAddressを含んでいること」をSTATUSの現在の記述に読書して書きます。 このアドレスのタイプはpktcMtaDevTimeServerAddressTypeオブジェクトの値で決定します。 後者に値の'ipv4(1)'があるとき、このオブジェクトはTime Synchronizationに使用されるTime ServerのIPアドレスを含んでいます。 S-MTAの場合では、0.0以外の値でこのオブジェクトに居住しなければなりません。.0 DHCPオプション4からの得られるとしての.0。 時刻を検索しなければならないプロトコルはRFC868で定義されます。 E-MTAの場合に、このオブジェクトは0.0の値を含まなければなりません。.0 アドレスがタイプするなら、E-MTAが時間同期化にTimeプロトコルを使用しないので(E-MTAはDOCSISケーブルモデムによって検索された時間を費やします)、.0は'ipv4(1)'です。 現在、'ipv4(1)'を除いて、pktcMtaDevTimeServerAddressTypeの値があるとき、このオブジェクトの動きは指定されませんが、それはこのMIBモジュールの将来のバージョンで指定されるかもしれません。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevTimeServerのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「RFC868、時間プロトコル」という参照。 RFC2131、ダイナミックなホスト構成プロトコル。 「RFC2132、DHCPオプション、およびBOOTPベンダー拡張子。」 ::= pktcMtaDevServer8
pktcMtaDevConfigFile OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object specifies the MTA device configuration file
information, including the access method, the server name,
and the configuration file name. The value of this object
is the Uniform Resource Locator (URL) of the configuration
file for TFTP or HTTP download.
If this object value is a TFTP URL, it must be formatted
as defined in RFC 3617.
If this object value is an HTTP URL, it must be formatted
as defined in RFC 2616.
If the MTA SNMP Enrollment mechanism is used, then the MTA
must download the file provided by the Provisioning Server
pktcMtaDevConfigFile OBJECT-TYPE SYNTAX SnmpAdminStringマックス-ACCESSは「このオブジェクトがMTAデバイス構成ファイル情報を指定します、アクセス法、サーバー名、および構成ファイル名を含んでいて」STATUSの現在の記述に読書して書きます。 このオブジェクトの値はTFTPのための構成ファイルかHTTPダウンロードのUniform Resource Locator(URL)です。 このオブジェクト値がTFTP URLであるなら、RFC3617で定義されるようにそれをフォーマットしなければなりません。 このオブジェクト値がHTTP URLであるなら、RFC2616で定義されるようにそれをフォーマットしなければなりません。 MTA SNMP Enrollmentメカニズムが使用されているなら、MTAはProvisioning Serverによって提供されたファイルをダウンロードしなければなりません。
Nechamkin & Mule Standards Track [Page 23] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[23ページ]。
during provisioning via an SNMP SET on this object.
If the MTA SNMP Enrollment mechanism is not used, this
object MUST contain the URL value corresponding to the
'siaddr' and 'file' fields received in the DHCP ACK to
locate the configuration file: the 'siaddr' and 'file'
fields represent the host and file of the TFTP URL,
respectively. In this case, the MTA MUST return an
'inconsistentValue' error in response to SNMP SET
operations.
The MTA MUST return a zero-length string if the server
address (host part of the URL) is unknown.
If a value is written into an instance of
pktcMtaDevConfigFile, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3617, URI Scheme for TFTP; RFC 2616, HTTP 1.1"
::= { pktcMtaDevServer 9 }
これのSNMP SETを通した食糧を供給している間、反対してください。 MTA SNMP Enrollmentメカニズムが使用されていないなら、このオブジェクトは構成ファイルの場所を見つけるようにDHCP ACKに受け取られた'siaddr'と'ファイル'野原に対応するURL値を含まなければなりません: 'siaddr'と'ファイル'分野はそれぞれTFTP URLのホストとファイルの代理をします。 この場合、MTA MUSTはSNMP SET操作に対応して'inconsistentValue'誤りを返します。 サーバアドレス(URLのホスト部分)が未知であるなら、MTA MUSTはゼロ長ストリングを返します。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevConfigFileのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 RFC3617、TFTPのURI体系。 RFC2616、HTTP1.1インチ:、:= pktcMtaDevServer9
pktcMtaDevSnmpEntity OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the FQDN of the SNMP entity of the
Provisioning Server. When the MTA SNMP Enrollment
Mechanism is used, this object represents the server that
the MTA communicates with, that it receives the
configuration file URL from, and that it sends the
enrollment notification to. The SNMP entity is also the
destination entity for all the provisioning
notifications. It may be used for post-provisioning
SNMP operations. During the provisioning phase, this
SNMP entity FQDN is supplied to the MTA via DHCP option
122, sub-option 3, as defined in RFC 3495. The MTA must
resolve the FQDN value before its very first network
interaction with the SNMP entity during the provisioning
phase."
このオブジェクトはProvisioning ServerのSNMP実体のFQDNを含んでいます。pktcMtaDevSnmpEntity OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「. いつからのMTA SNMP Enrollment Mechanismによる使用されて、このオブジェクトがMTAが交信するサーバを表して、構成ファイルURLを受けるということであるか、登録通知を送る、」 また、SNMP実体はすべての食糧を供給する通知のための目的地実体です。 それはポストに食糧を供給するSNMP操作に使用されるかもしれません。 食糧を供給する段階の間、DHCPオプション122、サブオプション3でこのSNMP実体FQDNをMTAに供給します、RFC3495で定義されるように。 「MTAはSNMP実体とのかなりの最初のネットワーク相互作用の前に食糧を供給する段階の間、FQDN値を決議しなければなりません。」
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 10 }
「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「RFC3495、CableLabsクライアント構成のためのDHCPオプション。」 ::= pktcMtaDevServer10
pktcMtaDevProvConfigHash OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(20))
MAX-ACCESS read-write
STATUS current
pktcMtaDevProvConfigHash OBJECT-TYPE SYNTAX OCTET STRING、(SIZE(20)) MAX-ACCESSはSTATUSに電流を読書して書きます。
Nechamkin & Mule Standards Track [Page 24] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[24ページ]。
DESCRIPTION
" This object contains the hash value of the contents of the
configuration file.
The authentication algorithm is Secure Hashing Algorithm
1 (SHA-1), and the length is 160 bits. The hash
calculation MUST follow the requirements defined in the
PacketCable Security Specification. When the MTA SNMP
Enrollment mechanism is used, this hash value is
calculated and sent to the MTA prior to sending the
config file. This object value is then provided by the
Provisioning server via an SNMP SET operation.
When the MTA SNMP Enrollment mechanism is not in use, the
hash value is provided in the configuration file itself,
and it is also calculated by the MTA. This object value
MUST represent the hash value calculated by the MTA.
When the MTA SNMP Enrollment mechanism is not in use, the
MTA must reject all SNMP SET operations on this object and
return an 'inconsistentValue' error.
If a value is written into an instance of
pktcMtaDevProvConfigHash, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification."
::= { pktcMtaDevServer 11 }
記述は「構成ファイルのコンテンツのハッシュ値を含これが反対するしています」。 認証アルゴリズムはSecure Hashing Algorithm1です(SHA-1)、そして、長さは160ビットです。 ハッシュ計算はPacketCable Security Specificationで定義された要件に続かなければなりません。 MTA SNMP Enrollmentメカニズムが使用されているとき、コンフィグファイルを送る前に、このハッシュ値をMTAに計算して、送ります。 そして、ProvisioningサーバはSNMP SET操作でこのオブジェクト値を提供します。 MTA SNMP Enrollmentメカニズムが使用中でないときに、ハッシュ値を構成ファイル自体に提供します、そして、また、MTAはそれについて計算します。 このオブジェクト値はMTAによって計算されたハッシュ値を表さなければなりません。 MTA SNMP Enrollmentメカニズムが使用中でないときに、MTAはこのオブジェクトにおけるすべてのSNMP SET操作を拒絶して、'inconsistentValue'誤りを返さなければなりません。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevProvConfigHashのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「PacketCableセキュリティ仕様。」 ::= pktcMtaDevServer11
pktcMtaDevProvConfigKey OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(32))
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object contains the key used to encrypt/decrypt
the configuration file when secure SNMPv3 provisioning
is used.
The value of this object is provided along with the
configuration file information (pktcMtaDevConfigFile)
and hash (pktcMtaDevProvConfigHash) by the Provisioning
Server via SNMP SET once the configuration file has been
created, as defined by the PacketCable Security
specification.
pktcMtaDevProvConfigKey OBJECT-TYPE SYNTAX OCTET STRING、(SIZE(32)) MAX-ACCESSは「このオブジェクトは安全なSNMPv3の食糧を供給するのが使用されているとき、構成ファイルを暗号化するか、または解読するのに使用されるキーを含んでいること」をSTATUSの現在の記述に読書して書きます。 構成ファイルがいったん作成されると、このオブジェクトの値は構成ファイル情報(pktcMtaDevConfigFile)とハッシュ(pktcMtaDevProvConfigHash)と共にSNMP SETを通してProvisioning Serverによって提供されます、PacketCable Security仕様で定義されるように。
The privacy algorithm is defined by the
pktcMtaDevProvConfigEncryptAlg MIB object. The
MTA requirements related to the privacy algorithm are
defined in the PacketCable Security Specification.
プライバシーアルゴリズムはpktcMtaDevProvConfigEncryptAlg MIBオブジェクトによって定義されます。 プライバシーアルゴリズムに関連するMTA要件はPacketCable Security Specificationで定義されます。
If this object is set at any other provisioning step than
that allowed by the PacketCable MTA Device
このオブジェクトがPacketCable MTA Deviceによって許容されたそれよりいかなる他の食糧を供給するステップにも設定されるなら
Nechamkin & Mule Standards Track [Page 25] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[25ページ]。
Provisioning Specification, the MTA SHOULD return
an 'inconsistentValue' error.
This object must not be used in non secure provisioning
mode. In non-secure provisioning modes, the MTA SHOULD
return an 'inconsistentValue' in response to SNMP SET
operations, and the MTA SHOULD return a zero-length
string in response to SNMP GET operations.
If a value is written into an instance of
pktcMtaDevProvConfigKey, the agent MUST NOT retain the
supplied value across MTA re-initializations or reboots."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification."
::= { pktcMtaDevServer 12 }
Specificationに食糧を供給して、MTA SHOULDは'inconsistentValue'誤りを返します。 非安全な食糧を供給するモードでこのオブジェクトを使用してはいけません。 非安全な食糧を供給するモードで、MTA SHOULDはSNMP SET操作に対応して'inconsistentValue'を返します、そして、MTA SHOULDはSNMP GET操作に対応してゼロ長ストリングを返します。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevProvConfigKeyのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「PacketCableセキュリティ仕様。」 ::= pktcMtaDevServer12
pktcMtaDevProvConfigEncryptAlg OBJECT-TYPE
SYNTAX PktcMtaDevProvEncryptAlg
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object defines the encryption algorithm used for
privacy protection of the MTA Configuration File content."
DEFVAL { des64CbcMode }
::= { pktcMtaDevServer 13 }
pktcMtaDevProvConfigEncryptAlg OBJECT-TYPE SYNTAX PktcMtaDevProvEncryptAlgマックス-ACCESSは「このオブジェクトはMTA Configuration File内容のプライバシー保護に使用される暗号化アルゴリズムを定義すること」をSTATUSの現在の記述に読書して書きます。 DEFVAL des64CbcMode:、:= pktcMtaDevServer13
pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE
SYNTAX Unsigned32 (0..180)
UNITS "seconds"
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object defines a Kerberos Key Management timer on the
MTA. It is the time period during which the MTA saves the
nonce and Server Kerberos Principal Identifier to match an
AP Request and its associated AP Reply response from the
Provisioning Server.
After the timeout has been exceeded, the client discards
this (nonce, Server Kerberos Principal Identifier) pair,
after which it will no longer accept a matching AP Reply.
This timer only applies when the Provisioning Server
initiated key management for SNMPv3 (with a
Wake Up message).
If this object is set to a zero value, the MTA MUST return
an 'inconsistentValue' in response to SNMP SET operations.
This object should not be used in non-secure provisioning
modes. In non-secure provisioning modes, the MTA MUST
return an 'inconsistentValue' in response to SNMP SET
operations, and the MTA MUST return a zero value in
pktcMtaDevProvSolicitedKeyTimeout OBJECT-TYPE SYNTAX Unsigned32(0 .180)UNITS「秒」マックス-ACCESSは「このオブジェクトはMTAの上のケルベロスKey Managementタイマを定義すること」をSTATUSの現在の記述に読書して書きます。 それはMTAがProvisioning ServerからAP Requestとその関連AP Reply応答に合うように一回だけとServerケルベロスプリンシパルIdentifierを取っておく期間です。タイムアウトが超えられている後にクライアントはこの(一回だけ、ServerケルベロスプリンシパルIdentifier)組を捨てます。(その時、それはもう合っているAP Replyを受け入れなかったでしょう後)。 Provisioning ServerがSNMPv3(和氣Upメッセージがある)のためにかぎ管理に着手したときだけ、このタイマは適用されます。 このオブジェクトがaゼロ値に設定されるなら、MTA MUSTはSNMP SET操作に対応して'inconsistentValue'を返します。 非安全な食糧を供給するモードでこのオブジェクトを使用するべきではありません。 非安全な食糧を供給するモードで、MTA MUSTはSNMP SET操作に対応して'inconsistentValue'を返します、そして、MTA MUSTは中で値を全くaに返しません。
Nechamkin & Mule Standards Track [Page 26] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[26ページ]。
response to SNMP GET operations.
If a value is written into an instance of
pktcMtaDevProvSolicitedKeyTimeout, the agent MUST NOT
retain the supplied value across MTA re-initializations
or reboots."
DEFVAL { 3 }
::= { pktcMtaDevServer 14 }
SNMP GET操作への応答。 「MTA再初期化処理の向こう側に供給値を保有してはいけない、値がpktcMtaDevProvSolicitedKeyTimeoutのインスタンスに書かれるなら、さもなければ、エージェントはリブートします。」 DEFVAL3:、:= pktcMtaDevServer14
--================================================================= -- -- Unsolicited key updates are retransmitted according to an -- exponential back-off mechanism using two timers and a maximum -- retry counter for AS replies. -- The initial retransmission timer value is the nominal timer -- value (pktcMtaDevProvUnsolicitedKeyNomTimeout). The -- retransmissions occur with an exponentially increasing interval -- that caps at the maximum timeout value -- (pktcMtaDevProvUnsolicitedKeyMaxTimeout). -- Retransmissions stop when the maximum retry counter is reached -- (pktcMtaDevProvUnsolicitedKeyMaxRetries). -- For example, with values of 3 seconds for the nominal -- timer, 100 seconds for the maximum timeout, and 8 retries max, -- and with an exponential value of 2, this results in -- retransmission intervals will be 3 s, 6 s, 12 s, 24 s, 48 s, -- 96 s, 100 s, and 100 s; -- retransmissions then stop because the maximum number of -- retries (8) has been reached. -- --================================================================= -- -- Timeouts for unsolicited key management updates are only -- pertinent before the first SNMPv3 message is sent between the -- MTA and the Provisioning Server and before the configuration -- file is loaded. -- --=================================================================
--================================================================= -- -- --2個のタイマと最大を使用する指数の下に後部メカニズム--再試行カウンタに従って、求められていない主要なアップデートはAS回答のために再送されます。 -- 初期の再送信タイマー値は名目上のタイマです--値(pktcMtaDevProvUnsolicitedKeyNomTimeout)。 --「再-トランスミッション」は指数関数的に増加する間隔で現れます(pktcMtaDevProvUnsolicitedKeyMaxTimeout)。(最大のタイムアウトの上限はそれを評価します)。 -- 最大の再試行カウンタに達しているとき、Retransmissionsは止まります--(pktcMtaDevProvUnsolicitedKeyMaxRetries。) -- 例えば、タイマ、最大のタイムアウトのための100秒、および8つの再試行が最大限にするという名目上のための3秒の値と2の指数の値で、これは中に結果として生じます--再送信間隔は3秒間になるでしょう、6秒間、12秒間、24秒間、48秒間--96秒間、100秒間、および100秒間 -- 次に、「再-トランスミッション」が止まる、最大数、--再試行(8)に達しました。 -- --================================================================= -- -- 求められていないかぎ管理アップデートのためのタイムアウトがそうである、単に--、適切である、最初のSNMPv3メッセージに発信する前、--、MTA、構成--Provisioning Serverとファイルする前に、ロードされています。 -- --=================================================================
pktcMtaDevProvUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (0..600)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the timeout value that applies to
an MTA-initiated AP-REQ/REP key management exchange with
the Provisioning Server in SNMPv3 provisioning.
It is the maximum timeout value, and it may not be exceeded
in the exponential back-off algorithm. If the DHCP option
pktcMtaDevProvUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32(0 .600)UNITS「秒」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「SNMPv3の食糧を供給することでProvisioning ServerとのMTAによって開始されたAP-REQ/REPかぎ管理交換に適用されるタイムアウト値を定義これが反対するします」。 それは最大のタイムアウト値です、そして、指数の下に後部アルゴリズムで超えられないかもしれません。 DHCPオプションです。
Nechamkin & Mule Standards Track [Page 27] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[27ページ]。
code 122, sub-option 5, is provided to the MTA, it
overwrites this value.
In non-secure provisioning modes, the MTA MUST
return a zero value in response to SNMP GET
operations."
REFERENCE
" PacketCable Security Specification."
DEFVAL {600}
::= { pktcMtaDevServer 15 }
コード122(サブオプション5)はMTAに、この値を上書きするかどうかということです。 「非安全な食糧を供給するモード、ゼロがSNMP GET操作に対応して評価するMTA MUSTリターン。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL600:、:= pktcMtaDevServer15
pktcMtaDevProvUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (0..600)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the starting value of the timeout
for the AP-REQ/REP Backoff and Retry mechanism
with exponential timeout in SNMPv3 provisioning.
If the DHCP option code 122, sub-option 5, is provided
the MTA, it overwrites this value.
In non-secure provisioning modes, the MTA MUST
return a zero value in response to SNMP GET
operations."
REFERENCE
" PacketCable Security Specification."
DEFVAL {3}
::= { pktcMtaDevServer 16}
pktcMtaDevProvUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32(0 .600)UNITS「秒」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「AP-REQ/REP BackoffとRetryメカニズムのために指数のタイムアウトでSNMPv3の食糧を供給することでタイムアウトの始めの値を定義これが反対するします」。 DHCPオプションコード122(サブオプション5)にMTAを提供するなら、それはこの値を上書きします。 「非安全な食糧を供給するモード、ゼロがSNMP GET操作に対応して評価するMTA MUSTリターン。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL3:、:= pktcMtaDevServer16
pktcMtaDevProvUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..32)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a retry counter that applies to
an MTA-initiated AP-REQ/REP key management exchange with
the Provisioning Server in secure SNMPv3 provisioning.
It is the maximum number of retries before the MTA stops
attempting to establish a Security Association with
Provisioning Server.
If the DHCP option code 122, sub-option 5, is provided to
the MTA, it overwrites this value.
If this object is set to a zero value, the MTA MUST return
an 'inconsistentValue' in response to SNMP SET operations.
In non-secure provisioning modes, the MTA MUST
return a zero value in response to SNMP GET
operations."
REFERENCE
pktcMtaDevProvUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32(0 .32)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「安全なSNMPv3の食糧を供給することでProvisioning ServerとのMTAによって開始されたAP-REQ/REPかぎ管理交換に適用される再試行カウンタを含これが反対するしています」。 MTAが、Provisioning Serverと共にSecurity Associationを設立するのを試みるのを止める前にそれは再試行の最大数です。DHCPオプションコード122(サブオプション5)をMTAに提供するなら、この値を上書きします。 このオブジェクトがaゼロ値に設定されるなら、MTA MUSTはSNMP SET操作に対応して'inconsistentValue'を返します。 「非安全な食糧を供給するモード、ゼロがSNMP GET操作に対応して評価するMTA MUSTリターン。」 参照
Nechamkin & Mule Standards Track [Page 28] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[28ページ]。
" PacketCable Security Specification."
DEFVAL {8}
::= { pktcMtaDevServer 17 }
「PacketCableセキュリティ仕様。」 DEFVAL8:、:= pktcMtaDevServer17
pktcMtaDevProvKerbRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the name of the associated
provisioning Kerberos realm acquired during the MTA4
provisioning step (DHCP Ack) for SNMPv3 provisioning.
The uppercase ASCII representation of the associated
Kerberos realm name MUST be used by both the Manager (SNMP
entity) and the MTA.
The Kerberos realm name for the Provisioning Server is
supplied to the MTA via DHCP option code 122, sub-option 6,
as defined in RFC 3495. In secure SNMP provisioning mode,
the value of the Kerberos realm name for the Provisioning
Server supplied in the MTA configuration file must match
the value supplied in the DHCP option code 122,
sub-option 6. Otherwise, the value of this object must
contain the value supplied in DHCP Option 122,
sub-option 6."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
RFC 3495, DHCP Option for CableLabs Client Configuration."
::= { pktcMtaDevServer 18 }
pktcMtaDevProvKerbRealmName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「ケルベロス分野がSNMPv3の食糧を供給するためにステップ(DHCP Ack)に食糧を供給するMTA4の間に取得した関連食糧を供給することの名前を含これが反対するしています」。 マネージャ(SNMP実体)とMTAの両方で関連ケルベロス分野名の大文字しているASCII表現を使用しなければなりません。 DHCPオプションコード122、サブオプション6でProvisioning Serverのためのケルベロス分野名前をMTAに提供します、RFC3495で定義されるように。 モードに食糧を供給する安全なSNMPでは、MTA構成ファイルで供給されたProvisioning Serverのためのケルベロス分野名の値はDHCPオプションコード122、サブオプション6で供給された値に合わなければなりません。 「さもなければ、このオブジェクトの値はDHCP Option122、サブオプション6で供給された値を含まなければなりません。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 「RFC3495、CableLabsクライアント構成のためのDHCPオプション。」 ::= pktcMtaDevServer18
pktcMtaDevProvState OBJECT-TYPE
SYNTAX INTEGER {
operational (1),
waitingForSnmpSetInfo (2),
waitingForTftpAddrResponse (3),
waitingForConfigFile (4)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object defines the MTA provisioning state.
If the state is:
pktcMtaDevProvState OBJECT-TYPE SYNTAX INTEGER、操作上の(1)、waitingForSnmpSetInfo(2)、waitingForTftpAddrResponse(3)、waitingForConfigFile(4)、マックス-ACCESSの読書だけのSTATUSの現在の記述は「状態に食糧を供給するMTAを定義これが反対するします」。 状態がそうなら:
'operational(1)', the device has completed the loading
and processing of the initialization parameters.
'操作上の(1)'、デバイスは初期化パラメタのローディングと処理を終了しました。
'waitingForSnmpSetInfo(2)', the device is waiting on
its configuration file download access information.
Note that this state is only reported when the MTA
デバイスは、構成ファイルダウンロードアクセス情報で'waitingForSnmpSetInfo(2)'と待っています。 MTAであるときにだけ、この状態が報告されることに注意してください。
Nechamkin & Mule Standards Track [Page 29] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[29ページ]。
SNMP enrollment mechanism is used.
SNMP登録メカニズムは使用されています。
'waitingForTftpAddrResponse(3)', the device has sent a
DNS request to resolve the server providing the
configuration file, and it is awaiting for a response.
Note that this state is only reported when the MTA
SNMP enrollment mechanism is used.
'waitingForTftpAddrResponse(3)'、サーバを決議するというDNS要求はデバイスで構成ファイルを提供しました、そして、それは応答のために待っています。 MTA SNMP登録メカニズムが使用されているときだけ、この状態が報告されることに注意してください。
'waitingForConfigFile(4)', the device has sent a
request via TFTP or HTTP for the download of its
configuration file, and it is awaiting for a response or
the file download is in progress."
REFERENCE
" PacketCable MTA Device Provisioning Specification,
PacketCable Security Specification."
::= { pktcMtaDevServer 19 }
「デバイスは、構成ファイルのダウンロードのために'waitingForConfigFile(4)'とTFTPかHTTPで要求を送りました、そして、応答のために待っているか、またはファイルダウンロードは進行しています。」 「仕様に食糧を供給するPacketCable MTAデバイス、PacketCableセキュリティ仕様」という参照。 ::= pktcMtaDevServer19
--
-- The following object group describes the security objects.
--
-- -- 以下のオブジェクトグループはセキュリティオブジェクトについて説明します。 --
pktcMtaDevManufacturerCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the MTA Manufacturer Certificate.
The object value must be the ASN.1 DER encoding of the MTA
manufacturer's X.509 public key certificate. The MTA
Manufacturer Certificate is issued to each MTA
manufacturer and is installed into each MTA at the time of
manufacture or with a secure code download. The specific
requirements related to this certificate are defined in
the PacketCable or IPCablecom Security specifications."
REFERENCE
" PacketCable Security Specification."
pktcMtaDevManufacturerCertificate OBJECT-TYPE SYNTAXのDocsX509ASN1DEREncodedCertificateのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA Manufacturer Certificateを含これが反対するしています」。 オブジェクト値はMTAメーカーのX.509公開鍵証明書のASN.1DERコード化でなければなりません。 MTA Manufacturer CertificateはそれぞれのMTAメーカーに発行されて、製造時点か安全なコードダウンロードで各MTAにインストールされます。 「この証明書に関連する決められた一定の要求はPacketCableかIPCablecom Security仕様に基づき定義されます。」 「PacketCableセキュリティ仕様」という参照。
::= {pktcMtaDevSecurity 1}
::= pktcMtaDevSecurity1
pktcMtaDevCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the MTA Device Certificate.
The object value must be the ASN.1 DER encoding of the
MTA's X.509 public-key certificate issued by the
manufacturer and installed into the MTA at the time of
pktcMtaDevCertificate OBJECT-TYPE SYNTAXのDocsX509ASN1DEREncodedCertificateのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA Device Certificateを含これが反対するしています」。 オブジェクト値がMTAにメーカーによって発行されたMTAのX.509公開鍵証明書をコード化して、インストールするASN.1DERでなければならない、時点
Nechamkin & Mule Standards Track [Page 30] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[30ページ]。
manufacture or with a secure code download.
This certificate contains the MTA MAC address. The
specific requirements related to this certificate are
defined in the PacketCable or IPCablecom Security
specifications."
REFERENCE
" PacketCable Security Specification."
::= { pktcMtaDevSecurity 2 }
製造しているか、または安全なコードと共にダウンロードしてください。 この証明書はMTA MACアドレスを含んでいます。 「この証明書に関連する決められた一定の要求はPacketCableかIPCablecom Security仕様に基づき定義されます。」 「PacketCableセキュリティ仕様」という参照。 ::= pktcMtaDevSecurity2
pktcMtaDevCorrelationId OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains a correlation ID, an arbitrary value
generated by the MTA that will be exchanged as part of the
device capability data to the Provisioning Application.
This random value is used as an identifier to correlate
related events in the MTA provisioning sequence.
This value is intended for use only during the MTA
initialization and configuration file download."
REFERENCE
" PacketCable MTA Device Provisioning Specification."
::= { pktcMtaDevSecurity 3 }
pktcMtaDevCorrelationId OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「相関関係ID、デバイス能力データの一部としてProvisioning Applicationと交換されるMTAによって生成された任意の値を含これが反対するしています」。 関連させる識別子が系列に食糧を供給するMTAでイベントを関係づけたので、この無作為の値は使用されています。 「この値は使用のためにMTA初期化と構成ファイルダウンロードだけの間意図します。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 ::= pktcMtaDevSecurity3
pktcMtaDevTelephonyRootCertificate OBJECT-TYPE
SYNTAX DocsX509ASN1DEREncodedCertificate
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the telephony Service Provider Root
certificate. The object value is the ASN.1 DER encoding of
the IP Telephony Service Provider Root X.509 public key
certificate. This certification is stored in the MTA
non-volatile memory and can be updated with a secure code
download. This certificate is used to validate the initial
AS Reply received by the MTA from the Key Distribution
Center (KDC) during the MTA initialization. The specific
requirements related to this certificate are defined in
the PacketCable or IPCablecom Security specifications."
REFERENCE
" PacketCable Security Specification."
::= { pktcMtaDevSecurity 4 }
pktcMtaDevTelephonyRootCertificate OBJECT-TYPE SYNTAXのDocsX509ASN1DEREncodedCertificateのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「電話Service Provider Root証明書を含これが反対するしています」。 オブジェクト値はIP Telephony Service Provider Root X.509公開鍵証明書のASN.1DERコード化です。 この証明をMTA非揮発性メモリーに保存して、安全なコードダウンロードでアップデートできます。 この証明書は、MTA初期化の間、Key Distributionセンター(KDC)からMTAによって受け取られた初期のAS Replyを有効にするのに使用されます。 「この証明書に関連する決められた一定の要求はPacketCableかIPCablecom Security仕様に基づき定義されます。」 「PacketCableセキュリティ仕様」という参照。 ::= pktcMtaDevSecurity4
--================================================================= -- -- Informative Procedures for Setting up Security Associations --
--================================================================= -- -- セキュリティ協会を設立するための有益な手順--
Nechamkin & Mule Standards Track [Page 31] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[31ページ]。
-- A Security Association may be set up either via configuration or -- via NCS signaling. -- -- I. Security association setup via configuration. -- -- The realm must be configured first. Associated with the realm -- is a KDC. The realm table (pktcMtaDevRealmTable) indicates -- information about the realm (e.g., name, organization name) and -- parameters associated with KDC communications (e.g., grace -- periods, AS Request/AS Reply adaptive back-off parameters). -- -- Once the realm is established, one or more CMS(es) may be -- defined in the realm. Associated with each CMS -- entry in the pktcMtaDevCmsTable is an explicit reference -- to a Realm via the realm name (pktcMtaDevCmsKerbRealmName), -- the FQDN of the CMS, and parameters associated with IPSec -- key management with the CMS (e.g., clock skew, AP Request/ -- AP Reply adaptive back-off parameters). -- -- II. Security association setup via NCS signaling. -- -- The procedure of establishing the Security Associations -- for NCS signaling is described in the PacketCable Security -- specification. -- It involves the analysis of the pktcNcsEndPntConfigTable row -- for the corresponding endpoint number and the correlation of -- the CMS FQDN from this row with the CMS Table and -- consequently, with the Realm Table. Both of these tables -- are defined below. The pktcNcsEndPntConfigTable is defined in -- the IP over Cable Data Network (IPCDN) -- NCS Signaling MIB [NCSSIGMIB]. -- -- III. When the MTA receives wake-up or re-key messages from a -- CMS, it performs key management based on the corresponding -- entry in the CMS table. If the matching CMS entry does not -- exist, it must ignore the wake-up or re-key messages. -- --================================================================= --================================================================= -- -- pktcMtaDevRealmTable -- -- The pktcMtaDevRealmTable shows the KDC realms. The table is -- indexed with pktcMtaDevRealmIndex. The Realm Table contains the -- pktcMtaDevRealmName in conjunction with any server that needs -- a Security Association with the MTA. Uppercase must be used -- to compare the pktcMtaDevRealmName content. --
-- または、Security Associationが構成でセットアップされるかもしれない、--NCSシグナリングで。 -- -- I. 構成を通したセキュリティ協会セットアップ。 -- -- 最初に、分野を構成しなければなりません。 分野に関連づけられました--KDCです。 そして、(pktcMtaDevRealmTable)が示す分野テーブル--、分野(例えば、名前、組織名)の情報、--KDCコミュニケーション(例えば、優雅--期間、AS Request/AS Replyの適応型の下に後部パラメタ)に関連しているパラメタ。 -- -- 分野がいったん確立されると、1CMS(es)が確立されます--分野では、定義されます。 各CMSに関連づけられました--pktcMtaDevCmsTableのエントリーは(例えば、斜行の時間を計ってください、AP Request/--AP Replyの適応型の下に後部パラメタ)というかぎ管理というCMSの分野名(pktcMtaDevCmsKerbRealmName)(CMS、およびIPSecに関連しているパラメタのFQDN)を通したRealmの明白な参照です。 -- -- II。 NCSシグナリングを通したセキュリティ協会セットアップ。 -- -- Security Associationsを設立する手順--NCSに関しては、シグナリングはPacketCable Securityで説明されます--仕様。 -- そして、対応する終点番号と相関関係のためのpktcNcsEndPntConfigTable行の分析にかかわる、--、CMS Tableとのこの行からのCMS FQDN、--その結果、Realm Tableと共に。 これらのテーブルの両方--以下では、定義されます。 pktcNcsEndPntConfigTableは--Cable Data Network(IPCDN)の上のIP--NCS Signaling MIB[NCSSIGMIB]で定義されます。 -- -- III。 MTAは、いつ上に目覚めるのを受けるか、そして、aからの再主要なメッセージ--CMS、対応に基づくかぎ管理を実行します--CMSテーブルのエントリー。 エントリーがそうしない合っているCMS--存在しているなら、それは航跡上がっているか再主要なメッセージを無視しなければなりません。 -- --================================================================= --================================================================= -- -- pktcMtaDevRealmTableはKDC分野を見せています。pktcMtaDevRealmTable----テーブルはそうです--pktcMtaDevRealmIndexと共に索引をつけられます。 Realm TableはMTAと--必要とするどんなサーバに関連したpktcMtaDevRealmName--a Security Associationを含んでいます。 大文字を使用しなければなりません--pktcMtaDevRealmName内容を比較するために。 --
Nechamkin & Mule Standards Track [Page 32] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[32ページ]。
--=================================================================
--=================================================================
pktcMtaDevRealmAvailSlot OBJECT-TYPE
SYNTAX Unsigned32 (0..64)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object contains the index number of the first
available entry in the realm table (pktcMtaDevRealmTable).
If all the entries in the realm table have been assigned,
this object contains the value of zero.
A management station should create new entries in the
realm table, using the following procedure:
pktcMtaDevRealmAvailSlot OBJECT-TYPE SYNTAX Unsigned32(0 .64)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「分野テーブル(pktcMtaDevRealmTable)の最初の利用可能なエントリーの指数を含これが反対するしています」。 分野テーブルのすべてのエントリーを割り当ててあるなら、このオブジェクトはゼロの値を含んでいます。 以下の手順を用いて、管理局は分野テーブルで新しいエントリーを作成するはずです:
First, issue a management protocol retrieval operation
to determine the value of the first available index in the
realm table (pktcMtaDevRealmAvailSlot).
まず最初に、管理プロトコル検索操作を発行して、分野テーブル(pktcMtaDevRealmAvailSlot)の最初の利用可能なインデックスの値を決定してください。
Second, issue a management protocol SET operation
to create an instance of the pktcMtaDevRealmStatus
object by setting its value to 'createAndWait(5)'.
2番目に、管理プロトコルSET操作を発行して、'createAndWait(5)'に値を設定することによって、pktcMtaDevRealmStatusオブジェクトのインスタンスを作成してください。
Third, if the SET operation succeeded, continue
modifying the object instances corresponding to the newly
created conceptual row, without fear of collision with
other management stations. When all necessary conceptual
columns of the row are properly populated (via SET
operations or default values), the management station may
SET the pktcMtaDevRealmStatus object to 'active(1)'."
::= { pktcMtaDevSecurity 5 }
SET操作が成功したなら、3番目に新たに作成された概念的な行に対応するオブジェクトインスタンスを変更し続けてください、他の管理局との衝突への恐怖なしで。 「行のすべての必要な概念的なコラムが適切に居住されるとき(SET操作かデフォルト値で)、管理局が居住される、SET pktcMtaDevRealmStatusが'アクティブな(1)'に反対する、」 ::= pktcMtaDevSecurity5
pktcMtaDevRealmTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevRealmEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object contains the realm table.
The CMS table (pktcMtaDevCmsTable) and the realm table
(pktcMtaDevRealmTable) are used for managing the MTA-CMS
Security Associations. The realm table defines the
Kerberos realms for the Application Servers (CMSes and the
Provisioning Server)."
::= { pktcMtaDevSecurity 6 }
pktcMtaDevRealmTable OBJECT-TYPEのSYNTAX SEQUENCE OF PktcMtaDevRealmEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「分野テーブルを含これが反対するしています」。 CMSテーブル(pktcMtaDevCmsTable)と分野テーブル(pktcMtaDevRealmTable)は、MTA-CMS Security Associationsを管理するのに使用されます。 「分野テーブルはApplication Servers(CMSesとProvisioning Server)のためにケルベロス分野を定義します。」 ::= pktcMtaDevSecurity6
pktcMtaDevRealmEntry OBJECT-TYPE
SYNTAX PktcMtaDevRealmEntry
MAX-ACCESS not-accessible
STATUS current
pktcMtaDevRealmEntry OBJECT-TYPE SYNTAX PktcMtaDevRealmEntryのマックス-ACCESSのアクセスしやすくないSTATUS海流
Nechamkin & Mule Standards Track [Page 33] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[33ページ]。
DESCRIPTION
" This table entry object lists the MTA security parameters
for a single Kerberos realm. The conceptual rows MUST NOT
persist across MTA reboots."
INDEX { pktcMtaDevRealmIndex }
::= { pktcMtaDevRealmTable 1 }
記述は「ただ一つのケルベロス分野のためのMTAセキュリティパラメタをリストアップこのテーブル項目が反対するします」。 「概念的な行はMTAリブートの向こう側に持続してはいけません。」 pktcMtaDevRealmIndexに索引をつけてください:、:= pktcMtaDevRealmTable1
PktcMtaDevRealmEntry ::= SEQUENCE {
pktcMtaDevRealmIndex Unsigned32,
pktcMtaDevRealmName SnmpAdminString,
pktcMtaDevRealmPkinitGracePeriod Unsigned32,
pktcMtaDevRealmTgsGracePeriod Unsigned32,
pktcMtaDevRealmOrgName LongUtf8String,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout Unsigned32,
pktcMtaDevRealmUnsolicitedKeyNomTimeout Unsigned32,
pktcMtaDevRealmUnsolicitedKeyMaxRetries Unsigned32,
pktcMtaDevRealmStatus RowStatus
}
PktcMtaDevRealmEntry:、:= 系列pktcMtaDevRealmIndex Unsigned32、pktcMtaDevRealmName SnmpAdminString、pktcMtaDevRealmPkinitGracePeriod Unsigned32、pktcMtaDevRealmTgsGracePeriod Unsigned32、pktcMtaDevRealmOrgName LongUtf8String、pktcMtaDevRealmUnsolicitedKeyMaxTimeout Unsigned32、pktcMtaDevRealmUnsolicitedKeyNomTimeout Unsigned32、pktcMtaDevRealmUnsolicitedKeyMaxRetries Unsigned32、pktcMtaDevRealmStatus RowStatus
pktcMtaDevRealmIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..64)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the realm table index."
::= { pktcMtaDevRealmEntry 1}
pktcMtaDevRealmIndex OBJECT-TYPE SYNTAX Unsigned32(1 .64)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「分野テーブルインデックスを定義これが反対するします」。 ::= pktcMtaDevRealmEntry1
pktcMtaDevRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object identifies the Kerberos realm name in all
capitals. The MTA MUST prohibit the instantiation of any
two rows with identical Kerberos realm names. The MTA MUST
also verify that any search operation involving Kerberos
realm names is done using the uppercase ASCII
representation of the characters."
::= { pktcMtaDevRealmEntry 2 }
pktcMtaDevRealmName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトはすべての首都でケルベロス分野名を特定します」。 MTA MUSTは同じケルベロス分野名でどんな2つの行の具体化も禁止します。 「また、MTA MUSTは、ケルベロス分野名にかかわるどんな索敵行動もキャラクタの大文字しているASCII表現を使用し終わっていることを確かめます。」 ::= pktcMtaDevRealmEntry2
pktcMtaDevRealmPkinitGracePeriod OBJECT-TYPE
SYNTAX Unsigned32 (15..600)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the PKINIT Grace Period. For the
purpose of key management with Application Servers (CMSes
マックス-ACCESSが読書して作成するpktcMtaDevRealmPkinitGracePeriod OBJECT-TYPE SYNTAX Unsigned32(15 .600)UNITS「数分」STATUSの現在の記述は「PKINITグレースPeriodを含これが反対するしています」。 Application Serversとのかぎ管理の目的、(CMSes
Nechamkin & Mule Standards Track [Page 34] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[34ページ]。
or the Provisioning Server), the MTA must utilize the
PKINIT exchange to obtain Application Server tickets. The
MTA may utilize the PKINIT exchange to obtain Ticket
Granting Tickets (TGTs), which are then used to obtain
Application Server tickets in a TGS exchange.
The PKINIT exchange occurs according to the current Ticket
Expiration Time (TicketEXP) and on the PKINIT Grace Period
(PKINITGP). The MTA MUST initiate the PKINIT exchange at
the time: TicketEXP - PKINITGP."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 15 }
::= { pktcMtaDevRealmEntry 3 }
Provisioning Server)、MTAは、Application Serverチケットを得るのにPKINIT交換を利用しなければなりません。 MTAは、Ticket Granting Tickets(TGTs)を入手するのにPKINIT交換を利用するかもしれません。(次に、Ticket Granting Ticketsは、TGS交換でApplication Serverチケットを得るのに使用されます)。 PKINIT交換は現在のTicket Expiration Time(TicketEXP)とPKINITグレースPeriod(PKINITGP)の上に起こります。 MTA MUSTは当時PKINIT交換を起こします: 「TicketEXP--、PKINITGP、」 「PacketCableセキュリティ仕様」という参照。 DEFVAL15:、:= pktcMtaDevRealmEntry3
pktcMtaDevRealmTgsGracePeriod OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "minutes"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the Ticket Granting Server Grace
Period (TGSGP). The Ticket Granting Server (TGS)
Request/Reply exchange may be performed by the MTA
on demand whenever an Application Server ticket is
needed to establish security parameters. If the MTA
possesses a ticket that corresponds to the Provisioning
Server or a CMS that currently exists in the CMS table,
the MTA MUST initiate the TGS Request/Reply exchange
at the time: TicketEXP - TGSGP."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 10 }
::= { pktcMtaDevRealmEntry 4 }
マックス-ACCESSが読書して作成するpktcMtaDevRealmTgsGracePeriod OBJECT-TYPE SYNTAX Unsigned32(1 .600)UNITS「数分」STATUSの現在の記述は「Ticket Granting ServerグレースPeriod(TGSGP)を含これが反対するしています」。 Application Serverチケットがセキュリティパラメタを確立するのに必要であるときはいつも、Ticket Granting Server(TGS)要求/回答交換はオンデマンドのMTAによって実行されるかもしれません。 MTAが現在CMSテーブルに存在するProvisioning ServerかCMSに対応するチケットを所有しているなら、MTA MUSTは当時TGS Request/回答交換を起こします: 「TicketEXP--、TGSGP、」 「PacketCableセキュリティ仕様」という参照。 DEFVAL10:、:= pktcMtaDevRealmEntry4
pktcMtaDevRealmOrgName OBJECT-TYPE
SYNTAX LongUtf8String
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the X.500 organization name attribute
as defined in the subject name of the service provider
certificate."
REFERENCE
" PacketCable Security Specification;
RFCs 3280 and 4630, Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile"
::= { pktcMtaDevRealmEntry 5 }
pktcMtaDevRealmOrgName OBJECT-TYPE SYNTAX LongUtf8Stringマックス-ACCESSは「サービスプロバイダー証明書の対象の名前で定義されて、このオブジェクトは属性というX.500組織名を含む」STATUSの現在の記述を読書して作成します。 「PacketCableセキュリティ仕様」という参照。 「RFCs3280と4630、インターネットX.509公開鍵暗号基盤証明書、および証明書失効リスト(CRL)プロフィール」:、:= pktcMtaDevRealmEntry5
Nechamkin & Mule Standards Track [Page 35] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[35ページ]。
pktcMtaDevRealmUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum time the MTA will
attempt to perform the exponential back-off algorithm.
This timer only applies when the MTA initiated key
management. If the DHCP option code 122, sub-option 4, is
provided to the MTA, it overwrites this value.
pktcMtaDevRealmUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32(1 .600)UNITS「秒」マックス-ACCESSは「このオブジェクトはMTAが、指数の下に後部アルゴリズムを実行するのを試みる最大の時代に指定する」STATUSの現在の記述を読書して作成します。 MTAがかぎ管理に着手したときだけ、このタイマは適用されます。 DHCPオプションコード122(サブオプション4)をMTAに提供するなら、それはこの値を上書きします。
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
指数の下に後部メカニズムによると、求められていない主要なアップデートは、AS回答に2個のタイマと最大の再試行カウンタを使用することで再送されます。 初期の再送信タイマー値は名目上のタイマ値(pktcMtaDevRealmUnsolicitedKeyNomTimeout)です。 「再-トランスミッション」は最大のタイムアウトの上限が評価する指数関数的に増加する間隔(pktcMtaDevRealmUnsolicitedKeyMaxTimeout)で現れます。 最大の再試行カウンタに達しているとき(pktcMatDevRealmUnsolicitedMaxRetries)、Retransmissionsは止まります。
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s, and retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 100 }
::= { pktcMtaDevRealmEntry 6 }
「例えば、3の値で、名目上のタイマのための秒、最大のタイムアウトのための20秒、および5つの再試行が最大限にします、そして、再送信間隔は、12秒間、3秒間、6秒間と、20秒間と、20秒間になるでしょう、そして、再試行の最大数に達したので、次に、「再-トランスミッション」は止まります。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL100:、:= pktcMtaDevRealmEntry6
pktcMtaDevRealmUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..600000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the initial timeout value
for the AS-REQ/AS-REP exponential back-off and retry
mechanism. If the DHCP option code 122, sub-option 4, is
provided to the MTA, it overwrites this value.
This value should account for the average roundtrip
time between the MTA and the KDC, as well as the
processing delay on the KDC.
マックス-ACCESSが読書して作成するpktcMtaDevRealmUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32(100 .600000)UNITS「ミリセカンド」STATUSの現在の記述は「下にAS-REQ/AS-REPの指数の後部と再試行メカニズムに初期のタイムアウト値を指定これが反対するします」。 DHCPオプションコード122(サブオプション4)をMTAに提供するなら、それはこの値を上書きします。 この値はMTAとKDCの間で平均した往復の時間を説明するべきです、KDCの上の処理遅れと同様に。
Nechamkin & Mule Standards Track [Page 36] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[36ページ]。
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
指数の下に後部メカニズムによると、求められていない主要なアップデートは、AS回答に2個のタイマと最大の再試行カウンタを使用することで再送されます。 初期の再送信タイマー値は名目上のタイマ値(pktcMtaDevRealmUnsolicitedKeyNomTimeout)です。 「再-トランスミッション」は最大のタイムアウトの上限が評価する指数関数的に増加する間隔(pktcMtaDevRealmUnsolicitedKeyMaxTimeout)で現れます。 最大の再試行カウンタに達しているとき(pktcMatDevRealmUnsolicitedMaxRetries)、Retransmissionsは止まります。
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, in retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s; retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 3000 }
::= { pktcMtaDevRealmEntry 7 }
間隔は、「再-トランスミッション」では、例えば、3の値で、名目上のタイマのための秒、最大のタイムアウトのための20秒、および5つの再試行が最大限にして、3秒間と、6秒間と、12秒間と、20秒間と、20秒間になるでしょう。 「そして、再試行の最大数に達したので、「再-トランスミッション」は止まります。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL3000:、:= pktcMtaDevRealmEntry7
pktcMtaDevRealmUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum number of retries the
MTA attempts to obtain a ticket from the KDC.
pktcMtaDevRealmUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32(0 .1024)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトはKDCからチケットを得るためにMTAが試みる再試行の最大数を指定します」。
Unsolicited key updates are retransmitted according to an
exponential back-off mechanism using two timers and a
maximum retry counter for AS replies.
The initial retransmission timer value is the nominal
timer value (pktcMtaDevRealmUnsolicitedKeyNomTimeout). The
retransmissions occur with an exponentially increasing
interval that caps at the maximum timeout value
(pktcMtaDevRealmUnsolicitedKeyMaxTimeout).
Retransmissions stop when the maximum retry counter is
reached (pktcMatDevRealmUnsolicitedMaxRetries).
指数の下に後部メカニズムによると、求められていない主要なアップデートは、AS回答に2個のタイマと最大の再試行カウンタを使用することで再送されます。 初期の再送信タイマー値は名目上のタイマ値(pktcMtaDevRealmUnsolicitedKeyNomTimeout)です。 「再-トランスミッション」は最大のタイムアウトの上限が評価する指数関数的に増加する間隔(pktcMtaDevRealmUnsolicitedKeyMaxTimeout)で現れます。 最大の再試行カウンタに達しているとき(pktcMatDevRealmUnsolicitedMaxRetries)、Retransmissionsは止まります。
For example, with values of 3 seconds for the nominal
timer, 20 seconds for the maximum timeout, and 5 retries
max, retransmission intervals will be 3 s, 6 s,
12 s, 20 s, and 20 s; retransmissions then stop because
the maximum number of retries has been reached."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 5 }
再送信間隔は、例えば、3の値で、名目上のタイマのための秒、最大のタイムアウトのための20秒、および5つの再試行が最大限にして、3秒間と、6秒間と、12秒間と、20秒間と、20秒間になるでしょう。 「そして、再試行の最大数に達したので、「再-トランスミッション」は止まります。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL{ 5 }
Nechamkin & Mule Standards Track [Page 37] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[37ページ]。
::= { pktcMtaDevRealmEntry 8 }
::= pktcMtaDevRealmEntry8
pktcMtaDevRealmStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the row status of this realm in the
realm table (pktcMtaDevRealmTable).
pktcMtaDevRealmStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトは分野テーブル(pktcMtaDevRealmTable)でこの分野の行状態を定義します」。
An entry in this table is not qualified for activation
until the object instances of all corresponding columns
have been initialized, either by default values, or via
explicit SET operations. Until all object instances in
this row are initialized, the status value for this realm
must be 'notReady(3)'.
In particular, two columnar objects must be explicitly
SET: the realm name (pktcMtaDevRealmName) and the
organization name (pktcMtaDevRealmOrgName). Once these 2
objects have been set and the row status is SET to
'active(1)', the MTA MUST NOT allow any modification of
these 2 object values.
The value of this object has no effect on whether other
columnar objects in this row can be modified."
::= { pktcMtaDevRealmEntry 9 }
すべての対応するコラムのオブジェクトインスタンスまで起動に資格がないので、初期化されてください、そうした、とどちらかが、デフォルトで評価するということであるかこのテーブルのエントリーは明白なSET操作でそうします。 この行のすべてのオブジェクトインスタンスが初期化されるまで、この分野への状態値は'notReady(3)'であるに違いありません。 2個の円柱状のオブジェクトが明らかに特に、そうであるに違いない、SET: 分野名(pktcMtaDevRealmName)と組織は(pktcMtaDevRealmOrgName)を命名します。 行状態がいったんこれらの2個のオブジェクトが設定されて、'アクティブな(1)'へのSETになると、MTA MUST NOTはこれらの2つのオブジェクト値のどんな変更も許します。 「このオブジェクトの値はこの行の他の円柱状のオブジェクトを変更できるかどうかに関して効き目がありません。」 ::= pktcMtaDevRealmEntry9
--================================================================= -- -- The CMS table, pktcMtaDevCmsTable -- -- The CMS table and the realm table (pktcMtaDevRealmTable) are used -- for managing the MTA signaling security. The CMS table defines -- the CMSes the MTA is allowed to communicate with and contains -- the parameters describing the SA establishment between the MTA -- and a CMS. -- The CMS table is indexed by pktcMtaDevCmsIndex. The table -- contains the CMS FQDN (pktcMtaDevCmsFQDN) and the associated -- Kerberos realm name (pktcMtaDevCmsKerbRealmName) so that the MTA -- can find the corresponding Kerberos realm name in the -- pktcMtaDevRealmTable. -- --=================================================================
--================================================================= -- -- CMSテーブル、pktcMtaDevCmsTable----MTAシグナリングセキュリティを管理するのにおいて、CMSテーブルと分野テーブル(pktcMtaDevRealmTable)は使用されています。 CMSes MTAは許容されています。テーブルが定義するCMS--、パラメタがMTAと、CMSの間のSA設立について説明して、コミュニケートして、含んでいる、--CMSテーブルはpktcMtaDevCmsIndexによって索引をつけられます。 テーブル--、MTA--対応するケルベロス分野を見つけることができるのがコネを命名するようにCMS FQDN(pktcMtaDevCmsFQDN)でケルベロス分野名義(pktcMtaDevCmsKerbRealmName)の関連を含んでいる、--pktcMtaDevRealmTable。 -- --=================================================================
pktcMtaDevCmsAvailSlot OBJECT-TYPE
SYNTAX Unsigned32 (0..128)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
pktcMtaDevCmsAvailSlot OBJECT-TYPE SYNTAX Unsigned32(0 .128)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Nechamkin & Mule Standards Track [Page 38] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[38ページ]。
" This object contains the index number of the first
available entry in the CMS table (pktcMtaDevCmsTable).
If all the entries in the CMS table have been assigned,
this object contains the value of zero.
A management station should create new entries in the
CMS table, using the following procedure:
「このオブジェクトはCMSテーブル(pktcMtaDevCmsTable)の最初の利用可能なエントリーの指数を含んでいます。」 CMSテーブルのすべてのエントリーを割り当ててあるなら、このオブジェクトはゼロの値を含んでいます。 以下の手順を用いて、管理局はCMSテーブルで新しいエントリーを作成するはずです:
First, issue a management protocol retrieval operation
to determine the value of the first available index in the
CMS table (pktcMtaDevCmsAvailSlot).
まず最初に、管理プロトコル検索操作を発行して、CMSテーブル(pktcMtaDevCmsAvailSlot)の最初の利用可能なインデックスの値を決定してください。
Second, issue a management protocol SET operation
to create an instance of the pktcMtaDevCmsStatus
object by setting its value to 'createAndWait(5)'.
2番目に、管理プロトコルSET操作を発行して、'createAndWait(5)'に値を設定することによって、pktcMtaDevCmsStatusオブジェクトのインスタンスを作成してください。
Third, if the SET operation succeeded, continue
modifying the object instances corresponding to the newly
created conceptual row, without fear of collision with
other management stations. When all necessary conceptual
columns of the row are properly populated (via SET
operations or default values), the management station may
SET the pktcMtaDevCmsStatus object to 'active(1)'."
::= { pktcMtaDevSecurity 7 }
SET操作が成功したなら、3番目に新たに作成された概念的な行に対応するオブジェクトインスタンスを変更し続けてください、他の管理局との衝突への恐怖なしで。 「行のすべての必要な概念的なコラムが適切に居住されるとき(SET操作かデフォルト値で)、管理局が居住される、SET pktcMtaDevCmsStatusが'アクティブな(1)'に反対する、」 ::= pktcMtaDevSecurity7
pktcMtaDevCmsTable OBJECT-TYPE
SYNTAX SEQUENCE OF PktcMtaDevCmsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the CMS table.
The CMS table (pktcMtaDevCmsTable) and the realm table
(pktcMtaDevRealmTable) are used for managing security
between the MTA and CMSes. Each CMS table entry defines
a CMS the managed MTA is allowed to communicate with
and contains security parameters for key management with
that CMS."
::= { pktcMtaDevSecurity 8 }
pktcMtaDevCmsTable OBJECT-TYPE SYNTAX SEQUENCE OF PktcMtaDevCmsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「CMSテーブルを定義これが反対するします」。 CMSテーブル(pktcMtaDevCmsTable)と分野テーブル(pktcMtaDevRealmTable)は、MTAとCMSesの間のセキュリティを管理するのに使用されます。 「それぞれのCMSテーブル項目は、管理されたMTAがコミュニケートできるCMSを定義して、そのCMSとのかぎ管理のためのセキュリティパラメタを含んでいる」、:、:= pktcMtaDevSecurity8
pktcMtaDevCmsEntry OBJECT-TYPE
SYNTAX PktcMtaDevCmsEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This table entry object lists the MTA key management
parameters used when establishing Security Associations
with a CMS. The conceptual rows MUST NOT persist across
MTA reboots."
INDEX { pktcMtaDevCmsIndex }
pktcMtaDevCmsEntry OBJECT-TYPE SYNTAX PktcMtaDevCmsEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「. 概念的な行がMTAリブートの向こう側に固持してはいけないCMSとSecurity Associationsを設立するとき使用されるMTAかぎ管理パラメタをリストアップこのテーブル項目が反対するします」。 インデックスpktcMtaDevCmsIndex
Nechamkin & Mule Standards Track [Page 39] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[39ページ]。
::= { pktcMtaDevCmsTable 1 }
::= pktcMtaDevCmsTable1
PktcMtaDevCmsEntry ::= SEQUENCE {
pktcMtaDevCmsIndex Unsigned32,
pktcMtaDevCmsFqdn SnmpAdminString,
pktcMtaDevCmsKerbRealmName SnmpAdminString,
pktcMtaDevCmsMaxClockSkew Unsigned32,
pktcMtaDevCmsSolicitedKeyTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyNomTimeout Unsigned32,
pktcMtaDevCmsUnsolicitedKeyMaxRetries Unsigned32,
pktcMtaDevCmsIpsecCtrl TruthValue,
pktcMtaDevCmsStatus RowStatus
}
PktcMtaDevCmsEntry:、:= 系列pktcMtaDevCmsIndex Unsigned32、pktcMtaDevCmsFqdn SnmpAdminString、pktcMtaDevCmsKerbRealmName SnmpAdminString、pktcMtaDevCmsMaxClockSkew Unsigned32、pktcMtaDevCmsSolicitedKeyTimeout Unsigned32、pktcMtaDevCmsUnsolicitedKeyMaxTimeout Unsigned32、pktcMtaDevCmsUnsolicitedKeyNomTimeout Unsigned32、pktcMtaDevCmsUnsolicitedKeyMaxRetries Unsigned32、pktcMtaDevCmsIpsecCtrl TruthValue、pktcMtaDevCmsStatus RowStatus
pktcMtaDevCmsIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..128)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
" This object defines the CMS table index."
::= { pktcMtaDevCmsEntry 1 }
pktcMtaDevCmsIndex OBJECT-TYPE SYNTAX Unsigned32(1 .128)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「CMSテーブルインデックスを定義これが反対するします」。 ::= pktcMtaDevCmsEntry1
pktcMtaDevCmsFqdn OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the CMS FQDN. The MTA must
prohibit the instantiation of any two rows with identical
FQDNs. The MTA must also verify that any search and/or
comparison operation involving a CMS FQDN is case
insensitive. The MTA must resolve the CMS FQDN as required
by the corresponding PacketCable Specifications."
REFERENCE
" PacketCable MTA Device Provisioning Specification;
PacketCable Security Specification;
PacketCable Network-Based Call Signaling Protocol
Specification."
::= { pktcMtaDevCmsEntry 2 }
pktcMtaDevCmsFqdn OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトはCMS FQDNを指定します」。 MTAは同じFQDNsと共にどんな2つの行の具体化も禁止しなければなりません。 また、MTAは、CMS FQDNにかかわるどんな検索、そして/または、比較操作も大文字と小文字を区別しないことを確かめなければなりません。 「MTAは必要に応じて対応するPacketCable SpecificationsでCMS FQDNを決議しなければなりません。」 「仕様に食糧を供給するPacketCable MTAデバイス」という参照。 PacketCableセキュリティ仕様。 「PacketCableのネットワークベースの呼び出しシグナリングは仕様を議定書の中で述べます。」 ::= pktcMtaDevCmsEntry2
pktcMtaDevCmsKerbRealmName OBJECT-TYPE
SYNTAX SnmpAdminString (SIZE(1..255))
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object identifies the Kerberos realm name in uppercase
characters associated with the CMS defined in this
pktcMtaDevCmsKerbRealmName OBJECT-TYPE SYNTAX SnmpAdminString(SIZE(1 .255))マックス-ACCESSが読書して作成する、STATUSの現在の記述は「これで定義されるCMSに関連している大文字しているキャラクタのケルベロス分野名を特定これが反対するします」。
Nechamkin & Mule Standards Track [Page 40] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[40ページ]。
conceptual row. The object value is a reference
point to the corresponding Kerberos realm name in the
realm table (pktcMtaDevRealmTable)."
::= { pktcMtaDevCmsEntry 3 }
概念的な行。 「オブジェクト値は分野テーブル(pktcMtaDevRealmTable)の対応するケルベロス分野名への基準点です。」 ::= pktcMtaDevCmsEntry3
pktcMtaDevCmsMaxClockSkew OBJECT-TYPE
SYNTAX Unsigned32 (1..1800)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object specifies the maximum allowable clock skew
between the MTA and the CMS defined in this row."
DEFVAL { 300 }
::= { pktcMtaDevCmsEntry 4 }
マックス-ACCESSが読書して作成するpktcMtaDevCmsMaxClockSkew OBJECT-TYPE SYNTAX Unsigned32(1 .1800)UNITS「秒」STATUSの現在の記述は「この行で定義されたMTAとCMSの間の最大の許容できる時計斜行を指定これが反対するします」。 DEFVAL300:、:= pktcMtaDevCmsEntry4
pktcMtaDevCmsSolicitedKeyTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..30000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines a Kerberos Key Management timer on the
MTA. It is the time period during which the MTA saves the
nonce and Server Kerberos Principal Identifier to match an
AP Request and its associated AP Reply response from the
CMS. This timer only applies when the CMS initiated key
management (with a Wake Up message or a Rekey message)."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 1000 }
::= { pktcMtaDevCmsEntry 5 }
マックス-ACCESSが読書して作成するpktcMtaDevCmsSolicitedKeyTimeout OBJECT-TYPE SYNTAX Unsigned32(100 .30000)UNITS「ミリセカンド」STATUSの現在の記述は「MTAの上のケルベロスKey Managementタイマを定義これが反対するします」。 それはMTAがCMSからAP Requestとその関連AP Reply応答に合うように一回だけとServerケルベロスプリンシパルIdentifierを取っておく期間です。「CMSがかぎ管理(和氣UpメッセージかRekeyメッセージがある)に着手したときだけ、このタイマは適用されます。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL1000:、:= pktcMtaDevCmsEntry5
--================================================================= -- -- Unsolicited key updates are retransmitted according to an -- exponential back-off mechanism using two timers and a maximum -- retry counter for AS replies. -- The initial retransmission timer value is the nominal timer -- value (pktcMtaDevCmsUnsolicitedKeyNomTimeout). The -- retransmissions occur with an exponentially increasing interval -- that caps at the maximum timeout value -- (pktcMtaDevCmsUnsolicitedKeyMaxTimeout). -- Retransmissions stop when the maximum retry counter is reached -- (pktcMatDevCmsUnsolicitedMaxRetries). -- For example, with values of 3 seconds for the nominal -- timer, 20 seconds for the maximum timeout, and 5 retries max, -- retransmission intervals will be 3 s, 6 s, 12 s,
--================================================================= -- -- --2個のタイマと最大を使用する指数の下に後部メカニズム--再試行カウンタに従って、求められていない主要なアップデートはAS回答のために再送されます。 -- 初期の再送信タイマー値は名目上のタイマです--値(pktcMtaDevCmsUnsolicitedKeyNomTimeout)。 --「再-トランスミッション」は指数関数的に増加する間隔で現れます(pktcMtaDevCmsUnsolicitedKeyMaxTimeout)。(最大のタイムアウトの上限はそれを評価します)。 -- 最大の再試行カウンタに達しているとき、Retransmissionsは止まります--(pktcMatDevCmsUnsolicitedMaxRetries。) -- 例えば、タイマ、最大のタイムアウトのための20秒、および5つの再試行が最大限にするという名目上のための3秒の値で、再送信間隔は3秒間になるでしょう、6秒間、12秒間
Nechamkin & Mule Standards Track [Page 41] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[41ページ]。
-- 20 s, and 20 s; retransmissions then stop due to the -- maximum number of retries reached. -- --=================================================================
-- 20秒間、および20秒間。 次に、「再-トランスミッション」が止まる、--最大数の再試行に達しました。 -- --=================================================================
pktcMtaDevCmsUnsolicitedKeyMaxTimeout OBJECT-TYPE
SYNTAX Unsigned32 (1..600)
UNITS "seconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the timeout value that only applies
to an MTA-initiated key management exchange. It is the
maximum timeout, and it may not be exceeded in the
exponential back-off algorithm."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 600 }
::= { pktcMtaDevCmsEntry 6 }
マックス-ACCESSが読書して作成するpktcMtaDevCmsUnsolicitedKeyMaxTimeout OBJECT-TYPE SYNTAX Unsigned32(1 .600)UNITS「秒」STATUSの現在の記述は「MTAによって開始されたかぎ管理交換に適用されるだけであるタイムアウト値を定義これが反対するします」。 「それは最大のタイムアウトです、そして、指数の下に後部アルゴリズムで超えられないかもしれません。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL600:、:= pktcMtaDevCmsEntry6
pktcMtaDevCmsUnsolicitedKeyNomTimeout OBJECT-TYPE
SYNTAX Unsigned32 (100..30000)
UNITS "milliseconds"
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the starting value of the timeout
for an MTA-initiated key management. It should account for
the average roundtrip time between the MTA and the CMS and
the processing time on the CMS."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 500 }
::= { pktcMtaDevCmsEntry 7 }
マックス-ACCESSが読書して作成するpktcMtaDevCmsUnsolicitedKeyNomTimeout OBJECT-TYPE SYNTAX Unsigned32(100 .30000)UNITS「ミリセカンド」STATUSの現在の記述は「MTAによって開始されたかぎ管理のためにタイムアウトの始めの値を定義これが反対するします」。 . 「MTAとCMSの間の平均した往復の時間とCMSの上の処理時間を説明するべきである」REFERENCE「PacketCableセキュリティ仕様。」 DEFVAL500:、:= pktcMtaDevCmsEntry7
pktcMtaDevCmsUnsolicitedKeyMaxRetries OBJECT-TYPE
SYNTAX Unsigned32 (0..1024)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object contains the maximum number of retries before
the MTA stops attempting to establish a Security
Association with the CMS."
REFERENCE
" PacketCable Security Specification."
DEFVAL { 5 }
::= { pktcMtaDevCmsEntry 8 }
pktcMtaDevCmsUnsolicitedKeyMaxRetries OBJECT-TYPE SYNTAX Unsigned32(0 .1024)マックス-ACCESSはSTATUSの現在の記述を読書して作成します。「MTAが、CMSとSecurity Associationを設立するのを試みるのを止める前にこのオブジェクトは再試行の最大数を含んでいる」、REFERENCE「PacketCableセキュリティ仕様。」 DEFVAL5:、:= pktcMtaDevCmsEntry8
Nechamkin & Mule Standards Track [Page 42] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[42ページ]。
pktcMtaDevCmsIpsecCtrl OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
" This object specifies the MTA IPSec control flag.
If the object value is 'true', the MTA must use Kerberos
Key Management and IPsec to communicate with this CMS. If
it is 'false', IPSec Signaling Security and Kerberos key
management are disabled for this specific CMS."
DEFVAL { true }
::= { pktcMtaDevCmsEntry 9 }
pktcMtaDevCmsIpsecCtrl OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「MTA IPSec指揮旗を指定これが反対するします」。 「以下のこと、オブジェクト値が本当に'本当(必須が. このCMSそれが'偽であるか、そして、'主要な管理がこの特定のCMSのために無効にされるIPSec Signaling Securityとケルベロス」とコミュニケートするのにケルベロスKey ManagementとIPsecを使用するMTA)'DEFVALであるなら:= pktcMtaDevCmsEntry9
pktcMtaDevCmsStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
" This object defines the row status associated with this
particular CMS in the CMS table (pktcMtaDevCmsTable).
pktcMtaDevCmsStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「このオブジェクトはCMSテーブル(pktcMtaDevCmsTable)のこの特定のCMSに関連している行状態を定義します」。
An entry in this table is not qualified for activation
until the object instances of all corresponding columns
have been initialized, either by default values or via
explicit SET operations. Until all object instances in
this row are initialized, the status value for this realm
must be 'notReady(3)'.
In particular, two columnar objects must be SET: the
CMS FQDN (pktcMtaDevCmsFqdn) and the Kerberos realm name
(pktcMtaDevCmsKerbRealmName). Once these 2 objects have
been set and the row status is SET to 'active(1)', the MTA
MUST NOT allow any modification of these 2 object values.
すべての対応するコラムのオブジェクトインスタンスがデフォルトで値か明白なSET操作で初期化されるまで、このテーブルのエントリーは起動に資格がありません。 この行のすべてのオブジェクトインスタンスが初期化されるまで、この分野への状態値は'notReady(3)'であるに違いありません。 2個の円柱状のオブジェクトが特に、SETであるに違いありません: CMS FQDN(pktcMtaDevCmsFqdn)とケルベロス分野は(pktcMtaDevCmsKerbRealmName)を命名します。 行状態がいったんこれらの2個のオブジェクトが設定されて、'アクティブな(1)'へのSETになると、MTA MUST NOTはこれらの2つのオブジェクト値のどんな変更も許します。
The value of this object has no effect on
whether other columnar objects in this row can be
modified."
::= { pktcMtaDevCmsEntry 10 }
「このオブジェクトの値はこの行の他の円柱状のオブジェクトを変更できるかどうかに関して効き目がありません。」 ::= pktcMtaDevCmsEntry10
pktcMtaDevResetKrbTickets OBJECT-TYPE
SYNTAX BITS {
invalidateProvOnReboot (0),
invalidateAllCmsOnReboot (1)
}
MAX-ACCESS read-write
STATUS current
DESCRIPTION
" This object defines a Kerberos Ticket Control Mask that
instructs the MTA to invalidate the specific Application
マックス-ACCESSが「特定のApplicationを無効にするようMTAに命令するケルベロスTicket Control Maskを定義これが反対するする」とSTATUSの現在の記述に読書して書くpktcMtaDevResetKrbTickets OBJECT-TYPE SYNTAX BITS invalidateProvOnReboot(0)、invalidateAllCmsOnReboot(1)
Nechamkin & Mule Standards Track [Page 43] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[43ページ]。
Server Kerberos ticket(s) that are stored locally in the
MTA NVRAM (non-volatile or persistent memory).
If the MTA does not store Kerberos tickets in NVRAM, it
MUST ignore setting of this object and MUST report a BITS
value of zero when the object is read.
If the MTA supports Kerberos tickets storage in NVRAM, the
object value is encoded as follows:
- Setting the invalidateProvOnReboot bit (bit 0) to 1
means that the MTA MUST invalidate the Kerberos
Application Ticket(s) for the Provisioning Application
at the next MTA reboot if secure SNMP provisioning mode
is used. In non-secure provisioning modes, the MTA MUST
return an 'inconsistentValue' in response to SNMP SET
operations with a bit 0 set to 1.
- Setting the invalidateAllCmsOnReboot bit (bit 1) to 1
means that the MTA MUST invalidate the Kerberos
Application Ticket(s) for all CMSes currently assigned
to the MTA endpoints.
If a value is written into an instance of
pktcMtaDevResetKrbTickets, the agent MUST retain the
supplied value across an MTA re-initialization or
reboot."
REFERENCE
"PacketCable Security Specification."
DEFVAL { { } }
::= { pktcMtaDevSecurity 9 }
MTA NVRAM(非揮発性の、または、永続的な記憶)に局所的に保存されるサーバケルベロスチケット。 MTAがNVRAMにケルベロスチケットを保存しないなら、それは、このオブジェクトの設定を無視しなければならなくて、オブジェクトが読まれるとき、ゼロのBITS値を報告しなければなりません。 MTAが、NVRAMでケルベロスがチケットストレージであるとサポートするなら、オブジェクト値は以下の通りコード化されます: - invalidateProvOnRebootビット(ビット0)を1に設定するのは、モードに食糧を供給する安全なSNMPが使用されているならMTA MUSTが次のMTAリブートのときにProvisioning ApplicationのためにケルベロスApplication Ticket(s)を無効にすることを意味します。 非安全な食糧を供給するモードで、MTA MUSTはしばらく0セットによるSNMP SET操作に対応して'inconsistentValue'を1に返します。 - invalidateAllCmsOnRebootビット(ビット1)を1に設定するのは、MTA MUSTが現在MTA終点に割り当てられているすべてのCMSesのためにケルベロスApplication Ticket(s)を無効にすることを意味します。 「値がpktcMtaDevResetKrbTicketsのインスタンスに書かれるなら、エージェントは、MTA再初期化の向こう側に供給値を保有しなければならないか、またはリブートしなければなりません。」 「PacketCableセキュリティ仕様」という参照。 DEFVAL、:、:= pktcMtaDevSecurity9
-- -- The following group, pktcMtaDevErrors, defines an OID -- corresponding to error conditions encountered during the MTA -- provisioning. --
-- -- MTAの間に遭遇するエラー条件に対応している、以下のグループ(pktcMtaDevErrors)はOIDを定義します--食糧を供給すること。 --
pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY
STATUS current
DESCRIPTION
"This object defines the OID corresponding to the error
condition when too many errors are encountered in the
MTA configuration file during provisioning."
::= { pktcMtaDevErrors 1 }
pktcMtaDevErrorsTooManyErrors OBJECT-IDENTITY STATUSの現在の記述は「あまりに多くの誤りが食糧を供給している間MTA構成ファイルで遭遇するとき、エラー条件に対応するOIDを定義これが反対するします」。 ::= pktcMtaDevErrors1
pktcMtaDevProvisioningEnrollment NOTIFICATION-TYPE
OBJECTS {
sysDescr,
pktcMtaDevSwCurrentVers,
pktcMtaDevTypeIdentifier,
ifPhysAddress,
pktcMtaDevCorrelationId
pktcMtaDevProvisioningEnrollment通知タイプが反対する、sysDescr、pktcMtaDevSwCurrentVers、pktcMtaDevTypeIdentifier、ifPhysAddress、pktcMtaDevCorrelationId
Nechamkin & Mule Standards Track [Page 44] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[44ページ]。
}
STATUS current
DESCRIPTION
" This INFORM notification is issued by the MTA to initiate
the PacketCable provisioning process when the MTA SNMP
enrollment mechanism is used.
It contains the system description, the current software
version, the MTA device type identifier, the MTA MAC
address (obtained in the MTA ifTable in the ifPhysAddress
object that corresponds to the ifIndex 1), and a
correlation ID."
::= { pktcMtaNotification 1 }
} 「このINFORM通知はMTA SNMP登録メカニズムが使用されているときプロセスに食糧を供給するPacketCableを開始するためにMTAによって発行される」STATUSの現在の記述。 「システム記述、現在のソフトウェアバージョン、MTA装置タイプ識別子、MTA MACアドレス(ifIndex1に対応するifPhysAddressオブジェクトのMTA ifTableでは、得る)、および相関関係IDを含んでいます。」 ::= pktcMtaNotification1
pktcMtaDevProvisioningStatus NOTIFICATION-TYPE
OBJECTS {
ifPhysAddress,
pktcMtaDevCorrelationId,
pktcMtaDevProvisioningState
}
STATUS current
DESCRIPTION
" This INFORM notification may be issued by the MTA to
confirm the completion of the PacketCable provisioning
process, and to report its provisioning completion
status.
It contains the MTA MAC address (obtained in the MTA
ifTable in the ifPhysAddress object that corresponds
to the ifIndex 1), a correlation ID and the MTA
provisioning state as defined in
pktcMtaDevProvisioningState."
::= { pktcMtaNotification 2 }
pktcMtaDevProvisioningStatus NOTIFICATION-TYPE OBJECTS、ifPhysAddress、pktcMtaDevCorrelationId、pktcMtaDevProvisioningState、「このINFORM通知はプロセスに食糧を供給するPacketCableの完成を確認して、完成状態に食糧を供給すると報告するためにMTAによって発行されるかもしれない」STATUSの現在の記述。 「pktcMtaDevProvisioningStateで定義されるように状態に食糧を供給するMTA MACアドレス(ifIndex1に対応するifPhysAddressオブジェクトのMTA ifTableでは、得る)、相関関係ID、およびMTAを含んでいます。」 ::= pktcMtaNotification2
-- -- Compliance Statements --
-- -- 承諾声明--
pktcMtaCompliances OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
pktcMtaGroups OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
pktcMtaCompliancesオブジェクト識別子:、:= pktcMtaConformance1pktcMtaGroupsオブジェクト識別子:、:= pktcMtaConformance2
pktcMtaBasicCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" The compliance statement for MTA devices that implement
PacketCable or IPCablecom requirements.
pktcMtaBasicCompliance MODULE-COMPLIANCE STATUSの現在の記述、「PacketCableかIPCablecomが要件であると実装するMTAデバイスのための承諾声明。」
This compliance statement applies to MTA implementations
that support PacketCable 1.0 or IPCablecom requirements,
which are not IPv6-capable at the time of this
この承諾声明はPacketCable1.0かIPCablecomがこの時点でIPv6できない要件であるとサポートするMTA実装に適用されます。
Nechamkin & Mule Standards Track [Page 45] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[45ページ]。
RFC publication."
「RFC公表。」
MODULE -- Unconditionally mandatory groups for MTAs
MODULE--MTAsには、無条件に義務的なグループ
MANDATORY-GROUPS {
pktcMtaGroup,
pktcMtaNotificationGroup
}
義務的なグループpktcMtaGroup、pktcMtaNotificationGroup
OBJECT pktcMtaDevDhcpServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevDhcpServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevDnsServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevDnsServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevTimeServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevTimeServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDhcp1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp1 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDhcp2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp2 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDns1
オブジェクトpktcMtaDevServerDns1
Nechamkin & Mule Standards Track [Page 46] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[46ページ]。
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDns2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns2 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevTimeServer
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevTimeServer SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevProvConfigEncryptAlg
SYNTAX PktcMtaDevProvEncryptAlg
DESCRIPTION
"An implementation is only required to support
values of none(0) and des64Cbcmode(1).
An IV of zero is used to encrypt in des64Cbcmode, and
the length of pktcMtaDevProvConfigKey is 64 bits, as
defined in the PacketCable Security specification.
Other encryption types may be defined in future
versions of this MIB module."
OBJECT pktcMtaDevProvConfigEncryptAlg SYNTAX PktcMtaDevProvEncryptAlg記述、「実装がなにもの値が(0)とdes64Cbcmode(1)であるとサポートするのに必要であるだけです」。 ゼロのIVはdes64Cbcmodeで暗号化するのにおいて使用されています、そして、pktcMtaDevProvConfigKeyの長さは64ビットです、PacketCable Security仕様に基づき定義されるように。 「他の暗号化タイプはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevRealmOrgName
SYNTAX LongUtf8String (SIZE (1..384))
DESCRIPTION
"The Organization Name field in X.509 certificates
can contain up to 64 UTF-8 encoded characters,
as defined in RFCs 3280 and 4630. Therefore, compliant
devices are only required to support Organization
Name values of up to 64 UTF-8 encoded characters.
Given that RFCs 3280 and 4630 define the UTF-8 encoding,
compliant devices must support a maximum size of 384
octets for pktcMtaDevRealmOrgName. The calculation of
384 octets comes from the RFC 3629 UTF-8 encoding
definition whereby the UTF-8 encoded characters
are encoded as sequences of 1 to 6 octets,
assuming that code points as high as 0x7ffffffff
might be used. Subsequent versions of Unicode and ISO
10646 have limited the upper bound to 0x10ffff.
OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String(SIZE(1 .384))記述、「X.509証明書のOrganization Name分野はコード化されたキャラクタを64UTF-8まで含むことができます、RFCs3280と4630年に定義されるように」。 したがって、言いなりになっているデバイスが、最大64UTF-8のOrganization Name値にコード化されたキャラクタをサポートするのに必要であるだけです。 RFCs3280と4630がUTF-8コード化を定義するなら、言いなりになっているデバイスはpktcMtaDevRealmOrgNameのために384の八重奏の最大サイズをサポートしなければなりません。 384の八重奏の計算はコード化されたキャラクタが、1〜6つの八重奏の系列としてコード化されて、そのコードが0x7ffffffffと同じくらい高く指すと仮定するUTF-8が使用されるかもしれない定義をコード化するRFC3629UTF-8から来ます。 ユニコードとISO10646のその後のバージョンは上限を0x10ffffに制限しました。
Nechamkin & Mule Standards Track [Page 47] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[47ページ]。
Consequently, the current version of UTF-8, defined in
RFC 3629, does not require more than four octets to
encode a valid code point."
「その結果、RFC3629で定義されたUTF-8の最新版は有効なコード・ポイントをコード化するために4つ以上の八重奏を必要としません。」
::= { pktcMtaCompliances 1 }
::= pktcMtaCompliances1
pktcMtaGroup OBJECT-GROUP
OBJECTS {
pktcMtaDevResetNow,
pktcMtaDevSerialNumber,
pktcMtaDevSwCurrentVers,
pktcMtaDevFQDN,
pktcMtaDevEndPntCount,
pktcMtaDevEnabled,
pktcMtaDevProvisioningCounter,
pktcMtaDevErrorOid,
pktcMtaDevErrorValue,
pktcMtaDevErrorReason,
pktcMtaDevTypeIdentifier,
pktcMtaDevProvisioningState,
pktcMtaDevHttpAccess,
pktcMtaDevCertificate,
pktcMtaDevCorrelationId,
pktcMtaDevManufacturerCertificate,
pktcMtaDevDhcpServerAddressType,
pktcMtaDevDnsServerAddressType,
pktcMtaDevTimeServerAddressType,
pktcMtaDevProvConfigEncryptAlg,
pktcMtaDevServerDhcp1,
pktcMtaDevServerDhcp2,
pktcMtaDevServerDns1,
pktcMtaDevServerDns2,
pktcMtaDevTimeServer,
pktcMtaDevConfigFile,
pktcMtaDevSnmpEntity,
pktcMtaDevRealmPkinitGracePeriod,
pktcMtaDevRealmTgsGracePeriod,
pktcMtaDevRealmAvailSlot,
pktcMtaDevRealmName,
pktcMtaDevRealmOrgName,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
pktcMtaDevRealmUnsolicitedKeyNomTimeout,
pktcMtaDevRealmUnsolicitedKeyMaxRetries,
pktcMtaDevRealmStatus,
pktcMtaDevCmsAvailSlot,
pktcMtaDevCmsFqdn,
pktcMtaDevCmsKerbRealmName,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout,
pktcMtaGroupオブジェクト群対象、pktcMtaDevResetNow、pktcMtaDevSerialNumber、pktcMtaDevSwCurrentVers、pktcMtaDevFQDN、pktcMtaDevEndPntCount、pktcMtaDevEnabled、pktcMtaDevProvisioningCounter、pktcMtaDevErrorOid、pktcMtaDevErrorValue、pktcMtaDevErrorReason; pktcMtaDevTypeIdentifier、pktcMtaDevProvisioningState、pktcMtaDevHttpAccess、pktcMtaDevCertificate、pktcMtaDevCorrelationId、pktcMtaDevManufacturerCertificate、pktcMtaDevDhcpServerAddressType、pktcMtaDevDnsServerAddressType、pktcMtaDevTimeServerAddressType; pktcMtaDevProvConfigEncryptAlg、pktcMtaDevServerDhcp1、pktcMtaDevServerDhcp2、pktcMtaDevServerDns1、pktcMtaDevServerDns2、pktcMtaDevTimeServer、pktcMtaDevConfigFile、pktcMtaDevSnmpEntity、pktcMtaDevRealmPkinitGracePeriod、pktcMtaDevRealmTgsGracePeriod、pktcMtaDevRealmAvailSlot、pktcMtaDevRealmName、pktcMtaDevRealmOrgName、pktcMtaDevRealmUnsolicitedKeyMaxTimeout、pktcMtaDevRealmUnsolicitedKeyNomTimeout、pktcMtaDevRealmUnsolicitedKeyMaxRetries、pktcMtaDevRealmStatus、pktcMtaDevCmsAvailSlot、pktcMtaDevCmsFqdn、pktcMtaDevCmsKerbRealmName、pktcMtaDevCmsUnsolicitedKeyMaxTimeout
Nechamkin & Mule Standards Track [Page 48] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[48ページ]。
pktcMtaDevCmsUnsolicitedKeyNomTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxRetries,
pktcMtaDevCmsSolicitedKeyTimeout,
pktcMtaDevCmsMaxClockSkew,
pktcMtaDevCmsIpsecCtrl,
pktcMtaDevCmsStatus,
pktcMtaDevResetKrbTickets,
pktcMtaDevProvUnsolicitedKeyMaxTimeout,
pktcMtaDevProvUnsolicitedKeyNomTimeout,
pktcMtaDevProvUnsolicitedKeyMaxRetries,
pktcMtaDevProvKerbRealmName,
pktcMtaDevProvSolicitedKeyTimeout,
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey,
pktcMtaDevProvState,
pktcMtaDevProvisioningTimer,
pktcMtaDevTelephonyRootCertificate
}
STATUS current
DESCRIPTION
" A collection of objects for managing PacketCable or
IPCablecom MTA implementations."
::= { pktcMtaGroups 1 }
pktcMtaDevCmsUnsolicitedKeyNomTimeout、pktcMtaDevCmsUnsolicitedKeyMaxRetries、pktcMtaDevCmsSolicitedKeyTimeout、pktcMtaDevCmsMaxClockSkew、pktcMtaDevCmsIpsecCtrl、pktcMtaDevCmsStatus、pktcMtaDevResetKrbTickets、pktcMtaDevProvUnsolicitedKeyMaxTimeout; pktcMtaDevProvUnsolicitedKeyNomTimeout、pktcMtaDevProvUnsolicitedKeyMaxRetries、pktcMtaDevProvKerbRealmName、pktcMtaDevProvSolicitedKeyTimeout、pktcMtaDevProvConfigHash、pktcMtaDevProvConfigKey、pktcMtaDevProvState、pktcMtaDevProvisioningTimer、pktcMtaDevTelephonyRootCertificate STATUSの現在の記述、「PacketCableを管理するためのオブジェクトかIPCablecom MTA実装の収集。」 ::= pktcMtaGroups1
pktcMtaNotificationGroup NOTIFICATION-GROUP
NOTIFICATIONS {
pktcMtaDevProvisioningStatus,
pktcMtaDevProvisioningEnrollment
}
STATUS current
DESCRIPTION
" A collection of notifications dealing with the change of
MTA provisioning status."
::= { pktcMtaGroups 2 }
pktcMtaNotificationGroup NOTIFICATION-GROUP NOTIFICATIONS、pktcMtaDevProvisioningStatus、pktcMtaDevProvisioningEnrollment、STATUSの現在の記述、「状態に食糧を供給するMTAの変化に対処する通知の収集。」 ::= pktcMtaGroups2
pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
" The compliance statement for S-MTA devices
that implement PacketCable or IPCablecom requirements.
pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE STATUSの現在の記述、「PacketCableかIPCablecomが要件であると実装するS-MTAデバイスのための承諾声明。」
This compliance statement applies to S-MTA implementations
that support PacketCable or IPCablecom requirements,
which are not IPv6-capable at the time of this
RFC publication."
「この承諾声明はPacketCableかIPCablecomがこのRFC公表時点でIPv6できない要件であるとサポートするS-MTA実装に適用されます。」
MODULE -- Unconditionally Mandatory Groups for S-MTA devices
MANDATORY-GROUPS {
MODULE、無条件である、S-MTAデバイスMANDATORY-GROUPSのためのMandatory Groups
Nechamkin & Mule Standards Track [Page 49] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[49ページ]。
pktcMtaGroup,
pktcMtaNotificationGroup
}
pktcMtaGroup、pktcMtaNotificationGroup
OBJECT pktcMtaDevDhcpServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevDhcpServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevDnsServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevDnsServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevTimeServerAddressType
SYNTAX InetAddressType { ipv4(1) }
DESCRIPTION
" Support for address types other than 'ipv4(1)'
is not presently specified and therefore is not
required. It may be defined in future versions of
this MIB module."
記述が「'ipv4(1)以外のアドレスタイプのためにサポートする'OBJECT pktcMtaDevTimeServerAddressType SYNTAX InetAddressType ipv4(1)は現在、指定されないで、またしたがって、必要でない、」 「それはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDhcp1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp1 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDhcp2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDhcp2 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevServerDns1
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns1 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
Nechamkin & Mule Standards Track [Page 50] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[50ページ]。
OBJECT pktcMtaDevServerDns2
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevServerDns2 SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevTimeServer
SYNTAX InetAddress (SIZE(4))
DESCRIPTION
"An implementation is only required to support IPv4
addresses. Other address types support may be defined in
future versions of this MIB module."
OBJECT pktcMtaDevTimeServer SYNTAX InetAddress、(「IPv4アドレスであるとサポート実装が必要であるだけである」SIZE(4)) DESCRIPTION。 「タイプがサポートする他のアドレスはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevProvConfigEncryptAlg
SYNTAX PktcMtaDevProvEncryptAlg
DESCRIPTION
"An implementation is only required to support
values of none(0) and des64Cbcmode(1).
An IV of zero is used to encrypt in des64Cbcmode, and
the length of pktcMtaDevProvConfigKey is 64 bits, as
defined in the PacketCable Security specification.
Other encryption types may be defined in future
versions of this MIB module."
OBJECT pktcMtaDevProvConfigEncryptAlg SYNTAX PktcMtaDevProvEncryptAlg記述、「実装がなにもの値が(0)とdes64Cbcmode(1)であるとサポートするのに必要であるだけです」。 ゼロのIVはdes64Cbcmodeで暗号化するのにおいて使用されています、そして、pktcMtaDevProvConfigKeyの長さは64ビットです、PacketCable Security仕様に基づき定義されるように。 「他の暗号化タイプはこのMIBモジュールの将来のバージョンで定義されるかもしれません。」
OBJECT pktcMtaDevRealmOrgName
SYNTAX LongUtf8String (SIZE (1..384))
DESCRIPTION
"The Organization Name field in X.509 certificates
can contain up to 64 UTF-8 encoded characters, as
defined in RFCs 3280 and 4630. Therefore, compliant
devices are only required to support Organization
Name values of up to 64 UTF-8 encoded characters.
Given that RFCs 3280 and 4630 define the UTF-8 encoding,
compliant devices must support a maximum size of 384
octets for pktcMtaDevRealmOrgName. The calculation of
384 octets comes from the RFC 3629 UTF-8 encoding
definition whereby the UTF-8 encoded characters
are encoded as sequences of 1 to 6 octets,
assuming that code points as high as 0x7ffffffff
might be used. Subsequent versions of Unicode and ISO
10646 have limited the upper bound to 0x10ffff.
Consequently, the current version of UTF-8, defined in
RFC 3629 does not require more than four octets to
encode a valid code point."
MODULE DOCS-CABLE-DEVICE-MIB
MANDATORY-GROUPS {
OBJECT pktcMtaDevRealmOrgName SYNTAX LongUtf8String(SIZE(1 .384))記述、「X.509証明書のOrganization Name分野はコード化されたキャラクタを64UTF-8まで含むことができます、RFCs3280と4630年に定義されるように」。 したがって、言いなりになっているデバイスが、最大64UTF-8のOrganization Name値にコード化されたキャラクタをサポートするのに必要であるだけです。 RFCs3280と4630がUTF-8コード化を定義するなら、言いなりになっているデバイスはpktcMtaDevRealmOrgNameのために384の八重奏の最大サイズをサポートしなければなりません。 384の八重奏の計算はコード化されたキャラクタが、1〜6つの八重奏の系列としてコード化されて、そのコードが0x7ffffffffと同じくらい高く指すと仮定するUTF-8が使用されるかもしれない定義をコード化するRFC3629UTF-8から来ます。 ユニコードとISO10646のその後のバージョンは上限を0x10ffffに制限しました。 「その結果UTF-8の最新版、RFCで定義されて、3629は有効なコード・ポイントをコード化するために4つ以上の八重奏を必要としません。」 モジュールのDOCSケーブルデバイスMIBの義務的なグループ
Nechamkin & Mule Standards Track [Page 51] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[51ページ]。
docsDevSoftwareGroupV2
}
docsDevSoftwareGroupV2
MODULE DOCS-IETF-BPI2-MIB
MANDATORY-GROUPS {
docsBpi2CodeDownloadGroup
}
モジュールのDOCS-IETF-BPI2-MIBの義務的なグループdocsBpi2CodeDownloadGroup
::= { pktcMtaCompliances 2 }
::= pktcMtaCompliances2
END
終わり
5. Acknowledgements
5. 承認
The current editors would like to thank the members of the IETF IPCDN working group and the CableLabs PacketCable Provisioning and OSS focus team for their comments and suggestions. In particular, we wish to express our gratitude for the contributions made by the following individuals (in no particular order): Angela Lyda,Sumanth Channabasappa, Matt A. Osman, Klaus Hermanns, Paul Duffy, Rick Vetter, Sasha Medvinsky, Roy Spitzer, Itay Sherman, Satish Kumar and Eric Rosenfeld. Finally, special thanks to our area director Bert Wijnen, Rich Woundy, Randy Presuhn, Mike Heard, and Dave Thaler.
現在のエディタは彼らのコメントと提案についてIETF IPCDNワーキンググループ、CableLabs PacketCable Provisioning、およびOSS焦点チームのメンバーに感謝したがっています。 特に、以下の個人(特に決まった順番でなく)によってされた貢献のために感謝したいと思います: アンジェラ・リダ、Sumanth Channabasappa、マットA.オスマン朝、クラウスHermanns、ポール・ダフィー、リック・フェッター、サシャMedvinsky、ロイ・スピッツァー、Itayシャーマン、サティシュ・クマー、およびエリック・ローゼンフェルド。 最終的に私たちの領域のバートWijnenディレクター、リッシュWoundy、ランディPresuhn、マイクHeard、およびデーヴThalerへの特別な感謝。
6. Security Considerations
6. セキュリティ問題
There are a number of management objects defined in this MIB module with a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations. Improper manipulation of the objects defined in this MIB may result in random behavior of MTA devices and may result in service disruption. These are the tables and objects and their sensitivity/vulnerability:
aがあります。読書して書くことのマックス-ACCESS節でこのMIBモジュールで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。 このMIBで定義されたオブジェクトの不適当な操作は、MTAデバイスの無作為の働きをもたらして、サービスの崩壊をもたらすかもしれません。 これらは、テーブルと、オブジェクトとそれらの感度/脆弱性です:
- The following objects, if SET maliciously, would cause the MTA
device to reset and/or stop its service:
- 以下で、サービスをSETであるなら陰湿に反対して、リセットする、そして/または、MTAデバイスを止めるでしょう:
pktcMtaDevResetNow.
pktcMtaDevEnabled.
pktcMtaDevResetNow. pktcMtaDevEnabled。
- All writable objects in the pktcMtaDevServer group and some in the
pktcMtaDevRealmTable share the potential, if SET maliciously, to
prevent the MTA from provisioning properly. Thus, they are
considered very sensitive for service delivery. The objects in
question are:
- pktcMtaDevServerグループにおけるすべての書き込み可能なオブジェクトとpktcMtaDevRealmTableの或るものは、SETであるなら適切に食糧を供給するのからのMTAを防ぐために陰湿に可能性を共有します。 したがって、それらはサービス配送に非常に敏感であると考えられます。 問題のオブジェクトは以下の通りです。
Nechamkin & Mule Standards Track [Page 52] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[52ページ]。
pktcMtaDevProvisioningTimer,
pktcMtaDevDhcpServerAddressType,
pktcMtaDevDnsServerAddressType,
pktcMtaDevTimeServerAddressType,
pktcMtaDevProvConfigEncryptAlg,
pktcMtaDevServerDns1,
pktcMtaDevServerDns2,
pktcMtaDevTimeServer,
pktcMtaDevConfigFile,
pktcMtaDevProvConfigHash,
pktcMtaDevProvConfigKey,
pktcMtaDevProvSolicitedKeyTimeout,
pktcMtaDevRealmName,
pktcMtaDevRealmOrgName,
pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
pktcMtaDevRealmUnsolicitedKeyNomTimeout,
pktcMtaDevRealmUnsolicitedKeyMaxRetries, and
pktcMtaDevRealmStatus.
pktcMtaDevProvisioningTimer、pktcMtaDevDhcpServerAddressType、pktcMtaDevDnsServerAddressType、pktcMtaDevTimeServerAddressType、pktcMtaDevProvConfigEncryptAlg、pktcMtaDevServerDns1、pktcMtaDevServerDns2、pktcMtaDevTimeServer、pktcMtaDevConfigFile、pktcMtaDevProvConfigHash; pktcMtaDevProvConfigKey、pktcMtaDevProvSolicitedKeyTimeout、pktcMtaDevRealmName、pktcMtaDevRealmOrgName、pktcMtaDevRealmUnsolicitedKeyMaxTimeout、pktcMtaDevRealmUnsolicitedKeyNomTimeout、pktcMtaDevRealmUnsolicitedKeyMaxRetries、およびpktcMtaDevRealmStatus。
Certain of the above objects have additional specific vulnerabilities:
ある上のオブジェクトでは、追加特定の脆弱性を持ってください:
o pktcMtaDevServerDns1 and pktcMtaDevServerDns2, if SET
maliciously, could prevent the MTA from being authenticated and
consequently from getting telephony services.
o SETであるなら陰湿に、MTAが認証されるのを防いで、その結果、電話を手に入れるのからそうするかもしれません。pktcMtaDevServerDns1とpktcMtaDevServerDns2、サービス。
o pktcMtaDevRealmStatus, if SET maliciously, could cause the
whole row of the table to be deleted, which may prevent MTA
from getting telephony services.
o pktcMtaDevRealmStatus、SETであるなら、陰湿に、テーブルについて全体の行を引き起こす場合がありました。削除されるために、どれが、MTAが電話サービスを得るのを防ぐかもしれないか。
- All writable objects in the pktcMtaDevCmsTable table share the
potential, if SET maliciously, to disrupt the telephony service by
altering which Call Management Server the MTA must send signaling
registration to; in particular:
- pktcMtaDevCmsTableテーブルのすべての書き込み可能なオブジェクトがSETであるならCall Management Server MTAがシグナリング登録を送らなければならない変わるのによる電話サービスを中断するために陰湿に可能性を共有します。 特に:
pktcMtaDevCmsFqdn,
pktcMtaDevCmsKerbRealmName,
pktcMtaDevCmsMaxClockSkew,
pktcMtaDevCmsSolicitedKeyTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxTimeout,
pktcMtaDevCmsUnsolicitedKeyNomTimeout,
pktcMtaDevCmsUnsolicitedKeyMaxRetries (this object, if set to a
zero value '0', may prevent the MTA from retrying its attempt
to establish a Security Association with the CMS), and
pktcMtaDevCmsStatus.
pktcMtaDevCmsFqdn、pktcMtaDevCmsKerbRealmName、pktcMtaDevCmsMaxClockSkew、pktcMtaDevCmsSolicitedKeyTimeout、pktcMtaDevCmsUnsolicitedKeyMaxTimeout、pktcMtaDevCmsUnsolicitedKeyNomTimeout、pktcMtaDevCmsUnsolicitedKeyMaxRetries(ゼロへのセットが'0'を評価するなら、このオブジェクトは、MTAがCMSとSecurity Associationを設立する試みを再試行するのを防ぐかもしれない)、およびpktcMtaDevCmsStatus。
Nechamkin & Mule Standards Track [Page 53] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[53ページ]。
- Some writable objects in the pktcMtaDevRealmTable table will not
have an immediate effect on service, if SET maliciously. However,
they may impact the service performance and cause avalanche
attacks on provisioning and Kerberos KDC servers, especially after
massive device reboots occur. The objects in question are as
follows:
- pktcMtaDevRealmTableテーブルのいくつかの書き込み可能なオブジェクトはSETであるならサービスのときに陰湿にてきめんに利かないでしょう。 しかしながら、彼らは食糧を供給するのとケルベロスKDCサーバに対するサービス性能と原因殺到攻撃に影響を与えるかもしれません、大規模なデバイスリブートが起こった特に後に。 問題のオブジェクトは以下の通りです:
pktcMtaDevResetKrbTickets: This object, if set to 'true', will
cause the MTA to request a new Kerberos ticket at reboot.
pktcMtaDevResetKrbTickets: このオブジェクトで、'本当に'設定されると、MTAはリブートで新しいケルベロスチケットを要求するでしょう。
pktcMtaDevRealmPkinitGracePeriod, pktcMtaDevRealmTgsGracePeriod:
These 2 objects, if set to short time periods, will cause the MTA
to renew its tickets more frequently.
pktcMtaDevRealmPkinitGracePeriod、pktcMtaDevRealmTgsGracePeriod: これらの2個のオブジェクトで、短い期間に設定されると、MTAは、より頻繁にチケットを取り替えるでしょう。
Some of the readable objects in this MIB module (i.e., objects with a MAX-ACCESS other than not-accessible) may be considered sensitive or vulnerable in some network environments. Some of these objects may contain information that may be sensitive from a business or customer perspective. It is thus important to control even GET and/or NOTIFY access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP.
このMIBモジュール(すなわち、アクセスしやすくないのを除いたマックス-ACCESSがあるオブジェクト)によるいくつかの読み込み可能なオブジェクトがいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 これらのいくつかのオブジェクトが企業によって機密であるかもしれない情報か顧客見解を含むかもしれません。 SNMPを通してネットワークの上にそれらを送るとき、その結果、GET、そして/または、これらのオブジェクトへのNOTIFYアクセスさえ制御して、ことによるとこれらのオブジェクトの値を暗号化するのさえ重要です。
These are the tables and objects and their sensitivity and vulnerability:
これらは、それらのテーブルと、オブジェクトと、感度と脆弱性です:
- Some readable objects in the pktcMtaDevBase, pktcMtaDevServer, and
pktcMtaDevSecurity groups share the potential, if read
maliciously, to facilitate Denial-of-Service (DoS) attacks against
provisioning or Kerberos servers. The object in question are as
follows:
- pktcMtaDevBase、pktcMtaDevServer、およびpktcMtaDevSecurityグループにおけるいくつかの読み込み可能なオブジェクトが可能性を共有します、食糧を供給するかケルベロスサーバに対してサービス妨害(DoS)攻撃を容易にするために陰湿に読まれるなら。 問題のオブジェクトは以下の通りです:
pktcMtaDevServerDhcp1, pktcMtaDevServerDhcp2, and
pktcMtaDevSnmpEntity. The values of these objects may be used to
launch DoS attacks on the Telephony Service Provider DHCP or
Provisioning servers.
pktcMtaDevServerDhcp1、pktcMtaDevServerDhcp2、およびpktcMtaDevSnmpEntity。 これらのオブジェクトの値は、Telephony Service Provider DHCPかProvisioningサーバに対するDoS攻撃に着手するのに使用されるかもしれません。
pktcMtaDevProvKerbRealmName, pktcMtaDevManufacturerCertificate,
pktcMtaDevCertificate and pktcMtaDevTelephonyRootCertificate. The
values of these objects may be used by attackers to launch DoS
attacks against Kerberos servers.
pktcMtaDevProvKerbRealmName、pktcMtaDevManufacturerCertificate、pktcMtaDevCertificate、およびpktcMtaDevTelephonyRootCertificate。 これらのオブジェクトの値は、ケルベロスサーバに対してDoS攻撃に着手するのに攻撃者によって使用されるかもしれません。
- One additional readable object may expose some security threats:
pktcMtaDevFQDN. This object may include sensitive information
about the domain name, and potentially, the domain topology.
- ある追加読み込み可能なオブジェクトが、何らかのセキュリティが脅威であると暴露するかもしれません: pktcMtaDevFQDN。 このオブジェクトはドメイン名に関する機密情報、および潜在的にドメイントポロジーを含むかもしれません。
SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPSec), even then, there is no control as to who on the secure network is
SNMPv3の前のSNMPバージョンは十分な安全性を含んでいませんでした。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、その時でさえ、だれが安全なネットワークの一員であるかに関してコントロールが全くありません。
Nechamkin & Mule Standards Track [Page 54] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[54ページ]。
allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module.
このMIBモジュールで(読むか、変える、作成する、または削除します)オブジェクトをアクセスとGET/SETに許容しました。
It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see Section 8 in [RFC3410]), including full support for the SNMPv3 cryptographic mechanisms (for authentication and privacy).
implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは([RFC3410]でセクション8を見てください)、RECOMMENDEDです、SNMPv3の暗号のメカニズム(認証とプライバシーのための)の全面的な支援を含んでいて。
Further, deployment of SNMP versions prior to SNMPv3 is NOT RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to enable cryptographic security. It is then a customer/operator responsibility to ensure that the SNMP entity giving access to an instance of this MIB module is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them.
さらに、SNMPv3の前のSNMPバージョンの展開はNOT RECOMMENDEDです。 代わりに、それはSNMPv3を配布して、暗号のセキュリティを可能にするRECOMMENDEDです。 そして、このMIBモジュールのインスタンスへのアクセスを与えるSNMP実体が本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために適切に構成されるのを保証するのは、顧客/オペレータ責任です。
7. IANA Considerations
7. IANA問題
The MIB module defined in this document uses the following IANA- assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers registry:
本書では定義されたMIBモジュールはSMI民数記登録に記録されたOBJECT IDENTIFIER値が割り当てられた以下のIANAを使用します:
Descriptor OBJECT IDENTIFIER value
---------- -----------------------
pktcIetfMtaMib { mib-2 140 }
記述子OBJECT IDENTIFIER価値---------- ----------------------- pktcIetfMtaMibmib-2 140
8. Normative References
8. 引用規格
[RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD
26, RFC 868, May 1983.
[RFC868] ポステル、J.、およびK.Harrenstien(「時間プロトコル」、STD26、RFC868)は1983がそうするかもしれません。
[RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD
33, RFC 1350, July 1992.
[RFC1350] Sollins、K.、「TFTPプロトコル(改正2)」、STD33、RFC1350、1992年7月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendor Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[RFC2287] Krupczak, C. and J. Saperia, "Definitions of
System-Level Managed Objects for Applications", RFC
2287, February 1998.
[RFC2287]KrupczakとC.とJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、RFC2287、1998年2月。
Nechamkin & Mule Standards Track [Page 55] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[55ページ]。
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder J., Case,
J. Rose, M. and S. Waldbusser, "Structure of
Management Information Version 2 (SMIv2)", STD 58,
RFC 2578, April 1999.
[RFC2578]McCloghrieとK.とパーキンスとD.とSchoenwaelder J.とケース、J.ローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J. Case,
J. Rose, M. and S. Waldbusser, "Textual Conventions
for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.ケース、J.ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder J., Case,
J., Rose, M. and S. Waldbusser, "Conformance
Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelder J.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee,
"Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
June 1999.
[RFC2616] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo,
"Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL)
Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network
Management Protocol (SNMP) Management Frameworks",
STD 62, RFC 3411, December 2002.
[RFC3411] ハリントン、D.、Presuhn、R.、およびB.Wijnen、「簡単なネットワーク管理プロトコル(SNMP)管理フレームワークについて説明するためのアーキテクチャ」、STD62、RFC3411(2002年12月)。
[RFC3418] Presuhn, R., "Management Information Base (MIB) for
the Simple Network Management Protocol (SNMP)", STD
62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、「簡単なネットワーク管理プロトコル(SNMP)のための管理情報ベース(MIB)」、STD62、RFC3418、2002年12月。
[RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration
Protocol (DHCP) Option for CableLabs Client
Configuration", RFC 3495, March 2003.
[RFC3495]BeserとB.とP.ダフィー、「CableLabsクライアント構成のためのDynamic Host Configuration Protocol(DHCP)オプション」、RFC3495、2003年3月。
[RFC3594] Duffy, P., "PacketCable Security Ticket Control
Sub-Option for the DHCP CableLabs Client
Configuration (CCC) Option", RFC 3594, September
2003.
[RFC3594] ダフィー、P.、「DHCP CableLabsクライアント構成(CCC)オプションのためのサブオプションのPacketCableセキュリティチケットコントロール」、RFC3594、2003年9月。
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet
Network Addresses", RFC 4001, February 2005.
2005年2月の[RFC4001]ダニエルとM.とハーバーマンとB.とRouthier、S.とJ.Schoenwaelder、「インターネットネットワーク・アドレスのための原文のコンベンション」RFC4001。
Nechamkin & Mule Standards Track [Page 56] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[56ページ]。
[RFC4131] Green, S., Ozawa, K., Cardona, E., and A.
Katsnelson, "Management Information Base for Data
Over Cable Service Interface Specification (DOCSIS)
Cable Modems and Cable Modem Termination Systems for
Baseline Privacy Plus", RFC 4131, September 2005.
[RFC4131] グリーン、S.、小沢、K.、Cardona、E.、およびA.Katsnelson、「基線プライバシープラスのケーブルサービスインターフェース仕様(DOCSIS)ケーブルモデムとケーブルモデム終了システムの上のデータのための管理情報ベース」、RFC4131(2005年9月)。
[RFC4630] Housley, R. and S. Santesson, "Update to
DirectoryString Processing in the Internet X.509
Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC
4630, August 2006.
[RFC4630]Housley(R.とS.Santesson)は「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)プロフィールで処理をDirectoryStringにアップデートします」、RFC4630、2006年8月。
[RFC4639] Woundy, R. and K. Marez, "Cable Device Management
Information Base for Data-Over-Cable Service
Interface Specification (DOCSIS) Compliant Cable
Modems and Cable Modem Termination Systems", RFC
4639, December 2006.
[RFC4639]Woundy(R.とK.Marez)は「データ過剰ケーブルのサービスのインターフェース仕様(DOCSIS)対応することのケーブルモデムとケーブルモデム終了システムのためにデバイス管理情報ベースに電報を打ちます」、RFC4639、2006年12月。
[PKT-SP-PROV] Packetcable MTA Device Provisioning Specification,
Issued, PKT-SP-PROV-I11-050812, August 2005.
http://www.packetcable.com/specifications/
http://www.cablelabs.com/specifications/archives/
仕様に食糧を供給して、支給された[PKT-SP-PROV]Packetcable MTAデバイス、PKT-SP-PROV-I11-050812、8月2005日の http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/
[PKT-SP-SEC] PacketCable Security Specification, Issued, PKT-SP-
SEC-I12-050812, August 2005.
http://www.packetcable.com/specifications/
http://www.cablelabs.com/specifications/archives/
[PKT-SP-SEC] PacketCableセキュリティ仕様、発行されたPKT-SP SEC-I12-050812、8月2005日の http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/
[ITU-T-J112] Transmission Systems for Interactive Cable
Television Services, Annex B, J.112, ITU-T, March,
1998.
[ITU-T-J112] 1998年3月の対話的なケーブルテレビ放送、別館B、J.112、ITU-Tの伝動装置。
[ITU-T-J168] IPCablecom Multimedia Terminal Adapter (MTA) MIB
requirements, J.168, ITU-T, March, 2001.
[ITU-T-J168] IPCablecom Multimediaティーエー(MTA)MIB要件、J.168、ITU-T、2001年3月。
9. Informative References
9. 有益な参照
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3410] ケース、J.、マンディ、R.、パーテイン、D.、およびB.スチュワート、「インターネット標準の管理フレームワークのための序論と適用性声明」、RFC3410(2002年12月)。
[RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme
and Applicability Statement for the Trivial File
Transfer Protocol (TFTP)", RFC 3617, October 2003.
[RFC3617] リアと、E.と、「Uniform Resource Identifier(URI)体系とトリビアル・ファイル転送プロトコル(TFTP)のための適用性証明」、RFC3617(2003年10月)
Nechamkin & Mule Standards Track [Page 57] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[57ページ]。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[PKT-SP-MIB-MTA] Packetcable MTA MIB Specification, Issued, PKT-SP-
MIB-MTA-I10-050812, August 2005.
http://www.packetcable.com/specifications/
http://www.cablelabs.com/specifications/archives/
[PKT-SP-MIB-MTA]Packetcable MTA MIB仕様、PKT-SP- MIB-MTA-I10-050812、発行されて、8月2005日の http://www.packetcable.com/specifications/ http://www.cablelabs.com/specifications/archives/
[ETSITS101909-8] ETSI TS 101 909-8: "Access and Terminals (AT);
Digital Broadband Cable Access to the Public
Telecommunications Network; IP Multimedia Time
Critical Services; Part 8: Media Terminal Adaptor
(MTA) Management Information Base (MIB)".
[ETSITS101909-8]ETSI t101 909-8: 「アクセスと端末(AT)」。 公立のテレコミュニケーションネットワークへのデジタル広帯域のケーブルアクセス。 IPのマルチメディアの時間の重要なサービス。 パート8: 「メディアターミナルアダプタ(MTA)管理情報ベース(MIB)。」
[EN300001] EN 300 001 V1.5.1 (1998-10):"European Standard
(Telecommunications series) Attachments to Public
Switched Telephone Network (PSTN); General technical
requirements for equipment connected to an analogue
subscriber interface in the PSTN".
[EN300001]EN300 001V1.5.1(1998-10): 「Public Switched Telephone Network(PSTN)へのヨーロッパのStandard(テレコミュニケーションシリーズ)付属」。 「設備のための一般技術的要求事項はPSTNのアナログ加入者インタフェースに接続しました。」
[EN300659-1] EN 300 659-1: "Public Switched Telephone Network
(PSTN); Subscriber line protocol over the local loop
for display (and related) services; Part 1: On hook
data transmission".
[EN300659-1]アン300 659-1: 「公衆電話交換網(PSTN)」。 ディスプレイ(そして、関係する)サービスのための回線折返しの上の加入者系列プロトコル。 第1部: 「フックデータ伝送。」
[NCSSIGMIB] Beacham G., Kumar S., Channabasappa S., "Network
Control Signaling (NCS) Signaling MIB for
PacketCable and IPCablecom Multimedia Terminal
Adapters (MTAs)", Work in Progress, June 2006.
[NCSSIGMIB]ビーチャムG.、クマーS.、「PacketCableのためにMIBに合図しながら(NCS)を示すネットワーク制御とIPCablecomマルチメディア端末アダプター(MTAs)」というChannabasappa S.は進行中(2006年6月)で働いています。
Nechamkin & Mule Standards Track [Page 58] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[58ページ]。
Authors' Addresses
作者のアドレス
Eugene Nechamkin Broadcom Corporation, 200 - 13711 International Place Richmond, BC, V6V 2Z8 CANADA
ユージンNechamkin Broadcom社、リッチモンド、紀元前、200--13711の国際場所V6V 2Z8カナダ
Phone: +1 604 233 8500 EMail: enechamkin@broadcom.com
以下に電話をしてください。 +1 8500年の604 233メール: enechamkin@broadcom.com
Jean-Francois Mule Cable Television Laboratories, Inc. 858 Coal Creek Circle Louisville, Colorado 80027-9750 U.S.A.
Inc.858石炭クリーク円のルイビル、ジャン・フランソワラバケーブルテレビ研究所コロラド80027-9750米国
Phone: +1 303 661 9100 EMail: jf.mule@cablelabs.com
以下に電話をしてください。 +1 9100年の303 661メール: jf.mule@cablelabs.com
Nechamkin & Mule Standards Track [Page 59] RFC 4682 IPCDN MTA MIB December 2006
Nechamkinとラバ規格はIPCDN MTA MIB2006年12月にRFC4682を追跡します[59ページ]。
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機能のための基金は現在、インターネット協会によって提供されます。
Nechamkin & Mule Standards Track [Page 60]
Nechamkinとラバ標準化過程[60ページ]
一覧
スポンサーリンク
