Subject: [BEHAVE] New NAT MIB vs RFC4008

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Jul 2012 15:55:56 -0400

WG,

For draft-ietf-behave-nat-mib, the most pressing thing we need to do is 
resolve the situation with regard to RFC4008. It looks to me like the 
best way forward is, as suggested by Dave Thaler, to merge our MIB with 
the one from RFC4008 and mark all the objects defined by RFC4008 with 
"STATUS deprecated". This would also solve the issue of naming because 
we could just drop the "new" prefix. Then we can tag our draft with 
"Obsoletes: 4008" and remove the paragraph about 4008 coexistence.

Unless the WG disagrees, I'll do this before the Monday deadline.

I will also remove the CGN-specific parts. They will hopefully progress 
in sunset4. Look for draft-perreault-sunset4-cgn-mib.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 10 Jul 2012 23:27:13 +0200

On Tue, Jul 10, 2012 at 03:55:56PM -0400, Simon Perreault wrote:
> WG,
> 
> For draft-ietf-behave-nat-mib, the most pressing thing we need to do
> is resolve the situation with regard to RFC4008. It looks to me like
> the best way forward is, as suggested by Dave Thaler, to merge our
> MIB with the one from RFC4008 and mark all the objects defined by
> RFC4008 with "STATUS deprecated". This would also solve the issue of
> naming because we could just drop the "new" prefix. Then we can tag
> our draft with "Obsoletes: 4008" and remove the paragraph about 4008
> coexistence.
> 

I first like to understand why RFC4008 is broken and why the new MIB
is significantly better. If RFC4008 is indeed unfixably broken, it
can be made historic and a new MIB can be produced. But this needs to
be properly documented. As such, I suggest to focus on writing concise
and clear text explaining why RFC4008 is so badly broken. And I would
of course would like to hear as well the voices of those who shipped
the RFC 4008 MIB in products.

/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/>

---

From: Simon Perreault <[email-masked]>
Date: Tue, 10 Jul 2012 18:43:50 -0400

On 07/10/2012 05:27 PM, Juergen Schoenwaelder wrote:
> and clear text explaining why RFC4008 is so badly broken.

Will do.

> And I would

FWIW, Juniper in particular not only shipped RFC 4008 but also extended it.

The fact that 4008 is present and used in the wild can be seen as one 
reason to mark stuff as deprecated rather than making the whole thing 
historic.

Simon