summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4682.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc4682.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc4682.txt')
-rw-r--r--doc/rfc/rfc4682.txt3363
1 files changed, 3363 insertions, 0 deletions
diff --git a/doc/rfc/rfc4682.txt b/doc/rfc/rfc4682.txt
new file mode 100644
index 0000000..285deeb
--- /dev/null
+++ b/doc/rfc/rfc4682.txt
@@ -0,0 +1,3363 @@
+
+
+
+
+
+
+Network Working Group E. Nechamkin
+Request for Comments: 4682 Broadcom Corp.
+Category: Standards Track J-F. Mule
+ CableLabs
+ December 2006
+
+
+ Multimedia Terminal Adapter (MTA) Management Information Base
+ for PacketCable- and IPCablecom-Compliant Devices
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The IETF Trust (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.
+
+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
+
+
+
+Nechamkin & Mule Standards Track [Page 1]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+1. The Internet-Standard Management Framework
+
+ For a detailed overview of the documents that describe the current
+ Internet-Standard Management Framework, please refer to section 7 of
+ RFC 3410 [RFC3410].
+
+ 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].
+
+2. Terminology
+
+ 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].
+
+ 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].
+
+ 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].
+
+ 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].
+
+ 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.
+
+ Multimedia Terminal Adapter
+ A Multimedia Terminal Adapter (MTA) is a PacketCable- or IPCablecom-
+ compliant device providing telephony services over a cable or hybrid
+
+
+
+Nechamkin & Mule Standards Track [Page 2]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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).
+
+ 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.
+
+ 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].
+
+ Voice over IP
+ Voice over IP (VoIP) is a technology providing the means to transfer
+ digitized packets with voice information over IP networks.
+
+ 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.
+
+ 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].
+
+ TFTP
+ The Trivial File Transfer Protocol (TFTP) is defined by RFC 1350
+ [RFC1350].
+
+ HTTP
+ The Hypertext Transfer Protocol (HTTP/1.1) is defined by RFC 2616
+ [RFC2616].
+
+ Call Management Server
+ A Call Management Server (CMS) is an element of the PacketCable
+ network infrastructure that controls audio connections between MTAs.
+
+
+
+Nechamkin & Mule Standards Track [Page 3]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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.
+
+ 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.
+
+ 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).
+
+ Security Association
+ A Security Association (SA) is a one-way relationship between a
+ sender and a receiver offering security services on the communication
+ flow.
+
+3. Introduction
+
+ 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:
+
+ - The PacketCable 1.0 MTA MIB Specification [PKT-SP-MIB-MTA].
+
+ - The ITU-T IPCablecom MTA MIB requirements [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].
+
+ 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.
+
+
+
+Nechamkin & Mule Standards Track [Page 4]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+3.1. Structure of the MTA MIB
+
+ The MTA MIB module is identified by pktcIetfMtaMib and is structured
+ in three object groups:
+
+ - pktcMtaDevBase defines the management information pertinent to the
+ MTA device itself.
+
+ - pktcMtaDevServer defines the management information pertinent to
+ the provisioning back office servers.
+
+ - pktcMtaDevSecurity defines the management information pertinent to
+ the PacketCable and IPCablecom security mechanisms.
+
+ 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.
+
+ 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.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:
+
+ - pktcMtaDevSerialNumber. This object contains the MTA Serial
+ Number.
+
+ - pktcMtaDevEndPntCount. This object contains the number of
+ endpoints present in the managed MTA.
+
+ - pktcMtaDevProvisioningState. This object contains the information
+ describing the completion state of the MTA initialization process.
+
+ - pktcMtaDevEnabled. This object controls the administrative state
+ of the MTA endpoints and allows operators to enable or disable
+ telephony services on the device.
+
+ - pktcMtaDevResetNow. This object is used to instruct the MTA to
+ reset.
+
+
+
+Nechamkin & Mule Standards Track [Page 5]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+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.
+
+ Some highlights are as follows:
+
+ - pktcMtaDevServerDhcp1. This object contains the IP address of the
+ primary DHCP server designated for the MTA provisioning.
+
+ - pktcMtaDevServerDhcp2. This object contains the IP address of the
+ secondary DHCP server designated for the MTA provisioning.
+
+ - 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.
+
+ - pktcMtaDevServerDns2. This object contains the IP address of the
+ secondary DNS used by the managed MTA to resolve the FQDN and IP
+ addresses.
+
+ - pktcMtaDevConfigFile. This object contains the name of the
+ provisioning configuration file the managed MTA must download from
+ the 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.
+
+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.
+
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 6]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ The two tables in this object group are as follows:
+
+ - pktcMtaDevRealmTable. This table is used in conjunction with any
+ Application Server that communicates securely with the managed MTA
+ (CMS or Provisioning Server).
+
+ - pktcMtaDevCmsTable. This table contains the parameters describing
+ the SA establishment between the MTA and CMSes.
+
+3.5. Relationship between MIB Objects in the MTA 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.
+
+ 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.
+
+ The SA establishment process consists of two steps:
+
+ 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.
+
+ 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.
+
+ 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:
+
+ - pktcMtaDevProvUnsolicitedKeyMaxTimeout,
+
+ - pktcMtaDevProvUnsolicitedKeyNomTimeout,
+
+
+
+Nechamkin & Mule Standards Track [Page 7]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ - pktcMtaDevProvUnsolicitedKeyMaxRetries, and
+
+ - pktcMtaDevProvSolicitedKeyTimeout.
+
+3.6. Secure Software Download
+
+ 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.
+
+ 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:
+
+ - docsBpi2CodeDownloadGroup, defined in the IETF BPI Plus MIB module
+ (DOCS-IETF-BPI2-MIB [RFC4131]).
+
+ - docsDevSoftwareGroupV2, defined in the IETF Cable Devicev2 MIB
+ module (DOCS-CABLE-DEVICE-MIB [RFC4639]).
+
+3.7. X.509 Certificates Dependencies
+
+ 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].
+
+ 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].
+
+ 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.
+
+
+
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 8]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+4. Definitions
+
+ The MIB module below makes references and citations to [RFC868],
+ [RFC3280], [RFC4630], and [RFC3617].
+
+ PKTC-IETF-MTA-MIB DEFINITIONS ::= BEGIN
+
+ 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]
+
+ 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,
+
+
+
+Nechamkin & Mule Standards Track [Page 9]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ Richmond, BC, V6V 2Z8
+ CANADA
+ Phone: +1 604 233 8500
+ Email: 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
+
+ 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"
+
+ DESCRIPTION
+ "This MIB module defines the basic management object
+ for the Multimedia Terminal Adapter devices compliant
+ with PacketCable and IPCablecom requirements.
+
+ 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."
+
+ REVISION "200609180000Z" -- September 18, 2006
+
+ DESCRIPTION
+ "Initial version, published as RFC 4682."
+
+ ::= { 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:
+
+ 'none(0)' no encryption is used,
+ 'des64CbcMode(1)' DES 64-bit key in CBC mode,
+
+
+
+Nechamkin & Mule Standards Track [Page 10]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ '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)
+ }
+
+ --=================================================================
+ -- The MTA MIB module only supports a single 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 }
+
+ --
+ -- The following pktcMtaDevBase group describes the base MTA objects
+ --
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 11]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ " PacketCable MTA Device Provisioning Specification."
+ ::= { pktcMtaDevBase 1 }
+
+ 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 }
+
+ 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."
+
+ ::= { pktcMtaDevBase 3 }
+
+ 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."
+
+
+
+Nechamkin & Mule Standards Track [Page 12]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ ::= { pktcMtaDevBase 4 }
+
+ 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 }
+
+ 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.
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 13]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ Specification."
+ ::= { pktcMtaDevBase 6 }
+
+ 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 }
+
+ 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.
+
+ 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'.
+
+ inProgress:
+ If the MTA is in the process of being provisioned,
+ the MTA MUST return the value '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
+
+
+
+Nechamkin & Mule Standards Track [Page 14]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ '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'.
+
+ 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'.
+
+ failureInternalError:
+ If the configuration file cannot be parsed due to an
+ Internal error, the MTA MUST return the value
+ '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'.
+
+ 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 }
+
+ 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 }
+
+ pktcMtaDevProvisioningTimer OBJECT-TYPE
+ SYNTAX Unsigned32 (0..30)
+ UNITS "minutes"
+ MAX-ACCESS read-write
+ STATUS current
+
+
+
+Nechamkin & Mule Standards Track [Page 15]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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}
+
+ 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}
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 16]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ the MTA reboots."
+ REFERENCE
+ " PacketCable MTA Device Provisioning Specification."
+ ::= {pktcMtaDevBase 12 }
+
+ 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}
+
+ PktcMtaDevErrorOidsEntry ::= SEQUENCE {
+ 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.
+
+ 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.
+
+ 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."
+
+ ::= {pktcMtaDevErrorOidsEntry 1}
+
+
+
+
+Nechamkin & Mule Standards Track [Page 17]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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.
+
+ 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."
+
+ ::= {pktcMtaDevErrorOidsEntry 2}
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 18]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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'.
+
+ 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'."
+
+ ::= {pktcMtaDevErrorOidsEntry 3}
+
+ 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.
+
+ 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}
+
+ --
+ -- The following group describes server access and parameters used
+
+
+
+Nechamkin & Mule Standards Track [Page 19]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ -- for the initial MTA provisioning and bootstrapping phases.
+ --
+
+ 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}
+
+ 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.
+
+ 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 }
+
+ pktcMtaDevServerDhcp2 OBJECT-TYPE
+ SYNTAX InetAddress
+ MAX-ACCESS read-only
+
+
+
+Nechamkin & Mule Standards Track [Page 20]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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.
+
+ 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 }
+
+ 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}
+
+ 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)'
+
+
+
+Nechamkin & Mule Standards Track [Page 21]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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 }
+
+ 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}
+
+ pktcMtaDevTimeServer OBJECT-TYPE
+ SYNTAX InetAddress
+
+
+
+Nechamkin & Mule Standards Track [Page 22]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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}
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 23]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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."
+
+ REFERENCE
+ " PacketCable MTA Device Provisioning Specification;
+ RFC 3495, DHCP Option for CableLabs Client Configuration."
+ ::= { pktcMtaDevServer 10 }
+
+ pktcMtaDevProvConfigHash OBJECT-TYPE
+ SYNTAX OCTET STRING (SIZE(20))
+ MAX-ACCESS read-write
+ STATUS current
+
+
+
+Nechamkin & Mule Standards Track [Page 24]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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.
+
+ 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.
+
+ If this object is set at any other provisioning step than
+ that allowed by the PacketCable MTA Device
+
+
+
+Nechamkin & Mule Standards Track [Page 25]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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 }
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 26]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ --=================================================================
+ --
+ -- 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.
+ --
+ --=================================================================
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 27]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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}
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 28]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ " PacketCable Security Specification."
+ DEFVAL {8}
+ ::= { pktcMtaDevServer 17 }
+
+ 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 }
+
+ 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:
+
+ 'operational(1)', the device has completed the loading
+ and processing of the initialization parameters.
+
+ 'waitingForSnmpSetInfo(2)', the device is waiting on
+ its configuration file download access information.
+ Note that this state is only reported when the MTA
+
+
+
+Nechamkin & Mule Standards Track [Page 29]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ SNMP enrollment mechanism is used.
+
+ '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.
+
+ '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 }
+
+ --
+ -- 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."
+
+ ::= {pktcMtaDevSecurity 1}
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 30]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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 }
+
+ 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 }
+
+ --=================================================================
+ --
+ -- Informative Procedures for Setting up Security Associations
+ --
+
+
+
+Nechamkin & Mule Standards Track [Page 31]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ -- 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.
+ --
+
+
+
+Nechamkin & Mule Standards Track [Page 32]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ --=================================================================
+
+ 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:
+
+ First, issue a management protocol retrieval operation
+ to determine the value of the first available index in the
+ realm table (pktcMtaDevRealmAvailSlot).
+
+ Second, issue a management protocol SET operation
+ to create an instance of the pktcMtaDevRealmStatus
+ object by setting its value to 'createAndWait(5)'.
+
+ 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 }
+
+ 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 }
+
+ pktcMtaDevRealmEntry OBJECT-TYPE
+ SYNTAX PktcMtaDevRealmEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+
+
+
+Nechamkin & Mule Standards Track [Page 33]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ PktcMtaDevRealmEntry ::= SEQUENCE {
+ 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}
+
+ 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 }
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 34]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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 }
+
+ 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 }
+
+
+
+Nechamkin & Mule Standards Track [Page 35]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+
+ 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.
+
+ 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).
+
+ 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 }
+
+ 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.
+
+
+
+
+Nechamkin & Mule Standards Track [Page 36]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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).
+
+ 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 }
+
+ 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.
+
+ 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).
+
+ 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 }
+
+
+
+Nechamkin & Mule Standards Track [Page 37]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ ::= { pktcMtaDevRealmEntry 8 }
+
+ 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).
+
+ 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 }
+
+ --=================================================================
+ --
+ -- 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.
+ --
+ --=================================================================
+
+ pktcMtaDevCmsAvailSlot OBJECT-TYPE
+ SYNTAX Unsigned32 (0..128)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+
+
+
+Nechamkin & Mule Standards Track [Page 38]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ " 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:
+
+ First, issue a management protocol retrieval operation
+ to determine the value of the first available index in the
+ CMS table (pktcMtaDevCmsAvailSlot).
+
+ Second, issue a management protocol SET operation
+ to create an instance of the pktcMtaDevCmsStatus
+ object by setting its value to 'createAndWait(5)'.
+
+ 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 }
+
+ 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 }
+
+ 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 }
+
+
+
+Nechamkin & Mule Standards Track [Page 39]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ ::= { pktcMtaDevCmsTable 1 }
+
+ PktcMtaDevCmsEntry ::= SEQUENCE {
+ 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 }
+
+ 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 }
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 40]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ conceptual row. The object value is a reference
+ point to the corresponding Kerberos realm name in the
+ realm table (pktcMtaDevRealmTable)."
+ ::= { pktcMtaDevCmsEntry 3 }
+
+ 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 }
+
+ 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 }
+
+ --=================================================================
+ --
+ -- 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,
+
+
+
+Nechamkin & Mule Standards Track [Page 41]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ -- 20 s, and 20 s; retransmissions then stop due to the
+ -- maximum number of retries reached.
+ --
+ --=================================================================
+
+ 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 }
+
+ 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 }
+
+ 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 }
+
+
+
+
+Nechamkin & Mule Standards Track [Page 42]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ 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).
+
+ 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.
+
+ The value of this object has no effect on
+ whether other columnar objects in this row can be
+ modified."
+ ::= { pktcMtaDevCmsEntry 10 }
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 43]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ --
+ -- The following group, pktcMtaDevErrors, defines an OID
+ -- corresponding to error conditions encountered during the MTA
+ -- provisioning.
+ --
+
+ 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 }
+
+ pktcMtaDevProvisioningEnrollment NOTIFICATION-TYPE
+ OBJECTS {
+ sysDescr,
+ pktcMtaDevSwCurrentVers,
+ pktcMtaDevTypeIdentifier,
+ ifPhysAddress,
+ pktcMtaDevCorrelationId
+
+
+
+Nechamkin & Mule Standards Track [Page 44]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ }
+ 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 }
+
+ 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 }
+
+ --
+ -- Compliance Statements
+ --
+
+ pktcMtaCompliances OBJECT IDENTIFIER ::= { pktcMtaConformance 1 }
+ pktcMtaGroups OBJECT IDENTIFIER ::= { pktcMtaConformance 2 }
+
+ pktcMtaBasicCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ " The compliance statement for MTA devices that implement
+ PacketCable or IPCablecom requirements.
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 45]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ RFC publication."
+
+ MODULE -- Unconditionally mandatory groups for MTAs
+
+ MANDATORY-GROUPS {
+ 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."
+
+ 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."
+
+ 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."
+
+ 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 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 pktcMtaDevServerDns1
+
+
+
+Nechamkin & Mule Standards Track [Page 46]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 (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 (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 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 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.
+
+
+
+Nechamkin & Mule Standards Track [Page 47]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ Consequently, the current version of UTF-8, defined in
+ RFC 3629, does not require more than four octets to
+ encode a valid code point."
+
+ ::= { pktcMtaCompliances 1 }
+
+ 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,
+
+
+
+Nechamkin & Mule Standards Track [Page 48]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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 }
+
+ pktcMtaNotificationGroup NOTIFICATION-GROUP
+ NOTIFICATIONS {
+ pktcMtaDevProvisioningStatus,
+ pktcMtaDevProvisioningEnrollment
+ }
+ STATUS current
+ DESCRIPTION
+ " A collection of notifications dealing with the change of
+ MTA provisioning status."
+ ::= { pktcMtaGroups 2 }
+
+ pktcMtaBasicSmtaCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ " The compliance statement for S-MTA devices
+ that implement PacketCable or IPCablecom requirements.
+
+ 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."
+
+ MODULE -- Unconditionally Mandatory Groups for S-MTA devices
+ MANDATORY-GROUPS {
+
+
+
+Nechamkin & Mule Standards Track [Page 49]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ 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."
+
+ 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."
+
+ 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."
+
+ 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 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 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."
+
+
+
+Nechamkin & Mule Standards Track [Page 50]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+
+ 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 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 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 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 {
+
+
+
+Nechamkin & Mule Standards Track [Page 51]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ docsDevSoftwareGroupV2
+ }
+
+ MODULE DOCS-IETF-BPI2-MIB
+ MANDATORY-GROUPS {
+ docsBpi2CodeDownloadGroup
+ }
+
+ ::= { pktcMtaCompliances 2 }
+
+ END
+
+5. Acknowledgements
+
+ 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.
+
+6. Security Considerations
+
+ 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:
+
+ - The following objects, if SET maliciously, would cause the MTA
+ device to reset and/or stop its service:
+
+ 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:
+
+
+
+
+Nechamkin & Mule Standards Track [Page 52]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ pktcMtaDevProvisioningTimer,
+ pktcMtaDevDhcpServerAddressType,
+ pktcMtaDevDnsServerAddressType,
+ pktcMtaDevTimeServerAddressType,
+ pktcMtaDevProvConfigEncryptAlg,
+ pktcMtaDevServerDns1,
+ pktcMtaDevServerDns2,
+ pktcMtaDevTimeServer,
+ pktcMtaDevConfigFile,
+ pktcMtaDevProvConfigHash,
+ pktcMtaDevProvConfigKey,
+ pktcMtaDevProvSolicitedKeyTimeout,
+ pktcMtaDevRealmName,
+ pktcMtaDevRealmOrgName,
+ pktcMtaDevRealmUnsolicitedKeyMaxTimeout,
+ pktcMtaDevRealmUnsolicitedKeyNomTimeout,
+ pktcMtaDevRealmUnsolicitedKeyMaxRetries, and
+ 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 pktcMtaDevRealmStatus, if SET maliciously, could cause the
+ whole row of the table to be deleted, which may prevent MTA
+ from getting telephony services.
+
+ - 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:
+
+ 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.
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 53]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ - 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:
+
+ pktcMtaDevResetKrbTickets: This object, if set to 'true', will
+ cause the MTA to request a new Kerberos ticket at reboot.
+
+ pktcMtaDevRealmPkinitGracePeriod, pktcMtaDevRealmTgsGracePeriod:
+ These 2 objects, if set to short time periods, will cause the MTA
+ to renew its tickets more frequently.
+
+ 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.
+
+ 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:
+
+ 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.
+
+ pktcMtaDevProvKerbRealmName, pktcMtaDevManufacturerCertificate,
+ pktcMtaDevCertificate and pktcMtaDevTelephonyRootCertificate. The
+ values of these objects may be used by attackers to launch DoS
+ attacks against Kerberos servers.
+
+ - 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.
+
+ 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
+
+
+
+Nechamkin & Mule Standards Track [Page 54]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ allowed to access and GET/SET (read/change/create/delete) the objects
+ in this MIB module.
+
+ 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).
+
+ 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.
+
+7. IANA Considerations
+
+ The MIB module defined in this document uses the following IANA-
+ assigned OBJECT IDENTIFIER values, recorded in the SMI Numbers
+ registry:
+
+ Descriptor OBJECT IDENTIFIER value
+ ---------- -----------------------
+ pktcIetfMtaMib { mib-2 140 }
+
+8. Normative References
+
+ [RFC868] Postel, J. and K. Harrenstien, "Time Protocol", STD
+ 26, RFC 868, May 1983.
+
+ [RFC1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD
+ 33, RFC 1350, July 1992.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
+ RFC 2131, March 1997.
+
+ [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
+ Vendor Extensions", RFC 2132, March 1997.
+
+ [RFC2287] Krupczak, C. and J. Saperia, "Definitions of
+ System-Level Managed Objects for Applications", RFC
+ 2287, February 1998.
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 55]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ [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.
+
+ [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J. Case,
+ J. Rose, M. and S. Waldbusser, "Textual Conventions
+ for SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder J., Case,
+ J., Rose, M. and S. Waldbusser, "Conformance
+ Statements for SMIv2", STD 58, RFC 2580, April 1999.
+
+ [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.
+
+ [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces
+ Group MIB", RFC 2863, June 2000.
+
+ [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.
+
+ [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.
+
+ [RFC3418] Presuhn, R., "Management Information Base (MIB) for
+ the Simple Network Management Protocol (SNMP)", STD
+ 62, RFC 3418, December 2002.
+
+ [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration
+ Protocol (DHCP) Option for CableLabs Client
+ Configuration", RFC 3495, March 2003.
+
+ [RFC3594] Duffy, P., "PacketCable Security Ticket Control
+ Sub-Option for the DHCP CableLabs Client
+ Configuration (CCC) Option", RFC 3594, September
+ 2003.
+
+ [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
+ Schoenwaelder, "Textual Conventions for Internet
+ Network Addresses", RFC 4001, February 2005.
+
+
+
+
+Nechamkin & Mule Standards Track [Page 56]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ [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.
+
+ [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.
+
+ [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.
+
+ [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-SEC] PacketCable Security Specification, Issued, PKT-SP-
+ SEC-I12-050812, August 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-J168] IPCablecom Multimedia Terminal Adapter (MTA) MIB
+ requirements, J.168, ITU-T, March, 2001.
+
+9. Informative References
+
+ [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
+ "Introduction and Applicability Statements for
+ Internet-Standard Management Framework", RFC 3410,
+ December 2002.
+
+ [RFC3617] Lear, E., "Uniform Resource Identifier (URI) Scheme
+ and Applicability Statement for the Trivial File
+ Transfer Protocol (TFTP)", RFC 3617, October 2003.
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 57]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+ [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
+ 10646", STD 63, RFC 3629, November 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/
+
+ [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)".
+
+ [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".
+
+ [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".
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 58]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+Authors' Addresses
+
+ Eugene Nechamkin
+ Broadcom Corporation,
+ 200 - 13711 International Place
+ Richmond, BC, V6V 2Z8
+ CANADA
+
+ Phone: +1 604 233 8500
+ EMail: enechamkin@broadcom.com
+
+
+ Jean-Francois Mule
+ Cable Television Laboratories, Inc.
+ 858 Coal Creek Circle
+ Louisville, Colorado 80027-9750
+ U.S.A.
+
+ Phone: +1 303 661 9100
+ EMail: jf.mule@cablelabs.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 59]
+
+RFC 4682 IPCDN MTA MIB December 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (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.
+
+ 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.
+
+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.
+
+ 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.
+
+ 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+Nechamkin & Mule Standards Track [Page 60]
+