Subject: Re: Heads Up - New Notification Log MIB Draft

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 18 Dec 1998 01:19:59 +0100

>>>>> wkenneth  writes:

wkenneth> OwnerIndex I think is currently 32 octets. 

There is currently only something I would call a name index with the
idea that owner information is encoded into the name, perhaps
separated from the 'real' name with a special character.

wkenneth> So it can take up to 33 of the 128 maximum
wkenneth> subidentifiers. Would a second be defined with a max length
wkenneth> of 32 or would the original OwnerIndex be made smaller? In
wkenneth> the first case 66 of the 128 subidentifiers would be
wkenneth> taken. In the second case I'm not sure if the two would be
wkenneth> defined with a max length of 16 octets each or some other
wkenneth> distribution used. But in any case more subidentifiers would
wkenneth> be used. 

My point is that there is no real difference if I use

   5.'a'.'d'.'m'.'i'.'n'.5.'e'.'x'.'p'.'r'.'1'

or 

   11.'a'.'d'.'m'.'i'.'n'.'-'.'e'.'x'.'p'.'r'.'1'

Both instance identifier have the same length on the wire. Your
comment above refers to the maximum length allowed for these instance
identifiers. Even the worst case above (66 subidentifier) still fits
well into the overall limit of 128 subidentifier.

wkenneth> I also agree with Bob's comment about increased
wkenneth> agent/subagent complexity. There is also increased overall
wkenneth> MIB complexity whenever an additional index element is
wkenneth> added.

I claim that the complexity is the same with regard to the message
sizes exchanged in a agent/subagent environment. Whether two indexes
are more complex than a single index with some special overloaded
meanings really depends on your toolkit, the design of your internal
data structures and the processing you have to perform on the values.

wkenneth> I haven't heard this discussed before but I have ran across
wkenneth> some MIBs (SMTP related I think) where the maximum length of
wkenneth> all indexes into a table can exceed 128 subidentifiers. I
wkenneth> think there where words that said basically that the 128
wkenneth> limit existed and that it was up to the user and/or
wkenneth> implementor of the MIB to worry about it. This approach
wkenneth> seems wrong to me but I would like to here what others
wkenneth> think.

I agree with you that this is bad (probably better called illegal) MIB
design. The SNMP specs are pretty clear what the limit is and using
something outside of these limits will cause interoperability
problems.

wkenneth> Another consideration is that I'm not sure if the folks that
wkenneth> actually will administer SNMP security/access will want the
wkenneth> capability to provide the level of control that one or more
wkenneth> SnmpAdminString indexes gives you. My feeling is that most
wkenneth> would be happy to be able to use USM/VACM as it is and limit
wkenneth> access based on read only views and read-write views using
wkenneth> the table OID. Most network/system administrators that I've
wkenneth> talked with seem to be over worked. Their organizations
wkenneth> seems to be getting smaller and/or getting more work. Not
wkenneth> sure they would have the time to administer complex
wkenneth> configurations even if they wanted to.

DISMAN MIBs control complex management functions - the Script MIB even
allows to install new management functions on the fly. This is very
different from many of the classic MIBs. And you really want to have
finer grained access control - being able to make sure that nobody
even accidentally modifies a critical script will be necessary in
order to survive.

wkenneth> A single ownerIndex does do more then enhance VACM
wkenneth> access. It identifies the entity that created (owns) a
wkenneth> row. I prefer using a SnmpAdminString for this then using an
wkenneth> arbitrary integers to distinguish between rows.

I fail to see how this statement is related to this thread. But I tend
to agree (if you replace ownerIndex with name index). ;-)

							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)

---

From: [email-masked]
Date: Thu, 17 Dec 1998 18:30:07 -0500

>Just to be very clear on this: The difference between using
>"structured names" as suggested by Bob and using explicit owner
>strings and names is a single subidentifier. And if people start to
>put a delimiting character between the owner part and the name part in
>a "structured name" (and there are good reasons to do so - see the
>DISMAN meeting minutes), the number of subidentifiers used is actually
>identical.

OwnerIndex I think is currently 32 octets. So it can take up to 33 of the
128 maximum subidentifiers. Would a second be defined with a max length of
32 or would the original OwnerIndex be made smaller? In the first case
66 of the 128 subidentifiers would be taken. In the second case I'm not
sure if the two would be defined with a max length of 16 octets each or
some other distribution used. But in any case more subidentifiers would be
used. I also agree with Bob's comment about increased agent/subagent
complexity. There is also increased overall MIB complexity whenever
an additional index element is added.

I haven't heard this discussed before but I have ran across some MIBs (SMTP
related I think) where the maximum length of all indexes into a
table can exceed 128 subidentifiers. I think there where words that
said basically that the 128 limit existed and that it was up to
the user and/or implementor of the MIB to worry about it. This approach
seems wrong to me but I would like to here what others think.

Another consideration is that I'm not sure if the folks that actually will
administer SNMP security/access will want the capability to provide the
level of control that one or more SnmpAdminString indexes gives you.
My feeling is that most would be happy to be able to use USM/VACM as
it is and limit access based on read only views and read-write views
using the table OID. Most network/system administrators that I've talked
with seem to be over worked. Their organizations seems to be getting
smaller and/or getting more work. Not sure they would have the time to
administer complex configurations even if they wanted to.

A single ownerIndex does do more then enhance VACM access. It identifies
the entity that created (owns) a row. I prefer using a SnmpAdminString
for this then using an arbitrary integers to distinguish between rows.

Ken