Re: Diffs in the Hardaker and Perkins Drafts

>>>>> On Mon, 23 Sep 2002 18:18:31 -0700, "David T. Perkins" <[email protected]> said:

[Sorry for the delay.]

David> The other point was that I wanted to be able to specify columns
David> from related tables in the same request. For example, columns
David> from the IF table and the Ethernet extension table (filter on
David> ifType = Ethernet).  Wes's proposal didn't support this because
David> it allowed the iteration order to be determined by the agent on
David> each table, and, thus, the iterration order for the IF table
David> and the Ethernet extensions table could be different. When
David> different, it would be too expensive for the agent to do a
David> "join" to put them back together to return a row in the
David> resulting "projection".

In summary, one of 2 things will happen if you request two identically
indexed tables within one protocol op with my OOPS proposal (issues
of things happening while the agent is looking for data not discussed):

1) you'll get both tables back in the response, with the same data
   ordering because that's how the agent did it on it's side.  I'd
   even bet that this would be the most common (99%) case.

2) you'll get them back in a different order because the agent didn't
   store them in the same way on the agent's side.

#1 isn't a problem for anyone, and #2 is where I don't think I wanted
to impose the burden on the poor-little-old-agent.

If you really think it's necessary, maybe we could put in an optional
method of attempting joins by carefully specifying a column number as
a CHOICE { int, oid } where something would reference an external
column.  That would fit your requirements for joins, but I still think
we should force agent's to support it and it should be optional.

-- 
Wes Hardaker
Network Associates Laboratories