[aprssig] IGate wildcards/Telpac data

[AE5PL Lists]

> -----Original Message-----
> From: Steve Dimse
> Posted At: Tuesday, February 15, 2005 7:38 AM
> Subject: [aprssig] IGate wildcards/Telpac data
> 
> The idea here is to use a wildcard in the IGate to send out 
> all telpac nodes. In order to avoid flooding the local area 
> with these packets, the IGate would need to use a filtered 
> port set to an appropriate radius to be sure that only local 
> nodes were sent to RF.
> 
> In theory, this will work fine. In practice, it is virtually 
> certain that some IGates will run WL-* in the IGate list, and 
> end up on an unfiltered port, flooding the IGates.

If this happens, the responsible IGate operator will be contacted by
local operators and have the opportunity to correct the situation.  I
think you give IGate operators far less credit than they deserve.

> My feeling is the real callsigns should be used for these 
> objects, and an IGate operator should need to enter each one 
> manually into his code. There is always the option for IGate 
> programmers to add the ability to detect these packets 
> themselves, and send out ones within a set radius. I just 

This will not happen on a large basis and it then goes against what you
said above.

> think the wildcard is too dangerous to accept. Another 

If this attitude is taken, then there really is no reason for the
packets to be inserted on APRS-IS as few if any IGate operators will
take the time to track who has a local TelPac node and who doesn't.
This is the same issue with IRLP nodes and EchoLink links/repeaters.
The idea is to give the non-Internet connected ham the ability to
readily identify and use the respective resource.

> problem is this would prevent the deployment of any KISS 
> IGates in the future. These would have the effect of 
> shortening the IGated packets, and even though no IGate 
> currently uses this, I think it is foolish to throw this 
> possibility away.

This mythical IGate will never happen because we are no longer (and
haven't been for years) restricted to 8080 memory footprints for network
appliance devices.  The savings in bandwidth is less than .1 of a second
per gated packet, not worth an investment in the development of such a
device.  Plus the looping potential becomes much greater with the
removal of the third-party packet format and would likely cause more
grief than any perceived gate-by-prefix problem.  The "KISS IGate" is a
non-issue and should be left for dead.

> Currently, findU is blocking this plan because of a 
> long-standing (meaning I didn't add this to block the plan, 
> it was added years ago to prevent the -NET, -HOME, -IP SSIDs 
> that were becoming problematic) requirement that callsigns be
> AX-25 compliant. If the community does not object to the WL- 

This has never been problematic except to you.  It is common practice on
APRS-IS and has been for years.  APRS-IS logins (and therefore
origination callsign-SSID's) are only restricted by the 9 alphanumeric
character limit imposed because of object name and callsign-SSID text
lengths so as not to break any database (and client) applications.

73,

Pete Loveall AE5PL
mailto:pete at ae5pl.net