idnits 2.17.1 draft-ietf-ipcdn-igmp-proxy-mib-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 5 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 8) being 145 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 26 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 158: '...e text. Vendors SHOULD provide time-o...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1998) is 9379 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 521, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 525, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 528, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 531, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '3') ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1573 (ref. '5') (Obsoleted by RFC 2233) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Experimental RFC: RFC 1224 (ref. '7') -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT IGMP Proxy MIB August 1998 4 Cable Device IGMP Proxy MIB for DOCSIS compliant Cable Modems 5 draft-ietf-ipcdn-igmp-proxy-mib-00.txt 7 Jonathan Fellows 8 General Instrument 9 jfellows@gi.com 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, and 15 its Working Groups. Note that other groups may also distribute working 16 documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as a "work in progress". 23 To view the entire list of current Internet-Drafts, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), or ftp.isi.edu (US). 28 Abstract 30 This memo defines an experimental portion of the Management Information 31 Base (MIB) for use with network management protocols in the Internet 32 community. In particular, it defines a basic set of managed objects 33 for SNMP-based management of conditional access to IP multicast groups 34 by DOCSIS compliant cable modems. 36 This memo specifies a MIB module in a manner that is compliant to the 37 SNMPv2 SMI. The set of objects is consistent with the SNMP framework 38 and existing SNMP standards. 40 This memo does not specify a standard for the Internet community. 42 1. The SNMPv2 Network Management Framework 44 The SNMPv2 Network Management Framework presently consists of three 45 major components. They are: 47 o the SMI, described in RFC 1902 [1] - the mechanisms used for 48 describing and naming objects for the purpose of management. 50 o the MIB-II, STD 17, RFC 1213 [2] - the core set of managed objects 51 for the Internet suite of protocols. 53 o the protocol, RFC 1157 [3] and/or RFC 1905 [4], - the protocol for 54 accessing managed objects. 56 The Framework permits new objects to be defined for the purpose of 57 experimentation and evaluation. 59 2. Object Definitions 61 Managed objects are accessed via a virtual information store, termed 62 the Management Information Base or MIB. Objects in the MIB are defined 63 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 64 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 65 an administratively assigned name. The object type together with an 66 object instance serves to uniquely identify a specific instantiation of 67 the object. For human convenience, we often use a textual string, 68 termed the descriptor, to refer to the object type. 70 3. Overview 72 This MIB provides a set of objects required for the management of 73 conditional access to IP multicast groups. The subjects of this policy 74 are the set of Customer Premises hosts connected to an IPCDN network by 75 a DOCSIS compliant Cable Modem. 77 The basic principle of operation is that a Cable Modem implements an IP 78 multicast table which is used to filter IP multicast addressed 79 datagrams received on either the cable modem HFC interface or the cable 80 modem CPE interface. This filter serves two purposes: 81 (1) only IP multicast traffic for currently subscribed group addresses 82 is passed into the CPE environment, reducing the bandwidth consumed 83 in the CPE environment by multicast traffic. 84 (2) SNMP network management stations can define a conditional access 85 policy based on enterprise specific data of any kind (such as pay- 86 per-group, for example). 88 It is traditional in access control systems to distinguish between 89 potential access to a resource and actual or current access to 90 resources. Potential access is often represented in the form of Access 91 Control Lists (ACLs) associated with controlled resources. Actual 92 access is often represented in the form of an entry in an address 93 resolution, translation, or filtering mechanism that stands between a 94 subject and a resource. For this IGMP Proxy specification, the 95 authoritative definition of potential access resides in one or more 96 SNMP management stations. Consistency of this information between 97 multiple management stations is beyond the scope of this specification. 99 The Permission Cache Table is the local representation of potential 100 access to IP multicast groups in a cable modem. It is an object in the 101 cable modem IGMP Proxy MIB that is used to cache access rules resulting 102 from previous mediation decisions by the management system. A single 103 rule may match a range of IP multicast addresses. This cache serves to 104 reduce the mediation workload on the SNMP infrastructure. Entries in 105 this table are only created or destroyed by explicit SNMP management 106 action via SET commands. 108 The IGMP Proxy MIB defines current accesses for a cable modem in a 109 separate table, the Current Filters Table. Each entry specifies access 110 rights (none, send, receive, send and receive) to a single IP multicast 111 address. The local agent, as part of IGMP Proxy protocol processing, 112 creates entries in this table. Entries in the Current Filters table 113 are periodically rechecked against both permissions and current CPE 114 group membership, and deleted when necessary. Explicit deletion by 115 SNMP management action is also allowed. 117 The IGMP Proxy protocol is based on the interception of CPE IGMP JOIN 118 requests (Host membership reports) by the cable modem, which then 119 generates an SNMP trap to its designated SNMP management station. An 120 entry is created in the IGMP Proxy MIB Pending Request Table. When an 121 SNMP SET is made to the Permission Cache Table, the new rule is checked 122 against all pending IGMP request. For those that match, new entries 123 are created in the Current Filters Table, and the original IGMP JOIN 124 message is propagated upstream. Since SNMP traps are not acknowledged 125 and may be lost in transmission, the IGMP Proxy protocol provides for 126 retransmission of SNMP traps after a suitable timeout. 128 3.1. Structure of the MIB 130 This MIB is structured in a single group with three tables: 132 Permission_Cache_Table 133 Mcast_address ip_address 134 Address_mask ip_address 135 Access-Rights: (none | send | receive | send_and_receive) 136 Time_To_Live: seconds 138 Current_Filters_Table 139 Mcast_address ip_address 140 Access-Rights: (none | send | receive | send_and_receive) 141 Max_hops counter 142 Recheck_timer seconds 144 Pending_Requests_Table 145 Mcast_address ip_address 146 Join message: opaque igmp message 147 Retry_timer seconds 148 Max_retries: counter 150 3.2 Events and Traps 152 This section needs work to define the IGMP Proxy trap generated when a 153 CPE IGMP JOIN message is received at the CPE LAN/ CM�s CMCI interface. 155 The definition and coding of events is vendor-specific. In deference 156 to the network operator who must troubleshoot multi-vendor networks, 157 the circumstances and meaning of each event should be reported as 158 human-readable text. Vendors SHOULD provide time-of-day clocks in CMs 159 to provide useful timestamping of events. 161 For each vendor-specific event that is reportable via TRAP, the vendor 162 must create an enterprise-specific trap definition. Trap definitions 163 MUST include the event reason encoded as DisplayString and should be 164 defined as: 166 trapName NOTIFICATION-TYPE 167 OBJECTS { 168 ifIndex, 169 eventReason, 170 other useful objects 171 } 172 STATUS current 173 DESCRIPTION 174 "trap description" 175 ::= Object Id 177 Note that ifIndex is only included if the event or trap is interface 178 related. 180 The last digit of the trap OID for enterprise-specific traps must match 181 docsDevEvId. For SNMPv1-capable Network Management systems, this is 182 necessary to correlate the event type to the trap type. Many Network 183 Management systems are only capable of trap filtering on an enterprise 184 and single-last-digit basis. 186 4. Definitions 188 gi OBJECT IDENTIFIER ::= { 189 iso(1) 190 org(3) 191 dod(6) 192 internet(1) 193 private(4) 194 enterpresis(1) 195 1166 196 } 197 giproducts OBJECT IDENTIFIER ::= { gi 1 } 199 sb2100 OBJECT IDENTIFIER ::= { giproducts 19 } 201 McastProxyMIBObjects ::= { sb2100 63 } 203 -- Permission Cache Table object definitions 205 mcastPermissionCacheTable OBJECT-TYPE 206 SYNTAX SEQUENCE OF McastPermissionCacheEntry 207 MAX-ACCESS not-accessible 208 STATUS current 209 DESCRIPTION 210 "The Permission Cache Table defines potential access to IP 211 multicast group addresses by CPE hosts. (It does not define 212 actual current access � which is defined in a different 213 table � the Current Filters Table.) Permission Cache Table 214 entries are derived from authoritative information stored 215 by one or more management stations. Entries in this table 216 can match a range of IP multicast addresses that share the 217 same access rights. A Holding Time attribute specifies the 218 length of time that a Permission Cache Table entry is held 219 in the table before being aged out." 220 ::= { mcastProxyMIBObjects 1 } 222 mcastPermissionCacheEntry OBJECT-TYPE 223 SYNTAX McastPermissionCacheEntry 224 MAX-ACCESS not-accessible 225 STATUS current 226 DESCRIPTION 227 "Defines potential access to IP Multicast groups by CPE 228 hosts. For each entry in this table, the contents are not 229 readable unless the management station has read-write 230 permission." 231 INDEX { mcastPermissionCacheIndex } 232 ::= { mcastPermissionCacheTable 1 } 234 McastPermissionCacheEntry ::= SEQUENCE { 235 mcastPermissionCacheIndex INTEGER, 236 mcastPermissionCacheIp IpAddress, 237 mcastPermissionCacheIpMask IpAddress, 238 mcastPermissionCacheAccessControl INTEGER, 239 mcastPermissionCacheHoldingTime INTEGER, 240 mcastPermissionCacheStatus RowStatus 241 } 243 mcastPermissionCacheIndex OBJECT-TYPE 244 SYNTAX INTEGER (1..2147483647) 245 MAX-ACCESS not-accessible 246 STATUS current 247 DESCRIPTION 248 "Index used to order the application of access entries." 249 ::= { mcastPermissionCacheEntry 1 } 251 mcastPermissionCacheIp OBJECT-TYPE 252 SYNTAX IpAddress 253 MAX-ACCESS read-create 254 STATUS current 255 DESCRIPTION 256 "The IP multicast address (or address range) controlled by 257 this rule. By convention, the IP address is �0� in those 258 fields not covered by the accompanying mask value.[is this 259 accurate in the multicast scenario ?] At the boundaries of 260 this convention, if the mask is 0.0.0.0 then a fully 261 specified IP address is in this field (matches a single 262 address), while if the mask is 255.255.255.255, then the 263 address field would be 0.0.0.0 (matches any address)" 264 DEFVAL { 'ffffffff'h } 265 ::= { mcastPermissionCacheEntry 2 } 267 mcastPermissionCacheIpMask OBJECT-TYPE 268 SYNTAX IpAddress 269 MAX-ACCESS read-create 270 STATUS current 271 DESCRIPTION 272 "The IP subnet mask of the IP multicast address or address 273 range." 274 DEFVAL { 'ffffffff'h } 275 ::= { mcastPermissionCacheEntry 3 } 277 mcastPermissionCacheAccessControl OBJECT-TYPE 278 SYNTAX INTEGER { 279 none(1), 280 send(2), 281 receive(3), 282 sendReceive(4), 283 } 284 MAX-ACCESS read-create 285 STATUS current 286 DESCRIPTION 287 "Specifies the type of access allowed for IP multicast 288 addresses that match this rule. Setting this object to 289 none(1) causes all matching IGMP join requests to be 290 rejected. Send(2) allows only sending of IP datagrams from 291 the CPE LAN with a matching IP multicast address. 292 Receive(3) allows only reception of IP datagrams from the 293 HFC interface with a matching IP multicast address. 294 SendReceive(4) allows both sending and receiving of IP 295 datagrams with a matching IP multicast address." 296 DEFVAL { none } 297 ::= { mcastPermissionCacheEntry 4 } 299 mcastPermissionCacheHoldingTime OBJECT-TYPE 300 SYNTAX INTEGER (0..2147483647) 301 MAX-ACCESS read-create 302 STATUS current 303 DESCRIPTION 304 "Indicates the time in seconds for which this table entry 305 should be held in the permission cache table before being 306 aged (deleted) by the agent. A short time indicates that 307 authoritative access control data changes often at the 308 management station(s), and new requests should be 309 remediated against authoritative data. A long time 310 indicates stable authoritative access control data which 311 can be cached for long periods of time. A value of zero 312 indicates a permanent cache entry which never ages out." 313 DEFVAL { 86400 } 314 ::= { mcastPermissionCacheEntry 5 } 316 mcastPermissionCacheEntry Status OBJECT-TYPE 317 SYNTAX RowStatus 318 MAX-ACCESS read-create 319 STATUS current 320 DESCRIPTION 321 "Controls and reflects the status of rows in this table." 322 ::= { mcastPermissionCacheEntry 6 } 324 -- Current Filters Table object definitions 326 mcastCurrentFiltersTable OBJECT-TYPE 327 SYNTAX SEQUENCE OF McastCurrentFiltersEntry 328 MAX-ACCESS not-accessible 329 STATUS current 330 DESCRIPTION 331 "The Current Filters Table defines the current access 332 rights to IP multicast addresses by CPE hosts. A CM only 333 forwards an IP multicast datagram if a matching entry is 334 found in this table." 335 ::= { mcastProxyMIBObjects 2 } 337 mcastCurrentFiltersEntry OBJECT-TYPE 338 SYNTAX McastCurrentFiltersEntry 339 MAX-ACCESS not-accessible 340 STATUS current 341 DESCRIPTION 342 "Controls filtering of access to IP Multicast groups by CPE 343 hosts. For each entry in this table, the contents are not 344 readable unless the management station has read-write 345 permission." 346 INDEX { mcastCurrentFiltersIp } 347 ::= { mcastCurrentFiltersTable 1 } 349 McastCurrentFiltersEntry ::= SEQUENCE { 350 mcastCurrentFiltersIp IpAddress, 351 mcastCurrentFiltersAccessControl INTEGER, 352 mcastCurrentFiltersMaxHops INTEGER, 353 mcastCurrentFiltersRecheckTime INTEGER, 354 } 356 mcastCurrentFiltersIp OBJECT-TYPE 357 SYNTAX IpAddress 358 MAX-ACCESS read-only 359 STATUS current 360 DESCRIPTION 361 "The IP multicast address controlled by this rule." 362 DEFVAL { 'ffffffff'h } 363 ::= { mcastCurrentFiltersEntry 1 } 365 mcastCurrentFiltersAccessControl OBJECT-TYPE 366 SYNTAX INTEGER { 367 none(1), 368 send(2), 369 receive(3), 370 sendReceive(4), 371 } 372 MAX-ACCESS read-write 373 STATUS current 374 DESCRIPTION 375 "Specifies the type of access allowed for IP multicast 376 addresses that match this rule. Setting this object to 377 none(1) causes deletion of this row in the table, which 378 results in immediate revocation of access rights to the IP 379 multicast address involved. Send(2) allows only sending of 380 IP datagrams from the CPE LAN with a matching IP multicast 381 address. Receive(3) allows only reception of IP datagrams 382 from the HFC interface with a matching IP multicast 383 address. SendReceive(4) allows both sending and receiving 384 of IP datagrams with a matching IP multicast address." 385 DEFVAL { none } 386 ::= { mcastCurrentFiltersEntry 2 } 388 mcastCurrentFiltersMaxHops OBJECT-TYPE 389 SYNTAX INTEGER (0..2147483647) 390 MAX-ACCESS read-only 391 STATUS current 392 DESCRIPTION 393 "Indicates the maximum value of the IP hop count value in 394 an outgoing IP datagram. The datagram is discarded if it�s 395 hop count exceeds this value. This is intended as a way to 396 control the scope of multicast from a CPE LAN." 397 ::= { mcastPermissionCacheEntry 3 } 399 mcastCurrentFiltersRecheckTime OBJECT-TYPE 400 SYNTAX INTEGER (0..2147483647) 401 MAX-ACCESS read-only 402 STATUS current 403 DESCRIPTION 404 "Indicates the time in seconds for which this table entry 405 should be held in the current filter table before being 406 revalidated. Revalidation involves: (1) remediation 407 against the Permission Cache Table, and (2) checking for 408 group membership on the CPE LAN with an IGMP host 409 membership query ( IGMP type 1 message addressed to the all 410 hosts group address 224.0.0.1) message. If remediation is 411 successful and there are still active CPE group members, 412 then the timer is reset to the value specified in this 413 entry. Failure of either of these checks results in 414 deletion of the entry. " 415 ::= { mcastCurrentFiltersEntry 4 } 417 -- Pending Requests Table object definitions 419 mcastPendingRequestsTable OBJECT-TYPE 420 SYNTAX SEQUENCE OF McastPendingRequestsEntry 421 MAX-ACCESS not-accessible 422 STATUS current 423 DESCRIPTION 424 "The Pending Requests Table tracks outstanding SNMP 425 Multicast Proxy Join traps. Since IGMP JOIN messages are 426 not automatically regenerated by CPE hosts, and SNMP trap 427 messages are not reliably transmitted to management 428 stations, a positive acknowledgement protocol with timeouts 429 and retries is needed. This table maintains the state for 430 this protocol." 431 ::= { mcastProxyMIBObjects 3 } 433 mcastPendingRequestsEntry OBJECT-TYPE 434 SYNTAX McastPendingRequestsEntry 435 MAX-ACCESS not-accessible 436 STATUS current 437 DESCRIPTION 438 "Defines pending requests for access to IP Multicast groups 439 by CPE hosts. For each entry in this table, the contents 440 are not readable unless the management station has read- 441 write permission." 442 INDEX { mcastPendingRequestsIp } 443 ::= { mcastPendingRequestsTable 1 } 445 McastPendingRequestsEntry ::= SEQUENCE { 446 mcastPendingRequestsIp IpAddress, 447 mcastPendingRequestsTrapMsg OPAQUE, 448 mcastPendingRequestsRetryTimer INTEGER, 449 mcastPendingRequestsMaxRetries INTEGER, 450 } 452 mcastPendingRequestsIp OBJECT-TYPE 453 SYNTAX IpAddress 454 MAX-ACCESS read-only 455 STATUS current 456 DESCRIPTION 457 "The IP multicast address for which the IGMP JOIN message 458 of this entry was generated." 459 DEFVAL { 'ffffffff'h } 460 ::= { mcastPendingRequestsEntry 1 } 462 mcastPendingRequestsTrapMsg OBJECT-TYPE 463 SYNTAX OPAQUE STRING 464 MAX-ACCESS read-only 465 STATUS current 466 DESCRIPTION 467 "The complete original IGMP JOIN message." 468 ::= { mcastPendingRequestsEntry 2 } 470 mcastPendingRequestsRetryTimer OBJECT-TYPE 471 SYNTAX INTEGER (0..2147483647) 472 MAX-ACCESS read-only 473 STATUS current 474 DESCRIPTION 475 "Indicates the time in seconds for which the agent should 476 wait to receive an SNMP SET on the Permission Cache Table 477 that matches the IP multicast entry in this table before 478 regenerating the IGMP JOIN trap." 479 DEFVAL { 60 } 480 ::= { mcastPendingRequestsEntry 3 } 482 mcastPendingRequestsMaxRetries OBJECT-TYPE 483 SYNTAX INTEGER {0..2147483647) 484 MAX-ACCESS read-only 485 STATUS current 486 DESCRIPTION 487 "Specifies the number of times to resend the IGMP JOIN trap 488 if no SNMP response is received. Subject to rate controls 489 on SNMP trap generation defined elsewhere." 490 DEFVAL { 6 } 491 ::= { mcastPendingRequestsEntry 4 } 493 5. Acknowledgments 495 This document was produced by TBD. It reflects comments by Steve 496 Keller, Poornima Lalwaney, and Victor Hou. 498 6. References 500 Need to add IGMP references 502 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 503 S. Waldbusser, "Structure of Management Information for Version 2 504 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 505 January 1996. 507 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 508 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 509 RFC 1213, Hughes LAN Systems, Performance Systems International, 510 August 1991. 512 [3] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple 513 Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP 514 Research, Performance Systems International, MIT Lab for Computer 515 Science, May 1990. 517 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and 518 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 519 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 521 [5] McCloghrie, K. and F. Kastenholz, "Evolution of the Interfaces 522 Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software, 523 January 1994. 525 [6] "MCNS Data Over Cable Services Cable Modem Radio Frequency 526 Interface Specification SP-RFID01-970326", MCNS, August 1997. 528 [7] L. Steinberg, "Techniques for Managing Asynchronously Generated 529 Alerts", RFC 1224, May 1991. 531 [8] "MCNS Data Over Cable Services Operations Support System Interface 532 Specification SP-OSSII01-970403", MCNS, August 1997. 534 7. Security Considerations 536 The basic service supported through this MIB is conditional access for 537 IP multicast groups, which is a security related service. Operational 538 security for this MIB is for further study. 540 8. Author's Address 542 Jonathan Fellows 543 General Instrument 544 6450 Sequence Drive 545 San Diego, CA 92121 546 U.S.A. 548 Phone: +1 619 404 3720 549 Email: jfellows@gi.com