Gateway Port config locking

We discuss security on all products that connect to our network quite regularly. Unfortunately, it isn't as easy as user levels within GCE, or more appropriately current products like Net3 Concert. This would actually require the user levels and protection in each end device. If it is done within the software, anyone could easily download a new installer and have access to everything. It is something we hope to consider in the future, but as you might expect it's not a trivial task. I am quite glad to see some request for it, as this helps validate the need so we can prioritize to potential work.

I have a huge concern with network security at present. I work at a university with 2 venues currently networked up, multiple dimmer racks, consoles, access points and remotes, architectural control processors and Net3 gateways.

At present, there's nothing to stop one of our inquisitive students downloading a copy of concert, plugging into my network and changing device configurations.

There needs to be some default read-only access level or a way of making devices un-discoverable on the network.

I've a friend in a receiving venue and he's already had issues with a touring show coming in and changing his venue network configurations without permission.

Concert is a great tool, but in the wrong hands can be disastrous to a venue.

My venues would also benefit from some ability to "restrict" gateway config changes, particularly for architectural fixtures/controllers. In my case, it's just to prevent authorized users from accidentally changing the wrong config (You would think naming a gateway "TH AMX - DO NOT CHANGE" would do it)

The ideas mentioned above, the protected IP fields in GCE, read-only status disabled through the faceplate, or something like adding ":RO" to the end of a gateway name and having all copies of GCE acknowledge that, until the name was changed or the protected IP password was entered, would really help.

As a last resort, would moving the gateways to a different address space cause significant issues? For instance, putting architectural gateways on 192.168.1.0, assuming it's a typical flat unrouted, non-igmp ETC network?

Thanks

My venues would also benefit from some ability to "restrict" gateway config changes, particularly for architectural fixtures/controllers. In my case, it's just to prevent authorized users from accidentally changing the wrong config (You would think naming a gateway "TH AMX - DO NOT CHANGE" would do it)

The ideas mentioned above, the protected IP fields in GCE, read-only status disabled through the faceplate, or something like adding ":RO" to the end of a gateway name and having all copies of GCE acknowledge that, until the name was changed or the protected IP password was entered, would really help.

As a last resort, would moving the gateways to a different address space cause significant issues? For instance, putting architectural gateways on 192.168.1.0, assuming it's a typical flat unrouted, non-igmp ETC network?

Thanks

In that kind of network the sACN levels will traverse between subnets, but configuration and feedback will not.

So assuming there's no requirement for RDM feedback from those Gateways, this will work.

It will make the views in GCE a little confusing though, as it will be able to detect that the Gateways in the other subnet exist, but won't be able to connect to them to download their current config, so will display the 'factory default' settings instead of their real ones.