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

[Benoit Claise <[e-mail]>]

Thanks Dave for the background information.
 From this, I draw two conclusions:
- RFC 4008 not implementated. Taking into account the MIB doctor 
discussion about the deprecated versus obsolete Textual Conventions, I 
removed the TC point from my DISCUSS (done already +/- 4 hours ago, so 
you should have received an updated DISCUSS.
- you convinced me that the reference doesn't have to be normative.

Thanks, Benoit
> 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
> .
>