[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Generalizing element selection in Wes's -02pre OOPS draft
Wes,
I've inserted <bob> / </bob>'s below.
Regards,
Bob
Bob Moore
Advanced Design and Technology
Application Integration Middleware Division
IBM Software Group
+1-919-254-4436
remoore@us.ibm.com
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
PM
>>>>> 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. <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
removed.
<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.
</bob>
--
Wes Hardaker
Network Associates Laboratories