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

From: "Benoit Claise" <[email-masked]>
Date: Mon, 08 Jun 2015 06:41:17 -0700

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.

---

From: "ietfdbh" <[email-masked]>
Date: Mon, 8 Jun 2015 13:15:20 -0400

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
[email-masked]
+1-603-828-1401

> -----Original Message-----
> From: Behave [mailto:[email-masked]] On Behalf Of Benoit Claise
> Sent: Monday, June 08, 2015 9:41 AM
> To: The IESG
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Spencer
> Dawkins; [email-masked]
> Subject: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-
> deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)
> 
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Jun 2015 21:18:48 +0200

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 15 Jun 2015 11:22:55 -0400

I'm cleaning up this document and responding to particular open points. 
The main change to the document itself is to add the following sentences 
to the Security Considerations section. I will also review Jouni's 
comments to make sure they are all covered.

"Amongst other matters, these considerations cover the case where both 
this MIB module and NAT-MIB-V2 are present. In fact, such a situation is 
unlikely because <xref target="RFC4008"/>, as a MIB module oriented 
toward configuration, was overtaken by events and saw little 
implementation."

Tom

> Thanks Dave for the background information.
...
>>>    new (to be approved) NAT-MIB-v2).

[PTT] Covered in the v2 document.

...
>>> I see two occurences of this change: InetAddress (SIZE (4|16) versus

[PTT] To get rid of a SMILINT warning about potentially excessive number 
of sub-identifiers.

...

>>> version, but with only the STATUS changed to deprecated would be
[PTT] Added in the Abstract.

"All RFC 4008 MIB objects are included in this version unchanged with 
only the STATUS changed to deprecated, with a non-substantive exception. 
The exception was to retype internet addresses with a
(SIZE (4|16) qualification to get rid of a SMILINT warning."

...

---

From: Benoit Claise <[email-masked]>
Date: Mon, 22 Jun 2015 08:51:24 +0200

Thanks Tom,
...
> [PTT] Covered in the v2 document.
Can you please let me know which text addresses my DISCUSS.
https://www.ietf.org/rfcdiff?url2=draft-perrault-behave-deprecate-nat-mib-v1-02

Also, for the copyright and date, I was referring to the MIB description:

             DESCRIPTION
                     "This MIB module defines the generic managed objects
                      for NAT.

                      Copyright (C) The Internet Society (2014).  This
                      version of this MIB module is part of RFC yyyy; see
                      the RFC itself for full legal notices."

Regards, Benoit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 22 Jun 2015 12:39:50 -0400

Hi, Tom,

Just keeping up ...

>                  the RFC itself for full legal notices."

These are the remaining points for Benoit's Discuss on this document, is
that correct?

Thanks,

Spencer

---

From: Tom Taylor <[email-masked]>
Date: Tue, 23 Jun 2015 16:34:43 -0400

Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, 
it can be fixed in AUTH48.

Reviewing the IESG evaluation, I note the suggestion to leave out the 
MIB module definition itself and just have text saying (as Joel 
suggested) that all objects are deprecated. Would people agree to that? 
That would eliminate my fiddling with syntax to eliminate SMILINT warnings.

Regarding the Discuss: the Security Considerations section currently reads:

   "All objects in this MIB module have been deprecated.  As a result,
    security considerations in [I-D.ietf-behave-nat-mib-v2] apply
    instead.  Amongst other matters, these considerations cover the case
    where both this MIB module and NAT-MIB-V2 are present.  In fact, such
    a situation is unlikely because [RFC4008], as a MIB module oriented
    toward configuration, was overtaken by events and saw little
    implementation."

Was this too condensed?

Tom

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jun 2015 10:50:58 +0200

Hi Tom,
> suggested) that all objects are deprecated. Would people agree to 
> that? That would eliminate my fiddling with syntax to eliminate 
> SMILINT warnings.
>
Not what I was expecting, but I guess it does the job to clear the 
DISCUSS. Clearing now.

Regards, Benoit

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jun 2015 06:26:21 -0400

>> Reviewing the IESG evaluation, I note the suggestion to leave out the
MIB module definition itself and just have text saying (as Joel suggested)
that all objects are deprecated. Would people agree to that? That would
eliminate my fiddling with syntax to eliminate SMILINT warnings.

So, two questions -

- is the issue that changing the definition while deprecating the objects
is strange?

- if the document just said "all objects are deprecated", would the
resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave the syntax
unchanged, and point out that the syntax generates SMILINT warnings whether
the objects are deprecated or not, but since all this document is doing is
deprecating objects, the syntax is left unchanged, and anyone who
implements the V1 MIB now will have bigger problems than the SMILINT
warnings, but I don't know that's the right answer.

DISCUSS. Clearing now.

Thank you, of course.

Spencer

---

From: Benoit Claise <[email-masked]>
Date: Wed, 24 Jun 2015 14:10:23 +0200

Dear all,
>
>
> On Jun 24, 2015 04:51, "Benoit Claise" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> > Hi Tom,
> >
> >> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright 
> thing, it can be fixed in AUTH48.
> >>
> >> Reviewing the IESG evaluation, I note the suggestion to leave out 
> the MIB module definition itself and just have text saying (as Joel 
Forgot to reply to this one.
I believe the draft makes sense as done right now.
People might want to extract all MIB modules from RFC and load them all.
This way, they would directly see in their MIB browser that the MIB 
objects are deprecated.

Regards, Benoit
>
> So, two questions -
>
> - is the issue that changing the definition while deprecating the 
> objects is strange?
>
> unchanged, and point out that the syntax generates SMILINT warnings 
> whether the objects are deprecated or not, but since all this document 
> is doing is deprecating objects, the syntax is left unchanged, and 
> anyone who implements the V1 MIB now will have bigger problems than 
> the SMILINT warnings, but I don't know that's the right answer.
>
> >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >>>
> >>>>   Thanks Tom,
> >>>> ...
> >>>>
> >>>>

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Jun 2015 11:16:58 -0400

Below with [PTT]

> - is the issue that changing the definition while deprecating the objects

[PTT] Yes, per guidelines quoted by Benoit.
> resulting MIB modules still produce SMILINT warnings?

[PTT] Yes. I just verified that RFC 4008 generates the following warnings
mibs/NAT-MIB:932: [5] {index-exceeds-too-large} warning: index of row 
`natAddrBindEntry' can exceed OID size limit by 141 subidentifier(s)
mibs/NAT-MIB:1162: [5] {index-exceeds-too-large} warning: index of row 
`natAddrPortBindEntry' can exceed OID size limit by 143 subidentifier(s)
...

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Jun 2015 11:18:55 -0400

OK, our messages crossed. I will take no further actions other than 
making sure the copyright date is fixed.

Tom

...

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jun 2015 11:21:10 -0400

So, I think we're finishing up here ...

On Wed, Jun 24, 2015 at 8:10 AM, Benoit Claise <[email-masked]> wrote:

>  Dear all,
>
>
> On Jun 24, 2015 04:51, "Benoit Claise" < <[email-masked]>
> [email-masked]> wrote:
> >
> > Hi Tom,
> >

So, that makes sense to me.

The related question was whether the syntax popping up SMILINT warnings was
OK for someone who did that - as I understand it, the syntax in the objects
being deprecated would generate the same warnings, without the changes Tom
had proposed.

Could you clue me in?

Thanks!

Spencer

p.s. Tom, when Benoit answets this question, the only other point I'm aware
of was 2014 copyright dates in the object definitions. I would be more
comfortable sending the RFC Editor a draft version that they don't have to
fix and we don't have to check in AUTH48. Could you spin a version with the
copyright date fix, plus whatever you and Benoit converge on re: syntax?

> >>> On Mon, Jun 22, 2015 at 2:51 AM, Benoit Claise < <[email-masked]>
> [email-masked]> wrote:
> >>>
> >>>>   Thanks Tom,
> >>>> ...
> >>>>
> >>>>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jun 2015 11:23:40 -0400

Hi, Tom,

On Wed, Jun 24, 2015 at 11:18 AM, Tom Taylor <[email-masked]>
wrote:

> OK, our messages crossed. I will take no further actions other than making
> sure the copyright date is fixed.

And double-crossed :-)

Could you submit a version of the draft with the copyright date fix, and I
can send an approval note for that?

Spencer

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Jun 2015 11:38:53 -0400

Done.

Tom

...

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 24 Jun 2015 18:07:17 -0400

+1

As a MIB Doctor, I am not sure it would be “legal” per RFC2578 to alter the status of the objects without re-publishing the object definition.

I have not researching the “legal” arguments thoroughly, but I think it would not be “legal”.

As a (past) implementer of network management software, I think it is important that an NMS can import the current status of each object from the MIB database “schema” into the local database format being used internally. An RFC that simply says “all these objects are deprecated” doesn’t meet the requirements of that situation.

David Harrington

 <mailto:[email-masked]> [email-masked]

+1-603-828-1401

From: Benoit Claise [mailto:[email-masked]] 
Sent: Wednesday, June 24, 2015 8:10 AM
To: Spencer Dawkins at IETF
Cc: [email-masked]; [email-masked]; The IESG; Jouni Korhonen; ietfdbh; Tom Taylor; Tina Tsou
Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-deprecate-nat-mib-v1-01: (with DISCUSS and COMMENT)

Dear all, 

On Jun 24, 2015 04:51, "Benoit Claise" <[email-masked]> wrote:
>
> Hi Tom,
>
>> Yes, I believe so. If the RFC Ed. doesn't pick up the copyright thing, it can be fixed in AUTH48.
>>
>> Reviewing the IESG evaluation, I note the suggestion to leave out the MIB module definition itself and just have text saying (as Joel suggested) that all objects are deprecated. Would people agree to that? That would eliminate my fiddling with syntax to eliminate SMILINT warnings.

Forgot to reply to this one.
I believe the draft makes sense as done right now.
People might want to extract all MIB modules from RFC and load them all.
This way, they would directly see in their MIB browser that the MIB objects are deprecated.

Regards, Benoit

So, two questions - 

- is the issue that changing the definition while deprecating the objects is strange?

- if the document just said "all objects are deprecated", would the resulting MIB modules still produce SMILINT warnings?

Obviously, I'm wondering if the right answer is to leave the syntax unchanged, and point out that the syntax generates SMILINT warnings whether the objects are deprecated or not, but since all this document is doing is deprecating objects, the syntax is left unchanged, and anyone who implements the V1 MIB now will have bigger problems than the SMILINT warnings, but I don't know that's the right answer.

> Not what I was expecting, but I guess it does the job to clear the DISCUSS. Clearing now.

Thank you, of course.

Spencer

---

From: "ietfdbh" <[email-masked]>
Date: Wed, 24 Jun 2015 18:18:44 -0400

I recommend leaving the object definitions unchanged, except for the status clause. I think some of the SMILINT rules were not set when RFC4008 was published. The consensus of the MIB Doctors wasn't "set" until RFC4181, and SMILINT both helped drive the consensus, pre-4181, and automates the consensus, post-4181.

RFC2578 recommends explaining in each description clause why the object is deprecated.
I personally feel that having one statement in the module-identity explaining the deprecation could suffice, this discussion is running parallel to the discussion of why we need to change the status in each object and re-publish. Given that the per-object deprecation is important so an NMS can import that information, it would be helpful to operators to look at the imported deprecated object and see the description of why it was deprecated (Some NMS's bring up the object definition/description as a sort of man-page for each object, so an operator doesn't need to hunt down the info in RFCs while fighting network fires. So I think it would be justified to put an explanation into each object description. 

I would be satisfied with a textual reference to the NAT-V2-MIB and a REFERENCE clause to the new RFC, in each deprecated object. This would make for a normative reference, I think.

David Harrington
[email-masked]
+1-603-828-1401
> From: Tom Taylor [mailto:[email-masked]]
> Sent: Wednesday, June 24, 2015 11:17 AM
> To: Spencer Dawkins at IETF; Benoit Claise
> Cc: [email-masked]; [email-masked]; The IESG; Jouni Korhonen; ietfdbh;
> Tina Tsou
> Subject: Re: [BEHAVE] Benoit Claise's Discuss on draft-perrault-behave-
> whether

---

From: Tom Taylor <[email-masked]>
Date: Wed, 24 Jun 2015 18:30:39 -0400

OK, if others accept this, I guess I have one more editing pass. And I 
should close out all the issues I set up inb the issue tracker.

Tom

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Wed, 24 Jun 2015 21:24:58 -0400

So, I was perhaps jumping a gun?

I sent the approval note for this draft earlier today.

Should I be asking the IESG Secretary to hold this document while I make
sure we're in sync?

Spencer

>> I recommend leaving the object definitions unchanged, except for the
status clause. I think some of the SMILINT rules were not set when RFC4008
was published. The consensus of the MIB Doctors wasn't "set" until RFC4181,
and SMILINT both helped drive the consensus, pre-4181, and automates the
consensus, post-4181.
>> I personally feel that having one statement in the module-identity
explaining the deprecation could suffice, this discussion is running
parallel to the discussion of why we need to change the status in each
object and re-publish. Given that the per-object deprecation is important
so an NMS can import that information, it would be helpful to operators to
look at the imported deprecated object and see the description of why it
was deprecated (Some NMS's bring up the object definition/description as a
sort of man-page for each object, so an operator doesn't need to hunt down
the info in RFCs while fighting network fires. So I think it would be
justified to put an explanation into each object description.
>>
>> I would be satisfied with a textual reference to the NAT-V2-MIB and a
REFERENCE clause to the new RFC, in each deprecated object. This would make
for a normative reference, I think.
>> [email-masked]
thing,
>>>> MIB module definition itself and just have text saying (as Joel
suggested)
>>>> - is the issue that changing the definition while deprecating the
objects