Mattias Gyllenvarg via cisco-nsp wrote on 29/10/2025 13:42:
In my experience, the guiding principle for what is included in each tier
is designed to force you to select the most advanced tier or at least one
tier higher then you want too by feature gerrymandering.

I have no major issue with reasonable RTU licensing, but that's "reasonable" as defined by the customer rather than by the vendor. In a couple of weeks time, I'll be putting in an order with one of my networking suppliers for additional RTU licensing for some kit, and will be quite happy to do so. The costs don't sting, the feature set doesn't sting, it's RTU, and there are no practical sting-in-the-tail issues.

I.e. the vendor realised that setting out to hurt the customer was a bad approach when they were creating their licensing model. The outcome is that there's a good long-term working relationship between the customer and the vendor and this is a good place for starting conversations about new sales, including licensing.

License-related upgrade restrictions were mentioned. As it happens, when we were evaluating alternative equipment to the RTU vendor above, we ended up hard-bricking an alternative vendor's kit after an upgrade failed due to ... licensing. The device in question - which was a door-stop at that point - was shipped back to the vendor and they lost out on 7-8 years of hardware and licensing sales over the lifetime of that particular network architecture.

I sure hope Cisco don't think that upgrade restrictions due to licensing are a good idea. Not least because there's nothing like finding this sort of thing out at 02:00 in the middle of a maintenance window when you're under time pressure to get a job completed, with operational consequences if the upgrade isn't done (see my previous rants on cisco-nsp many years ago about transceiver locking for exactly the same reason).

Nick
_______________________________________________
cisco-nsp mailing list  [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/

Reply via email to