Re: DS MIB - please review this list...

[Fred Baker <fred@cisco.com>]

At 04:46 PM 3/2/2001 +0100, Juergen Schoenwaelder wrote:
>You are asking what the benefit is of having the discriminating
>InetAddressType object registered directly before the InetAddress
>object (the union). The benefit here is that an application can
>(whether that is an agent code generator or a generic manager) can
>identify the discriminating InetAddressType for a given InetAddress
>union automatically.
>
>(a) I don't care about this because my tools are not going to take
>     advantage of it anyway.

I observe that for everything else in any MIB, one has to understand the 
object being managed in order to correctly manage it, and that involves 
understanding the MIB. I don't see any difference in this case.

Let's look carefully at this particular case, in order to understand it. I 
want to, let's say, install a filter that identifies some stream of 
traffic. In setting up such a filter, we need to set up a classifier 
content entry, which means that we will get the following information from 
the user:

     diffServSixTupleClfrId           Unsigned32,
     diffServSixTupleClfrDstAddrType  InetAddressType,
     diffServSixTupleClfrDstPrefixLength InetAddressPrefixLength,
     diffServSixTupleClfrDstAddr      InetAddress,
     diffServSixTupleClfrSrcAddrType  InetAddressType,
     diffServSixTupleClfrSrcPrefixLength InetAddressPrefixLength,
     diffServSixTupleClfrSrcAddr      InetAddress,
     diffServSixTupleClfrDscp         DscpOrAny,
     diffServSixTupleClfrProtocol     Unsigned32,
     diffServSixTupleClfrDstL4PortMin InetPortNumber,
     diffServSixTupleClfrDstL4PortMax InetPortNumber,
     diffServSixTupleClfrSrcL4PortMin InetPortNumber,
     diffServSixTupleClfrSrcL4PortMax InetPortNumber,
     diffServSixTupleClfrStatus       RowStatus

In order to fill in diffServSixTupleClfrId, we will read 
diffServSixTupleClfrNextFree, which gives us the value of the next 
available classifier ID. The RowStatus Variable will, of course, also be 
handled per its TC.

The four InetPortNumbers may or may not be written; if the value of 
diffServSixTupleClfrProtocol     is 6 (TCP) or 11 (UDP), the ports are 
meaningful, otherwise they are not. And in any event, even if they are 
meaningful, we may not choose to install them, or any of the other 
variables - the filter may be matching all TCP traffic, or all traffic to a 
given destination, or all traffic from a given CIDR Prefix, or any 
combination of other factors.

We will then build a diffServClfrElementEntry, which will link the 
classifier into the router or switch's packet classification tables. In 
other words, we will set up the objects:

     diffServClfrElementId          Unsigned32,
     diffServClfrElementClfrId      Unsigned32,
     diffServClfrElementPrecedence  Unsigned32,
     diffServClfrElementNext        RowPointer,
     diffServClfrElementSpecific    RowPointer,
     diffServClfrElementStatus      RowStatus

In so doing, we will read diffServClfrElementNextFree in order to figure 
out what the value of diffServClfrElementId should be, and then point the 
new diffServClfrElementEntry at the diffServSixTupleClfrEntry we just 
built. We will also inspect the diffServClfrTable to find an appropriate 
value for diffServClfrElementClfrId. We will decide whether the classifier 
we are building is ambiguous or deterministic; if it is ambiguous, we will 
set diffServClfrElementPrecedence appropriately in order to disambiguate 
it. And we will link it into a chain of other filters, which means that we 
will set some other classifier's diffServClfrElementNext to point to it, 
and set this classifier's diffServClfrElementNext to {0 0}. And again, the 
RowStatus Variable will also be handled per its TC.

Of course, one cannot automatically know any of this; this is something the 
MIB defined, and which the MIB application writer will have to sort out.

Now, one could build this all using a MIB Browser. The network manager 
would (of course) spend the time to read the MIB and understand that he has 
to read diffServClfrElementNextFree and diffServSixTupleClfrNextFree, and 
then do separate SETs to three different entries. And somewhere in the 
course of that, he would of course know that he had to say twice that the 
header he was looking at was an IPv6 header, so therefore the addresses in 
it are IPv6 addresses - the part that you are so adamant that he must do, 
for the ease of building an automated application. That application would 
last in the real world perhaps a few seconds - the amount of time it would 
take the network manager to realize what he was looking at, shrug, and walk 
away.

Or, a network management vendor that actually wanted to do something useful 
would embed all that into an application that simply asked the user

         are you filtering an IP6 packet or an IPv4 packet?
         What destination address or prefix, if any?
         What DSCP if any?
         What source address or prefix, if any?
         What IP Protocol, if any?
                 If that was TCP/UDP, what destination port range if any?
                 If that was TCP/UDP, what source port range if any?

In all probability, he would do that using a web form which put up

         choice selector for IPv4 vs IPv6, defaulting to IPv4
         choice selector for "what protocol is this", defaulting to "any 
protocol"
         fill-in-the-blank that defaulted to "no DSCP specified"
         two columns of fill-in-the-blank:
             one for source address, prefix length, and port
             one for destination address, prefix length, and port

It would do the rest of the job invisibly. It would do all of the steps I 
called out above, but do so "under the hood".

Which application would you use? If you were building one, which would you 
build? If you were buying one, which would you buy?

How many times did the application that you chose ask you about the 
InetAddressType? In the whole scheme of the operation, what effect did the 
fact that the InetAddressType was specified once or twice have on it? What 
effect did the fact that InetAddressType preceded InetAddressPrefixLength 
preceded InetAddress in the enumeration of the entry have one anything? 
What did any given optimization or other such rule actually buy you?

Listen. This is not about cute tricks that an application might use in some 
semi-automated way. It is not about heavy-handed nonsense about whether I 
am willing to abide by rules or not. It is not about whether I am willing 
to have an extra name in the entry. It is about building real applications 
for real people to use in real networks. If you're going to design rules 
into MIBs and TCs, you have to think not about what is cute in a cerebral 
world of what might be, but what's actually useful in the real world. MUSTs 
should be used when they tell you "if you don't do this, the thing won't 
work", not when you have trick you think is cute.

If we were smart enough to have type/value pairs (CHOICEs) in our 
abstraction of ASN.1, I would say "of course, send a typed value". That 
would make an incredible lot of sense, and the lack of permission to use 
CHOICE and compound objects has been among my criticisms of SNMP for a 
decade. But we don't have those, and we're not that smart. Given what we 
have, the application designer does NOT build automagic MIB manipulators, 
he builds a MIB application in the NMS and in the Agent specific to what is 
being controlled.

You only have to say you are looking at an IPv4 or IPv6 header once. Having 
said that, you know the type of every address you will encounter.

Your MUST in this regard adds no value. None. None whatsoever. It instead 
displays a total disconnect from the application designer's reality, and 
from the network operator's reality.

And by the way, if you *are* going to have the MUST, there has got to be a 
simpler way to say it than

             An InetAddressPrefixLength value is always interpreted
             within the context of an InetAddressType value. The
             InetAddressType only object or InetAddressType with
             InetAddress objects which define the context must be
             registered immediately before the object which uses the
             InetAddressPrefixLength textual convention. In other
             words, the object identifiers for the InetAddressType
             object and the InetAddressPrefixLength object MUST
             have the same length and the last sub-identifier of
             the InetAddressType object MUST be 1 less than the
             last sub-identifier of the InetAddressPrefixLength
             object and MUST be 2 less than the last sub-identifier
             of the InetAddressPrefixLength object if an InetAddress
             object is defined between InetAddressType and
             InetAddressPrefixLength objects.

How about something like:

"The objects defining the InetAddressType, InetAddressPrefixLength, and 
InetAddress are an ordered set; if present, they MUST be enumerated in the 
Entry containing them in exactly that sequence."

I read your paragraph above several times before deciding that what it 
meant is what I set forth in my proposed text.