Hi -

(Odd that I didn't see the original report)

The report is correct that RFC 3415 defines a possible errorIndication
of notInView, and that RFC 3413 doesn't explicitly say what to do about
it.  But that's about it. The cases enumerated in 3.2 (5) are errors
that effectively short-circuit request processing before hand-off to
RFC 3416.  What happens with notInView is a "fall-through" case
regardless of the operation type.  The proposed change is thus, in my
opinion, neither needed nor helpful.

Deep inside an agent additional processing of notInView (or its moral
equivalent) happens iteratively during the processing needed
to handle GetBulk and GetNext, far beyond the straightforward
processing for Get, Set, Trap and Inform.  That's really in the
realm of RFC 3416, which doesn't even mention this ASI or the
gory details needed to handle those operation types, particularly
when subagents are supported.

With two decades of distance, I can (still) see that the text could have
been clearer, but what's there now is (still) correct.

Randy

On 2023-11-02 8:31 AM, Blumenthal, Uri - 0553 - MITLL wrote:
Offhand, I rather doubt this is a valid errata.

Thanks

Regards,
Uri

On Nov 2, 2023, at 06:48, Rob Wilton (rwilton) 
<[email protected]> 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 <[email protected]>
Sent: Thursday, November 2, 2023 4:53 AM
To: [email protected]; Rob Wilton (rwilton) <[email protected]>; 
[email protected]; [email protected]
Cc: [email protected]; [email protected]
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 <[email protected]>

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
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to