| |
ZL3AI > APRDIG 07.03.04 18:45l 225 Lines 9135 Bytes #999 (0) @ WW
BID : 2982-ZL3AI
Read: GUEST
Subj: TAPR Digest, Mar 05, 8/9
Path: DB0FHN<DB0THA<DB0ERF<DB0FBB<DB0GOS<ON0AR<ON0AR<7M3TJZ<LZ3NP<KD7HAH<
WA7V<VK7AX<ZL2BAU<ZL3VML
Sent: 040307/1039Z @:ZL3VML.#80.NZL.OC #:20537 [Chch-NZ] FBB7.00i $:2982-ZL3AI
From: ZL3AI@ZL3VML.#80.NZL.OC
To : APRDIG@WW
Subject: RE: stir up the path pot!
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 5 Mar 2004 15:44:59 -0500
X-Message-Number: 45
On 3/5/04 at 3:09 PM Robert Bruninga <bruninga@usna.edu> sent:
>Steve Reeiterates his proposal. Bob's excerpted comments:
>
>All I was after was "feedback" to the users about paths.
>Not draconian measures to cut them off.
>You are still totally missunderstanding my proposal. It has
>NOTHING to do with filtering. And it has NOTHING to do
>with users of long paths in areas where such use is acceptible!
>I would NEVER do that. It NEVER works to deny service or
>to BLOCK people. That just never works on HAM radio.
>
>I have no clue where you get these concepts.
Where do I get them? Here is the first proiposal I say from you, the one I
have been fighting so vigoursly against, which certainly seems to me to be
advocating filtering people!
====== Forwarded Message ======
Date: 3/4/04 1:46 PM
Received: 3/4/04 6:50 PM -0000
From: Robert Bruninga <bruninga@usna.edu>
To: TAPR APRS Special Interest Group <aprssig@lists.tapr.org>
>We. need. to intercept the packets on the IS and filter
>them OUT!
Hummh... interesting concept.
I always object strongly to any on-air filtering or policing, because
we just cannot tell what that person's immediate needs are
at any instant in time. Such filtering ruins the integrity of the
network if it makes arbitrary decisions like this.
BUT!!! we have to penalize the long term use of such paths
somehow if we expect them to ever learn... and change...
Eric's suggestion to Filter them from the APRS-IS is something
worth considering...
If we penalize them from getting to the APRS Global Internet
system because of long paths, then we are not "interfering"
with their immediate RF communicaitons needs, but we are
offering a penalty... That is the only way to get these people to
learn...
Would this work?
1) All IGATE clients DEFAULT to not accepting any packet
with a path length greater than WIDE2-2.
2) Local IGate SYSOP can determine based on TRAFFIC,
and local topology whether 3-3, 4-4, 5-5, or even 7-7 are
permissible in his area.
Then again, where 5-5 can be used, then it can be used.
But where it is intolerable, the IGate filters it out. It puts
the IGate sysops in control of stuff in their areas, and because
of the penalty, the end user learns why he is not getting in.
====== End Forwarded Message ======
Geez Bob, sometimes I think you need to see a neurologist ;-)
Steve K4HG
----------------------------------------------------------------------
Subject: RE: stir up the path pot! PLEASE START OVER
From: "Daron J. Wilson" <daron@wilson.org>
Date: Fri, 5 Mar 2004 12:57:36 -0800
X-Message-Number: 46
Hey, can we get a restart on this thread? Geez this is going nuts. I
suggest that if there is a proposal to be made, it be made and posted
somewhere then point us to it with a link. We'll go read it, digest it,
and comment. That way you can easily point people there to read it in
its entirety. This is getting so confusing the authors of the proposals
can't even follow it.
73 N7HQR
----------------------------------------------------------------------
Subject: Fix it on the Client Side Was RE: stir up the path pot!
<LYR30523-183132-2004.03.04-19.51.25--kb2scs#optonline.net@lists.tapr.org>
From: kb2scs@optonline.net
Date: Fri, 05 Mar 2004 16:17:55 -0500
X-Message-Number: 47
Hi All
I have a solution that will lessen the problem at the source. The APRS
client software should not allow the user to type in any path. When a user
wants to add to the canned paths in PMmap a dialog box comes up and the
user can only click on buttons that make the path for them.
There is a text box where the user can type in call signs. But if he wants
wide,wide then he has to click on the wide button twice.
When the user clicks on the ok button if his path is more than 3 hops a
message appears on his screen stating that a path of 3 hops or more cause
qrm but PMmap will allow you to use this path just be aware of the qrm you
are causing.
Thus the user is educated. So if he has a good reason to use a path of 3
hops or more he can. If education will have no effect on him then he would
use 3 or more hops regardless.
Yes I know it will take years for old software to disappear.
But at least this method takes care of the problem at the source.
Let us hope we never witness the "Silence Of The Hams"
73 DE John KB2SCS
E-Mail: kb2scs@arrl.net
----------------------------------------------------------------------
Subject: APRS Arbitration Proposal
From: Steve Dimse <k4hg@tapr.org>
Date: Fri, 5 Mar 2004 16:49:59 -0500
X-Message-Number: 48
On 3/5/04 at 12:57 PM Daron J. Wilson <daron@wilson.org> sent:
>Hey, can we get a restart on this thread? Geez this is going nuts. I
>suggest that if there is a proposal to be made, it be made and posted
>somewhere then point us to it with a link.
That's not too convenient, many people don't have ready access to web
servers, and even for those that do the sig is a more convenient place to
post. It is unfortunate that TAPR is no longer archiving the messages, but
most people use email programs that allow them to save emails if they
choose to.
I will restate my proposal, since Bob has apparently abandonded his earlier
proposal to filter data from the APRS IS, removing his name as the arbitor.
The problem is abuse of the VHF network, as APRS has grown in popularity it
has become succeptible to abuse by poor paths and high beacon rates. My
personal take on things is that almost all of these issues can and should
be handled by Elmerish contacts between local hams. My suspicion is that
many people complaining about the problem have not made any serious attempt
to contact the offenders, and are looking for others to do the dirty work.
Still some clearly state they have contacted offenders and been ignored, I
have no reason to doubt them. Therefore, perhaps some of the persuation Bob
originally proposed and later abandoned is not a bad thing.
Therefore, here is my amended proposal:
When a ham (complainant) feels another ham (defendant) is causing excessive
problems on the VHF network in the complainant's area, he can initiate a
complaint. Before it will be considered, there must be the following
supporting information:
1. The nature of the alleged violation
2. Documentation of the attempts made to contact the defendant, including
dates, any email, phone, and ground addresses used, the messages
themselves, and the results of those attempts.
3. Supporting emails from three other local hams documenting that the
alleged violation is actually causing a problem on the local VHF network,
and is counter to local norms.
After this information has been received, the arbitor will decide if the
complaint appears legitimate, if so he will send an email to the defendant
using any address used by the complainant and found at qrz.com, as well as
using his callsign@amsat.org and arrl.net. This email will contain the
documentation of provided, and give the defendant 5 days to either settle
the issue locally, or provide explanation of why this behavior is within
local norms, or of overriding benefit to APRS, ham radio, or the community
at large.
If not settled in the 5 days after the email, a ban will be instituted on
the findU site, preventing access to find.cgi, wxpage.cgi, near.cgi, and
possibly others where the root callsign is the search criteria (IOW if the
offending station is K4HG-5, K4HG and K4HG-1 through -15 are all blocked).
When requested the page will instead display a message stating why access
was blocked, and giving the contact information for the complainant. There
will be a machine readable page of active blocks where any other
application may obtain the current blacklist.
This places the burden on the local hams to settle the issue, however in
those rare cases where there is problem that a user will not address, this
at least provides some penalty.
Anonymous complaints will not be considered under any circumstances, if you
are not willing to publicly stand up and take the heat, don't bother
complaining. The arbitor will not take the heat for you.
I'd be very happy if someone else (or a group of people) were to take the
role of arbitor, but APRS being what it is, I don't expect anyone else to
step forward, and and am willing to do it myself in that case.
Steve K4HG
----------------------------------------------------------------------
Subject: TNC-2 and MFJ-1270 performance
From: "Scott Miller" <scott@opentrac.org>
Date: Fri, 5 Mar 2004 15:21:48 -0800
X-Message-Number: 49
Does anyone have any hard data on the decoding performance of the TNC-2 and
its clones (or anything with an XR2211 demodulator) as compared to, for
example, a TCM3105-based unit like the KPC-3 or any of the MX614-based TNCs?
I understand the XR2211 has a hard time with twisted audio. Do the others
do any better? How's its stability?
Scott
N1VG
----------------------------------------------------------------------
Read previous mail | Read next mail
| |
