Offhand, I rather doubt this is a valid errata. Thanks
Regards, Uri > On Nov 2, 2023, at 06:48, Rob Wilton (rwilton) > <rwilton=40cisco....@dmarc.ietf.org> wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside the Laboratory. > |-------------------------------------------------------------------! > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
