Re: [OPSAWG] [Technical Errata Reported] RFC3413 (7694)

[Rob Wilton (rwilton)]

Hi Blake,

Thanks for the extra context.  Generally, IETF has a high bar for what it will 
accept as errata, particularly if it looks like it could have a high impact, 
and particularly when the RFC in question is now so old, and I generally err on 
the side of caution!

For me to mark this errata as verified then I need to determine that this is a 
mistake or omission and that the text that you suggest is what the WG intended 
and had consensus for at the time when the draft was approved for publication.  
If there is doubt or ambiguity then another choice is “hold for document 
update” which effectively says that this should be considered for a future 
revision of this RFC, if that occurs.  The third choice is that the errata is 
rejected, which would occur if the consensus was that the current text is 
correct.

Regards,
Rob


From: Nemura, Blake 
Sent: Thursday, November 2, 2023 2:57 PM
To: Rob Wilton (rwilton) ; mu...@tislabs.com; 
d...@enterasys.com; opsawg@ietf.org; Jürgen Schönwälder 
; Randy Presuhn 

Subject: RE: [Technical Errata Reported] RFC3413 (7694)

I went through entire STD 62 to try to determine how notInView case is supposed 
to be handled, and this seemed to me (and my team implementing SNMPv3 in our 
products), based on the combination of multiple related RFCs referenced, to be 
the most appropriate and logical choice.

However, the main point of this erratum is just that it is not clear; the 
notInView error case handling is not defined.

If the authors/experts feel a different error-status or handling is more 
appropriate, such as to explicitly add it into the otherError case and result 
in a genErr error-status, that could be okay too. Although that would seem to 
conflict with RFC3416 4.2.5 (1), and otherwise the only explicit noAccess 
error-status case is in usmUserOwnAuth/PrivKeyChange descriptions.

Thank you for your consideration of this report.

Best,
Blake

From: Rob Wilton (rwilton) mailto:rwil...@cisco.com>>
Sent: Thursday, November 02, 2023 5:47 AM
To: mu...@tislabs.com; 
d...@enterasys.com; 
opsawg@ietf.org; Jürgen Schönwälder 
mailto:jschoenwaelder@constructor.university>>;
 Randy Presuhn 
mailto:randy_pres...@alumni.stanford.edu>>
Cc: Nemura, Blake mailto:bnem...@zebra.com>>
Subject: RE: [Technical Errata Reported] RFC3413 (7694)

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
ZjQcmQRYFpfptBannerStart
External Sender
This message came from outside our organization. Please use caution before 
acting on the message.
ZjQcmQRYFpfptBannerEnd

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 
mailto:rfc-edi...@rfc-editor.org>>

Sent: Thursday, November 2, 2023 4:53 AM

To: war...@kumari.net; Rob Wilton (rwilton) 
mailto: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://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_errata_eid7694=DwIGaQ=Qwsh1H-X9ypOoLLEcAIltRyC0Dw0FG3Mmyd56ahml5w=lPfzzfb7P6JnRX7KHetEnJUQ73Ip0b_Gi7F4Es-CoMM=XArDtevwDu4lwoJL71VdxN4YHBEPEAvGTIXqiqw5T7-iSHPtALuezSsr8ZeqYVoH=T_Fz_YiP1BwpFqeQ7SJnmPMbef3POGY0UxjzXGRq9Gs=



--

Type: Technical

Reported by: Blake Nemura mailto: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 

Re: [OPSAWG] [Technical Errata Reported] RFC3413 (7694)

[Rob Wilton (rwilton)]

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  
Sent: Thursday, November 2, 2023 4:53 AM
To: war...@kumari.net; Rob Wilton (rwilton) ; 
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 

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