<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Specifying a path of NSR is craziness... what happens when NSR mobiles
wander out of range of their NSR area? The existing WIDE digi's won't
respond to them. One of the slick things about NSR is that it allows
the continued use of the legacy WIDEn-n path element.<br>
<br>
The more correct thing to do is to have NSR digipeaters respond to
packets with paths containing:<br>
-RELAY<br>
-WIDE<br>
-TRACE<br>
-WIDEn-n<br>
-no path specified<br>
<br>
Packets which contain a path with one or more elements that do not
contain any of the above aliases will not be tampered with.<br>
<br>
I get the feeling that the resistance to NSR is the giving up of
control for one-off situations. Bob hit the nail on the head by saying
that one of the perks of ham radio is the ability to adapt under
varying circumstances. But sometimes control is too much bother. As
an example, I use DHCP at home for all my devices that I hook to my
LAN. I _could_ use static IPs (and sometimes do), but for 99% of my
applications DHCP fits the bill. The important thing is that the
_ability_ to use static IPs is there if I need it. Same goes for
NSR... if NSR could allow the average user "plug and play" coverage,
and still provide a back door way for the power users to do what they
need, we'd have a winner.<br>
<br>
What the APRS on-air network has devolved into is a system that is open
for abuse either willfully (those running paths like WIDE7-7,RELAY),
absent mindedly (those running WIDE5-5 and forget to change paths as
they enter a populated area), or those who out of appathy just set and
forget their path. There are a few "power users" who know what they
are doing and they should be able to flag their packets somehow to
prevent the network from modifying their packets. Now, seriously, I
wonder how much better a power user's chance of getting his
specifically routed packet thru the network would be if by and large,
the rest of the users were corralled into smaller, better managed
boxes? Which, by the way is where most of us want to be. For the most
part, I just want my tracker to be seen at findu... but there are times
when I'd like to go further.... and in every case that Bob has
mentioned going further, it was to a place that he knew the callsigns
of the digi's and could (and did) specify a path.<br>
<br>
I think there is room within the NSR spec to 1)control the network to
prevent abusive paths or at least limit the damage to one or two
digipeaters, 2) provide automatic pruning down of the area covered,
3)allow the power users the elbow room to tinker.<br>
<br>
Wes<br>
<br>
Robert Bruninga wrote:
<blockquote cite="mids2bac101.067@FSGWHUB.usna.edu" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:wa7nwp@jnos.org">wa7nwp@jnos.org</a> 06/23/05 12:10 PM >>>
</pre>
</blockquote>
</blockquote>
<pre wrap="">Would it be possible to do both? Client
stations could choose either an outgoing
NSR path (an anti-path) or a legacy path as needed?
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, I think the two can co-exist. Just name
the PATH as "NSR" and that then gives your packet
over to the NSR system and it will route it
according to the NSR's sysop's design.
Of course this waters down its potential, because its
biggest advantage was to be able to prevent users
from abusing their freedome to choose their own path.
But I would have no problems with it at all under
these general rules:
1) A user can send a WIDE2-2 anywhere and
WILL get 1 or 2 hops out of it guarnateed.
( THe APRS default path)...
2) A user can send ANY length D1,D2,D3 directed
path (since even a full 7 hop path is less total
copies on the network than a single W2-2) and
is an inconsequential load on the system, but
permits the users the flexibility to handle
unusual needs.
Any other path will be at the mercy of the NSR
sysop. Or just select the path of "NSR" for
full NSR routing.
Bob
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:wa7nwp@jnos.org">wa7nwp@jnos.org</a> 06/23/05 12:10 PM >>>
</pre>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->On Thu, 23 Jun 2005, Robert Bruninga wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">to effectively implement the NSR algorithm.
</pre>
</blockquote>
<pre wrap="">...
I fully suport the APRS-IS, and global messaging
via the internet, but it being able to use a reasonable
RF path as needed where needed is the essence of
HAM radio in my mind. There is a big difference between
the distribution needs of APRS 24/7 home stations just
doing nothing all day versus a real-live-HAM radio
activity with humans at both ends...
</pre>
</blockquote>
<pre wrap=""><!---->
Would it be possible to do both? Client stations
could choose either an outgoing NSR path (an anti-path)
or a legacy path as needed?
Bill - WA7NWP
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
_______________________________________________
aprssig mailing list
<a class="moz-txt-link-abbreviated" href="mailto:aprssig@lists.tapr.org">aprssig@lists.tapr.org</a>
<a class="moz-txt-link-freetext" href="https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig">https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig</a>
</pre>
</blockquote>
</body>
</html>