As per Relevance of the word february, we have this rfc below:
Network Working Group M.
Request for Comments: 2514 3
Category: Standards Track E.
Cisco
K.
February 1999
Definitions of Textual Conventions and OBJECT-
for ATM
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
Table of
1 Introduction .......................................... 2
2 Definitions ........................................... 3
3 Acknowledgments ....................................... 17
4 References ............................................ 17
5 Security Considerations ............................... 17
6 Authors' Addresses .................................... 18
7 Intellectual Property ................................. 19
8 Full Copyright Statement .............................. 20
This memo describes Textual Conventions and OBJECT-IDENTITIES
for managing ATM-based interfaces, devices, networks and services
1.
This memo describes Textual Conventions and OBJECT-IDENTITIES
for managing ATM-based interfaces, devices, networks and services
Noto, et. al. Standards Track [Page 1]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
When designing a MIB module, it is often useful to define new
similar to those defined in the SMI. In comparison to a type
in the SMI, each of these new types has a different name, a
syntax, but a more precise semantics. These newly defined types
termed textual conventions, and are used for the convenience
humans reading the MIB module. This is done through
Conventions as defined in RFC1903 [1]. It is the purpose of
document to define the set of textual conventions available to
MIB modules
When designing MIB modules, it is also often useful to
further properties with object identifier assignments so that
can be further used by other MIB modules. This is done through
OBJECT-IDENTITY macro defined in RFC1902 [2]. This document
OBJECT-IDENTITIES available to ATM MIB modules
Note that for organizational purposes OBJECT IDENTITIES
defined in RFC1695 have been moved to this specification and
longer appear in the revision of RFC1695 [3]. However, the
OBJECT IDENTIFIERs have been preserved
For an introduction to the concepts of ATM connections, see [3].
2.
ATM-TC-MIB DEFINITIONS ::=
MODULE-IDENTITY, OBJECT-IDENTITY
TimeTicks, mib-2
FROM SNMPv2-
TEXTUAL-
FROM SNMPv2-TC
atmTCMIB MODULE-
LAST-UPDATED "9810190200Z
ORGANIZATION "IETF AToMMIB Working Group
CONTACT-
" Michael
Postal: 3Com
5400 Bayfront Plaza, M/S 3109
Santa Clara, CA 95052
Tel: +1 408 326 2218
E-mail: mike_noto@3com.
Ethan Mickey
Noto, et. al. Standards Track [Page 2]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Postal: Cisco
170 W. Tasman Dr
San Jose, CA 95134
Tel: +1 408 526 6408
E-mail: mspiegel@cisco.
Kaj
Postal:
331 Newman Springs
Red Bank, NJ 07701
Tel: +1 732 758 5254
Fax: +1 732 758 4177
E-mail: kaj@bellcore.com
"This MIB Module provides Textual
and OBJECT-IDENTITY Objects to be used
ATM systems."
::= { mib-2 37 3 } -- atmMIB 3 (see [3])
-- The Textual Conventions defined below are
--
AtmAddr ::= TEXTUAL-
DISPLAY-HINT "1x
STATUS
"An ATM address. The semantics are implied
the length. The address types are: -
address (0 octets) - E.164 (8 octets) -
(20 octets) In addition, when
are used the AtmAddr may represent
concatenation of address and subaddress.
associated address types are: - E.164, E.164
(16 octets) - E.164, NSAP (28 octets) - NSAP
NSAP (40 octets) Address lengths other
defined in this definition imply
types defined elsewhere. Note: The E.164
address is encoded in BCD format."
SYNTAX OCTET STRING (SIZE(0..40))
AtmConnCastType ::= TEXTUAL-
STATUS
"The type of topology of a connection (point
Noto, et. al. Standards Track [Page 3]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
to-point, point-to-multipoint). In the
of point-to-multipoint, the orientation
this VPL or VCL in the connection
On a host
- p2mpRoot indicates that the
is the root of the p2mp connection
- p2mpLeaf indicates that the
is a leaf of the p2mp connection
On a switch interface
- p2mpRoot indicates that cells
by the switching fabric from the
are from the root of the p2mp connection
- p2mpLeaf indicates that cells
to the interface from the switching
are to the leaf of the p2mp connection."
SYNTAX INTEGER {
p2p(1),
p2mpRoot(2),
p2mpLeaf(3)
}
AtmConnKind ::= TEXTUAL-
STATUS
"The type of call control used for an
connection at a particular interface. The
is as follows
pvc(1)
Virtual link of a PVC. Should not
used for an PVC/SVC (i.e., Soft PVC
crossconnect
svcIncoming(2)
Virtual link established after
received signaling request to
an SVC
svcOutgoing(3)
Virtual link established after
transmitted or forwarded
request to setup an SVC
spvcInitiator(4)
Virtual link at the PVC side of
SVC/PVC crossconnect, where
switch is the initiator of the Soft
setup
spvcTarget(5)
Virtual link at the PVC side of
SVC/PVC crossconnect, where
switch is the target of the Soft
Noto, et. al. Standards Track [Page 4]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
setup
For PVCs, a pvc virtual link is always cross
connected to a pvc virtual link
For SVCs, an svcIncoming virtual link is always cross
connected to an svcOutgoing virtual link
For Soft PVCs, an spvcInitiator is either cross-connected
an svcOutgoing or an spvcTarget, and an spvcTarget is
cross-connected to an svcIncoming or an spvcInitiator."
SYNTAX INTEGER {
pvc(1),
svcIncoming(2),
svcOutgoing(3),
spvcInitiator(4),
spvcTarget(5)
}
AtmIlmiNetworkPrefix ::= TEXTUAL-
STATUS
"A network prefix used for ILMI
registration. In the case of ATM
addresses (AESAs), the network prefix is the
13 octets of the address which includes the AFI
IDI, and HO-DSP fields. In the case of
E.164 addresses, the network prefix is the
E.164 address encoded in 8 octets, as if it
an E.164 IDP in an ATM endsystem
structure."
"ATM Forum, Integrated Local Management
(ILMI) Specification, Version 4.0,
af-ilmi-0065.000, September 1996, Section 9
ATM Forum, ATM User-Network Interface
Specification, Version 4.0 (UNI 4.0),
af-sig-0061.000, June 1996, Section 3"
SYNTAX OCTET STRING (SIZE(8|13))
AtmInterfaceType ::= TEXTUAL-
STATUS
"The connection setup procedures used for
identified interface
Other: Connection setup procedures other
those listed below
Noto, et. al. Standards Track [Page 5]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Auto-configuration
Indicates that the connection
procedures are to be determined dynamically
or that determination has not yet
completed. One such mechanism is via
Forum ILMI auto-configuration procedures
ITU-T DSS2:
- ITU-T Recommendation Q.2931,
Integrated Service Digital Network (B-ISDN
Digital Subscriber Signalling System No.2
(DSS2) User-Network Interface (UNI) Layer 3
Specification for Basic Call/
Control (September 1994)
- ITU-T Draft Recommendation Q.2961,
B-ISDN DSS 2 Support of Additional
Parameters (May 1995)
- ITU-T Draft Recommendation Q.2971,
B-ISDN DSS 2 User Network Interface Layer 3
Specification for Point-to-
Call/connection Control (May 1995)
ATM Forum UNI 3.0:
ATM Forum, ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification
(1994).
ATM Forum UNI 3.1:
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
(November 1994).
ATM Forum UNI Signalling 4.0:
ATM Forum, ATM User-Network Interface (UNI
Signalling Specification Version 4.0,
af-sig-0061.000 (June 1996).
ATM Forum IISP (based on UNI 3.0 or UNI 3.1) :
Interim Inter-switch Signaling
(IISP) Specification, Version 1.0,
af-pnni-0026.000, (December 1994).
ATM Forum PNNI 1.0 :
ATM Forum, Private Network-Network
Specification, Version 1.0, af-pnni-0055.000,
(March 1996).
Noto, et. al. Standards Track [Page 6]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
ATM Forum B-ICI
ATM Forum, B-ICI Specification, Version 2.0,
af-bici-0013.002, (November 1995).
ATM Forum UNI PVC Only
An ATM Forum compliant UNI with
signalling disabled
ATM Forum NNI PVC Only
An ATM Forum compliant NNI with
signalling disabled."
SYNTAX INTEGER {
other(1),
autoConfig(2),
ituDss2(3),
atmfUni3Dot0(4),
atmfUni3Dot1(5),
atmfUni4Dot0(6),
atmfIispUni3Dot0(7),
atmfIispUni3Dot1(8),
atmfIispUni4Dot0(9),
atmfPnni1Dot0(10),
atmfBici2Dot0(11),
atmfUniPvcOnly(12),
atmfNniPvcOnly(13) }
AtmServiceCategory ::= TEXTUAL-
STATUS
"The service category for a connection."
"ATM Forum Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
SYNTAX INTEGER {
other(1), -- none of the
cbr(2), -- constant bit
rtVbr(3), -- real-time variable bit
nrtVbr(4), -- non real-time variable bit
abr(5), -- available bit
ubr(6) -- unspecified bit
}
AtmSigDescrParamIndex ::= TEXTUAL-
STATUS
"The value of this object identifies a row in
atmSigDescrParamTable. The value 0 signifies
none of the signalling parameters defined in
atmSigDescrParamTable are applicable."
Noto, et. al. Standards Track [Page 7]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
SYNTAX INTEGER (0..2147483647)
AtmTrafficDescrParamIndex ::= TEXTUAL-
STATUS
"The value of this object identifies a row in
atmTrafficDescrParamTable. The value 0
that no row has been identified."
SYNTAX INTEGER (0..2147483647)
AtmVcIdentifier ::= TEXTUAL-
STATUS
"The VCI value for a VCL. The maximum VCI
cannot exceed the value allowable
atmInterfaceMaxVciBits defined in ATM-MIB."
SYNTAX INTEGER (0..65535)
AtmVpIdentifier ::= TEXTUAL-
STATUS
"The VPI value for a VPL or VCL. The value VPI=0
is only allowed for a VCL. For ATM UNIs
VPCs the VPI value ranges from 0 to 255. The
value 0 is supported for ATM UNIs conforming
the ATM Forum UNI 4.0 Annex 8 (Virtual UNIs
specification. For ATM UNIs supporting VCCs
VPI value ranges from 0 to 255. For ATM NNIs
VPI value ranges from 0 to 4095. The maximum
value cannot exceed the value allowable
atmInterfaceMaxVpiBits defined in ATM-MIB."
SYNTAX INTEGER (0..4095)
AtmVorXAdminStatus ::= TEXTUAL-
STATUS
"The value determines the desired
status of a virtual link or cross-connect. The
and down states indicate that the traffic flow
enabled or disabled respectively on the
link or cross-connect."
SYNTAX INTEGER {
up(1),
down(2)
}
AtmVorXLastChange ::= TEXTUAL-
STATUS
Noto, et. al. Standards Track [Page 8]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
"The value of MIB II's sysUpTime at the time
virtual link or cross-connect entered its
operational state. If the current state
entered prior to the last re-initialization of
agent then this object contains a zero value."
SYNTAX
AtmVorXOperStatus ::= TEXTUAL-
STATUS
"The value determines the operational status of
virtual link or cross-connect. The up and
states indicate that the traffic flow is
or disabled respectively on the virtual link
cross-connect. The unknown state indicates
the state of it cannot be determined. The
will be down or unknown if the supporting
interface(s) is down or unknown respectively."
SYNTAX INTEGER {
up(1),
down(2),
unknown(3)
}
-- OBJECT-IDENTITIES
-- The following atmTrafficDescriptorTypes has been
-- from RFC1695 and no longer appear in the revision
-- RFC1695[3].
atmTrafficDescriptorTypes OBJECT IDENTIFIER ::= {mib-2 37 1 1}
--
-- See [3].
-- All other and new OBJECT
-- are defined under the following subtree
atmObjectIdentities OBJECT IDENTIFIER ::= {atmTCMIB 1}
-- The following values are defined for use
-- possible values of the ATM traffic descriptor type
atmNoTrafficDescriptor OBJECT-
STATUS
Noto, et. al. Standards Track [Page 9]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
"This identifies the no ATM
descriptor type. Parameters 1, 2, 3, 4,
and 5 are not used. This traffic
type can be used for best effort traffic."
::= {atmTrafficDescriptorTypes 1}
atmNoClpNoScr OBJECT-
STATUS
"This traffic descriptor type is for no
and no Sustained Cell Rate. The use of
parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: not
Parameter 3: not
Parameter 4: not
Parameter 5: not used."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994."
::= {atmTrafficDescriptorTypes 2}
atmClpNoTaggingNoScr OBJECT-
STATUS
"This traffic descriptor is for CLP
tagging and no Sustained Cell Rate. The
of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: peak cell rate in cells/
for CLP=0
Parameter 3: not
Parameter 4: not
Parameter 5: not used."
::= {atmTrafficDescriptorTypes 3}
atmClpTaggingNoScr OBJECT-
STATUS
"This traffic descriptor is for CLP
tagging and no Sustained Cell Rate. The
of the parameter vector for this type
Noto, et. al. Standards Track [Page 10]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: peak cell rate in cells/
for CLP=0 traffic,
tagged as CLP=1
Parameter 3: not
Parameter 4: not
Parameter 5: not used."
::= {atmTrafficDescriptorTypes 4}
atmNoClpScr OBJECT-
STATUS
"This traffic descriptor type is for no
with Sustained Cell Rate. The use of
parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0+1
Parameter 3: maximum burst size in
Parameter 4: not
Parameter 5: not used."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994."
::= {atmTrafficDescriptorTypes 5}
atmClpNoTaggingScr OBJECT-
STATUS
"This traffic descriptor type is for CLP
Sustained Cell Rate and no tagging. The
of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0
Parameter 3: maximum burst size in
Parameter 4: not
Parameter 5: not used."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Noto, et. al. Standards Track [Page 11]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Version 3.1 (UNI 3.1) Specification
November 1994."
::= {atmTrafficDescriptorTypes 6}
atmClpTaggingScr OBJECT-
STATUS
"This traffic descriptor type is for CLP
tagging and Sustained Cell Rate. The use
the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0 traffic, excess tagged
CLP=1
Parameter 3: maximum burst size in
Parameter 4: not
Parameter 5: not used."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994."
::= {atmTrafficDescriptorTypes 7}
atmClpNoTaggingMcr OBJECT-
STATUS
"This traffic descriptor type is for CLP
Minimum Cell Rate and no tagging. The use
the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: CDVT in tenths of
Parameter 3: minimum cell rate in cells/
Parameter 4:
Parameter 5: unused."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994."
::= {atmTrafficDescriptorTypes 8}
atmClpTransparentNoScr OBJECT-
STATUS
Noto, et. al. Standards Track [Page 12]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
"This traffic descriptor type is for the CLP
transparent model and no Sustained Cell Rate
The use of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: CDVT in tenths of
Parameter 3: not
Parameter 4: not
Parameter 5: not used
This traffic descriptor type is applicable
connections following the CBR.1
definition
Connections specifying this traffic
type will be rejected at UNI 3.0 or UNI 3.1
interfaces. For a similar traffic
type that can be accepted at UNI 3.0
UNI 3.1 interfaces, see atmNoClpNoScr."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 9}
atmClpTransparentScr OBJECT-
STATUS
"This traffic descriptor type is for the CLP
transparent model with Sustained Cell Rate
The use of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0+1
Parameter 3: maximum burst size in
Parameter 4: CDVT in tenths of
Parameter 5: not used
This traffic descriptor type is applicable
connections following the VBR.1
definition
Noto, et. al. Standards Track [Page 13]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Connections specifying this traffic
type will be rejected at UNI 3.0 or UNI 3.1
interfaces. For a similar traffic
type that can be accepted at UNI 3.0
UNI 3.1 interfaces, see atmNoClpScr."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 10}
atmNoClpTaggingNoScr OBJECT-
STATUS
"This traffic descriptor type is for no
with tagging and no Sustained Cell Rate.
use of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: CDVT in tenths of
Parameter 3: not
Parameter 4: not
Parameter 5: not used
This traffic descriptor type is applicable
connections following the UBR.2
definition ."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 11}
atmNoClpNoScrCdvt OBJECT-
STATUS
"This traffic descriptor type is for no
and no Sustained Cell Rate. The use of
parameter vector for this type
Parameter 1: peak cell rate in cells/
Noto, et. al. Standards Track [Page 14]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
for CLP=0+1
Parameter 2: CDVT in tenths of
Parameter 3: not
Parameter 4: not
Parameter 5: not used
This traffic descriptor type is applicable
CBR connections following the UNI 3.0/3.1
conformance definition for PCR CLP=0+1.
These CBR connections differ from CBR.1
connections in that the CLR
applies only to the CLP=0 cell flow
This traffic descriptor type is
applicable to connections following the UBR.1
conformance definition."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 12}
atmNoClpScrCdvt OBJECT-
STATUS
"This traffic descriptor type is for no
with Sustained Cell Rate. The use of
parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0+1
Parameter 3: maximum burst size in
Parameter 4: CDVT in tenths of
Parameter 5: not used
This traffic descriptor type is
to VBR connections following the UNI 3.0/3.1
conformance definition for PCR CLP=0+1
SCR CLP=0+1. These VBR
differ from VBR.1 connections in
the CLR objective applies only to the CLP=0
cell flow."
Noto, et. al. Standards Track [Page 15]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 13}
atmClpNoTaggingScrCdvt OBJECT-
STATUS
"This traffic descriptor type is for CLP
Sustained Cell Rate and no tagging. The
of the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0
Parameter 3: maximum burst size in
Parameter 4: CDVT in tenths of
Parameter 5: not used
This traffic descriptor type is applicable
connections following the VBR.2
definition."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 14}
atmClpTaggingScrCdvt OBJECT-
STATUS
"This traffic descriptor type is for CLP
tagging and Sustained Cell Rate. The use
the parameter vector for this type
Parameter 1: peak cell rate in cells/
for CLP=0+1
Parameter 2: sustainable cell rate in cells/
for CLP=0 traffic, excess tagged
CLP=1
Parameter 3: maximum burst size in
Noto, et. al. Standards Track [Page 16]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
Parameter 4: CDVT in tenths of
Parameter 5: not used
This traffic descriptor type is applicable
connections following the VBR.3
definition."
"ATM Forum,ATM User-Network Interface
Version 3.0 (UNI 3.0) Specification, 1994.
ATM Forum, ATM User-Network Interface
Version 3.1 (UNI 3.1) Specification
November 1994.
ATM Forum, Traffic Management Specification
Version 4.0, af-tm-0056.000, June 1996."
::= {atmTrafficDescriptorTypes 15}
3.
This document is a product of the AToMMIB Working Group
4.
[1] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser
"Textual Conventions for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1903, January 1996.
[2] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "
of Management Information for Version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1902, January 1996.
[3] Tesink, K., Editor, "Definitions of Managed Objects for
Management", RFC 2515, February 1999.
5. Security
This memo defines textual conventions and object identities for
in ATM MIB modules. Security issues for these MIB modules
addressed in the memos defining those modules
Noto, et. al. Standards Track [Page 17]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
6. Authors'
Michael
3Com
5400 Bayfront Plaza, M/S 3109
Santa Clara, CA 95052
Phone +1 408 326 2218
Email: mike_noto@3com.
Ethan Mickey
Cisco
170 W. Tasman Dr
San Jose, CA 95134
Phone +1 408 526 6408
EMail: mspiegel@cisco.
Kaj
331 Newman Springs
P.O. Box 7020
Red Bank, NJ 07701-7020
Phone: (732) 758-5254
EMail: kaj@bellcore.
Noto, et. al. Standards Track [Page 18]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
7. Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11. Copies
claims of rights made available for publication and any assurances
licenses to be made available, or the result of an attempt made
obtain a general license or permission for the use of
proprietary rights by implementors or users of this specification
be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
Noto, et. al. Standards Track [Page 19]
RFC 2514 ATM TCs and OBJECT-IDENTITIES February 1999
8. Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Noto, et. al. Standards Track [Page 20]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
