Subject: [MIB-DOCTORS] General question on MIBs

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 1 Dec 2011 10:41:46 +0200

Hi Doctors,

This question has been bugging me for some time, hope you can shed some
light on it. 

The SMIv2 standard allows for either including INDEX objects as columnar
objects of the table, in which case they are called auxiliary objects,
or not going so. MIB compilers I have worked with allow both options.

I see that common practice in standard MIBs is to define INDEX objects
as auxiliary objects (except when they are "reused" from a different
table or MIB). 

My question is: what is the advantage of doing this? In any event
set/get operations will include the INDEX object as part of the OID, so
what is the advantage of having the INDEX object as a columnar object? 

Thanks in advance for your help,

Daniel

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Dec 2011 10:28:15 +0100

> what is the advantage of having the INDEX object as a columnar object? 

I am not sure I understand your question and this is likely due to
terminology confusion. Here is what RFC 2578 says:

a) Objects listed in INDEX clauses are always columnar objects. They
   may be columnar objects of the same table or a different table.
   (Section 7.7 of RFC 2578).

b) Section 7.7 of RFC 2578 also says that objects which are both
   specified in the INDEX clause of a conceptual row and also columnar
   objects of the same conceptual row are termed auxiliary objects.

So perhaps your question really is whether auxiliary objects should be
not-accessible. RFC 2578 is pretty clear about this:

   The MAX-ACCESS clause for auxiliary objects is "not-accessible",
   except in a few special cases.

(1)  within a MIB module originally written to conform to SMIv1, and
     later converted to conform to SMIv2; or

(2)  a conceptual row must contain at least one columnar object which is
     not an auxiliary object.  In the event that all of a conceptual
     row's columnar objects are also specified in its INDEX clause, then
     one of them must be accessible, i.e., have a MAX-ACCESS clause of
     "read-only".

What is the advantage of readable auxiliary objects? I guess the
answer is a) simple-minded SNMP implementations that are not capable
to extract values out of instance identifiers and b) the astonishing
amount of confusion out there how SNMP actually works.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Daniel Cohn" <[email-masked]>
Date: Thu, 1 Dec 2011 15:34:19 +0200

Hi Juergen, thanks for your response. Let me clarify my question with an
example. Let's say I want to define a conceptual table, fooTable that is
indexed by interface.

Then I can either:

1.- Reuse the ifIndex from the standard IF-MIB as follows:

IMPORTS
	ifIndex FROM IF-MIB
...

fooTable OBJECT-TYPE
	SYNTAX SEQUENCE OF FooEntry

fooEntry OBJECT-TYPE
	SYNTAX FooEntry
INDEX {ifIndex}

FooEntry
	SEQUENCE {
		object1	...
		object2	...
		}

2.- Define a new ad-hoc fooIfIndex object, just for this table, with the
same meaning as the standard ifIndex, i.e. the index of the interface to
which the table information applies, as follows:

fooTable OBJECT-TYPE
	SYNTAX SEQUENCE OF FooEntry

fooEntry OBJECT-TYPE
	SYNTAX FooEntry
INDEX {fooIfIndex}

FooEntry
	SEQUENCE {
		fooIfIndex	InterfaceIndex
		object1	...
		object2	...
		}

fooIfIndex	OBJECT-TYPE
	SYNTAX InterfaceIndex
	DESCRIPTION "The index of the interface to which objects in
fooTable apply"
	....

Take for example RFC 4836. Instead of defining a new ifMauIfIndex,
ifIndex could have been imported from IF-MIB. So my question is - is
there any difference? Is any of the approaches preferred?

Thanks again,

Daniel                

-----Original Message-----
From: Juergen Schoenwaelder
[mailto:[email-masked]] 
Sent: Thursday, December 01, 2011 11:28 AM
To: Daniel Cohn
Cc: [email-masked]
Subject: Re: [MIB-DOCTORS] General question on MIBs

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 1 Dec 2011 16:11:13 +0100

> there any difference? Is any of the approaches preferred?

Generally, there is no difference. In the case of ifMauIfIndex there
is a difference since ifMauIfIndex is read-only - so it is a separate
object with its own OID one can retrieve.

/js

---

From: "Flick, John W" <[email-masked]>
Date: Thu, 1 Dec 2011 23:16:59 +0000

The specific case of ifMauIfIndex, it falls under the special case 1 in the text that Juergen quoted earlier:

(1)  within a MIB module originally written to conform to SMIv1, and
     later converted to conform to SMIv2;

ifMauIfIndex was originally defined in RFC 1515, which was written to conform to SMIv1, and was converted to SMIv2 for RFC 2239 (later updated by 2668, 3535 and then 4836).  In SMIv1, auxiliary objects were normally defined as read-only.  The convention of defining them as not-accessible was introduced with SMIv2.

So ifMauIfIndex is read-only for historical reasons.  If we were defining this from scratch today, we would just import ifIndex.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
Sent: Thursday, December 01, 2011 7:11 AM
To: Daniel Cohn
Cc: [email-masked]
Subject: Re: [MIB-DOCTORS] General question on MIBs

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
_______________________________________________
MIB-DOCTORS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mib-doctors

---

From: "Daniel Cohn" <[email-masked]>
Date: Sun, 4 Dec 2011 20:34:19 +0200

Thanks a lot Juergen and John, this completely clarifies the point.

Regards,

Daniel

-----Original Message-----
From: Flick, John W [mailto:[email-masked]] 
Sent: Friday, December 02, 2011 1:17 AM
To: Juergen Schoenwaelder; Daniel Cohn
Cc: [email-masked]
Subject: RE: [MIB-DOCTORS] General question on MIBs

The specific case of ifMauIfIndex, it falls under the special case 1 in
the text that Juergen quoted earlier:

ifMauIfIndex was originally defined in RFC 1515, which was written to
conform to SMIv1, and was converted to SMIv2 for RFC 2239 (later updated
by 2668, 3535 and then 4836).  In SMIv1, auxiliary objects were normally
defined as read-only.  The convention of defining them as not-accessible
was introduced with SMIv2.

So ifMauIfIndex is read-only for historical reasons.  If we were
defining this from scratch today, we would just import ifIndex.

John

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Juergen Schoenwaelder
Sent: Thursday, December 01, 2011 7:11 AM
To: Daniel Cohn
Cc: [email-masked]
Subject: Re: [MIB-DOCTORS] General question on MIBs

/js