Hi Neels,
On Wed, Sep 27, 2017 at 05:27:38PM +0200, Neels Hofmeyr wrote:
Also we do have a concept of nesting CTRL nodes
separated by dots in the
variable name, looking at bsc_ctrl_node_lookup() and fsm_ctrl_node_lookup().
correct.
I notice though that we do still have open doors for a
lot of nonsense being
sent to it without proper validation or error messages.
GET 42 existing-variable.trailing.names.ignored more nonsense following being ignored
in effect is identical to:
GET 42 existing-variable
So we should probably enforce that there is no ignored nonsense...
I agree.
Should we also enforce a numeric command ID?
I'm not following here. Where would that numeric command ID comning
from?
GET
currently-any-id-is-possible-even-\t-\n-is-accepted my-command
this is also not intended, I'm quite sure.
Going back to the OsmoHLR CTRL commands -- they are
implemented in a way that
doesn't match the CTRL interface ways. Let's collapse them.
SET enable-ps <IMSI>
SET disable-ps <IMSI>
SET status-ps <IMSI>
indeed, this is not proper.
SET subscriber.by-imsi.123456789098765.ps-enabled 1
SET subscriber.by-imsi.123456789098765.ps-enabled 0
GET subscriber.by-imsi.123456789098765.ps-enabled
makes a lot of sense to me.
We can also expand this later to things like
GET subscriber.by-imsi.123456789098765.status
SET subscriber.by-imsi.123456789098765.msisdn 2345
GET subscriber.by-msisdn.2342.status
SET subscriber.by-msisdn.2342.ps-enabled 0
GET subscriber.by-imei.987654321234565.imsi
looks good!
We could leave the enable-ps, disable-ps, status-ps
commands in place in case
anyone is using it yet. I assume no-one is though.
I don't think we need to keep compatibility at this point.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)