>>>>> C M Heard writes: >> The problem is that mgmt applications either understand the >> semantics of a particular implementation or they will have to guess >> or ignore some rows.
Mike> I undestand that a management application may not have full Mike> understanding of route table entries without understanding the Mike> nature of the opaque identifier. But I don't follow why that Mike> implies that a management application has to ignore some rows -- Mike> at least if all it's doing is inspecting rather than modifying Mike> the rows. The proposed index components are destination prefix, Mike> opaque identifier, and next hop. I can still determine how many Mike> routes to a given destination via a particular next hop exist Mike> (and query their other properties) even if I don't know what the Mike> opaque identifier is. Well, it depends what you expect from a management application. If your manager is a MIB brower which just shows the data to a human, things are fine. If however the management application want to reason about the data (e.g. which route will a packet with destination A take), then a totally opaque value basically means that the application can not answer this question. /js -- Juergen Schoenwaelder <http://www.informatik.uni-osnabrueck.de/schoenw/> -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
