Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'This memo deprecates MIB module NAT-MIB, a portion of the Management Information Base (MIB) previously defined …
Received changes through RFC Editor sync (changed abstract to '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, NATV2-MIB, which responds to deficiencies found in module NAT-MIB and adds new capabilities.

This document obsoletes RFC 4008. All MIB objects specified in RFC 4008 are included in this version unchanged with only the STATUS changed to deprecated.')
2015-10-27
06 (System) RFC published
2015-10-16
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2015-10-15
06 Suresh Krishnan Request for Last Call review by GENART Completed: Ready. Reviewer: Suresh Krishnan.
2015-10-14
06 (System) Notify list changed from simon.perreault@viagenie.ca, ssenthil@cisco.com, tom.taylor.stds@gmail.com, tina.tsou.zouting@huawei.com, behave@ietf.org, "Spencer Dawkins"  to behave@ietf.org
2015-10-02
06 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2015-09-28
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-08-19
06 (System) RFC Editor state changed to EDIT from MISSREF
2015-07-06
06 Tom Taylor IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-07-06
06 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-06.txt
2015-07-02
05 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2015-07-01
05 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2015-07-01
05 (System) IANA Action state changed to Waiting on Authors from In Progress
2015-06-29
05 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2015-06-28
05 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-05.txt
2015-06-25
04 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-06-25
04 (System) RFC Editor state changed to MISSREF
2015-06-25
04 (System) Announcement was received by RFC Editor
2015-06-24
04 (System) IANA Action state changed to In Progress
2015-06-24
04 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2015-06-24
04 Amy Vezza IESG has approved the document
2015-06-24
04 Amy Vezza Closed "Approve" ballot
2015-06-24
04 Amy Vezza Ballot approval text was changed
2015-06-24
04 Amy Vezza Ballot has been issued
2015-06-24
04 Amy Vezza Ballot writeup was changed
2015-06-24
04 Amy Vezza IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation - Defer::AD Followup
2015-06-24
04 Spencer Dawkins Ballot approval text was changed
2015-06-24
04 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-04.txt
2015-06-24
03 Benoît Claise
[Ballot comment]
Updated based on version 2.

- Jouni's feedback.
* There is also no text about operational and management implications
  related to deprecation …
[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.
2015-06-24
03 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2015-06-18
03 Tero Kivinen Closed request for Telechat review by SECDIR with state 'No Response'
2015-06-15
03 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-06-15
03 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-03.txt
2015-06-12
02 Benoît Claise
[Ballot discuss]
Updated based on version 2.

- Jouni's feedback.
* There is also no text about operational and management implications
  related to deprecation …
[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.
2015-06-12
02 Benoît Claise
[Ballot comment]
- I wanted to check this condition in RFC4181:

  - On the other hand, the module name MUST NOT be changed …
[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.
2015-06-12
02 Benoît Claise Ballot comment and discuss text updated for Benoit Claise
2015-06-11
02 Cindy Morgan IESG state changed to IESG Evaluation - Defer::Revised I-D Needed from IESG Evaluation - Defer
2015-06-11
02 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-06-11
02 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-06-10
02 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2015-06-10
02 Cindy Morgan Changed consensus to Yes from Unknown
2015-06-10
02 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2015-06-10
02 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2015-06-10
02 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2015-06-09
02 Kathleen Moriarty
[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 …
[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.
2015-06-09
02 Kathleen Moriarty [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty
2015-06-09
02 Ben Campbell
[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 …
[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.
2015-06-09
02 Ben Campbell [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell
2015-06-09
02 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2015-06-09
02 Joel Jaeggli
[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 …
[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:
2015-06-09
02 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-06-08
02 Tom Taylor IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2015-06-08
02 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-02.txt
2015-06-08
01 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2015-06-08
01 Benoît Claise
[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 …
[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.
2015-06-08
01 Benoît Claise Ballot discuss text updated for Benoit Claise
2015-06-08
01 Benoît Claise
[Ballot discuss]
This ballot is based on version 1 (I understand that v2 is on its way, waiting for the secretariat to post)

- Before …
[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.
2015-06-08
01 Benoît Claise
[Ballot comment]
- A point mentioned by Jouni that might be elevated to a DISCUSS (I let the security ADs decide):
* The Security Considerations …
[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.
2015-06-08
01 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2015-06-08
01 Barry Leiba
[Ballot comment]
The authors are already in the process of making the suggested changes below, and many thanks for considering my input.

---
The IANA …
[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?
2015-06-08
01 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2015-06-06
01 Barry Leiba
[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 …
[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?
2015-06-06
01 Barry Leiba Ballot comment text updated for Barry Leiba
2015-06-06
01 Barry Leiba
[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 …
[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]".
2015-06-06
01 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2015-06-05
01 Spencer Dawkins
1. Summary

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

  This memo deprecates MIB module NAT-MIB, …
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
2015-06-05
01 Spencer Dawkins
2015-06-05
01 Spencer Dawkins Document shepherd changed to Spencer Dawkins
2015-06-05
01 Tero Kivinen Request for Telechat review by SECDIR is assigned to Eric Osterweil
2015-06-05
01 Tero Kivinen Request for Telechat review by SECDIR is assigned to Eric Osterweil
2015-06-02
01 Tero Kivinen Closed request for Last Call review by SECDIR with state 'Withdrawn'
2015-05-26
01 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2015-05-26
01 (System) IANA Review state changed to IANA - Not OK from IANA OK - Actions Needed
2015-05-26
01 Benoît Claise Telechat date has been changed to 2015-06-11 from 2015-05-28
2015-05-26
01 Benoît Claise IESG state changed to IESG Evaluation - Defer from IESG Evaluation
2015-05-24
01 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for Writeup
2015-05-24
01 Spencer Dawkins Placed on agenda for telechat - 2015-05-28
2015-05-24
01 Spencer Dawkins Ballot has been issued
2015-05-24
01 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2015-05-24
01 Spencer Dawkins Created "Approve" ballot
2015-05-24
01 Spencer Dawkins Ballot writeup was changed
2015-04-29
01 (System) IESG state changed to Waiting for Writeup from In Last Call
2015-04-26
01 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Issues. Reviewer: Jouni Korhonen.
2015-04-24
01 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2015-04-24
01 Pearl Liang
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 …
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.
2015-04-05
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2015-04-05
01 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2015-04-02
01 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2015-04-02
01 Jean Mahoney Request for Last Call review by GENART is assigned to Suresh Krishnan
2015-04-02
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Eric Osterweil
2015-04-02
01 Tero Kivinen Request for Last Call review by SECDIR is assigned to Eric Osterweil
2015-04-01
01 Cindy Morgan IANA Review state changed to IANA - Review Needed
2015-04-01
01 Cindy Morgan
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 …
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.


2015-04-01
01 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2015-04-01
01 Spencer Dawkins Last call was requested
2015-04-01
01 Spencer Dawkins Ballot approval text was generated
2015-04-01
01 Spencer Dawkins Ballot writeup was generated
2015-04-01
01 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2015-04-01
01 Spencer Dawkins Last call announcement was generated
2015-04-01
01 Cindy Morgan This document now replaces draft-ietf-behave-nat-mib instead of None
2015-01-29
01 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-01-29
01 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-01.txt
2015-01-16
00 Spencer Dawkins IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2015-01-16
00 Spencer Dawkins IESG state changed to AD Evaluation from Publication Requested
2015-01-08
00 Spencer Dawkins State Change Notice email list changed to draft-perrault-behave-deprecate-nat-mib-v1.all@tools.ietf.org, simon.perreault@viagenie.ca, ssenthil@cisco.com, tom.taylor.stds@gmail.com, tina.tsou.zouting@huawei.com, behave@ietf.org
2015-01-08
00 Spencer Dawkins IESG process started in state Publication Requested
2015-01-07
00 Spencer Dawkins Shepherding AD changed to Spencer Dawkins
2015-01-07
00 Spencer Dawkins Intended Status changed to Proposed Standard from None
2015-01-07
00 Spencer Dawkins Stream changed to IETF from None
2015-01-07
00 Spencer Dawkins Stream changed to IETF from None
2014-10-19
00 Tom Taylor New version available: draft-perrault-behave-deprecate-nat-mib-v1-00.txt