D-GSM merge / open question on GT vs. IPA name

historical

Hi Neels,

some week[s] ago, you mentioned that the D-GSM merge is blocked around
the question on how the Global Title vs. IPA-name is to be resolved.

Sorry for not getting back any sooner, but I am simply not finding the
required amount of time to investigate this topic at the moment.

My personal opinion is that it should be a binary blob (buffer + length)
and nobody should make any assumptions about the contents.   This way we 
can store whatever we want in it, and I believe we're increasing possible
use cases where our HLR would have to work with "stateless" translators
between GSUP and MAP.  After all, let's say we receive a LU from a subscriber
roaming in MAP-land, then that request arrives with the GT of the MSC/VLR.

If we can natively "digest" such values, then the translator would not require
any state beyond the currently processed transaction (LU/ISD).  If we can not,
then the translator would have to keep long-term state such as tables to map
MAP-GT to IPA name or the like.  And that's of course more effort there,
and volatile state that you'd need to synchronize in case of high availability
or fail-over scenarios, etc.

I of course also know none of this is any current use case that any of
the sysmocom customers is funding sysmocom (and hence you) to spend time
on.

So in the end, I'll leave it to you to decide.  If you think the effort
for becoming "buffer+length" aware is relatively minimal (let's say up
to two days?) then by all means, implement that.  If you think it's more
work, then please go for the faster route of not considering
non-NUL-terminated strings as identifiers for "GSUP" peers.

In any case, I am happy to merge the D-GSM patch series once you think
it should be merged.  I put it in your trusted hands.  After all, we had
a tagged release only 7 commits ago (well, 5 of those are actually
already D-GSM related) in osmo-hlr, and should there be any fall-out
from the merge, we still have quite some time until some new tagged
release will happen a few months down the road.

Thanks!

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)