Re: Some questions on the base sming document

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

Another example is that when translated to SNMP SMI the translator
might want to create more that one table due to indexing. For example,
consider stats for a "source" and "dest" MAC address. With the current
SNMP SMI, you need to create two tables that "have the same columns",
but with index clause reordered to be able to retrieve by (source:dest)
and by (dest:source).

Note: I haven't read the updated SMIng docs yet, so maybe this is solved. However, the identifying (or indexing) of instances is a key topic.
It has gotten much attention and work in the database arena, and
is important that a much better job be done than that found in
SNMP's SMI.

Regards,
/david t. perkins

At 06:13 PM 3/13/2001 +0100, Frank Strauss wrote:
>Hi!
>
>Joel> Thank you for the clear reply.
>Joel> On the issue of the ordering of "key" fields, the concern I have with
>Joel> a "should" is that I am not clear on how even a human being would know
>Joel> whether the fields are in the right order.  If we mandate that the
>Joel> fields are in significance order, then any translator (human or
>Joel> machine) can use that fact.
>
>I think, there could be situation where there is no single `right'
>order that is appropriate for all possible mappings.
>
>An example: Imagine the smRunTable of the DISMAN-SCRIPT-MIB would have
>been modeled as an SMIng class. Its `unique' statement would contain
>the elements { smLaunchOwner, smLaunchName, smRunIndex }. In SNMP
>mappings the order of these elements in the `index' clause would be
>significant wrt efficient list retrievals by owner or by name. Both
>could be useful.  Hence, it is difficult to say, which order of these
>elements is 100% right in the SMIng definition. But maybe in most
>cases, there's an order that the author estimates to be more useful
>than another.
>
>If a human or a compiler maps an SMIng `unique' clause to an SNMP
>mapping's `index' clause, and if there are no other conditions that
>would favor any variation, then the order should be kept unchanged.
>[should I cut&paste this sentence to the snmp mapping document? ;-)]
>
>
>Joel> If we do not require this, then even a human being who is translating
>Joel> will need to examine each listed attribute and confirm that they are
>Joel> in the proper order.  But, if the reader is going to have to do that
>Joel> anyway, then the most it is worth saying is "it can be helpful to the
>Joel> reader of this class if the fields are in significance order", which
>Joel> is even weaker than "should".
>
>I think this "should" is appropriate, because it says to the SMIng
>module author that he should (must?) regard the order as significant,
>if he favors a certain order of the elements' significance in most
>common use cases. As with any other piece of a module, further details
>should be specified in the related `description' texts.
>
>
>Joel> PS:  "Should" is always an interesting condition to use in our
>Joel> documents.  Sometimes, the receiver of the message can tell if the
>Joel> sender (in this case reader and writer) has abided by the "should",
>Joel> and therefore gets a benefit from the fact that most cases will follow
>Joel> the rule.  Sometimes there is a robustness benefit if most people
>Joel> follow the "should".  Otherwise, "should" is not much better than
>Joel> "may".  I suppose we could recomment that the description clause
>Joel> include a sentence as to whether the keys are in order, so that at
>Joel> least a reader has a clue?
>
>A reminder to give all relevant details in `description' clauses could
>be applied to each and every subsection. Instead I kept a note in another
>piece of text that could become a SMIng guidelines document some day
>(currently, it serves just as a very short reminder file to me. it's
>available at http://www.ibr.cs.tu-bs.de/projects/sming/):
>
>          <t hangText="Variations from `the SHOULD case': ">
>            In any case where a piece of a SMIng module violates
>            a rule from the SMIng specifications that SHOULD be
>            observed, the module author has to explain the reasons
>            and all relevant details with special care in the
>            related description clause.
>          </t>
>
>
>Joel>      The other side of this question is whether there is ever a need
>Joel> to violate this "should".  If there is never a good reason to put them
>Joel> in other than significance order, then just make it a MUST.
>
>Maybe. It was my feeling that in cases where a condition cannot be
>clearly determined, a `conditional must' does not help a further.
>
>
> -frank