On Sun, Feb 19, 2017 at 6:35 AM, Jim Hankins jim@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

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

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@gmail.com wrote:

(Please trim inclusions from previous messages) _______________________________________________

...

On Sun, Feb 19, 2017 at 6:35 AM, Jim Hankins jim@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@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

On Sun, Feb 19, 2017 at 1:52 PM, Brian Kantor Brian@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

On Sun, Feb 19, 2017 at 2:41 PM, Brian Kantor Brian@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