19 Feb
2017
19 Feb
'17
5:02 a.m.
Jim,
For the european activity, you should read the Jann DG8NGN paper presented
at the DCC 2014 in Austin, TX.
http://tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf
73 Remi F6CNB/AG5IR
19 Feb
19 Feb
9:35 a.m.
Thanks,
This is encouraging. I agree with slide 60, being new to this, the on boarding has been
slow and mysterious. I.e. What specifically is required in the request, length of time
between responses in the request adds a dampening effect, even if not intended.
Jim
Sent from my iPhone
> On Feb 19, 2017, at 5:02 AM, F6CNB <f6cnb(a)hutin.org> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Jim,
>
>
>
> For the european activity, you should read the Jann DG8NGN paper presented
> at the DCC 2014 in Austin, TX.
>
>
>
> http://tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf
>
>
>
> 73 Remi F6CNB/AG5IR
>
>
>
>
1:28 p.m.
You can watch the video of the talk at the Ham Radio Now website.
Bill
On Feb 19, 2017 2:04 AM, "F6CNB" <f6cnb(a)hutin.org> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
Jim,
For the european activity, you should read the Jann DG8NGN paper presented
at the DCC 2014 in Austin, TX.
http://tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf
73 Remi F6CNB/AG5IR
2:12 p.m.
Also review http://hamwan.org
On Sun, Feb 19, 2017 at 10:28 AM, Bill Vodall <wa7nwp(a)gmail.com> wrote:
> (Please trim inclusions from previous messages)
> _______________________________________________
> You can watch the video of the talk at the Ham Radio Now website.
>
> Bill
>
>
> On Feb 19, 2017 2:04 AM, "F6CNB" <f6cnb(a)hutin.org> wrote:
>
> (Please trim inclusions from previous messages)
> _______________________________________________
> Jim,
>
>
>
> For the european activity, you should read the Jann DG8NGN paper presented
> at the DCC 2014 in Austin, TX.
>
>
>
> http://tapr.org/pdf/DCC2014-TheEuropeanHAMNET-DG8NGN.pdf
>
>
>
> 73 Remi F6CNB/AG5IR
>
>
>
>
3:27 p.m.
On Sun, Feb 19, 2017 at 6:35 AM, Jim Hankins <jim(a)hankinsbay.com> wrote:
This is encouraging. I agree with slide 60, being
new to this, the on boarding has been slow and mysterious. I.e. What specifically is
required in the request, length of time between responses in the request adds a dampening
effect, even if not intended.
In my observation, this is the single greatest problem with AMPR.
Nearly everyone new I have talked to about AMPR reports one of the two
things:
- "I requested a block and never heard back, so I thought the project
was dead. How long does it normally take? It's been a month so far."
- "I requested a /24 for my project linking nnn machines and only got
a /30, so I've had to NAT RFC1918 space and don't really use the AMPR
side for much."
To me, these problems are unacceptable. There are so many subscribers
here who would be willing to join the coordination team and are
competent at assessing block size needs. We need to have multiple
coordinators for each region, so that no coordinator is a single point
of failure.
I'd also like to see some metrics on time-to-allocation, and how often
allocation sizes are different than request sizes (especially
interesting would be comparing this to the utilization of the parent
block--I have a hunch coordinators are being stingy with assignments
when there's no need to be). Once we have some metrics we could set
reasonable goals. Off the cuff, 48 hours to receive an allocation
seems reasonable. I wonder what percent of allocations meet that goal
currently.
If the holdback is technical, I'd be willing to make the required
portal modifications myself. Please send the source code so that I can
get to work.
Tom KD7LXL
3:57 p.m.
Thanks Tom,
I am available to help as well if there is a technical need on the portal. Perhaps we can
collaborate.
I am a software developer working in the commercial emergency communications space.
Hopefully my allocation will be approved soon so I can get to work being a contributing
part of the community.
73
Jim, KD8MTY
Sent from my iPhone
On Feb 19, 2017, at 3:27 PM, Tom Hayward
<esarfl(a)gmail.com> wrote:
KD7LXL
4:15 p.m.
Hey Tom,
I don't know about others, but for me it took almost a month before getting an
allocation. I also heard the same timeframe from a friend before he got his. Still
wondering how long it will take to get a second allocation to play with bgp setups, but
first I need to get myself connected with the current allocation.
If I can be of help to anyone, please do not hesitate to contact me.
73, ON3RVH
On 19 Feb 2017, at 21:28, Tom Hayward
<esarfl(a)gmail.com> wrote:
(Please trim inclusions from previous messages)
_______________________________________________
On Sun, Feb 19, 2017 at 6:35 AM, Jim Hankins
<jim(a)hankinsbay.com> wrote:
This is encouraging. I agree with slide 60, being new to this, the on boarding has
been slow and mysterious. I.e. What specifically is required in the request, length of
time between responses in the request adds a dampening effect, even if not intended.
In my observation, this is the single greatest problem with AMPR.
Nearly everyone new I have talked to about AMPR reports one of the two
things:
- "I requested a block and never heard back, so I thought the project
was dead. How long does it normally take? It's been a month so far."
- "I requested a /24 for my project linking nnn machines and only got
a /30, so I've had to NAT RFC1918 space and don't really use the AMPR
side for much."
To me, these problems are unacceptable. There are so many subscribers
here who would be willing to join the coordination team and are
competent at assessing block size needs. We need to have multiple
coordinators for each region, so that no coordinator is a single point
of failure.
I'd also like to see some metrics on time-to-allocation, and how often
allocation sizes are different than request sizes (especially
interesting would be comparing this to the utilization of the parent
block--I have a hunch coordinators are being stingy with assignments
when there's no need to be). Once we have some metrics we could set
reasonable goals. Off the cuff, 48 hours to receive an allocation
seems reasonable. I wonder what percent of allocations meet that goal
currently.
If the holdback is technical, I'd be willing to make the required
portal modifications myself. Please send the source code so that I can
get to work.
Tom KD7LXL
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
4:23 p.m.
On Sun, Feb 19, 2017 at 03:57:44PM -0500, Jim Hankins wrote:
Hopefully my allocation will be approved soon so I can
get to work being a contributing part of the community.
73
Jim, KD8MTY
Your allocation request has been in the queue a few hours over 3 days.
It should be handled soon.
- Brian
4:52 p.m.
I just checked all of the outstanding allocation requests in the portal,
and with the exception of Finland and Italy, the volunteer coordinators
seem to be on top of things.
There are 17 requests in the queue; 4 for Italy, 5 for Finland, and 5
that are datestamped today. The remaining 3 are more than a week old.
I believe that a week at most should be our goal.
As always, specific complaints about coordination may be sent to me for
resolution.
- Brian
5:08 p.m.
On Sun, Feb 19, 2017 at 1:52 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
I believe that a week at most should be our goal.
As always, specific complaints about coordination may be sent to me for
resolution.
- Brian
Okay, a technical solution here, and one that I am volunteering to
implement, would be an automatic email to you (or maybe another group
of supervisory coordinators that you appoint) after an application has
been pending for a week. You could then grant the allocation yourself.
Hopefully that would be enough to keep new people involved when the
regional coordinator fails to make an allocation in a reasonable time
frame. Sound reasonable?
Tom KD7LXL
5:35 p.m.
On 20/02/2017 7:27 AM, Tom Hayward wrote:
- "I requested a block and never heard back, so I
thought the project
was dead. How long does it normally take? It's been a month so far."
- "I requested a /24 for my project linking nnn machines and only got
a /30, so I've had to NAT RFC1918 space and don't really use the AMPR
side for much."
I did have to wait a few weeks for my block, but that was only
because
the coordinator here happened to be away on vacation at the time - just
a case of bad timing on my part. Once they were back on deck, my
request was dealt with promptly. The second problem didn't arise
either, I was allocated a /24. Still working towards putting it to air
in my local area. Obviously this is a region/area specific issue.
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
5:41 p.m.
Thanks Tom. The portal already automatically sends reminder notices
to coordinators with outstanding allocation requests, twice a month.
If all the coordinators agree, we could change that to weekly.
I find that the coordinations which take more than a few minutes to handle
are those where the requester is confused and asking for something that
is not sensible, so an email exchange is necessary to get the request
straightened out. And it takes time to verify that the requester has
supplied a valid callsign that matches his name. You might be surprised
at how many folks just want a block of addresses and make up a callsign
to try to get some. We've even had cases where the person registered
a friend of his who is a ham but who has no interest in AMPRNet; they
just were stealing his identity to get a block of addresses.
And there are the BGP announced allocations, which require them to fill in
an additional form by email. (It's at this point that I often find out
that the person has no idea what BGP is and just checked the box out of
whim, or hasn't asked his ISP if they'll announce a block for him, etc.)
As for me granting coordinations, for historical reasons, each coordinator
may have his own way of allocating subnets. Since I can't know all
those schemes, it's not practical for me to just take a stab at it.
This is a volunteer organization, and people devote their time to it
as their schedule permits. I think the great majority of the volunteer
coordinators are doing a good job, and I don't think the system is broken.
When a coordinator seems to be unresponsive, I contact them to ask if I
can help. On these rare occasions, the allocation request just slipped
into a crack and a simple reminder is all that's necessary. If they
don't respond, I find another coordinator by looking for volunteers.
- Brian
On Sun, Feb 19, 2017 at 02:08:58PM -0800, Tom Hayward wrote:
Okay, a technical solution here, and one that I am
volunteering to
implement, would be an automatic email to you (or maybe another group
of supervisory coordinators that you appoint) after an application has
been pending for a week. You could then grant the allocation yourself.
Hopefully that would be enough to keep new people involved when the
regional coordinator fails to make an allocation in a reasonable time
frame. Sound reasonable?
Tom KD7LXL
6:04 p.m.
On Sun, Feb 19, 2017 at 2:41 PM, Brian Kantor <Brian(a)ucsd.edu> wrote:
Thanks Tom. The portal already automatically sends
reminder notices
to coordinators with outstanding allocation requests, twice a month.
If all the coordinators agree, we could change that to weekly.
I find that the coordinations which take more than a few minutes to handle
are those where the requester is confused and asking for something that
is not sensible, so an email exchange is necessary to get the request
straightened out. And it takes time to verify that the requester has
supplied a valid callsign that matches his name. You might be surprised
at how many folks just want a block of addresses and make up a callsign
to try to get some. We've even had cases where the person registered
a friend of his who is a ham but who has no interest in AMPRNet; they
just were stealing his identity to get a block of addresses.
And there are the BGP announced allocations, which require them to fill in
an additional form by email. (It's at this point that I often find out
that the person has no idea what BGP is and just checked the box out of
whim, or hasn't asked his ISP if they'll announce a block for him, etc.)
As for me granting coordinations, for historical reasons, each coordinator
may have his own way of allocating subnets. Since I can't know all
those schemes, it's not practical for me to just take a stab at it.
This is a volunteer organization, and people devote their time to it
as their schedule permits. I think the great majority of the volunteer
coordinators are doing a good job, and I don't think the system is broken.
When a coordinator seems to be unresponsive, I contact them to ask if I
can help. On these rare occasions, the allocation request just slipped
into a crack and a simple reminder is all that's necessary. If they
don't respond, I find another coordinator by looking for volunteers.
- Brian
I agree that most of the time the system works adequately. I
absolutely believe there's room for improvement.
Automatic systems can be used to verify callsigns, eliminating much of
the latency in legitimate requests. Multiple schemes could be used
including using HTTPS with Logbook of the World certificate based
client verification (we use this method for authentication within the
HamWAN network, both with and without encryption). Databases like FCC
ULS could be automatically cross-referenced in cases where they didn't
present a certificate. When automatic methods are exhausted, the
request can be dropped into a queue for manual verification. This
verification queue can be handled by any responsible volunteer,
freeing up the coordinators' time to focus on actual allocations.
For BGP, application form labeling and fields can be improved so there
are fewer accidental selections. By adding the NSP fields to the
application, you could save the time it takes to ask for more
information and generate your form letter.
To support assistant coordinators (eliminating single point of
failure), there could be a section for the coordinator to document
their allocation plan logic. If documented properly, anyone could
allocate space to the coordinator's specification without the
coordinator having to take any action. This also provides an
opportunity for peer review in cases of misguided allocation schemes
(such as breaking up a state block by county).
I appreciate the time you've taken to enumerate these challenges so
that we can discuss ways to improve them. I'd love to help improve the
AMPR systems.
Tom
9:04 p.m.
Hi Brian,
Thank you. The original allocation addition was the 8th. There has been some back and
forth with a fair amount of time in between. I was thinking what would be helpful is if
there was specific information required, it would be good to prompt for it ahead of time.
In reading through these threads, it appears there can be some variance in what may be
required by each coordinator. Perhaps instead of free form text block there could be a
means to prompt for some of the information that would be considered qualifying fields.
In my case I got asked for protocols and number of hosts as an example. Prior to that I
got the question. What are you doing with it? Some time was lost by not having enough
information in the original request that would provide the coordinator the information
they needed. So if you flagged some additional mandatory fields that might be helpful.
In your form you provide a subnet choice. Perhaps you also prompt the user for number of
hosts, number of subnets and protocols if that is something that coordinators will need.
When the time between messages is measured in days, getting as close to a “complete"
allocation request at the outset would be a real time saver.
I had further confusion in that it appeared the coordinator I was working with and sent an
email to as a welcome (as suggested) that initially got a response, it appeared the domain
for his email was parked per it’s webpage so I was concerned that perhaps there was a
delay due to this. I sent out a message as such to the contact us page for amprnet
flagging this. Perhaps it’s a non-issue as I did later get a request from the site for
further information which I responded.
Regards,
Jim
On Feb 19, 2017, at 4:23 PM, Brian Kantor
<Brian(a)UCSD.Edu> wrote:
> Jim, KD8MTY
2643
days inactive
2644
days old
13 comments
8 participants
participants (8)
-
Bill Vodall -
Brian Kantor -
F6CNB -
Jim Hankins -
K7VE - John -
Ruben ON3RVH -
Tom Hayward -
Tony Langdon