Re: RE: [AGENT++] Wrong exeption in GET-response to unavailable object instance

[fock at agentpp.com]

Hi Markus,

sysDescr.1 could *never* exist in any agent! Therefor
there is no potential that such an instance could exists
and that's why in my opinion returning noSuchObject is
appropriate here. Otherwise, a manager could think, that
sysDescr.1 could (a) be created or (b) could appear at
some later point in time. In case (a) the manager could
try to create the object and in case (b) it could retry
to get the instance.

In case of issuing a GET on 1.3.6.1.2.1.1.1 (sysDescr) 
there is no _prefix_ matching an object in the agent,
because only the *whole* OID would match such an object.

Again, the purpose of the noSuchInstance exception is
to indicate that there could be such an instance in the
agent, but currently there isn't one. In both of the 
above cases, this is not the case.

Any objections?

Best regards,
Frank

"Fehde, Marcus" <Marcus.Fehde at draeger.com> schrieb am 08.10.2004,
09:56:40:
> Hi Frank,
> 
> I'm not really convinced. The 1.3.6.1.2.1.1.1 (sysDescr) as well as the 1.3.6.1.2.1.1.1.1 (sysDescr.1) containing valid matching prefixes to sysDescr. The first one matches with the object it self (w/o instance) and the later matches also and could access another instance than 0. Of course this is not allowed for a scalar object, but nevertheless the SNMP protocol does not distinguish between scalar and (conceptual) columnar and hence the appropriate reaction should be noSuchInstance.
> I would agree if I had requested 1.3.6.1.2.1.1 which is no matching prefix to any object.
> 
> Regards,
> Marcus
> 
> -----Original Message-----
> From: Frank Fock [mailto:fock at agentpp.com] 
> Sent: Freitag, 8. Oktober 2004 09:35
> To: Fehde, Marcus
> Cc: Agent++ Mailing List
> Subject: Re: [AGENT++] Wrong exeption in GET-response to unavailable object instance
> 
> 
> Hi Marcus,
> 
> OK, now I understand your question. The noSuchObject is returned, because 1.3.6.1.2.1.1.1 is a scalar. Thus, 1.3.6.1.2.1.1.1.1 could not potentially be an instance for 1.3.6.1.2.1.1.1 (sysDescr).  I think the bottom line of the quoted paragraph of RFC 3416 is "potentially".
> 
> Do you agree?
> 
> Best regards,
> Frank
> 
> Fehde, Marcus wrote:
> 
> >Hi Frank,
> >
> >Sorry I was imprecise and of course it was a noSuchObject exception. So 
> >again the question, why the agent do not response a noSuchInstance 
> >exception?
> >
> >-Marcus
> >
> >-----Original Message-----
> >From: Frank Fock [mailto:fock at agentpp.com]
> >Sent: Freitag, 8. Oktober 2004 00:11
> >To: Fehde, Marcus
> >Cc: agentpp at agentpp.org
> >Subject: Re: [AGENT++] Wrong exeption in GET-response to unavailable object instance
> >
> >
> >Hi Marcus,
> >
> >There are only three exception states in SNMPv2c and SNMPv3: 
> >noSuchObject noSuchInstance endOfMibView
> >
> >With SNMPv1 all of the above exception states are mapped to the 
> >NO_SUCH_NAME error status. AGENT++ does not return the NO_SUCH_NAME 
> >error for SNMPv2c and SNMPv3 as you pointed out. Therefore I assume, 
> >that either you used SNMPv1 for the GET request or you used an 
> >AGENT++Win32 master agent in conjunction with a MS subagent DLL.
> >
> >Unfortunately, those DLLs do not return proper error codes.
> >
> >Hope this helps.
> >
> >Best regards,
> >Frank
> >
> >Fehde, Marcus wrote:
> >
> >  
> >
> >>Hi,
> >>
> >>may be I discovered a non-compliance to RFC 3416 regarding the
> >>exception in case of an unavailable object instance.
> >>Example:
> >>An GET-request to 1.3.6.1.2.1.1.1.0 works as expected.
> >>An GET-request to 1.3.6.1.2.1.1.1 result in a "no-such-name" exception as well as
> >>an GET-requesz to 1.3.6.1.2.1.1.1.1.
> >>
> >>Accordingly to RFC3416 the correct result would be an
> >>"no-such-instance" exception:
> >>
> >>RFC3416 (SNMPv2); pp. 10-11 states:
> >>"Upon receipt of a GetRequest-PDU, the receiving SNMP entity processes 
> >>each variable binding in the variable-binding list to produce a 
> >>Response-PDU.  All fields of the Response-PDU have the same values as 
> >>the corresponding fields of the received request except as indicated 
> >>below.  Each variable binding is processed as follows:
> >>  
> >>...
> >>  
> >>(2)  Otherwise, if the variable binding's name does not have an  
> >>OBJECT IDENTIFIER prefix which exactly matches the OBJECT  IDENTIFIER 
> >>prefix of any (potential) variable accessible by  this request, then 
> >>its value field is set to "noSuchObject".
> >>  
> >> (3)  Otherwise, the variable binding's value field is set to
> >>"noSuchInstance".
> >>
> >>Please, can someone verify this.
> >>
> >>Best regards/Mit freundlichen Gruessen
> >>
> >>Marcus Fehde
> >>Dipl. Ing. Technische Informatik (FH)
> >>
> >>Research & Development
> >>Business Unit Anaesthesia
> >>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> >>
> >>DRÄGER MEDICAL
> >>
> >>Dräger Medical AG & Co. KGaA
> >>Moislinger Allee 53-55
> >>D-23542 Lübeck 
> >>
> >>Tel:  + 49-451-882-3646
> >>Fax: + 49-451-882-4410
> >>E-mail: marcus.fehde at draeger.com 
> >>www.draeger-medical.com 
> >>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
> >>
> >>
> >>
> >> 
> >>
> >>----------------------------------------------------------------------
> >>-
> >>-
> >>
> >>_______________________________________________
> >>AGENTPP mailing list
> >>AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
> >> 
> >>
> >>    
> >>
> >
> >
> >  
> >
> >-----------------------------------------------------------------------
> >-
> >
> >_______________________________________________
> >AGENTPP mailing list
> >AGENTPP at agentpp.org http://agentpp.org/mailman/listinfo/agentpp
> >  
> >