| |
ZL3AI > APRDIG 06.03.04 14:31l 230 Lines 9564 Bytes #999 (0) @ WW
BID : 2970-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 04, 12/14
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<IK1ZNW<ZL2TZE<VK3TE<
ZL2BAU<ZL2BAU<ZL3VML
Sent: 040306/1129Z @:ZL3VML.#80.NZL.OC #:20460 [Chch-NZ] FBB7.00i $:2970-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 04 Mar 2004 20:00:06 -0500
X-Message-Number: 85
>>But right now there are only 6 or so IGate software codes.
>>They could be updated overnight and take a few weeks
>>for IGates to upgrade. Done. ENd of problem.
>This is assuming you can get all of the authors to issue upgrades
>to all of their code (and there are more than 6...)
But looking at the recent survey, the great majority of everyone is using
UIview. THus one author can fix 70% of the problem... with a few lines of
code...
bob
----------------------------------------------------------------------
Subject: RE: stir up the path pot!
From: Jeff King <jeff@aerodata.net>
Date: Thu, 4 Mar 2004 20:02:35 -0500
X-Message-Number: 86
On Thu, 04 Mar 2004 19:44:21 -0500, Robert Bruninga wrote:
>>>Ah, but we can do it overnight in SOFTWARE at the IGates but it
>>>would take 10 years to replace all the firmware digis. Thus, it is
>>>orders of magnitude easier to do it at the Igates.
>
>>>>Jeff King <jeff@aerodata.net> 3/4/04 2:54:00 PM >>>
>
>>Yeah, but what are you fixing? IMHO, nothing, your just covering
>>the problem up. The fragile low speed RF lans will be continued to
>>be trashed by people who don't care that their paths are excessive.
>
>Not at all.
OK, and the sun is not rising tomorrow as well. What I stated is backed up
by a large body of work, and if you want to ignore it, then that is your
choice. Just don't try and tell me orange is green, its not.
Bottom line, you fix the problem, you don't treat the symptom.
----------------------------------------------------------------------
Subject: RE: stir up the path pot!
From: "Robert Bruninga" <bruninga@usna.edu>
Date: Thu, 04 Mar 2004 20:09:47 -0500
X-Message-Number: 87
>>>Steve Dimse <k4hg@tapr.org> 3/4/04 5:51:33 PM >>>
>Here is a good example of why arbitrary rules of maximum
>digi paths just won't work, this was the second station I
>looked at with WIDE4 in the packets
>
>http://findu.com/cgi-bin/raw.cgi?call=N7NAT
>
>If you look at this data, almost all of it required 3 or 4 hops
A prefectly VALID path in his area, and presumably then the IGate in his
area would NOT have the restriction to 2 hops. The only IGates that would
impact that user would be IGates in areas where 4-4 is NOT acceptible. And
the IGATES know and understand this. Hence, this user would not be
impacted at all..
>If you implement this proposal of trashing everything
>longer than 2-2, this person cannot have his data on
>the internet.
The idea to limit to 2-2 or 3-3, or 4-4 is a LOCAL IGate thing. It doesnt
apply in areas where such restrictinos are not needed.
>Please, this is just a bad idea...you cannot enforce an
>arbitrary path on all APRS local area networks.
Two things missing in that statement:
1) It is not arbitrary, it is determined by the LOCAL IGate sysop
2) It does not apply to "all" networks, only one local network one at a
time, depending on LOCAL needs...
Bob
----------------------------------------------------------------------
Subject: RE: stir up the path pot!
From: Steve Dimse <k4hg@tapr.org>
Date: Thu, 4 Mar 2004 20:14:37 -0500
X-Message-Number: 88
On 3/4/04 at 7:35 PM Robert Bruninga <bruninga@usna.edu> sent:
>>this does nothing to educate the user, because with a position,
>>when they go to the find.cgi page they will see nothing but
>>a message saying no position, the weather page will say
>>no data, the message page no messages.
>
>No, it will display his original packet like this:
>
>LID>APRS,WIDE7-7,RELAY7-7:Packet Truncated due to too-big-path in
>area...
No, it will display "no position found for LID", or "No Weather Data for
LID", etc. The raw packet (which does not appear in wxpage under any
circumstance) is only displayed when there is a position to be shown.
>>It does nothing to adress that this is enforcing your will
>>upon others, even areas that accept these paths, and
>>are denying access to a resource that belongs to all of
>>amateur radio.
>
>No, it is only enfocing the will of the IGate sysops in each
>local area who hopefully are in the best position to take
>action for their local area. And this is fed back to the
>user when he looks on the APRS-IS... That is what we are
>looking for is a feedback path to the user.
The only way this could work is if every IGate user implements this, and at
the same or similar hop count. Otherwise, people will have MORE incentive
for increasing hops. The would be places where WIDE3-3 would fail to reach
findU, but where WIDE5-5 would work great.
>And we DONT WANT the feedback path on RF where
>it just adds to the load. (and doesnt get to abusvie trackers
>anyway...)
>
>>Finally, while it would give me a way to see what is wrong,
>>it still places me in the position of getting these emails,
>>investigating them, and answering them.
>
>No this is not an Email thing at all, It is simply a truncating
>and marking of excessive paths at the source of entry into
>the APRS-IS. The end user then sees the feedback when
>he checks to see his packets on FINDU.
Trust me, this is not the way it works. People will email to complain, like
they do now when theirt antenna is busted and they aren't getting out!
>>I'm still very much opposed, you are taking a heavy-handed
>>approach in a part of the system not being adversly affected.
>
>I dont see it that way. I see it as an easy way to get good
>LOCALLY derived feedback to users of abusive paths
>even if they are using trackers and not listening on RF
>without adding any further load to the already challenged RF.
>It is trivial to implement and thus has very good return on
>investment. The ideas to replace ALL 1000 digipeaters
>to solve the same problem WILL NEVER HAPPEN....
>Hence, this idea to implement the filter when it can be done
>quickly and easily...
To replace the software in all 300 odd IGates will take a very long time to
be implemented, even if you are able to sign on all the authors. Even one
not responding makes the whole exercise worse than useless, it will
encourage longer paths.
>>Instead of just wiping his data out, we could just shoot him
>>or cut his coax. I'd rank the proposed solution just below
>>these two alternatives.
>
>Those are good alternatives too, but not as easy to
>implement overnight in software.
What makes you think you can get 8 or more software authers and hundreds of
IGate operators to implement this overnight? And even if you could wave
your magic wand, you still are not addressing the root of the problem. For
example, I doubt that digi operator talked about earlier cares about
whether his position gets to findU. Instead, you have taken him off the map
for those people who look at digi positions, and made it impossible to
match a position with the callsign when it appears as the first call in the
via list (what did you call that, proximity APRS or some such). You've
taken out at least 5 stations (and probably a lot more) from the reports
APRS provides to the National Weather service. You've wiped out virtually
every European station from the face of APRS. These are good things???
>>What is wrong with dealing with these as they become
>>known, with a courteous email or snail mail, or a personal
>>visit? This is the way ham radio used to address operator
>>problems...
>
>Because in 12 years of APRS it hasnt worked and with
>more and more newbees getting on APRS without
>having evolved through APRS, they just dont get it.
If you want, I'll implement filtering at findU for any station you can tell
me is causing QRM and has ignored good faith attempts to resolve the issue.
That seems like a method of implementing your punishment without causing
the colateral damage of this proposal.
What I'll do is make you, Bob, the contact person. Anyone with a complaint
against the QRM being caused by a ham's path would forward documentation to
you, including how they had tried to contact the ham. If you are satisfied
(perhaps after attempting to contact them with notice of an upcoming
blacklist), just send me the callsign, and I'll add it to a table on my
server, whenever a request comes in for the callsign in the table, I'll
forward the request to a page saying that the request has been blocked at
the request of the father of APRS, perhaps include something written by you
about the path issue and how to fix it, and give your email address for
people to send questions and requests for re-instatement. Another email to
me after they have complied and I'll remove the block.
I'm not happy with this, having the APRS IS and findU, two of my creations
used to force behavior, but at least this method will keep innocent people
from suffering!
>>And as a last resort, after a ham has been educated,
>>if he still refuses despite knowing he is causing interference,
>>it can be bumped up to the FCC. I suspect that if the ham
>>is approached in a friendly educational manner this will
>>vitually never be needed!
>
>This never works. No ham likes being challenged.
>That is why this truncation at the IGate is such a good
>idea. It says "you may use that path, but you are
>not going to get into the APRS-IS with it." THus
>it is his choice.
That is just not true, even I with my naturally abrasive manner have had
hams respond favorably to my contact. I'm sure that a more diplomatic
person would do even better!
Steve K4HG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
