Re: [BEHAVE] WGLC on draft-ietf-behave-nat-mib

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Jul 10, 2013 at 03:52:00PM +0200, Simon Perreault wrote:
> Le 2013-05-31 15:47, ietfdbh a écrit :
> > 1) A while back, I suggested that, if you are deprecating all of the NAT-MIB
> > in rfc4008, that it would be better to do this as a separate document from
> > the NEW-NAT-MIB (or whatever the new module gets called). Simon asked me to
> > get consensus from the MIB Doctors.
> > 
> > I checked with the MIB Doctor list, and only got one reply - from Juergen,
> > who apparently recommended a single document. His response:
> > " I have probably been pushing them into this because at the beginning it
> > was not really clear why the existing NAT-MIB is fatally flawed such that it
> > needs a complete replacement. If the behave WG has meanwhile reached
> > consensus that indeed the existing NAT-MIB is fatally flawed and needs a
> > complete replacement, then indeed what you suggest makes sense. I assume the
> > WG has checked with those who have implementations of the existing NAT-MIB
> > (if any) that they agree on a need for a complete new MIB."
> 
> I'm having trouble parsing this.
> 
> Our position, and we feel we have the consensus of the WG with us, is
> that the existing NAT-MIB is fatally flawed and we need a complete
> replacement. The reasons are explained in section 3.1.
> https://tools.ietf.org/html/draft-ietf-behave-nat-mib-06#section-3.1
> 
> That's why we initially started with a brand new MIB, called the
> NEW-NAT-MIB. We changed into the current structure based on feedback
> from the working group in general and Juergen in particular.

As far as I recall, it was initially not clear whether there is
consensus that the NAT-MIB is fatally flawed. (And the text that is
now in section 3.1 did not exist at that time in the current level of
detail as far as I recall.)

I suggest a consensus call is made by the chairs on this fundamental
question. If there is consensus that the NAT-MIB is fatally flawed
(and note that opinions of implementors in particular matter here),
then declaring the MIB module in RFC 4008 historic (e.g. marking RFC
4008 historic) and creating a new MIB module may indeed be the right
thing to do.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>