RFC Errata
Found 6 records.
Status: Verified (3)
RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002
Source of RFC: snmpv3 (ops)
Errata ID: 2459
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mark Ellison
Date Reported: 2010-08-07
Verifier Name: Dan Romascanu
Date Verified: 2010-11-02
Section 4.2.1 says:
OBJECT snmpNotifyType
SYNTAX INTEGER {
trap(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Create/delete/modify access is not required.
Support of the value notify(2) is not required."
It should say:
OBJECT snmpNotifyType
SYNTAX INTEGER {
trap(1)
}
MIN-ACCESS read-only
DESCRIPTION
"Create/delete/modify access is not required.
Support of the value inform(2) is not required."
Notes:
the enumeration value as stated: notify(2)
the enumeration value should be: inform(2)
This appears in section 4.2.1, "Definitions" for the SNMP-NOTIFICATION-MIB spanning the page break between page 54 and 55 and contained within the snmpNotifyBasicCompliance macro.
Errata ID: 279
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Guan Hai Bing
Date Reported: 2002-12-27
Section 3.5.1.1 says:
(2) If appropriate outgoing management target information cannot be
found, the proxy forwarder increments the snmpProxyDrops
counter [RFC1907], and then calls the Dispatcher using the
returnResponsePdu abstract service interface.
It should say:
(2) If appropriate outgoing management target information cannot be
found, the proxy forwarder increments the snmpProxyDrops
counter [RFC3418], and then calls the Dispatcher using the
returnResponsePdu abstract service interface.
Notes:
In Sections 3.2 and 4.1.2:
by [RFC1905]
Should be:
by [RFC3416]
Errata ID: 280
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Eduardo Cardona
Date Reported: 2004-02-20
In Section 4.2.1, page 50, in DESCRIPTION clause of snmpNotifyFilterTable:
A more complete discussion of notification filtering
can be found in section 6. of [SNMP-APPL]."
It should say:
A more complete discussion of notification filtering
can be found in section 6. of RFC3413."
Notes:
Additionally, page 52, in DESCRIPTION clause of snmpNotifyFilterType:
filter. A more detailed discussion of the use of this
object can be found in section 6. of [SNMP-APPL]."
It should be:
filter. A more detailed discussion of the use of this
object can be found in section 6. of RFC3413."
Status: Reported (1)
RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002
Source of RFC: snmpv3 (ops)
Errata ID: 7694
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Blake Nemura
Date Reported: 2023-11-02
Section 3.2 says:
- If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
or noGroupName error, processing of the management operation is
halted, a PDU value is constructed using the values from the
originally received PDU, but replacing the error-status with an
authorizationError code, and error-index value of 0, and
control is passed to step (6) below.
- If the isAccessAllowed ASI returns an otherError, processing of
the management operation is halted, a different PDU value is
constructed using the values from the originally received PDU,
but replacing the error-status with a genError code and the
error-index with the index of the failed variable binding, and
control is passed to step (6) below.
It should say:
- If the isAccessAllowed ASI returns a notInView error for a
Write-Class viewType (e.g. for a SetRequest-PDU), processing
of the management operation is halted, a different PDU value is
constructed using the values from the originally received PDU,
but replacing the error-status with a noAccess code and the
error-index with the index of the failed variable binding, and
control is passed to step (6) below.
- If the isAccessAllowed ASI returns a noSuchView, noAccessEntry,
or noGroupName error, processing of the management operation is
halted, a PDU value is constructed using the values from the
originally received PDU, but replacing the error-status with an
authorizationError code, and error-index value of 0, and
control is passed to step (6) below.
- If the isAccessAllowed ASI returns an otherError, processing of
the management operation is halted, a different PDU value is
constructed using the values from the originally received PDU,
but replacing the error-status with a genError code and the
error-index with the index of the failed variable binding, and
control is passed to step (6) below.
Notes:
RFC3415, Section 3, defines 6 distinct errorIndication types for the isAccessAllowed ASI: notInView, noSuchView, noSuchContext, noGroupName, noAccessEntry, and otherError.
Whereas RFC3413 does not define handling of the notInView error. Whereby one might, presumably mistakenly, assume that notInView should be handled as "an otherError". However otherError is a distinct errorIndication for "undefined error" (presumably as a catch-all for possible implementation-level errors), whereas notInView is a defined error.
Additionally, RFC3416, Section 4.2.5, and only for SetRequest-PDU, clearly defines noAccess error-status as the first-priority validation check for "not...in the appropriate MIB view" case:
(1) If the variable binding's name specifies an existing or non-
existent variable to which this request is/would be denied
access because it is/would not be in the appropriate MIB view,
then the value of the Response-PDU's error-status field is set
to "noAccess", and the value of its error-index field is set to
the index of the failed variable binding.
Status: Held for Document Update (2)
RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002
Source of RFC: snmpv3 (ops)
Errata ID: 6531
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Robert Wilton
Date Held: 2021-04-13
Throughout the document, when it says:
4.1.1 Tag Lists .....................,........................ 29
It should say:
4.1.1 Tag Lists .............................................. 29
Notes:
Improper punctuation.
Errata ID: 6532
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Juli Mallett
Date Reported: 2021-04-13
Held for Document Update by: Robert Wilton
Date Held: 2021-04-13
Throughout the document, when it says:
4.1.2 Definitions ..................,......................... 30
It should say:
4.1.2 Definitions ............................................ 30
Notes:
Improper punctuation,