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: 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,
Status: Rejected (1)
RFC 3413, "Simple Network Management Protocol (SNMP) Applications", December 2002
Source of RFC: snmpv3 (ops)
Errata ID: 7694
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Blake Nemura
Date Reported: 2023-11-02
Rejected by: Rob Wilton
Date Rejected: 2024-01-15
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.
--VERIFIER NOTES--
This change is too significant to do as part of an errata update to a 20 year old RFC, and there is not clear consensus as to whether any changes are required here at all (hence rejected rather than marked as "held for document update").
There has been some further discussion of this errata here:
https://mailarchive.ietf.org/arch/msg/opsawg/TDMmdSZpDYIqGYHa5SvW1cfnW4c/`
https://mailarchive.ietf.org/arch/msg/opsawg/xnXWL9fTjOhVaiAFD6kmqa-ZeNc/