Internet-Draft E. Cardona draft-ietf-ipcdn-cable-gateway-addressing-mib-00.txt K. Luehrs Expires: December 2003 CableLabs G. Nakanishi Motorola D. Jones YAS BBV June 2003 Cable Gateway Addressing Management Information Base for CableHome compliant Residential Gateways Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. 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 SNMP- based management of Network Address Translation and transparent bridging functionality within a CableHome compliant residential gateway. Cardona, et. al. Expires - December 2003 [Page 1]
Internet-Draft CableHome Gateway Addressing MIB June 2003 This memo specifies a MIB module in a manner that is compliant to the SNMP SMIv2 [5][6][7]. The set of objects is consistent with the SNMP framework and existing SNMP standards. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents 1. The Internet-Standard Management Framework.....................2 2. Glossary.......................................................3 2.1 CATV.......................................................3 2.2 CableHome Residential Gateway..............................3 2.3 Portal Services............................................3 2.4 CAP (CableHome Address Portal).............................3 3. Overview.......................................................3 3.1 Structure of the MIB.......................................4 3.2 Management Requirements....................................4 4. MIB Definitions................................................5 5. Acknowledgements..............................................15 6. Formal Syntax.................................................15 7. Security Considerations.......................................15 8. Normative References..........................................16 9. Informative References........................................18 10. Intellectual Property........................................18 11. Author's Addresses...........................................18 12. Full Copyright Statement.....................................19 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 [12]. 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 [7], STD 58, RFC 2579 [8] and STD 58, RFC 2580 [9]. Cardona, et. al. Expires - December 2003 [Page 2]
Internet-Draft CableHome Gateway Addressing MIB June 2003 2. Glossary The terms in this document are derived either from normal cable system usage, from normal residential gateway operation, or from the documents associated with the CableHome Specifications [21]. 2.1 CATV Originally "Community Antenna Television", now used to refer to any cable or hybrid fiber and cable system used to deliver video signals to a community. 2.2 CableHome Residential Gateway A CableHome Residential gateway passes data traffic between the cable operator's broadband data network (the Wide Area Network, WAN) and the Local Area Network (LAN) in the cable data service subscriber's residence or business. In addition to passing traffic between the WAN and LAN, the CableHome Residential Gateway provides several services including a DHCP client and a DHCP server (RFC2131) [22], a TFTP server (RFC1350) [23], management services as enabled by SNMPv1/v2c/v3 agent compliant with the RFCs listed in Section 1, and security services including stateful packet inspection firewall functionality and software code image verification using techniques. 2.3 Portal Services A logical element aggregating the set of CableHome-specified functionality in a CableHome compliant cable gateway device. 2.4 CAP (CableHome Address Portal) The logical function within the Cable Gateway Device which provides the NAT/NAPT routing and transparent bridging functions. 3. Overview This MIB provides a set of objects required for the management of CAP NAT/NAPT and transparent bridging functions within CableHome compliant Residential Gateways (RG). The MIB is derived from the CableHome Specification. Depending on the configuration of the CAP, a CableHome RG will perform either standard NAT Network Address Translation or NAPT Network Address Port Translation. It is also possible to configure the CableHome RG to provide only NAT/NAPT functions,transparent bridging functions, or a combination of the two. Cardona, et. al. Expires - December 2003 [Page 3]
Internet-Draft CableHome Gateway Addressing MIB June 2003 The NAT/NAPT function of the CableHome RG generally translates traffic to and from privately addressed devices in the home network to one (NAPT) or more (NAT) public addresses that are provisioned into the RG for this purpose. In order for the CableHome RG to support devices and applications that are NAT/NAPT intolerant, the RG also supports a type of transparent bridging, which we call Passthrough, by configuring the RG to bridge traffic for all devices on the home network or to bridge traffic to and from particular hardware addresses on the home network. 3.1 Structure of the MIB This MIB is structured into two groups: 1. The cabhCapBase group provides a mechanism to define the inactivity timeouts for TCP, UDP, and ICMP traffic types. It also provides a mechanism to set the Primary Packet-handling Mode of the RG û either NAT, NAPT, or Passthrough. Finally, this group provides a means to reset most MIB values defined in this MIB to their factory defaults. 2. The cabhCapMap group contains information pertaining to the NAT/NAPT routing and transparent bridging (Passthrough) functions of the RG. The cabhCapMap group consists of two tables: û cabhCapMappingTable: Allows for creating and monitoring static and dynamic NAT and NAPT mappings. û cabhCapPassthroughTable: Allows for configuring the RG to transparently bridge traffic based on hardware addresses of devices on the home network. 3.2 Management Requirements In addition to the explicit requirements in this specification, the Cable Gateway MUST support all applicable CableHome and IETF requirements and MIB objects. Cardona, et. al. Expires - December 2003 [Page 4]
Internet-Draft CableHome Gateway Addressing MIB June 2003 4. MIB Definitions CABH-IETF-CAP-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, OBJECT-TYPE, Unsigned32, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, TimeStamp, TruthValue, RowStatus, PhysAddress FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF InetAddressType, InetAddress, InetPortNumber FROM INET-ADDRESS-MIB; cabhCapMib MODULE-IDENTITY LAST-UPDATED "200306210000Z" -- Jun 21, 2003 ORGANIZATION "IETF IPCDN Working Group" CONTACT-INFO "Kevin Luehrs Postal: Cable Television Laboratories, Inc. 400 Centennial Parkway Louisville, Colorado 80027-1266 U.S.A. Phone: +1 303-661-9100 Fax: +1 303-661-9199 E-mail: k.luehrs@cablelabs.com; mibs@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-chairs: Richard Woundy, Richard_Woundy@cable.comcast.com Jean-Francois Mule, jf.mule@cablelabs.com" DESCRIPTION "This MIB module supplies the basic management objects for the CableHome Addressing Portal (CAP) portion of the PS database. Copyright (C) The Internet Society (2003). This version of this MIB module is part of RFC xxxx; see the RFC Cardona, et. al. Expires - December 2003 [Page 5]
Internet-Draft CableHome Gateway Addressing MIB June 2003 itself for full legal notices." REVISION "200306210000Z" -- Jun 21, 2003 DESCRIPTION "Initial version, published as RFC xxxx." -- RFC editor to assign xxxx ::= { mib-2 xx } -- xx to be assigned by IANA -- Textual conventions CabhCapPacketMode ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The data type established when a binding/mapping is established." SYNTAX INTEGER { napt(1), -- NAT with port translation nat(2), -- Basic NAT passthrough(3) -- Pass Through External Address } cabhCapObjects OBJECT IDENTIFIER ::= { cabhCapMib 1 } cabhCapBase OBJECT IDENTIFIER ::= { cabhCapObjects 1 } cabhCapMap OBJECT IDENTIFIER ::= { cabhCapObjects 2 } --=================================================================== -- -- General CAP Parameters -- --=================================================================== cabhCapTcpTimeWait OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "This object is the maximum inactivity time to wait before assuming TCP session is terminated. It has no relation to the TCP session TIME_WAIT state referred to in [RFC793]" DEFVAL { 300 } ::= { cabhCapBase 1 } cabhCapUdpTimeWait OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" Cardona, et. al. Expires - December 2003 [Page 6]
Internet-Draft CableHome Gateway Addressing MIB June 2003 MAX-ACCESS read-write STATUS current DESCRIPTION "The inactivity time to wait before destroying CAP mappings for UDP." DEFVAL { 300 } -- 5 minutes ::={ cabhCapBase 2 } cabhCapIcmpTimeWait OBJECT-TYPE SYNTAX Unsigned32 UNITS "seconds" MAX-ACCESS read-write STATUS current DESCRIPTION "The inactivity time to wait before destroying CAP mappings for ICMP." DEFVAL { 300 } -- 5 minutes ::= { cabhCapBase 3 } cabhCapPrimaryMode OBJECT-TYPE SYNTAX CabhCapPacketMode MAX-ACCESS read-write STATUS current DESCRIPTION "The Primary Packet Handling Mode to be used." DEFVAL { napt } ::= { cabhCapBase 4 } cabhCapSetToFactory OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-write STATUS current DESCRIPTION "Reading this object always returns false(2). When the cabhCapSetToFactory object is set to true(1), the PS must take the following actions: 1. Clear all entries in the cabhCapMappingTable and cabhCapPassthroughTable. 2. Reset the following objects to their factory default values: cabhCapTcpTimeWait, cabhCapUdpTimeWait, cabhCapIcmpTimeWait, cabhCapPrimaryMode" ::= { cabhCapBase 5 } cabhCapLastSetToFactory OBJECT-TYPE SYNTAX TimeStamp Cardona, et. al. Expires - December 2003 [Page 7]
Internet-Draft CableHome Gateway Addressing MIB June 2003 MAX-ACCESS read-only STATUS current DESCRIPTION "The value of sysUpTime when cabhCapSetToFactory was last set to true. Zero if never reset." ::= { cabhCapBase 6 } --=================================================================== -- -- cabhCapMappingTable (CAP Mapping Table) -- -- The cabhCapMappingTable contains the info for all CAP mappings. -- --=================================================================== cabhCapMappingTable OBJECT-TYPE SYNTAX SEQUENCE OF CabhCapMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains IP address mappings between private network addresses, or network addresses and port numbers/ICMP sequence numbers, assigned to devices on the subscriber's home LAN, and network addresses, or network addresses and port numbers/ICMP sequence number, assigned by the cable operator, presumed to be on a separate subnetwork than the private IP addresses. The CAP Mapping Table is used by the CableHome Address Portal (CAP) function of the PS to make packet forwarding decisions." ::= { cabhCapMap 1 } cabhCapMappingEntry OBJECT-TYPE SYNTAX CabhCapMappingEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of the private IP (LAN) address - to - cable operator assigned IP (WAN) address mappings stored in the PS and used by the PS to make packet forwarding decisions." INDEX { cabhCapMappingIndex } ::= { cabhCapMappingTable 1 } CabhCapMappingEntry ::= SEQUENCE { cabhCapMappingIndex INTEGER, cabhCapMappingWanAddrType InetAddressType, cabhCapMappingWanAddr InetAddress, cabhCapMappingWanPort InetPortNumber, cabhCapMappingLanAddrType InetAddressType, Cardona, et. al. Expires - December 2003 [Page 8]
Internet-Draft CableHome Gateway Addressing MIB June 2003 cabhCapMappingLanAddr InetAddress, cabhCapMappingLanPort InetPortNumber, cabhCapMappingMethod INTEGER, cabhCapMappingProtocol INTEGER, cabhCapMappingRowStatus RowStatus } cabhCapMappingIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Index into the CAP Mapping Table." ::= { cabhCapMappingEntry 1 } cabhCapMappingWanAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address type assigned on the WAN side" DEFVAL { ipv4 } ::= { cabhCapMappingEntry 2 } cabhCapMappingWanAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address assigned by the cable operator's address (DHCP) server, and comprising the WAN-side IP address of the CAP Mapping tuple. This object is populated either dynamically by LAN-to-WAN outbound traffic or statically by the cable operator." ::= { cabhCapMappingEntry 3 } cabhCapMappingWanPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The TCP/UDP port number or ICMP sequence number on the WAN side. A port number of 0 indicates a NAT mapping. A non-zero port number indicates an NAPT mapping." DEFVAL { 0 } ::= { cabhCapMappingEntry 4 } cabhCapMappingLanAddrType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS read-create Cardona, et. al. Expires - December 2003 [Page 9]
Internet-Draft CableHome Gateway Addressing MIB June 2003 STATUS current DESCRIPTION "The IP address type assigned on the LAN side." DEFVAL { ipv4 } ::= { cabhCapMappingEntry 5 } cabhCapMappingLanAddr OBJECT-TYPE SYNTAX InetAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP address assigned by the DHCP server function of the PS (CableHome DHCP Server, CDS), and comprising the LAN-side IP address of the CAP Mapping tuple. This object is populated either dynamically as a result of LAN-to-WAN outbound traffic or statically by the cable operator." ::= { cabhCapMappingEntry 6 } cabhCapMappingLanPort OBJECT-TYPE SYNTAX InetPortNumber MAX-ACCESS read-create STATUS current DESCRIPTION "The TCP/UDP port number or ICMP sequence number on the LAN side. A port number/sequence number of 0 indicates a NAT mapping. A non-zero port number/sequence number indicates a NAPT mapping." DEFVAL { 0 } ::= { cabhCapMappingEntry 7 } cabhCapMappingMethod OBJECT-TYPE SYNTAX INTEGER { static(1), dynamic(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Indicates how this mapping was created. Static means that it was provisioned, and dynamic means that it was handled by the PS itself." ::= { cabhCapMappingEntry 8 } cabhCapMappingProtocol OBJECT-TYPE SYNTAX INTEGER { other(1), -- any other protocol; e.g. IGMP icmp(2), udp(3), tcp(4) Cardona, et. al. Expires - December 2003 [Page 10]
Internet-Draft CableHome Gateway Addressing MIB June 2003 } MAX-ACCESS read-create STATUS current DESCRIPTION "The protocol for this mapping." ::= { cabhCapMappingEntry 9 } cabhCapMappingRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus interlock for the creation and deletion of a cabhCapMappingTable entry. Changing the value of the IP address or port number columns of the CAP Mapping Table may have an effect on active traffic, so the PS will prevent modification of this table's columns and return an inconsistentValue error when cabhCapMappingRowStatus object is active(1). The PS must not allow RowStatus to be set to notInService(2)by a manager. A newly created row cannot be set to active(1) until the corresponding instances of cabhCapMappingWanAddrType, cabhCapMappingWanAddr, cabhCapMappingLanAddrType, cabhCapMappingLanAddr, and cabhCapMappingProtocol have been set. When Primary Packet-handling Mode is NAPT (cabhCapPrimaryMode is napt(1)), required behavior with respect to the cabhCapMappingRowStatus object is dependent upon the version of CableHome specification implemented in the product: - In CableHome 1.0 compliant products configured for NAPT Primary Packet-handling Mode, a newly provisioned row can not be set to active(1) until a non-zero value has been set for cabhCapMappingWanPort and cabhCapMappingLanPort objects. - Products compliant to CableHome specifications later than CableHome 1.0 are not subject to the cabhCapMappingWanPort and cabhCapMappingLanPort restrictions imposed on CableHome 1.0 compliant products. In CableHome 1.1 and later compliant devices configured to operate in NAPT Primary Packet-handling Mode, provisioned rows can be set to active(1) regardless of whether the value to which cabhCapMappingWanPort and cabhCapMappingLanPort have Cardona, et. al. Expires - December 2003 [Page 11]
Internet-Draft CableHome Gateway Addressing MIB June 2003 been set is zero or nonzero. When Primary Packet-handling Mode is NAT (cabhCapPrimaryMode is nat(2)), a newly created row cannot be set to active(1)if a non-zero value of cabhCapMappingWanPort and cabhCapMappingLanPort have been set." ::={ cabhCapMappingEntry 10 } --=================================================================== -- -- cabhCapPassthroughTable (CAP Passthrough Table) -- -- The cabhCapPassthroughTable contains the MAC Addresses for all -- LAN-IP Devices which will be configured as passthrough. -- --=================================================================== cabhCapPassthroughTable OBJECT-TYPE SYNTAX SEQUENCE OF CabhCapPassthroughEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains MAC addresses for LAN-IP Devices which are configured as passthrough mode." ::= { cabhCapMap 2 } cabhCapPassthroughEntry OBJECT-TYPE SYNTAX CabhCapPassthroughEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "List of hardware addresses of LAN IP Devices which are configured for passthrough mode." INDEX {cabhCapPassthroughIndex} ::= {cabhCapPassthroughTable 1} CabhCapPassthroughEntry::=SEQUENCE { cabhCapPassthroughIndex INTEGER, cabhCapPassthroughMacAddr PhysAddress, cabhCapPassthroughRowStatus RowStatus } cabhCapPassthroughIndex OBJECT-TYPE SYNTAX INTEGER (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index into the CAP Passthrough Table." ::= { cabhCapPassthroughEntry 1 } Cardona, et. al. Expires - December 2003 [Page 12]
Internet-Draft CableHome Gateway Addressing MIB June 2003 cabhCapPassthroughMacAddr OBJECT-TYPE SYNTAX PhysAddress (SIZE(0..16)) MAX-ACCESS read-create STATUS current DESCRIPTION "Hardware address of the LAN-IP Device to be configured as passthrough mode." ::={cabhCapPassthroughEntry 2} cabhCapPassthroughRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The RowStatus interlock for the creation and deletion of a cabhCapPassthroughTable entry. Any writable object in each row can be modified at any time while the row is active(1)." ::= { cabhCapPassthroughEntry 3 } -- -- notification group is for future extension. -- cabhCapNotification OBJECT IDENTIFIER ::= { cabhCapMib 2 0 } cabhCapConformance OBJECT IDENTIFIER ::= { cabhCapMib 3 } cabhCapCompliances OBJECT IDENTIFIER ::= { cabhCapConformance 1 } cabhCapGroups OBJECT IDENTIFIER ::= { cabhCapConformance 2 } -- -- Notification Group -- -- compliance statements cabhCapBasicCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for devices that implement the CableHome Portal Services functionality" MODULE --cabhCapMib -- unconditionally mandatory groups MANDATORY-GROUPS { cabhCapGroup } Cardona, et. al. Expires - December 2003 [Page 13]
Internet-Draft CableHome Gateway Addressing MIB June 2003 OBJECT cabhCapMappingWanAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT cabhCapMappingWanAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT cabhCapMappingLanAddrType SYNTAX InetAddressType { ipv4(1) } DESCRIPTION "An implementation is only required to support IPv4 addresses." OBJECT cabhCapMappingLanAddr SYNTAX InetAddress (SIZE(4)) DESCRIPTION "An implementation is only required to support IPv4 addresses." ::= { cabhCapCompliances 1 } cabhCapGroup OBJECT-GROUP OBJECTS { cabhCapTcpTimeWait, cabhCapUdpTimeWait, cabhCapIcmpTimeWait, cabhCapPrimaryMode, cabhCapSetToFactory, cabhCapLastSetToFactory, cabhCapMappingWanAddrType, cabhCapMappingWanAddr, cabhCapMappingWanPort, cabhCapMappingLanAddrType, cabhCapMappingLanAddr, cabhCapMappingLanPort, cabhCapMappingMethod, cabhCapMappingProtocol, cabhCapMappingRowStatus, cabhCapPassthroughMacAddr, cabhCapPassthroughRowStatus } STATUS current DESCRIPTION "Group of objects for CableHome CAP MIB." Cardona, et. al. Expires - December 2003 [Page 14]
Internet-Draft CableHome Gateway Addressing MIB June 2003 ::= { cabhCapGroups 1 } END 5. Acknowledgements Roy Spitzer - Consultant Mike Mannette - Consultant Randy Dunton - Intel Dmitrii Loukianov - Intel Itay Sherman - Texas Instruments Chris Zacker - Broadcom Rick Vetter - CableLabs John Bevilacqua - YAS Funding for the RFC Editor function is currently provided by the Internet Society. 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. 7. Security Considerations There are a number of management objects defined in this MIB that have 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. It is thus important to control even GET access to these objects and possibly to even encrypt the values of these objects when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. 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 allowed to access and GET/SET (read/change/create/delete) the objects in this MIB module. Cardona, et. al. Expires - December 2003 [Page 15]
Internet-Draft CableHome Gateway Addressing MIB June 2003 It is RECOMMENDED that implementers consider the security features as provided by the SNMPv3 framework (see [RFC3410], section 8), 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. 8. Normative References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 4 Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. 5 Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. 6 Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. 7 McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information for Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 8 McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999. 9 McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999. Cardona, et. al. Expires - December 2003 [Page 16]
Internet-Draft CableHome Gateway Addressing MIB June 2003 10 Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. 11 Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996. 12 Case, J., Mundy, R., Partain, D, and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", RFC 3410, December 2002. 13 Harrington D., Presuhn R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, December 2002. 14 Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 3412, December 2002. 15 Levi, D., Meyer, P., and B. Stewart, ôSimple Network Management Protocol (SNMP) Applications", RFC 3413, December 2002. 16 Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 3414, December 2002. 17 Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 3415, December 2002. 18 Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMPv2)", RFC 3416, Decemeber 2002. 19 Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol (SNMPv2)", RFC 3417, December 2002. 20 Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", RFC 3418, December 2002. 21 Cable Television Laboratories, ôCableHome 1.0 Specificationö, CH- SP-I02-020920, September 2002, http://www.cablelabs.com/projects/cablehome/specifications. Cardona, et. al. Expires - December 2003 [Page 17]
Internet-Draft CableHome Gateway Addressing MIB June 2003 9. Informative References 22 Drums, R., ôDynamic Host Configuration Protocolö, RFC 2131, March 1997. 23 Sollins, K., ôThe TFTP Protocol (Revision 2)ö, RFC 1350, July 1992. 24 Harrington, R., Presuhn, R., and B. Wijnen, ôAn Architecture for Describing SNMP Management Frameworksö, RFC 2571, April 1999. 25 Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, ôTextual Contentions for Internet Network Addressesö, May 2002. 10. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Author's Addresses Eduardo Cardona Cable Television Laboratories 400 Centennial Parkway Louisville, CO 80027 Phone: +1 303.661.9100 Email: e.cardona@cablelabs.com Cardona, et. al. Expires - December 2003 [Page 18]
Internet-Draft CableHome Gateway Addressing MIB June 2003 Kevin Luehrs Cable Television Laboratories 400 Centennial Parkway Louisville, CO 80027 Phone: +1 303.661.9100 Email: k.luehrs@cablelabs.com Greg Nakanishi Motorola Phone: +1 858.404.2366 Email: gnakanishi@motorola.com Doug Jones YAS Broadband Ventures 300 Brickstone Square Andover, MA 01810 Phone: +1 303.661.3823 Email: doug@yas.com 12. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Cardona, et. al. Expires - December 2003 [Page 19]
