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

[Ballot comment]
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.

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

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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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:

[Ballot discuss]
This ballot is based on version 1 (I understand that v2 is on its way, waiting for the secretariat to post)

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

See the discussion captured on the MIB-doctors list.

- Let me check something.
As noted by Jouni  in his OPS-DIR review,

    The smilint reports the following warnings:

    * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used
    * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used
    * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is never used
    * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used

My first reaction: it's normal because some objects are now deprecated (so not used any longer).
After some analysis ... When comparing the imports lines from RFC4008 and the ones from this draft, those 4 lines magically appeared in this draft. Why?
This asks the question: have you actually started your work from the MIB module extracted from RFC4008?

I started to file a DISCUSS on that very point. However, I was so bothered by this difference that I actually compared the MIB modules extracted from this draft and from RFC4008.
I see two occurences of this change: InetAddress (SIZE (4|16) versus InetAddress
Why?

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

[Ballot discuss]
This ballot is based on version 1 (I understand that v2 is on its way, waiting for the secretariat to post)

- Before deprecating the following textual conventions, have you checked that they are not used in any MIB modules?

NatProtocolType ::= TEXTUAL-CONVENTION
          STATUS      deprecated
          DESCRIPTION
                  "A list of protocols that support the network
                  address translation.  Inclusion of the values is
                  not intended to imply that those protocols
                  need to be supported.  Any change in this
                  TEXTUAL-CONVENTION should also be reflected in
                  the definition of NatProtocolMap, which is a
                  BITS representation of this."
          SYNTAX  INTEGER {
                        none (1),  -- not specified
                        other (2), -- none of the following
                        icmp (3),
                        udp (4),
                        tcp (5)
                    }

  NatProtocolMap ::= TEXTUAL-CONVENTION
          STATUS      deprecated
          DESCRIPTION
                  "A bitmap of protocol identifiers that support
                  the network address translation.  Any change
                  in this TEXTUAL-CONVENTION should also be
                  reflected in the definition of NatProtocolType."
          SYNTAX  BITS {
                    other (0),
                    icmp (1),
                    udp (2),
                    tcp (3)
                  }

  NatAddrMapId ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS deprecated
          DESCRIPTION
                  "A unique id that is assigned to each address map
                  by a NAT enabled device."
          SYNTAX  Unsigned32 (1..4294967295)

  NatBindIdOrZero ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS deprecated
          DESCRIPTION
                  "A unique id that is assigned to each bind by
                  a NAT enabled device.  The bind id will be zero
                  in the case of a Symmetric NAT."
          SYNTAX  Unsigned32 (0..4294967295)

  NatBindId ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS deprecated
          DESCRIPTION
                  "A unique id that is assigned to each bind by
                  a NAT enabled device."
          SYNTAX  Unsigned32 (1..4294967295)

  NatSessionId ::= TEXTUAL-CONVENTION
          DISPLAY-HINT "d"
          STATUS deprecated
          DESCRIPTION
                  "A unique id that is assigned to each session by
                  a NAT enabled device."
          SYNTAX  Unsigned32 (1..4294967295)

  NatBindMode ::= TEXTUAL-CONVENTION
          STATUS deprecated
          DESCRIPTION
                  "An indication of whether the bind is
                  an address bind or an address port bind."
          SYNTAX  INTEGER {
                        addressBind (1),
                        addressPortBind (2)
                  }

  NatAssociationType ::= TEXTUAL-CONVENTION
          STATUS deprecated
          DESCRIPTION
                  "An indication of whether the association is
                  static or dynamic."
          SYNTAX  INTEGER {
                        static (1),
                        dynamic (2)
                  }

  NatTranslationEntity ::= TEXTUAL-CONVENTION
          STATUS      deprecated
          DESCRIPTION
                  "An indication of a) the direction of a session for
                  which an address map entry, address bind or port
                  bind is applicable, and b) the entity (source or
                  destination) within the session that is subject to
                  translation."
          SYNTAX  BITS {
                    inboundSrcEndPoint (0),
                    outboundDstEndPoint(1),
                    inboundDstEndPoint (2),
                    outboundSrcEndPoint(3)
                  }

This is currently in discussion with the MIB doctors (draft authors are copied)
At the very minimum, a note in an "operations considerations" section, explaining the implications of removing TCs, is required

- This point above is in line with 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).

- Let me check something.
As noted by Jouni  in his OPS-DIR review,

    The smilint reports the following warnings:

    * mibs/NAT-MIB:15: [5] {import-unused} warning: identifier `DisplayString' imported from module `SNMPv2-TC' is never used
    * mibs/NAT-MIB:27: [5] {import-unused} warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used
    * mibs/NAT-MIB:33: [5] {import-unused} warning: identifier `InetAddressPrefixLength' imported from module `INET-ADDRESS-MIB' is never used
    * mibs/NAT-MIB:36: [5] {import-unused} warning: identifier `VPNIdOrZero' imported from module `VPN-TC-STD-MIB' is never used

My first reaction: it's normal because some objects are now deprecated (so not used any longer).
After some analysis ... When comparing the imports lines from RFC4008 and the ones from this draft, those 4 lines magically appeared in this draft. Why?
This asks the question: have you actually started your work from the MIB module extracted from RFC4008?

I started to file a DISCUSS on that very point. However, I was so bothered by this difference that I actually compared the MIB modules extracted from this draft and from RFC4008.
I see two occurences of this change: InetAddress (SIZE (4|16) versus InetAddress
Why?

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

[Ballot comment]
- A point mentioned by Jouni that might be elevated to a DISCUSS (I let the security ADs decide):
* The Security Considerations does not really discuss the security
  implications of the _deprecation_ itself e.g. there is going to be
  boxes out there that use the old MIB and others that use the new
  (to be approved) MIB and what that mixed environment might entail.
  There is some text that is getting to that direction (SNMPv2 and
  SNMPv3 security differences).

* Since the new MIB is kind of requirement for replacing this old
  to be deprecated MIB, I would assume the draft-ietf-behave-nat-mib-v2
  to be a _normative_ reference in this document.

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.

[Ballot comment]
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?

[Ballot comment]
Oh, and I meant to ask: 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?

[Ballot discuss]
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]".

1. Summary

  The responsible Area Director is Spencer Dawkins, who is also
  acting as document shepherd.

  This memo deprecates MIB module NAT-MIB, a portion of the Management
  Information Base (MIB) previously defined in RFC 4008 for devices
  implementing Network Address Translator (NAT) function.  A companion
  document defines a new version, NAT-MIB-V2, which responds to
  deficiencies found in module NAT-MIB and adds new capabilities.

  This document obsoletes RFC 4008.

2. Review and Consensus

  The decision to deprecate NAT-MIB and obsolete RFC 4008 happened as
  part of discussion of draft-ietf-behave-nat-mib in the BEHAVE working
  group. That decision was not straightforward, and at least one of the
  reasons was that if NAT-MIB had NOT been deprecated, the working group
  would have had to figure out what parts of NAT-MIB were still relevant,
  how to use NAT-MIB and NAT-MIB-V2 in a single network, and (best of all)
  how to bring the security considerations for NAT-MIB up to current
  practices. Given that much of Section 3.1 is describing most of NAT-MIB as
  unusable because implementations varied so widely on writability,
  what configuration parameters are exposed, support for interfaces, and
  poorly-defined NAT service types, that didn't seem like a good use of
  anyone's time.
 
  This draft was split out of the draft that defined NAT-MIB-V2, as a
  result of a suggestion by David Harrington, coming out of a MIB-Doctor
  review.
 
  It is an AD-sponsored draft, because the BEHAVE working group has been concluded.

3. Intellectual Property

  Each author has confirmed conformance with BCP 78/79. There are no IPR
  disclosures on the document.

4. Other Points

Notification list changed to simon.perreault@viagenie.ca, ssenthil@cisco.com, tom.taylor.stds@gmail.com, tina.tsou.zouting@huawei.com, behave@ietf.org, "Spencer Dawkins" <spencerdawkins.ietf@gmail.com> from simon.perreault@viagenie.ca, ssenthil@cisco.com, tom.taylor.stds@gmail.com, tina.tsou.zouting@huawei.com, behave@ietf.org

IESG/Authors:

IANA has reviewed  draft-perrault-behave-deprecate-nat-mib-v1-01.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA has questions about the IANA Considerations section of this document.

In the SMI Network Management MGMT Codes Internet-standard MIBsubregistry
of the Network Management Parameters registry located at:

http://www.iana.org/assignments/smi-numbers

IANA understands that this document obsoletes number 123 for "natMIB", which is
an existing entry.  The authors do not request any action of IANA.

IANA Question --> in other cases in this registry, when an entry is obsoleted, it is marked "OBSOLETE" in the registry. Should the entry 123 be so marked since this draft intends
to obsolete RFC4008?  Further, should the reference be updated to this draft?

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address Translators (NAT))) to Proposed Standard


The IESG has received a request from an individual submitter to consider
the following document:
- 'Deprecation of MIB Module NAT-MIB (Managed Objects for Network Address
  Translators (NAT))'
  as Proposed
Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-04-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This memo deprecates MIB module NAT-MIB, a portion of the Management
  Information Base (MIB) previously defined in RFC 4008 for devices
  implementing Network Address Translator (NAT) function.  A companion
  document defines a new version, NAT-MIB-V2, which responds to
  deficiencies found in module NAT-MIB and adds new capabilities.

  This document obsoletes RFC 4008.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-perrault-behave-deprecate-nat-mib-v1/ballot/


No IPR declarations have been submitted directly on this I-D.