-  Mapping of notification parameters is documented in section 3.
well as behaviour of proxy implementations.
mechanism, which is wholly consistent with the SMIv1.
-  STD 58, RFC 2579 which defines common MIB "Textual Conventions"
requirements for defining agent and manager capabilities .
three documents listed above (RFCs 2578, 2579, and 2580).
referred to throughout this document as SNMPv2c.
-  RFC 2572 which defines Message Processing and Dispatching .
-  RFC 2573 which defines various SNMP Applications .
objects on a per-user basis .
the SMIv2 definitions of 2578 through 2580 described above.
and which actually initiates generation of notifications.
-  Generation of exception codes.
-  Use of the Counter64 data type.
will provide SNMPv2 format parameters for generating notifications.
is nearly a proper superset of the approach defined in the SMIv1.
compliance statements, and capabilities statements.
changed to Integer32, or have an appropriate range specified.
MUST have the value of its SYNTAX clause changed to Counter32.
"protocol sense" as the maximal level of access for the object.
when converting an ACCESS clause to a MAX-ACCESS clause.
MUST have a DESCRIPTION clause defined.
clause or an AUGMENTS clause defined.
define the single ASN.1 identifier.
CONVENTIONs are described in section 2 of RFC2579 .
defined using an informal textual convention.
conceptual row which is an extension.
STATUS clause of that object MUST be changed to "obsolete".
(2)  The ENTERPRISE clause MUST be removed.
(3)  The VARIABLES clause MUST be renamed to the OBJECTS clause.
(4)  A STATUS clause MUST be added, with an appropriate value.
'obsolete' may be used as needed.
same manner as described in section 3.1 in this document.
(6)  A DESCRIPTION clause MUST be added, if not already present.
the information module undergoes review.
define a MODULE-COMPLIANCE statement for such a MIB document.
(2)  The STATUS clause SHOULD be added, with a value of 'current'.
are consistent with RFC2580 .
have a STATUS clause value of mandatory are deemed to be INCLUDED.
is refered to in this document as 'SNMPv2 notification parameters'.
notifications to the end user in a consistent format.
as a trap or an inform.
-  An enterprise parameter (OBJECT IDENTIFIER).
-  An agent-addr parameter (NetworkAddress).
-  A generic-trap parameter (INTEGER).
-  A specific-trap parameter (INTEGER).
-  A time-stamp parameter (TimeTicks).
-  A list of variable-bindings (VarBindList).
variable-binding in an SNMPv2-Trap-PDU or InformRequest-PDU.
identifiers, '0', and the SNMPv1 specific-trap parameter.
snmpTraps' as defined in RFC1907 .
snmpTrapOID with the last sub-identifier removed.
situation in which the translation occurs.
the SNMP entity in which the notification originator resides.
the SNMPv1 agent-addr parameter SHALL be set to 0.0.0.0.
SHALL be set to 0.0.0.0.
Otherwise, the SNMPv1 generic-trap parameter SHALL be set to 6.
section 4.1.3 and section 4.2).
network, multi-lingual implementations and proxy implementations.
supported by the mono-lingual implementation.
entities which support only a single SNMP message version.
consult a local database to select the appropriate message version.
and setting error-status and error-index to zero.
into SNMPv1 error codes when processing an SNMPv1 message.
forwarded SNMPv2c or SNMPv3 message.
uses some combination of SNMPv1 and SNMPv2 access to MIB data.
The SMIv2  defines one new syntax that is incompatible with SMIv1.
binding that caused this error.
and the action taken depends on the type of SNMP request.
request SHALL be returned with the response PDU.
original request SHALL be returned with the response PDU.
be followed when using an SNMPv2 access to MIB data.
using the table in section 4.3, "Error Status Mappings".
request) of the variable binding that caused the error-status.
from the data as it is returned by the access to MIB data.
each of the objects in the request.  This is implementation specific.
data may be treated in the normal manner for an SNMPv1 request.
than Counter64 is returned, or an error occurs.
be followed when calling SNMPv2 MIB access routines.
value of snmpNotifyType is trap(1) or inform(2).
There are no special requirements of a notification receiver.
notification using the desired set of parameters.
tag of the PDU to GetNextRequest-PDU.
the mappings in section 4.3.
PDU, the trap cannot be forwarded using SNMPv1.
status values into SNMPv1 error-status values.
of snmpInBadCommunityUses MUST be incremented.
between the two models are described as required.
these two models are also described as required.
contextName may be mapped to a community name.
-  The messageProcessingModel, which will be 0 (or 1 for SNMPv2c).
no such value in the received message).
-  The securityModel, which will be 1 (or 2 for SNMPv2c).
-  The securityLevel, which will be noAuthNoPriv.
-  The wholeMsg and wholeMsgLength.
-  The community string is equal to the snmpCommunityName value.
transportAddress matches a entry in the snmpTargetAddrTable.
not actually appear in the message.
-  The securityLevel, which is noAuthNoPriv.
ScopedPDU from the call to processIncomingMsg.
from the call to processIncomingMsg.
must be the same as the community string from the original request.
information of the original request.
If no such entry can be found, the notification is not sent.
subnet in an snmpTargetAddrTable rather than just a single address.
snmpTargetAddrTable only specify individual addresses).
snmpTargetAddrTAddress must exactly match a transport address.
when the value cannot be determined from the protocol.
avoid unauthorized access to MIB data that would otherwise be secure.
when using the 'public' community string.
with such situations might be to use an encrypted tunnel.
based Agents", RFC 1303, February 1992.
bi-lingual SNMP agent", RFC 2089, January 1997.
SNMP Management Frameworks", RFC 2571, May 1999.
-  Editorial changes to comply with current RFC requirements.
-  Added Intellectual Property section.
-  Replaced old introduction with complete new introduction/overview.
-  Added content for the Security Considerations Section.
-  Updated References to current documents.
-  Updated text to use current SNMP terminology.
-  Added coexistence for/with SNMPv3.
address and community of the originating SNMPv1 agent.
mapping within a multi-lingual SNMP Engine.
behaviour when multiple SNMP versions are involved.