--- 1/draft-ietf-pint-mib-02.txt 2007-12-18 18:54:40.000000000 +0100 +++ 2/draft-ietf-pint-mib-03.txt 2007-12-18 18:54:40.000000000 +0100 @@ -1,16 +1,18 @@ + PINT Working Group Murali Krishnaswamy -Internet Draft Dan Romascanu - Lucent Technologies +Internet Draft Lucent Technologies + Dan Romascanu + Avaya Communication Management Information Base for the PINT Services Architecture - + Abstract This memo describes a proposed MIB for the PINT Services Architecture. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working @@ -49,45 +51,43 @@ performance is closely related to host and network performance, they are not addressed here. 2. The SNMP Management Framework The SNMP Management Framework presently consists of five major components: o An overall architecture, described in RFC 2571 [2]. - o Mechanisms for describing and naming objects and events for - the purpose of management. The first version of this Struc- - ture of Management Information (SMI) is called SMIv1 and - described in RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The - second version, called SMIv2, is described in RFC 2578 [6], - RFC 2579 [7] and RFC 2580 [8]. + o Mechanisms for describing and naming objects and events for the + purpose of management. The first version of this Structure of + Management Information (SMI) is called SMIv1 and described in + RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second version, + called SMIv2, is described in RFC 2578 [6], RFC 2579 [7] and RFC + 2580 [8]. - o Message protocols for transferring management information. - The first version of the SNMP message protocol is called - SNMPv1 and described in RFC 1157 [9]. A second version of the - SNMP message protocol, which is not an Internet standards - track protocol, is called SNMPv2c and described in RFC 1901 - [10] and RFC 1906 [11]. The third version of the message pro- - tocol is called SNMPv3 and described in RFC 1906 [11], RFC - 2572 [12] and RFC 2574 [13]. + o Message protocols for transferring management information. The + first version of the SNMP message protocol is called SNMPv1 and + described in RFC 1157 [9]. A second version of the SNMP message + protocol, which is not an Internet standards track protocol, is + called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. + The third version of the message protocol is called SNMPv3 and + described in RFC 1906 [11], RFC 2572 [12] and RFC 2574 [13]. o Protocol operations for accessing management information. The - first set of protocol operations and associated PDU formats - is described in RFC 1157 [9]. A second set of protocol opera- - tions and associated PDU formats is described in RFC 1905 - [14]. + first set of protocol operations and associated PDU formats is + described in RFC 1157 [9]. A second set of protocol operations + and associated PDU formats is described in RFC 1905 [14]. - o A set of fundamental applications described in RFC 2573 [15] - and the view-based access control mechanism described in RFC - 2575 [16]. + o A set of fundamental applications described in RFC 2573 [15] and + the view-based access control mechanism described in RFC 2575 + [16]. A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [17]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI. This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate @@ -192,63 +193,83 @@ TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SysApplInstallPkgIndex FROM SYSAPPL-MIB SnmpAdminString FROM SNMP-FRAMEWORK-MIB; -- RFC 2271 [20] pintMib MODULE-IDENTITY - LAST-UPDATED "9908310732Z" - ORGANIZATION "Lucent Technologies" + LAST-UPDATED "200007241525Z" + ORGANIZATION "IETF PINT Working Group" CONTACT-INFO - "Murali Krishnaswamy - Postal: 3C-512, 101 Crawfords Corner Rd. + " + Chairs: + + Steve Bellovin + E-mail: smb@research.att.com + Igor Faynberg + E-mail: faynberg@lucent.com + + Murali Krishnaswamy + Postal: 3C-512, 101 Crawfords Corner Rd. Holmdel, NJ 07733 Tel: +1 (732)949-3611 FAX: +1 (732)949-3210 E-mail: murali@lucent.com Dan Romascanu Postal: Atidim Technology Park, Bldg 3 Tel Aviv, Israel Tel: +972 3 6458414 - E-mail: dromasca@lucent.com" + E-mail: dromasca@avaya.com + +General Discussion:pint@lists.bell-labs.com +To Subscribe: pint-request@lists.bell-labs.com +In Body: subscribe your-email-addres +Archive: http://www.bell-labs.com/mailing-lists/pint/ +" DESCRIPTION "This MIB defines the objects necessary to monitor PINT Services" - REVISION "9909161200Z" + REVISION "200007241525Z" DESCRIPTION "Initial version, published as RFC xxxx." ::= { mib-2 99999 } -- Not an IANA number PintServiceType ::= TEXTUAL-CONVENTION + STATUS current SYNTAX INTEGER { - R2C(1), -- Request-to-Talk - R2F(2), -- Request-to-Fax - R2FB(3), -- Request-to-Fax-Back - R2HC(4) -- Request-to-Hear-Content + r2C(1), -- Request-to-Talk + r2F(2), -- Request-to-Fax + r2FB(3), -- Request-to-Fax-Back + r2HC(4) -- Request-to-Hear-Content } +DESCRIPTION + "This TC describes the type of a PINT service." PintPerfStatPeriod ::= TEXTUAL-CONVENTION + STATUS current SYNTAX INTEGER { - Last30sec(1), -- Performance Statics for the last 30 sec - Last15min(2), -- 15 min - Last24Hr(3), -- 24 Hour - SinceReboot(4) -- Since the time the pint server was + last30sec(1), -- Performance Statics for the last 30 sec + last15min(2), -- 15 min + last24Hr(3), -- 24 Hour + sinceReboot(4) -- Since the time the pint server was -- last rebooted } DESCRIPTION - "Note that the values of the counters indexed with a value + "This TC describes the statistics period of time. + + Note that the values of the counters indexed with a value SinceReboot(4) can be potentially affected by a counter rollover. It is the responsibility of the application using this object to take into account that the counter has been zeroed each time it reached a value of (2**32-1)." pintServerConfig OBJECT IDENTIFIER ::= { pintMib 1 } pintServerMonitor OBJECT IDENTIFIER ::= { pintMib 2 } pintMibConformance OBJECT IDENTIFIER ::= { pintMib 3 } -- pintServerConfig - PINT configuration MIB variables @@ -760,34 +780,35 @@ is thus important to control even GET access to these objects and possibly to even encrypt the values of these object when sending them over the network via SNMP. Not all versions of SNMP provide features for such a secure environment. SNMPv1 by itself is not a secure environment. 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. - It is recommended that the implementers consider the security - features as provided by the SNMPv3 framework. Specifically, the use - of the User-based Security Model RFC 2574 [13] and the View- based + It is recommended that the implementers consider the security fea- + tures as provided by the SNMPv3 framework. Specifically, the use of + the User-based Security Model RFC 2574 [13] and the View- based Access Control Model RFC 2575 [16] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly config- ured to give access to the objects only to those principals (users) - that have legitimate rights to indeed GET or SET - (change/create/delete) them. + that have legitimate rights to indeed GET or SET (change/cre- + ate/delete) them. 8. IANA Considerations All extensions to the values listed in this MIB must be done through + Standards Action processes as defined in RFC 2434 [21]. 9. References [1] H.Lu, et. al, "Toward the PSTN/Internet Inter-Networking --Pre- PINT Implementations", RFC 2458, November 1998. [2] Wijnen, B., Harrington, D., and Presuhn, R., "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. @@ -784,22 +805,22 @@ Standards Action processes as defined in RFC 2434 [21]. 9. References [1] H.Lu, et. al, "Toward the PSTN/Internet Inter-Networking --Pre- PINT Implementations", RFC 2458, November 1998. [2] Wijnen, B., Harrington, D., and Presuhn, R., "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999. -[3] Rose, M. and McCloghrie, K., "Structure and Identification of - Management Information for TCP/IP-based Internets", RFC 1155, May +[3] Rose, M. and McCloghrie, K., "Structure and Identification of Man- + agement Information for TCP/IP-based Internets", RFC 1155, May 1990. [4] Rose, M. and McCloghrie, K., "Concise MIB Definitions", RFC 1212, March 1991. [5] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [6] McCloghrie, K., Perkins, D., and Schoenwaelder, J., "Structure of Management Information Version 2 (SMIv2)", RFC 2578, April 1999. @@ -837,38 +858,38 @@ [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999. [17] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999. [18] S. Petrack, L. Conroy, "The PINT Service Protocol: Extensions to - SIP and SDP for IP Access to Telephone Call Services", draft- - ietf-pint-protocol-01.txt, 14 July 1999. + SIP and SDP for IP Access to Telephone Call Services", draft-ietf- + pint-protocol-01.txt, 14 July 1999. [19] C. Krupczak, J. Saperia, "Definitions of System-Level Managed Objects for Applications", RFC 2287, February 1998. [20] D. Harrington, R. Presuhn, B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2271, January 1998. -[21] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", RFC 2434, October 1998. +[21] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA Consid- + erations Section in RFCs", RFC 2434, October 1998. 10. Authors' Addresses Murali Krishnaswamy Lucent Technologies 3C-512, 101 Crawfords Corner Rd. Holmdel, NJ 07733 Tel: +1 (732)949-3611 Fax: +1 (732)949-3210 E-mail: murali@lucent.com Dan Romascanu - Lucent Technologies + Avaya Communication Atidim Technology Park, Bldg 3 Tel Aviv, Israel Tel: +972 3 6458414 E-mail: dromasca@lucent.com