Subject: RE: TE MIB Indexes

From: "Natale, Robert C (Bob)" <[email-masked]>
Date: Tue, 29 May 2001 15:55:45 -0400

Hi Atmesh,

Index values must either be "known" a priori or discovered.
You can discover index values either via notifications (per
your comments below) or, more typically, via a GetNext walk
starting with some value preceding the first legal value for
the given index.  Often, a GetNext table "walk" is performed
to build a set of usable index values for a given instance
of a management app.

Let me know if that is unclear or seems problematic to you.

Thanks,

BobN

> -----Original Message-----
> From: AtmeshSrivastava [mailto:[email-masked]]
> Sent: Friday, May 25, 2001 4:05 PM
> To: [email-masked]; [email-masked]
> Subject: TE MIB Indexes
> 
> 
> Hi,
> In the TE Mib, for the TE Tunnel Table the Max Acess of the indexes is
> Accessible For Notify which means that these indexes are 
> generated only
> in the case of a trap event . Now for Snmp support how do you perform
> set , get and get next operation.
> Well in my Opinion only when you get the indexes through the trap you
> can use them to get the values of the other leaf variables for that
> particular index , that means you cannot do  a get next operation .The
> sameis applicable for the set operation .
> Please clarify on these issues as soon as possible.
> 
> Regards,
> Atmesh
> Software Engineer
> Multitech Software Systems India (p) Ltd
> 
> 
>

---

From: Hans Sjöstrand <[email-masked]>
Date: Wed, 30 May 2001 10:19:38 +0200

Bob,

You are perfectly true, but in this case there is actually a bug in the 
mib which is kind of confusing. Indexes SHALL always be "not-accessible", 
see section 7.7 in RFC1902. Making them "accessible-for-notify" breaks 
the SMI for SNMPv2 and upsets my compiler (although it's recoverable). 

The reason I guess is to include the objects in the notifications, but 
including auxiliary objects in notifications are cosidered bad practice
(exept for that it violates SMI) since the objects have the same value as
the OID itself. 

So, Tom et.al 

The auxiliary objects mplsTunnelIndex, mplsTunnelInstance, 
mplsTunnelIngressLSRId, mplsTunnelEgressLSRId should be removed
from the notifications (their values are anyway carried in the 
mplsTunnelAdminStatus) and the objects should be made not-accessible
in the mplsTunnelTable. 

Else you won't get the mib through either a compiler nor IESG ;-) 

Regards
/// Hasse

> From: [email-masked] [mailto:[email-masked]]On Behalf Of Natale,
> Robert C (Bob)
> Sent: den 29 maj 2001 21:56
> To: AtmeshSrivastava
> Cc: [email-masked]
> Subject: RE: TE MIB Indexes
> 
> 
> Hi Atmesh,
>