Subject: [MIB-DOCTORS] Experience deprecating textual conventions (draft-perrault-behave-deprecate-nat-mib)

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Jun 2015 14:30:40 +0200

MIB doctors,

I'm reviewing 
https://tools.ietf.org/html/draft-perrault-behave-deprecate-nat-mib-v1-01, 
on the IESG this week.
The authors want to deprecate the following TCs:

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

Do we have any experience deprecating TCs? Personally, I don't recall 
any previous instance.
How can we make sure that the TCs are not reused in different MIB modules?
A word from the authors, after investigation, is sufficient?
Would any of you have a comprehensive list of MIB modules to do a quick 
check?

It might be useful to stress, in an operational considerations section, 
that a consequence of deprecating these TCs is that any MIB module 
depending (including private extension) on those TCs is now unusable?
Btw, what I'm lacking in this document is whether or not RFC 4008 has 
been implemented.

What are your thoughts?

Regards, Benoit

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 8 Jun 2015 09:17:41 -0400

Benoit,

My concern is that it might be extremely difficult to know about existing
implementations and whether or not these TCs are implemented by vendors
several years back.  (How long have these TCs been around?)   Similarly,
(though maybe not an IETF concern) is that enterprise MIBs could have
implemented these TCs in enterprise MIBs.

My 2 cents is  to deprecate the objects that utilize the TCs if they are
outdated/unwanted/etc.   As you point out, deprecating a TC is not so
straightforward.     There was a similar situation in MPLS WG but the MIB
that utilized the TC is 10+ years old and widely implemented, and so I
argued against deprecating the TC for those reasons.    

-Joan

> -----Original Message-----
> From: MIB-DOCTORS [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: Monday, June 08, 2015 8:31 AM
> To: MIB Doctors (E-mail)
> Cc: Spencer Dawkins; draft-perrault-behave-deprecate-nat-mib-
> [email-masked]
> Subject: [MIB-DOCTORS] Experience deprecating textual conventions (draft-
> perrault-behave-deprecate-nat-mib)
> 
> MIB doctors,
> 
> I'm reviewing
> Do we have any experience deprecating TCs? Personally, I don't recall any
> previous instance.
that a
> consequence of deprecating these TCs is that any MIB module depending
> (including private extension) on those TCs is now unusable?
> Btw, what I'm lacking in this document is whether or not RFC 4008 has been
> implemented.
> 
> What are your thoughts?
> 
> Regards, Benoit
> 
> _______________________________________________
> MIB-DOCTORS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mib-doctors
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2014.0.4800 / Virus Database: 4311/9974 - Release Date: 06/08/15

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Jun 2015 10:23:48 -0400

The BEHAVE WG looked at whether RFC4008 had been implemented widely.
They reported very little evidence of implementation.
Of course, our feedback from the community about MIB module implementations
is extremely limited, so take the results of that survey with a grain of
salt.

I will observe that this status change is to deprecated, not obsolete, so it
is still useable, even in environments that pay attention to
deprecate/obsolete status changes.
Most NMSes probably won't be affected by the status change.

I'd be a bit more concerned about operational and security issues of
supporting both in a network.
But there is little evidence of RFC4008 implementation/deployment, so I'm
not sure it's a big concern.
Any MIB Doctors have access to a lab or other network with a long list of
devices supporting NATs?
Now might be a good time to re-survey operators/implementers whether they
have any existing deployments of RFC4008 implementations.

David Harrington
[email-masked]
+1-603-828-1401

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 08 Jun 2015 16:24:33 +0200

Inline, picking on one issue

On 08/06/15 14:30, Benoit Claise wrote:
>
> It might be useful to stress, in an operational considerations section, that a consequence of deprecating these TCs is that any MIB
> module depending (including private extension) on those TCs is now unusable?

Why would they be unusable?

My understanding of "deprecated" is that there should be no NEW implementations,
but existing ones should continues to work. So it seems simple to me, no?

Bert

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 16:24:51 +0200

> Btw, what I'm lacking in this document is whether or not RFC 4008 has 

The TCs are deprecated, which is not the same as 'unusable'.

RFC 2578:

   While the value "deprecated" also indicates an obsolete definition,
   it permits new/continued implementation in order to foster
   interoperability with older/existing implementations.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 08 Jun 2015 16:33:23 +0200

Inline

>     interoperability with older/existing implementations.

aha. so that is even stronger than what I wrote in that it even allows for
new implementaions. But I would assume that one would not use a TC in new
MIB modules that are under devlopment, right?

Bert

---

From: "Joan Cucchiara" <[email-masked]>
Date: Mon, 8 Jun 2015 10:54:16 -0400

Sorry, I made a mistake, the TC proposed in MPLS was to change the status to
OBSOLETE (not DEPRECATED) so, think this was easier decision as TC was used
in objects that are widely deployed.   

DEPRECATED might be fine as it can still be used.

-Joan

> Joan Cucchiara
> Sent: Monday, June 08, 2015 9:18 AM
> To: 'Benoit Claise'; 'MIB Doctors (E-mail)'
> Cc: 'Spencer Dawkins'; draft-perrault-behave-deprecate-nat-mib-
> [email-masked]
> Subject: Re: [MIB-DOCTORS] Experience deprecating textual conventions
> (draft-perrault-behave-deprecate-nat-mib)
> 
> Benoit,
> 
> > Would any of you have a comprehensive list of MIB modules to do a
> > quick check?
> >

---

From: Simon Perreault <[email-masked]>
Date: Mon, 08 Jun 2015 08:42:30 -0600

> argued against deprecating the TC for those reasons.

What problem would arise if we deprecate a TC used by non-deprecated
objects out there? Is this just a theoretical problem or does it has
practical consequences?

Simon

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 16:58:19 +0200

> MIB modules that are under devlopment, right?

In the IETF, this would likely not go through. Outside, it is up to
whoever decides. But most important: deprecated is not 'unusable',
it just marks something as - well deprecated.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jun 2015 17:00:05 +0200

> objects out there? Is this just a theoretical problem or does it has

I would expect a compiler to report this as a warning.

/js

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Jun 2015 17:08:25 +0200

Dear all,

> it just marks something as - well deprecated.
Ok. I have my answer.

Thanks to all.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 8 Jun 2015 10:26:02 -0500

>> it just marks something as - well deprecated.

Thanks from me, too :-)