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

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


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