Deprecation of MIB Module NAT-MIB: Managed Objects for Network Address Translators (NATs)
draft-perrault-behave-deprecate-nat-mib-v1-06

The authors are already in the process of making the suggested changes below, and many thanks for considering my input.

---
The IANA Considerations section says there are no IANA actions here.  Is that really so?  Don't you need to change the reference for the natMIB (123) from RFC4008 to this document?  Otherwise, what was the point of replicating the entire MIB and changing the status field of each item to "deprecated"?  It's clear that 4008 is no longer the current reference for natMIB.

I would actually suggest that you also change the description field for natMIB from "NAT-MIB" to "[deprecated]" or "NAT-MIB [deprecated]".

Do the Security Considerations, as written, really apply to this document?  Would it, perhaps, be more appropriate for these Security Considerations to say that this MIB Is entirely deprecated, and that the security considerations in draft-perrault-Behave-natv2-mib apply instead, to current nat MIBs?

I concur with Joel's comment about including the entire definition. I was rather surprised to find such a draft requires 57 pages.

I concur with Benoit's and Barry's comments that the security considerations aren't really the considerations for _this_ draft.

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

it seems a bit ridiculous to need to include the entire mib definition in order to state

3.1.  Deprecated Features

   All objects defined in [RFC4008] have been marked with "STATUS
   deprecated" for the following reasons:

I agree with Barry's last comment on the security considerations text.  SInce this draft has no security considerations, it doesn't need to point to the v2 draft for this work.  Either saying this draft has no considerations because it deprecates a mib is fine or say that the updated v2 covers security considerations for that nat mib.