<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 25, 2015 at 9:56 AM, Nishal Goburdhan <span dir="ltr"><<a href="mailto:nishal@controlfreak.co.za" target="_blank">nishal@controlfreak.co.za</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 24 Dec 2015, at 16:22, Gil Bahat wrote:<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. People will chip in if explained that the credits will help our company<br>
deliver better service to our users. However, the current credit system<br>
forces me to register it under my name and not theirs. it would be better<br>
if at registration point, a user could permanently assign credits to a<br>
recipient or group.<br>
</blockquote>
<br></span>
i’m not sure why this is the case.  i have exactly one probe registered in my name, and have distributed a few hundred.<br>
it’s easy enough, in an organisation, to have a general alias (eg. <a href="mailto:ripe-probes@example.isp.com" target="_blank">ripe-probes@example.isp.com</a>) to which something like the network team/whomever can have access to.  presumably this is a trusted group so tracking things like credits usage, etc. is a non-issue?<span class=""><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Building up on the above, perhaps gamification and groups are a good way<br>
to encourage adoption. Seeing how many credits your group generated makes<br>
it a bit like a (positive) contest.<br>
5. I have found trouble with getting coverage for mobile (3G/4G) networks.<br>
there are very few setups in which these are gateway'd to ethernet. as a<br>
case in point, we have a USB 3G adaptor as backup in the company and no one<br>
would mind if it's connected to a probe when it's unused (which is 99.99%<br>
of the time), but there is no physical port available for this (and<br>
possibly no CDC ethernet driver). another option might be to allow the<br>
probes to interface with mobile phones somehow, which would entail<br>
occasional access to these networks when a paired phone is nearby, but<br>
perhaps it would be better than nothing.<br>
</blockquote>
<br></span>
my general rule of thumb has been to advise *AGAINST* deployment in mobile networks (or more correctly, against deployment in usage-based-billing networks), unless the organisation/individual understands the costs attached to this.  since the majority of mobile accounts are limited to some silly data-cap, after which it becomes exorbitantly expensive, and even a relatively idle probe, can consume up to 2.5GB of data a month.  that’s a nasty surprise for someone that wasn’t expecting to see this data usage.  ymmv.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></blockquote><div dir="rtl"><br></div><div>tricky thing that, because those are networks with poor ATLAS coverage and in high demand (at least for us, we're a mobile app developer). I had 2 ways to approach this:</div><div><br></div><div>1. try to utilize idle backup connections at companies which otherwise use 3g/4g as a passive backup. I believe I'm going to have 2 such installations soon.</div><div>2. appeal directly to mobile operators to donate the equipment and bandwidth to host these probes. this is harder because there is no spare USB port on the probes themselves, so they either need to place them at their NOC (so it's not as representative) or bear the costs themselves. insofar no luck yet, though i'm trying to pull some leverage as a potential customer.</div><div>3. of course, if you're lucky enough to have no-cap plans in your country, you might be able to convince someone to do it.</div><div><br></div><div>Gil</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888">
—n.<br>
</font></span></blockquote></div><br></div></div>