[BEHAVE] new nat mib question

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 19 June 2012 19:38 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: behave@ietfa.amsl.com
Delivered-To: behave@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F20E11E816A for <behave@ietfa.amsl.com>; Tue, 19 Jun 2012 12:38:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.168
X-Spam-Level:
X-Spam-Status: No, score=-103.168 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 9iXsMcT0iqsZ for <behave@ietfa.amsl.com>; Tue, 19 Jun 2012 12:38:30 -0700 (PDT)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6C211E8134 for <behave@ietf.org>; Tue, 19 Jun 2012 12:38:30 -0700 (PDT)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8C23B20BEF; Tue, 19 Jun 2012 21:38:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 7l43_BVFmjOy; Tue, 19 Jun 2012 21:38:29 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2983720BEE; Tue, 19 Jun 2012 21:38:29 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id F27D11FEFE34; Tue, 19 Jun 2012 21:38:27 +0200 (CEST)
Date: Tue, 19 Jun 2012 21:38:26 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: behave@ietf.org
Message-ID: <20120619193826.GA23555@elstar.local>
Mail-Followup-To: behave@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [BEHAVE] new nat mib question
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jun 2012 19:38:31 -0000

Hi,

I have come across the new NAT MIB <draft-ietf-behave-nat-mib-01> and
I am not sure I understand the scope of this effort and how the result
will relate to the existing NAT-MIB in RFC 4008. The behave I-D says:

   [RFC4008] defines some objects for managing network address
   translators (NATs).  Current operational practice often requires
   additional objects, in particular for enterprise and Internet service
   provider (ISP) deployments.  This document defines those additional
   objects.

   This module is designed to be completely independent from [RFC4008].
   A NAT implementation could be managed using this module, the one from
   [RFC4008], or both

The first paragraph sounds like the goal is to define additional
objects relative to the RFC 4008 NAT-MIB while the second paragraph
says quite clearly that this is going to a competing MIB module. If
so, this is, as far as I know, the first time we have two
standards-track MIB modules for managing a single technology. Can
someone explain what the goal of this effort is or point me somewhere
into the archives so I can inform myself? Note, it might very well be
that the RFC 4008 NAT-MIB is seriously broken but then the proper
approach would be to write a new MIB replacing the old MIB, sending
RFC 4008 to historic.  Otherwise, it should be explained somewhere how
the new MIB plays together with the NAT-MIB. (My background on this is
essentially written down in draft-schoenw-behave-nat-mib-bis-00.)

I also think NEW-NAT-MIB is not a good name. What is new today is
going to be old tomorrow.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>