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

["ietfdbh" <[e-mail]>]

Hi,

Some historical connect:

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.

Re: normative

I think this module can be deprecated without any reference to natv2.
I think having a reference to natv2 is useful (and informational).
I believe this relationship is not normative because the nat-mib can be
implemented without implementing natv2-mib.
The nat-mib can likewise be deprecated without implementing the natv2-mib.

David Harrington
[e-mail]
[phone]

> -----Original Message-----
> From: Behave [mailto:[e-mail]] On Behalf Of Benoit Claise
> Sent: Monday, June 08, 2015 9:41 AM
> To: The IESG
> Cc: [e-mail]; [e-mail];
> [e-mail]; [e-mail]; Spencer
> Dawkins; [e-mail]
> Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-
> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)
> 
> Benoit Claise has entered the following ballot position for
> draft-perrault-behave-deprecate-nat-mib-v1-01: 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:
> ----------------------------------------------------------------------
> 
> 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.
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> 
> _______________________________________________
> Behave mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/behave