Subject: just stop now

From: Glenn Mansfield <[email-masked]>
Date: Fri, 11 Dec 1998 19:51:35 +0900 (JST)

Mike,
  ==   Background:
  ==
  ==     0. The IRR provides is an essential component that supports
  ==        Internet operation.
  ==
  ==>> Strongly asserted by some, not remotely true to the degree
  ==asserted
I will let the RPSL/IRR experts respond to that.
  ==
  ==     1. The IRR information a very rich and useful source of information
  ==        for network management. Applications of mapping and fault
  ==        management are coming up. Some examples  were shown at the
  ==        IETF-RPS-WG@Chicago.
  ==
  ==>> ibid.
It is for the people who are using it to develop applications to say that.
We are using it for network configuration and fault management. And, there
is NO alternative to the information in the IRR.
  ==
  ==     2. Presently there is no standard interface for accessing the IRR
  ==        information.
  ==
  ==>> unclear this is a problem that needs solving
I'll explain. My application needs to ask the IRR which AS is announcing
network 130.34/16  Or,  what is the policy dictated route from  150.80/16
to 130.34/16. There are tools for doing this - whois based, telnet based
etc. But there is no standard interface.
  ==
  ==     3. Since Management applications will use this information, SNMP
  ==        should be considered as one of the access mechanisms. That
  ==        calls for designing of MIBs
  ==
  ==>> inventive, but a dubious assertion for a number of reasons
  ==many useful things do not have MIBs, and having a MIB does not
  ==make it useful
??
Because "many useful things do not have MIBs" it is dubious ?
Having a MIB would make it useful as the management application would
use the same SNMP interface or protocol to access the information -
that is dubiuos ?
  ==
  ==   Proposal:
  ==     There is a proposal for three MIBs
  ==
  ==     IRR-Query MIB to query the IRRd for information that will
  ==     potentially be used  by management applications (as-info,
  ==     administrative info, connectivity info, route info etc.).
  ==     We are very keen about this MIB. And I admit that this MIB will
  ==     be of greater interest to network management folks and application
  ==     developers/designers.
  ==
  ==>> Have any operational network management efforts actually
  ==requested this in this form, or is this a "it would be a good thing
  ==for completeness" assertion?
  ==
You must have missed the Chicago RPS-WG and the minutes. Please refer to
that. And to see the developments this area you can access
       http://peco.nemoto.tohoku.ac.jp/IPAMaps
  [ You need a JDK1.1.5 compliant browser to view the applications]

  ==     IRR-MIBd MIB to monitor the IRRd application. The database, its
  ==     components, size, accesses, errors, security violations etc. etc.
  ==     All from a standard management interface. It requires a small
  ==     extension to the Network Service Minitoring MIB.
  ==     IMHO any application of importance should be SNMP-monitorable.
  ==>> there are general app monitoring MIBs already in progress. show why
  ==this is better and not just different.

Which MIB would you recommend?
The generic Application Management MIB(draft-ietf-applmib-mib-11.txt) MAY
be used along with the System Application MIB (RFC 2287) for management.
But these will not provide any information on the peculiarities of the IRR.
The IRR IS distributed and has (presently 5 ? ) multiple components. There 
are no MIBs defined to treat this genre of applications. [The other distributed 
application that comes to mind is the Directory Server MIB - but that does 
not quite fit the bill]

  ==
  ==     IRR-MIB: To access raw IRR info and possibly update too (using
  ==     SET). SNMPv3 security mechanism may be used.
  ==     This is not our primary interest. As far as applications are
  ==     concerned it will not make any difference whether SNMP is
  ==     used to manage the IRR or not.
  ==
  ==>> this is just silly. SNMPv3 is many things, but it is not a
  ==database query language and trying to implement same as a MIB
  ==is just ludicrous.
OK! OK! I will withdraw that one. Using SNMP for  practical management
sounded silly  and  ludicrous  at one stage. And then people started
using MIBs in Toasters and Coffee makers too :-)

Cheers

Glenn

---

From: Steve Heimlich <[email-masked]>
Date: Fri, 11 Dec 1998 10:41:23 -0500

While it looks like this may be headed off the table, I'll second Mike's
objection to what I view to be a force fit of SNMP here.  A somewhat
general DB query and access mechanism is required and there are probably
better models existing than SNMP.

Steve

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 11 Dec 1998 10:41:38 -0500

Glenn,

The MIB is not a work group item.  You can submit the draft as an
individual submission for consideration as informational.  Be advised
that AFAIK none of the organizations that are currently producing
software to be used as an repository server plan to write a MIB client.

Curtis