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

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Fred Baker writes:

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

I somehow have had trouble to identify what the core of your argument
really was. Your last email was helpful - at least I think that I
better understand what the core of your issues are.

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

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

So far, I do not see any argument.

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

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

I have to go back to the requirement we tried to address when we wrote
RFC 2851. We can then try to see whether you agree/disagree with the
requirement. If you agree with the requirement, we can discuss whether
the text in RFC 2851 is a good solution or whether things can be
improved. Once we have done that, we can discuss whether MUST or
SHOULD is appropriate.

The requirement we felt important to address is to (a) make it
possible to find algorithmically the discriminator for the union and
(b) to define some stricture so that MIB authors end up doing things
in ways that protect them from making mistakes which e.g. make later
extensions of tables with new objects impossible. Just forget about
what is in RFC 2851 right now (which you obviously do not like) and
take a moment to look at this requirement alone. Can you generally
agree that this is a good thing?  (If not, use one of your templates
to show me the flaw. ;-)

If you generally agree with the requirement, then the next thing is to
discuss solutions which address them. What is in RFC 2851 certainly
does address these requirements, but it requires in some cases to have
some additional redundant MIB objects. You have discussed this in some
depth below:

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

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

I see your point, although your argument about IEEE 802 MAC Address or
IPX Address is pointless since InetAddress does and will not cover
those.  But I still see what you are trying to say.

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

Well, you are now trying to find other rules to address the
requirement. Is the "must" in the last sentence a MUST or a SHOULD?
OK, let me comment on your proposal. Your rule above does not require
that the InetAddressType is registered before the InetAddress if you
have only one InetAddress or multiple InetAddress objects of the same
type. This is flawed. Lets assume you have a table which has a single
InetAddress and InetAddressType, registered in precisely that
order. This is legal according to your proposal.  Later, the MIB gets
revised and people add new objects to this table. The situation can
arise that the new objects contain another InetAddress of a different
type, so suddenly they have to comply to your rule above, but they
can't change the registration order of the original InetAddress and
InetAddressType pair anymore.

Please note that I did try to come up with alternate rules to satisfy
the requirements in an email I wrote on Fri, 2 Mar 2001 16:46:16
+0100:

: (b) I do agree that there are at least some benefits, but I am not
:     willing to pay the price of an additional column or index
:     component in cases where you have multiple InetAddress objects of
:     the same InetAddressType. Perhaps a slightly improved set of rules
:     would make me feel happier (e.g. just require that the
:     discriminating object is the last InetAddressType registered
:     before the InetAddress - which I think would handle the diffserv
:     filter case).

You never commented on this one. This rule I think addresses the
requirements, it adds flexibility in cases where you have only
addresses of the same type, and it does not have the flaw I have
outlined in your proposal above.

Well, to be honest, even this rule only works if new objects are only
appended to those already registered. If you have holes in the
registration, you can still construct cased where you can screw things
up. So one could argue that this rule is also flawed - but these are
really artifically constructed cases. Anyway, please note that the
rules in RFC 2851 even handle this case. (This issue would go away if
the rule quoted above also requires that there are no registration
gaps between the InetAddressType and InetAddress objects that refer to
that address type.)

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

As Bill already pointed out, this is not really what we wanted to say.
Again, with my proposed relaxed rule (b) above, we would just say that
the address type discriminating object is the last InetAddressType
registered before the InetAddressPrefixLength object.

Fred> I also gave you an argument in the specific case:

[...]

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

To summarize my position right now:

- I still believe in the following requirements

  (a) it must be possible to find algorithmically the discriminator
      for the union and
  (b) there must be some stricture so that MIB authors end up doing
      things in ways that protect them from making mistakes which make
      later extensions of tables with new objects impossible

- I believe RFC 2851 fulfills these two requirements.

- I see that in some cases, people want to be able to use multiple
  InetAddress objects of the same InetAddressType without having an
  InetAddressType for each.

- I personally would not mind to replace the current rules with new
  ones that do (a) and (b) at least for practically relevant MIB
  updates.

- I made a proposal how this might be done by relaxing the rules. The
  proposal still guarantees to work without surprises during "normal"
  MIB updates.

- I still believe the rules must be MUST so that automatic tools
  (whether these are code generators or MIB browsers) can rely on
  them.

/js

-- 
Juergen Schoenwaelder      Technical University Braunschweig
<schoenw@ibr.cs.tu-bs.de>  Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289    Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax:   +49 531 391 5936    <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>