Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-02: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Fri, 12 Jun 2015 07:25:47 -0700

Benoit Claise has entered the following ballot position for
draft-perrault-behave-deprecate-nat-mib-v1-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Updated based on version 2.

- Jouni's feedback.
* There is also no text about operational and management implications
  related to deprecation process of the old MIB and migrating to the
  new (to be approved) NAT-MIB-v2).

Inserting a few lines that there are not implementations (as mentioned by
Dave H.) would be sufficient.
Dave's messages copied here for your convenience:
The NAT-MIB was designed largely to be a NAT configuration MIB, back when
it
was hoped the security features of snmpv3 would make configuration using
snmp more tenable.
In reality, the complexity of snmpv3 security, and the continuation of
snmp
being listed as a top-ten vulnerability, discouraged people from moving
to
it quickly, and the other difficulties of snmp led to Netconf being
started,
and SNMP being identified a reasonable choice for monitoring, but not
configuration.
So the nat-mib was overtaken by events related to IETF management
protocols.

RFC4008 was treated as an individual submission after the NAT WG closed,
and
it was reviewed by the MIDCOM WG.
The IESG questioned whether NAT-MIB should be an IETF standard, because
the
official IETF stance at the time of IESG review  was "NATs are bad; use
IPv6".
See comments for RFC4008. 
So RFC4008 never had strong support from the IETF community.

Other technologies for working with NATs, such as STUN and TURN and ICE,
were already gaining traction by the time the nat-mib was approved.
I think Jon Peterson was one of the transport ADs at the time, and
working
for a service provider that used NATs. 
I recall him saying when the mib module was approved that he was glad
the
MIB work was finally completed so the community could focus on USEFUL
approaches to nats and stop dealing with the NAT-MIB module.
So the NAT-MIB was overtaken by NAT-related events even before its
approval.

NATs have had so many varieties, the behave WG was created to try to get
all
the various NAT approaches to work together better.
The configuration approach of the nat-mib only addressed a subset of
available NATs.
So the nat-mib never got much implementation support, and the behave WG
checked and found few implementations.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- I wanted to check this condition in RFC4181:

   - On the other hand, the module name MUST NOT be changed (except to
     correct typographical errors), existing definitions (even obsolete
     ones) MUST NOT be removed from the MIB module, and descriptors and
     OBJECT IDENTIFIER values associated with existing definitions MUST
     NOT be changed or re-assigned.

A word expressing that all RFC 4008 MIB objects are included in this
version, but with only the STATUS changed to deprecated would be
helpful.

EDITORIAL

* change the copyright date to 2015

* Unused Reference: 'RFC4787' is defined, but no reference was found
  in the text.

* SNMP acronym is the first time used in Section 1 unexpaned. The
  acronym is expanded later in Section 2. Expand it already in
  Section 1.