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

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/