Subject: IRR-MIB

From: "Glenn Mansfield" <[email-masked]>
Date: Sat, 19 Sep 1998 19:32:06 +0900

Hi,
    Just to refresh one memory and for the benefit of those who did
not attend the RPS-WG@Chicago and did have a chance to look at
the minutes and ftp://ftp.isi.edu/rps/chicago-ietf/irrmib.pdf

    1. The IRR information is a very useful source of information for
        network management. Applications of mapping and fault
        management are coming up. Some examples  were shown.
    2. Presently there is no standard interface for accessing the IRR
       information.
    3. Since Management applications will use this information, SNMP
       should be considered as one of the access mechanisms. That
       calls for designing of MIBs

    There were three proposals for MIBs

    IRR-MIB: To access raw IRR info and possibly update too (using
    SET). SNMPv3 security mechanism may be used.
    General feeling of the house- lack of faith in SNMP-SET
    mechanism.
    For accessing raw information - there was some interest

    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. There was some interest.

    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.).
    There was good interest in this MIB.

As, Curtis has pointed out the IRR-MIB is a lot of work. We have done
some work on it. And, we agree that it is not a straight forward job.
Maybe it is too early for this piece of work.
The IRRd-MIB and the IRR-Query-MIB are relatively simple. We donot think
that this will consume much WG resources and it is
certainly not matter for another working group. In fact, we did think
that this was part of the RPS-WG-Charter (3rd work item) though it
isn't spelt out in so many words. In any case, if the charter needs to be
revised then, please be assured that by next IETF at Florida we will have
the draft IRRd-MIB and draft IRR-QUERY-MIB ready.  There
is some interest, no dearth of volunteers, so why dither ?

Cheers

Glenn

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 21 Sep 1998 12:01:17 -0400

In message <000101bde3b8$c1a2c700$110000c0@saraswati>, "Glenn Mansfield" writes
>     For accessing raw information - there was some interest

I sensed an open mindedness and willingness to listen but I recall a
request for raise of hands over whether this was considered "something
useful".  If I remember correctly there were few hands.

>     from a standard management interface. There was some interest.

These are Unix systems (actually most are BSD) and MIB have proven
quite useless in administering Unix systems.  I think there was clear
consensus on omiting this or making it a separate informational draft.

> is some interest, no dearth of volunteers, so why dither ?

Glenn,

I've been involved in this sort of routing policy system since 1992
back in the NSF PRDB days and I don't remember anyone in that entire
6+ year time period ever suggesting that a MIB would be needed to
access the routing registry until you proposed this MIB.  I can say
with certainty that nothing on the current charter was intended to be
a MIB definition.  We don't want to be closed minded and we gave you
audience in the WG meeting.  I specifically asked for a raise of hands
during your presentation.

The question is not whether a MIB is possible or a lot of work.  The
question is really whether a MIB is the right way to access the
registry.  I strongly feel that it is not.  I got the impression from
the current users of the IRR and those running registries that they
see no need, and the impression from the implementors that they see no
need for a MIB and had no current intention to support a MIB.

There is useful work for us to do, so I hesitate to take something on
that no one but you sees a need for, since it distracts people with
little or no gain.  If you want to make an individual submission and
pursue an informational draft to document your private implementation,
that's up to you.

My preference on this is that this should not be a WG item.  I haven't
heard anyone other than you express a preference that this be a work
item.  I've heard lack of strong objection, but I haven't heard anyone
state that this is needed or that it should be a WG item.  If a few
people speak up in favor of a WG item, then perhaps the best thing is
to take a mailing list vote.

Curtis