Re: Generalizing element selection in Wes's -02pre OOPS draft

[Wes Hardaker <hardaker@tislabs.com>]

>>>>> On Tue, 12 Nov 2002 13:44:06 -0500, Robert Moore <remoore@us.ibm.com> said:

Robert,

Sorry for the delay.  I was up against a deadline for publishing a
software reference release which I just succeeded in getting out.
Anyway,

Robert> The only way to deal with AUGMENTing tables in the current
Robert> draft is to treat them as entirely separate Request-Objects.
Robert> The problem with this approach is that the agent is free to
Robert> supply the responses for these Request-Objects in different
Robert> orders.  Lining data from the different tables back up in this
Robert> case is not impossible for the management application to do,
Robert> but it would clearly be preferable if it did not have to do
Robert> this.

A few points:

1) This was actually by design.  My thinking was that for augmented
   tables, one of the following is true:

   a) the tables implemented in the agent will be aligned and the
      data returned for the two different requests contained in the
      entire pdu will generate identically ordered responses.  Thus,
      neither the management app nor the agent needs to do alignment
      work.  Joining the two response portions in the PDU are trivial.
      I'd expect this to be the 90-99% case.
   
   b) The tables implemented in the agent are *not* data aligned (ie,
      the table information are stored independently and in a
      different order).  In this case, I was limiting the sorting that
      the agent had to do.  IE, if the manager needs it combined then
      the manager should do it (insert high-scale database technology
      only available in managers here).  This would generally be the
      minority case, I would think, but I can see situations where
      this could easily happen.

   Anyway, David Perkins I think agrees with you that joining of
   augmentation tables should be supported within the protocol
   directly.  Thus, I'm currently out voted at 2-1 unless you change
   your mind.  I'd love to hear other opinions on this subject.  I'm
   certainly not in strong opposition of making a change.

2) But, the change is actually not needed.  The support for what you
   want to do is sort-of-already-there.  In fact there used to be a
   comment describing how to do it, but I struck it before publication
   in deciding to stick with my original notion of #1 above.
   Specifically, the ElementSpecifier includes a multiple-subcomponent
   CHOICE which is:

   a) currently an OID.  This could easily be a pointer to a column
      from anther table.  This would thus alleviate the need to remove
      the base-oid from the main PDU and only makes duplicating the
      external table reference as needed.

   b) I'll try to publish a new draft shortly after the conference
      with a new ElementSpecifier containing a multiple-subcomponent
      specifier which will actually be something like:

      SEQUENCE {  sub-component OBJECT IDENTIFIER
                  sub-elements  ElementSpecifier }

      (and if we decide to support direct requesting of augmentation
      tables, I'll just change the name from "sub-component" to
      "related-component" or something.

      In short augmenting tables can be entirely specified within the
      ElementSpecifier, and doesn't require a higher level change to
      the parent PDU structure (IMHO, a good thing).

So, given all the above, what do you think now?  If we are to support
requesting of augmentation tables directly within a single request,
I'd rather do it through something like #2a/b which would not remove
the base-element OID from the original request, thus regaining some of
the compression and forced related-data strictness that your change
removed.

-- 
Wes Hardaker
Network Associates Laboratories