As per Relevance of the word describing, we have this rfc below:











Network Working Group K.
Request For Comments: 1303 Hughes LAN
M.
Dover Beach
February 1992


A Convention for Describing SNMP-based

Status of This

This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited



This memo suggests a straight-forward approach towards
SNMP-based agents

Table of

1. The Network Management Framework ............................ 2
2. Objects ..................................................... 2
3. Describing Agents ........................................... 3
3.1 Definitions ................................................ 4
3.2 Mapping of the MODULE-CONFORMANCE macro .................... 5
3.2.1 Mapping of the LAST-UPDATED clause ....................... 6
3.2.2 Mapping of the PRODUCT-RELEASE clause .................... 6
3.2.3 Mapping of the DESCRIPTION clause ........................ 6
3.2.4 Mapping of the SUPPORTS clause ........................... 6
3.2.4.1 Mapping of the INCLUDES clause ......................... 6
3.2.4.2 Mapping of the VARIATION clause ........................ 6
3.2.4.2.1 Mapping of the SYNTAX clause ......................... 6
3.2.4.2.2 Mapping of the WRITE-SYNTAX clause ................... 7
3.2.4.2.3 Mapping of the ACCESS clause ......................... 7
3.2.4.2.4 Mapping of the CREATION-REQUIRES clause .............. 7
3.2.4.2.5 Mapping of the DEFVAL clause ......................... 7
3.2.4.2.6 Mapping of the DESCRIPTION clause .................... 7
3.3 Refined Syntax ............................................. 7
3.4 Usage Example .............................................. 8
4. Acknowledgements ............................................ 11
5. References .................................................. 11
6. Security Considerations...................................... 12
7. Authors' Addresses........................................... 12






McCloghrie & Rose [Page 1]

RFC 1303 Convention for Describing SNMP Agents February 1992


1. The Network Management

The Internet-standard Network Management Framework consists
three components. They are

RFC 1155 [1] which defines the SMI, the mechanisms used
describing and naming objects for the purpose of management
RFC 1212 [2] defines a more concise description mechanism
which is wholly consistent with the SMI

RFC 1213 [3] which defines MIB-II, the core set of
objects for the Internet suite of protocols

RFC 1157 [4] which defines the SNMP, the protocol used
network access to managed objects

The Framework permits new objects to be defined for
purpose of experimentation and evaluation

2.

Managed objects are accessed via a virtual information store
termed the Management Information Base or MIB. Within a
MIB module, objects are defined using RFC 1212's OBJECT-
macro. At a minimum, each object has a name, a syntax,
access-level, and an implementation-status

The name is an object identifier, an administratively
name, which specifies an object type. The object
together with an object instance serves to uniquely identify
specific instantiation of the object. For human convenience
we often use a textual string, termed the OBJECT DESCRIPTOR
to also refer to the object type

The syntax of an object type defines the abstract
structure corresponding to that object type. The ASN.1[5]
language is used for this purpose. However, RFC 1155
purposely restricts the ASN.1 constructs which may be used
These restrictions are explicitly made for simplicity

The access-level of an object type defines whether it
"protocol sense" to read and/or write the value of an
of the object type. (This access-level is independent of
administrative authorization policy.)

The implementation-status of an object type indicates
the object is mandatory, optional, obsolete, or deprecated




McCloghrie & Rose [Page 2]

RFC 1303 Convention for Describing SNMP Agents February 1992


3. Describing

When a MIB module is written, it is divided into units
conformance termed groups. If an agent claims conformance
a group, then it must implement each and every object
that group. Of course, for whatever reason, an agent
implement only a subset of the groups within a MIB module.
addition, the definition of some MIB objects leave
aspects of the definition to the discretion of an implementor

Practical experience has demonstrated a need for
describing the capabilities of an agent with regards to
MIB groups that it implements. This memo defines a new macro
MODULE-CONFORMANCE, which allows an agent implementor
describe the precise level of support which an agent claims
regards to a MIB group, and to bind that description to
sysObjectID associated with the agent. In particular,
objects may have restricted or augmented syntax or access
levels

If the MODULE-CONFORMANCE invocation is given to
management-station implementor, then that implementor
build management applications which optimize themselves
communicating with a particular agent. For example,
management-station can maintain a database of
invocations. When a management-station interacts with
agent, it retrieves the agent's sysObjectID. Based on this
it consults the database. If an entry is found, then
management application can optimize its behavior accordingly

This binding to sysObjectId may not always suffice to
all MIB objects to which an agent can provide access.
particular, this situation occurs where the agent
learns of the objects it supports, for example, an
supporting SMUX peers via the SMUX protocol [6]. In
situations, additional MIB objects beyond sysObjectID must
used to name other invocations of the MODULE-CONFORMANCE
to augment the description of MIB support provided by
agent. For example, if an agent's sysObjectID indicates
it supports the SMUX MIB, then each instance of
will indicate another MODULE-CONFORMANCE invocation which
dynamically being supported by the agent









McCloghrie & Rose [Page 3]

RFC 1303 Convention for Describing SNMP Agents February 1992


3.1.

RFC-1303 DEFINITIONS ::=


ObjectName,
FROM RFC1155-

FROM RFC1213-MIB

MODULE-CONFORMANCE MACRO ::=

TYPE NOTATION ::=
"LAST-UPDATED
value(update UTCTime
"PRODUCT-RELEASE
value(release DisplayString
"DESCRIPTION
value(description DisplayString


VALUE NOTATION ::= -- agent's sysObjectID --
value(VALUE ObjectName

ModulePart ::=
|

Modules ::=
| Modules

Module ::= -- name of module --
"SUPPORTS"
"INCLUDES" "{" Groups "}"


ModuleName ::= identifier

ModuleIdentifier ::=
value (moduleID OBJECT IDENTIFIER
|

Groups ::=
| Groups ","

Group ::= value(group OBJECT IDENTIFIER

VariationPart ::=
|



McCloghrie & Rose [Page 4]

RFC 1303 Convention for Describing SNMP Agents February 1992


Variations ::=
| Variations

Variation ::= "VARIATION" value(object ObjectName
Syntax WriteSyntax
Creation
"DESCRIPTION
value(limitext DisplayString

-- must be a refinement for object's
Syntax ::= "SYNTAX" type(SYNTAX
|

-- must be a refinement for object's
WriteSyntax ::= "WRITE-SYNTAX" type(WriteSYNTAX
|

Access ::= "ACCESS"
|

AccessValue ::= "read-only
| "read-write
| "write-only
| "not-accessible

Creation ::= "CREATION-REQUIRES" "{" Cells "}"

Cells ::=
| Cells ","

Cell ::= value(cell ObjectName

DefaultValue ::= "DEFVAL
"{" value (defval ObjectSyntax) "}"
|





3.2. Mapping of the MODULE-CONFORMANCE

It should be noted that the expansion of the MODULE-CONFORMANCE
is something which conceptually happens during implementation and
during run-time






McCloghrie & Rose [Page 5]

RFC 1303 Convention for Describing SNMP Agents February 1992


3.2.1. Mapping of the LAST-UPDATED

The LAST-UPDATED clause, which must be present, contains the date
time that this definition was last edited

3.2.2. Mapping of the PRODUCT-RELEASE

The PRODUCT-RELEASE clause, which must be present, contains a
description of the product release which includes this agent

3.2.3. Mapping of the DESCRIPTION

The DESCRIPTION clause, which must be present, contains a
description of this agent

3.2.4. Mapping of the SUPPORTS

The SUPPORTS clause, which need not be present, is repeatedly used
name each MIB module for which the agent claims a complete or
implementation. Each MIB module is named by its module name,
optionally, by its associated OBJECT IDENTIFIER as well. (Note
only a few MIB modules have had OBJECT IDENTIFIERs assigned to them.)

3.2.4.1. Mapping of the INCLUDES

The INCLUDES clause, which must be present for each use of
SUPPORTS clause, is used to name each MIB group associated with
SUPPORT clause, which the agent claims to implement

3.2.4.2. Mapping of the VARIATION

The VARIATION clause, which need not be present, is repeatedly
to name each MIB object which the agent implements in some variant
refined fashion

3.2.4.2.1. Mapping of the SYNTAX

The SYNTAX clause, which need not be present, is used to provide
refined SYNTAX for the object named in the correspondent
clause. Note that if this clause and a WRITE-SYNTAX clause are
present, then this clause only applies when instances of the
named in the correspondent VARIATION clause are read

Consult Section 3.3 for more information on refined syntax







McCloghrie & Rose [Page 6]

RFC 1303 Convention for Describing SNMP Agents February 1992


3.2.4.2.2. Mapping of the WRITE-SYNTAX

The WRITE-SYNTAX clause, which need not be present, is used
provide a refined SYNTAX for the object named in the
VARIATION clause when instances of that object are written

Consult Section 3.3 for more information on refined syntax

3.2.4.2.3. Mapping of the ACCESS

The ACCESS clause, which need not be present, is used to provide
refined ACCESS for the object named in the correspondent
clause

3.2.4.2.4. Mapping of the CREATION-REQUIRES

The CREATION-REQUIRES clause, which need not be present, is used
name the columnar objects of a conceptual row to which values must
explicitly assigned, by a SNMP Set operation, before the agent
create new instances of objects in that row. This clause must not
present unless the object named in the correspondent VARIATION
is a conceptual row, i.e., has a syntax which resolves to a
containing columnar objects. The objects named in the value of
clause usually will refer to columnar objects in that row. However
objects unrelated to the conceptual row may also be specified

The absence of this clause for a particular conceptual row
that the agent does not support the creation, via SNMP operations,
new object instances in that row

3.2.4.2.5. Mapping of the DEFVAL

The DEFVAL clause, which need not be present, is used to provide
refined DEFVAL value for the object named in the
VARIATION clause. The semantics of this value are identical to
of the OBJECT-TYPE macro's DEFVAL clause [2].

3.2.4.2.6. Mapping of the DESCRIPTION

The DESCRIPTION clause, which must be present for each use of
VARIATION clause, contains a textual description of the variant
refined implementation

3.3. Refined

The SYNTAX and WRITE-SYNTAX clauses allow an object's Syntax to
refined. However, not all refinements of syntax are appropriate.
particular



McCloghrie & Rose [Page 7]

RFC 1303 Convention for Describing SNMP Agents February 1992


(1) the object's primitive or application type (as defined
the SMI [1]) must not be changed

(2) an object defined with an SMI type of OBJECT IDENTIFIER
IpAddress, Counter, or TimeTicks cannot be refined; and

(3) an object defined to have a specific set of values (e.g.,
an INTEGER with named values) cannot have
values defined for it

3.4. Usage

Consider how one might document the 4BSD/ISODE "Secure"
agent

FourBSD-ISODE DEFINITIONS ::=


MODULE-
FROM RFC-1303
-- everything --
FROM RFCxxxx-
-- everything --
FROM RFC1213-
-- everything --
FROM UNIX-
-- everything --
FROM EVAL-MIB

fourBSD-isode-support MODULE-
LAST-UPDATED "9201252354Z
PRODUCT-RELEASE "ISODE 7.0 + 'Secure'
upgrade for SunOS 4.1"
DESCRIPTION "4BSD/ISODE 'Secure' SNMP

SUPPORTS RFCxxxx-MIB -- SNMP Party MIB --
INCLUDES { partyPublic, partyPrivate }

SUPPORTS RFC1213-
INCLUDES { system, interfaces, at, ip, icmp
tcp, udp, snmp }

VARIATION
CREATION-REQUIRES { atPhysAddress }
DESCRIPTION "Address mappings on 4BSD
both protocol and media addresses

VARIATION



McCloghrie & Rose [Page 8]

RFC 1303 Convention for Describing SNMP Agents February 1992


SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Unable to set test mode on 4BSD

VARIATION
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Information limited on 4BSD

VARIATION
SYNTAX INTEGER { maxttl(255) }
DESCRIPTION "Hard-wired on 4BSD

VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD

VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD

VARIATION
CREATION-REQUIRES { ipRouteNextHop }
DESCRIPTION "Routes on 4BSD require
destination and next-hop

VARIATION
SYNTAX INTEGER { direct(3), indirect(4) }
WRITE-SYNTAX INTEGER { invalid(2), direct(3),
indirect(4) }
DESCRIPTION "Information limited on 4BSD

VARIATION
SYNTAX INTEGER { other(1), icmp (4) }
DESCRIPTION "Information limited on 4BSD

VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD

VARIATION
CREATION-REQUIRES { ipNetToMediaPhysAddress }
DESCRIPTION "Address mappings on 4BSD
both protocol and media addresses

VARIATION
SYNTAX INTEGER { dynamic(3), static(4) }
WRITE-SYNTAX INTEGER { invalid(2), dynamic(3),
static(4) }
DESCRIPTION "Information limited on 4BSD



McCloghrie & Rose [Page 9]

RFC 1303 Convention for Describing SNMP Agents February 1992


VARIATION
ACCESS read-
DESCRIPTION "Unable to set this on 4BSD

VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD

VARIATION
ACCESS not-
DESCRIPTION "Information not available on 4BSD

SUPPORTS UNIX-
INCLUDES { agents, mbuf, netstat }

SUPPORTS EVAL-
INCLUDES { functions, expressions }

::= { fourBSD-isode 6 6 }



According to this invocation, an agent with a sysObjectID

{ fourBSD-isode 6 6 }

supports four MIB modules

From the SNMP Party MIB, all the objects contained in the
and partyPrivate groups are supported, without variation

From MIB-II, all groups except the egp group are supported. However
the







are not available, whilst the










McCloghrie & Rose [Page 10]

RFC 1303 Convention for Describing SNMP Agents February 1992


have a restricted syntax, and the



is available only for reading. Note that in the case of the




the set of values which may be read is different than the set
values which may be written. Finally, when creating a new row in
atTable, the set-request must create an instance of atPhysAddress
Similarly, when creating a new row in the ipRouteTable, the set
request must create an instance of ipRouteNextHop. Similarly,
creating a new row in the ipNetToMediaTable, the set-request
create an instance of ipNetToMediaPhysAddress

From the UNIX-MIB, all the objects contained in the agents, mbuf,
netstat groups are supported, without variation

From the EVAL-MIB, all the objects contained in the functions
expressions groups are supported, without variation

4.

The authors gratefully acknowledge the comments of Mark van der
of Hughes LAN Systems, and David T. Perkins of
Communications

5.

[1] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.

[2] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems
March 1991.

[3] McCloghrie K., and M. Rose, Editors, "Management
Base forNetwork Management of TCP/IP-based internets", RFC 1213,
Performance Systems International, March 1991.

[4] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol (SNMP), RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.




McCloghrie & Rose [Page 11]

RFC 1303 Convention for Describing SNMP Agents February 1992


[5] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization,
Standard 8824, December 1987.

[6] Rose, M., "SNMP MUX Protocol and MIB", RFC 1227,
Systems International, May 1991.

6. Security

Security issues are not discussed in this memo

7. Authors'

Keith
Hughes LAN
1225 Charleston
Mountain View, CA 94043

Phone: (415) 966-7934
EMail: kzm@hls.


Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2112

Phone: (415) 968-1052
EMail: mrose@dbc.mtview.ca.





















McCloghrie & Rose [Page 12]







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







Spectrum