Hi, I would appreciate input from the authors, and SNMP experts on how they think this errata should be processed please. I've looked at the appropriate sections of the RFC, but it isn't clear to me whether this errata is valid or not and I'm slightly nervous of making what could amount to quite a significant change to the external API.
Regards, Rob -----Original Message----- From: RFC Errata System <rfc-edi...@rfc-editor.org> Sent: Thursday, November 2, 2023 4:53 AM To: war...@kumari.net; Rob Wilton (rwilton) <rwil...@cisco.com>; mu...@tislabs.com; d...@enterasys.com Cc: bnem...@zebra.com; rfc-edi...@rfc-editor.org Subject: [Technical Errata Reported] RFC3413 (7694) The following errata report has been submitted for RFC3413, "Simple Network Management Protocol (SNMP) Applications". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid7694 -------------------------------------- Type: Technical Reported by: Blake Nemura <bnem...@zebra.com> Section: 3.2 Original Text ------------- - 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. Corrected Text -------------- - 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. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC3413 (draft-ietf-snmpv3-appl-v3-01) -------------------------------------- Title : Simple Network Management Protocol (SNMP) Applications Publication Date : December 2002 Author(s) : D. Levi, P. Meyer, B. Stewart Category : INTERNET STANDARD Source : SNMP Version 3 Area : Operations and Management Stream : IETF Verifying Party : IESG _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
