[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I've inserted <bob> / </bob>'s below.


Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group

                      Wes Hardaker                                                                                                     
                      <hardaker@tislabs        To:       Robert Moore/Raleigh/IBM@IBMUS                                                
                      .com>                    cc:       eos@ops.ietf.org                                                              
                                               Subject:  Re: Generalizing element selection in Wes's -02pre OOPS draft                 
                      11/13/2002 08:02                                                                                                 

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


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

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.  <bob> I'm not sure I
      understand your point here.  If the management app isn't
      *guaranteed* aligned data, won't it have to do the alignment step
      every time, even if the data are in fact aligned?</bob>

   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.<bob>I was not thinking about this
      case, but I see your point.  The question in my mind is just
      how rare this case will be - has anyone actually encountered
      an agent that works this way?</bob>

   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
<bob>When we first looked at this, we were also thinking along the
lines of #2b.  The problem we encountered is that while it's clear
how this works for the request-element-list, it's harder to see how
it would work for search-criteria.  If you're ANDing, ORing, and
negating filter elements, it seems like you'd end up with each
element basically self contained: one table ID plus one column ID.
Once we saw this potential for multiple occurrences of the same
table OID, we decided we'd be better off ensuring that each table
OID appeared only once.

I also don't understand your comment about regaining compression.
In the single-table case, where there's only one table OID
involved, our proposal is, aside from one extra SEQUENCE OF tag,
exactly equivalent to yours.

Wes Hardaker
Network Associates Laboratories