Re: SUBnetting weirdness

Dean Anderson <dean@ksr.com> Tue, 15 March 1994 21:24 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15201; 15 Mar 94 16:24 EST
Received: from CNRI.RESTON.VA.US by IETF.CNRI.Reston.VA.US id aa15191; 15 Mar 94 16:24 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19283; 15 Mar 94 16:24 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa15181; 15 Mar 94 16:24 EST
Received: from hopscotch.ksr.com by IETF.CNRI.Reston.VA.US id aa15133; 15 Mar 94 16:22 EST
Received: from frankenstein.ksr.com by ksr.com with SMTP id AA26943; Tue, 15 Mar 1994 16:22:22 -0500
Received: from grumpy by frankenstein.ksr.com (4.0/SMI-3.2) id AA28735; Tue, 15 Mar 94 16:23:56 EST
Received: by grumpy (4.1/KSR-2.0) id AA05948; Tue, 15 Mar 94 16:23:41 EST
Message-Id: <9403152123.AA05948@grumpy>
To: Joachim Martillo <martillo@thurifer.harvard.edu>
Cc: tli@cisco.com, cisco@spot.colorado.edu, funkb@worms-giis.army.mil, ietf@IETF.CNRI.Reston.VA.US, incoming-cisco@cisco.com, snmp@psi.com
Subject: Re: SUBnetting weirdness
In-Reply-To: Your message of "Tue, 15 Mar 1994 06:40:25 EST." <9403151140.AA00602@thurifer>
Date: Tue, 15 Mar 1994 16:23:40 -0500
X-Orig-Sender: ietf-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Dean Anderson <dean@ksr.com>

Smugly raping customers?  Prevaricating Employees breaking features?
Deprecate the IETF?

I don't think so.  Further, the IETF didn't do anything to anyone.
You need to complain to Cisco.

Sometimes old features conflict with new features.  Sometimes one can
easily add a switch and support both, but ultimately, the old features
are no longer supported and are eventually removed.

As Bruce said, there are some really old, historical reasons for
wanting to subnet on the 4th octet.  I had never even heard of doing
this, so it appears it is so obscure that supporting it has to be
questioned in the first place, even without it having been deprecated.
Apparently, he has some new reasons for updating into the 90's.

When a new feature comes along that is much easier to implement and
support if the old feature is removed, then one needs to make a
management decision about where to deploy resources.  Cisco did.  I
would much rather have them spend resources on supporting newer
routing protocols, than supporting obscure non-features that were
rarely used when they were features.

I think you are prevaricating when you say you have never had to drop
an old feature.  Or perhaps you have never had to support a product as
it evolves through its lifetime. You clearly have never integrated
mice with their many varied proprietary protocols into a system. I
would also point out that your phone example is likewise flawed.

Digital phones don't work on analog lines and vice versa.  At some
point, analog lines may not be offered.  Jumping up and down and
demanding analog lines will not help. You have to upgrade the old
technology or run an old switch for which you may not be able to get
parts or support.  Likewise, Bruce can either run the old software,
and forego future enhancements and support, or upgrade his network to
use newer standards.

I think you are being kind of unreasonable. Your reports will no doubt
appreciate it if you stay more in touch with engineering reality.

		--Dean