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

[Fred Baker <fred@cisco.com>]

At 04:31 PM 3/5/2001 +0100, Juergen Schoenwaelder wrote:

> >>>>> Fred Baker writes:
>
>Fred> The InetAddress approach helps, in that people are on notice
>Fred> that they should be able to store a 16 byte address in one. It
>Fred> is not future-proof, however. If in the future we come up with
>Fred> an IPv17Address of 31 bytes, we are guaranteed to be storing the
>Fred> string in a fixed length container of 16 bytes. A variable
>Fred> length object would be better.
>
>InetAddress is of size (0..255) which will work just fine with 31 byte
>addresses (but not with 256 byte addresses).
>
>/js

Juergen, we are not communicating. I have just gone through this discussion 
from the top, and I don't think the list has answered my questions or my 
arguments. May be the issue is the form; let me give you a template for 
what I am looking for and let you fill in the blank.

I gave you a line of reasoning which says "you believe that a statement X 
is true. I believe that the statement X is false. In the general case, I 
believe X is false because _______. The specific case I am looking at is 
_______. In the specific case I am looking at, I believe that X is false 
because _______."

I am looking for something like one of the following from you. One possible 
answer is "you have convinced me that X is false; OK, here is what I 
propose that we do about it." A second is "I continue to believe that X is 
true. In the argument concerning the general case, the flaw in your 
argument is _______, and in the specific case that you proposed, the flaw 
in your argument is _______." A third is somewhere in between: "I continue 
to believe that X is true. In the argument concerning the general case, the 
flaw in your argument is _______, and while X may not be absolutely true in 
your specific case, in the specific cases _______, _______, and _______X is 
very obviously true because _______."


Let me repeat my arguments so that you can have them all in one place to 
review and respond to.

The statement I am concerned about is, to quote your email (which is much 
better worded thane the draft) "the InetAddressType/InetAddress pair is a 
kind of a discriminated union and that is why RFC 2851 says that the pair 
is always instantiated as a pair." In the case of the draft, I would assume 
that this also includes the InetAddressPrefixLength. Loosely quoted, the 
observation in the RFC and the draft is that "these MUST be encoded as an 
ordered set of attributes."

You argue in part that the MUST should not hinder me; it doesn't, and in 
the MIB in question the diffserv working group (ie your truly) has followed 
your must in its current Internet Draft. However, that is not my 
understanding of a correct use of the word "MUST". "It does it hinder you 
and I think it might be useful" is the supporting argument for noting a 
"MAY"; "I the designer think this is really important in most if not all 
cases" is the supporting argument for a "SHOULD". To me, "MUST indicates an 
absolute requirement of the specification" goes far beyond "the designer 
thinks this is important"; it means "the designer can show that something 
fundamental breaks when this is not observed." A TCP implementation MUST 
not renege on a window offered, because there are a number of indetermine 
states in the protocol exchange that happens if it does. A PPP 
implementation MUST support CHAP because that is the only way we have 
though of to convince vendors to address the market requirement for secure 
Internet access - theft of service results apart from that. I would be 
pleased if we put a MUST into an updated RFC 2179 or whatever that said 
"any use of the terms 'MUST' or 'MUST NOT' MUST be accompanied by a 
statement of the consequences of failure to observe it."

So the statement X is "these MUST be encoded as an ordered set of 
attributes; something fundamental breaks when this rule is not observed." 
Specifically, I asked "Can you argue the case for the stricture, generally 
or (better) in this application? "

I gave you an argument in the general case:

>A generic manager doesn't know that the type of the address object is 
>InetAddress apart from having read a MIB in; it otherwise looks like an 
>OCTET STRING. It therefore does not know to look at the object numerically 
>before in order to get the type, apart from having read in a MIB. If it 
>can read in a MIB, it can find the InetAddressType in the entry and 
>associate it with all of the InetAddress objects in the entry.

That statement leaves out an important bit of  context that was inherited 
from the previous part of the thread:  In a case where there is one IPvN 
address in the Entry, it is patently obvious which InetAddress is 
associated with which InetAddressType, because there is exactly one of 
each. In the multiple address case I am looking at, it is equally patently 
obvious. All of the InetAddresses in the entry are invariably of the same 
type, because they are filtering the same header and the IPv4/IPv6 header 
never mixes address families. You never send an IP packet to the Ethernet 
MAC Address of a device, and you never send it from your IPX Address, nor 
do you send it from your IPv6 address to one it its IPv4 addresses. By 
definition, you send it from your IPvN address to one of its IPvN addresses.

So it seems to me that there is only one reasonable case for the use of 
"MUST" - when there are multiple InetAddress objects and their types may 
vary. An acceptable compromise position might then be to rephrase the MIB 
as saying "In any Entry where there are multiple InetAddresses and they may 
reasonably differ in type in the same instance of the Entry, the 
InetAddressType object which defines the context must be registered 
immediately before the object which uses the InetAddress textual convention."

By the way, in that context, since you are adding InetAddressPrefixLength, 
you should reword it to take InetAddressPrefixLength into account: "...the 
InetAddressType object which defines the context must be registered 
immediately before the object which uses the InetAddress textual 
convention, or immediately before the InetAddressPrefixLength associated 
with that InetAddress if it is present."

I also gave you an argument in the specific case:

>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.

A summary of the specific argument is: "In this case, the addresses are 
invariably of the same type because they are represented in an IP header. 
The application therefore does not mandate using multiple IP Address types 
in the same filter. Generic applications other than MIB Browsing are not 
useful here, because what is involved in doing a SET is not generic in any 
sense, and a usable application that performs a SET would have to be 
written in a manner specific to the MIB."