Re: [sidr] adopt a mib

Michael Baer <baerm@mikesoffice.com> Mon, 08 August 2011 18:31 UTC

Return-Path: <baerm@mikesoffice.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7198121F8BA4 for <sidr@ietfa.amsl.com>; Mon, 8 Aug 2011 11:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xtsQJdTh13Uu for <sidr@ietfa.amsl.com>; Mon, 8 Aug 2011 11:31:25 -0700 (PDT)
Received: from mail.mikesoffice.com (v6.mikesoffice.com [IPv6:2001:470:1f05:274::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D40C21F8B8F for <sidr@ietf.org>; Mon, 8 Aug 2011 11:31:21 -0700 (PDT)
Received: from localhost (rebma.ipv6.mikesoffice.com [IPv6:2001:470:1f05:274:d69a:20ff:feb8:b0b2]) by mail.mikesoffice.com (Postfix) with ESMTPSA id 84AF19DBFC; Mon, 8 Aug 2011 11:31:47 -0700 (PDT)
From: Michael Baer <baerm@mikesoffice.com>
To: raszuk@cisco.com
References: <m2d3gkepg8.wl%randy@psg.com> <4E3B8930.9090605@cisco.com> <4E3B8EB1.7030007@bwijnen.net> <4E3B9018.80808@cisco.com>
X-Face: "*g#dUT3; 8M9AE5dLk\\b4G\cNCQkRb.g/2QwEXQKf.:<GckOP:; wBMTb7\%Y"JI=R<M6g?6}tR)6Z7rp5X*24G\bkb!
Date: Mon, 08 Aug 2011 11:31:47 -0700
In-Reply-To: <4E3B9018.80808@cisco.com> (Robert Raszuk's message of "Thu, 04 Aug 2011 23:39:20 -0700")
Message-ID: <m3wrenhi0c.fsf@mikesoffice.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: sidr wg list <sidr@ietf.org>
Subject: Re: [sidr] adopt a mib
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Aug 2011 18:31:26 -0000

>>>>> On Thu, 04 Aug 2011 23:39:20 -0700, Robert Raszuk <raszuk@cisco.com> said:

    Robert> Hi Bert,
    Robert> Many thx for your comment .. I was not able to stay at the IETF till
    Robert> the SIDR session.

    Robert> If that is the case the draft-ymbk-bgp-origin-validation-mib is just
    Robert> completely not ready for adoption until it contains bare minimum which
    Robert> will allow operators to use it.

    Robert> It would be insane to list 1 million of valid prefixes as opposed to
    Robert> little fraction of them being in question. Whoever authored that draft
    Robert> needs to develop a bit more real network operational experience :)

Hi Robert,

I am co-editing the MIB and was the person that originally put most of
the MIB into SMI form.  Major flaws in the original MIB design are going
to be mostly due to me.  My SNMP background is much greater than my
routing knowledge, and I'm sure it shows (not shockingly, no network
operator experience).  I expected and hoped to get feedback on what was
wrong with the MIB and how it could be improved.

I do look at WG at adoption criteria differently.  I can see your point
of view.  But I generally look on adoption as whether a document/MIB is
useful, and appropriate for a particular WG and not whether the first
version of the doc/MIB is ready, with just minor adjustment, to be coded
and used.

But regardless of WG adoption, I am curious whether you think these MIBs
would be useful to have, not in the current state, but in a closer to
ideal state?

And please give as much feedback as you can,

Thanks,
Mike


    Robert> Best regards,
    Robert> R.

    >> During the discussion at the SIDR WG session at IETF81 we
    >> found that the bgpVRTValid attribute in that table makes no
    >> sense, because we do not have that info. These are ALL
    >> validated ROAs (or better validated prefixes) as I understand
    >> it.
    >> 
    >> Bert
    >> On 8/5/11 8:09 AM, Robert Raszuk wrote:
    >>> Hi,
    >>> 
    >>> Just looking at draft-ymbk-bgp-origin-validation-mib may I ask what
    >>> would be the root OID string to start SNMP tree walk (or set the trap)
    >>> to list all INVALID or NOT_FOUND BGP entries ?
    >>> 
    >>> Rgs,
    >>> R.


    Robert> _______________________________________________
    Robert> sidr mailing list
    Robert> sidr@ietf.org
    Robert> https://www.ietf.org/mailman/listinfo/sidr


-- 
Michael Baer
baerm@mikesoffice.com