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

["Benoit Claise" <[e-mail]>]

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.