[aprssig] Proposal for APRS tocalls allocation process

Lynn W Deffenbaugh (Mr) KJ4ERJ at arrl.net
Thu Feb 17 16:28:18 EST 2022


I've your proposal and see no issues with it.  It would be good to get 
this process brought into the open and visible so that folks a) know 
what is expected, and b) know how to do that which is expected.

Good job!

Lynn (D) - KJ4ERJ - Author of APRSISCE for Windows Mobile and Win32

PS.  Chalk Hessu's e-mails up as also not getting through the list but 
only showing up in the archives.  Manually constructed quoted reply from 
the archives follows.

On Thu Feb 17 03:12:25 EST 2022, Heikki Hannikainen hessu at hes.iki.fi 

> Hi,
> I drafted a proposal for an APRS deviceid allocation policy. The idea is
> to have a document which specifies what kind of things are allocated
> unique APRS device identifiers (tocalls, mic-e type codes), what data goes
> in the allocation, and how it gets done. This would in turn help people
> requesting allocations create good requests, and help the team doing
> allocations to do a consistent job.
> The data contents described match what is *already* in the existing
> database, and the database is already used by a number of applications in
> this form and format, so at this point I would not change it much. There
> is more space for discussion in the surrounding process and policy.
> On "who gets an allocation": I think the main point is that everyone
> creating and distributing APRS things (devices, software, services) should
> get one, and the maintainers should only reject applications if they do
> not meet the written criteria. Requests and responses should be public so
> that the process is open and everyone sees if the allocations happen like
> they should.
> I added a clause saying unique, personal experimental stations should not
> be allocated with identifiers, because I'm afraid there might be many
> requests for such, and the database size may grow with such quite a lot,
> if it becomes a norm to allocate vanity tocalls which are then only used
> by a single station. There is one ticket from last week requesting 8
> different tocalls for an individual, and I'm not entirely sure what to do
> about it before getting more information from the requestor. In
> experimental use & unique custom scripts it might be simpler and more
> effective to just describe the station in the comment field.
> I considered adding something about how unused identifiers could be
> removed after a few years of inactivity, but couldn't come up with a good
> wording, and some old devices may reappear later on, so I left it out.
> Maybe it can be added later if necessary, if/when the database size is
> annoyingly big.
> The document focuses on destination callsign allocations, Mic-E specific
> details are missing for now and might go to a second document.
> PR:https://github.com/hessu/aprs-deviceid/pull/60
> Direct link to the proposal:
> https://github.com/hessu/aprs-deviceid/blob/b748d0c367c2f5e736b2fb5f88b592cedf849921/ALLOCATING.md
> Please read through it, and comment. If there are obvious speling
> mistakes, weird English or such, you can just make a review note on Github
> directly.
>     - Hessu, OH7LZB/AF5QT

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tapr.org/pipermail/aprssig_lists.tapr.org/attachments/20220217/99c316af/attachment.html>

More information about the aprssig mailing list