[44net] Re: AMPR Portal Cut-over 1 Month Later

On Fri, May 3, 2024 at 7:28 AM Charles J. Hargrove via 44net <44net(a)mailman.ampr.org> wrote: I'm happy to share my own (limited) perspective. Overall, I'd say it's a mixed bag. Let's start with the good: 1. Self-service DNS is very nice. It always struck me as a bit of an administrative burden that the coordinators had to get involved just to set up RR's in existing allocations. People have always been very gracious about it (thank you, Charles) but I also felt kind of sheepish asking, because I knew I was asking to take someone else's time. If I just want to change a hostname or add a record, this is much easier and I think will lend itself well to experimentation. 2. The portal itself is much _nicer_, from an aesthetic standpoint. Visually it's easier to use and better organized. 3. The use of 2FA seems like a net positive. Ok, the not-as-good, along with suggestions for improvement. 1. The roll-out was rocky. This is known; 'nuff said. Suggestion: It probably would have helped to have an extended "beta-test" period and a staged roll-out, inviting some set of users (maybe the coordinators?) to use it with dummy data, point out the flaws, etc. Some of the kinks with ticket permissions and the partial rollback might have been discovered and worked out ahead of time. 2. Communication: the change-over seemed rather abrupt. Perhaps I just wasn't paying sufficient attention, but my sense is that we'd heard that a new portal was coming and then poof, there it was. While that in and of itself is not a problem, things are sufficiently different that there are outstanding questions about e.g. the role of coordinators. Suggestion: more proactive communication with stakeholders in the existing organizational structure might have smoothed that out. A heads up with an FAQ for end-users addressing what's changing and how the new portal works could have reduced some confusion. 3. The "Level of Trust" mechanism seems a little under-developed and confusing. For instance, I've completed all of the automated verifications, yet I still haven't accumulated enough trust points to request a /24, even though I've already got a /24 allocated to me! That feels vaguely off. There's no clear relationship between the number of points one has and what sort of allocation one can request, etc. Further, it almost feels like a bit of a game: the next step is to request validation with a validator, but a) it's unclear exactly how, and b) as explained on the portal, there's no upper bound to the number of points one can request. Multiple meetings with validators gains one more points, but one wonders why? If I show an identifying document to a person who is, one presumes, trusted enough to say, "yes, this person showed a valid ID and I believe that they are who they say that they are" what is the utility of repeating that process over and over? Suggestion: streamline the LoT thing, and document it so that people know exactly what they have to do to get validated to a level to request whatever sized allocation they want or need. 4. I'm a bit disappointed that the source code isn't available for inspection. Yes, I get that this can result in endless bikeshedding ("why didn't you use _my_ favorite programming language?") but I also think it's important as a precedent. This is an experimental hobby; we should be sharing things like this in a spirit of openness. I'm a working software engineer, and my company makes rack-scale servers. We do software/hardware codesign from web-based consoles down to the board/FPGA/ASIC level; yet we open-source whatever we can, both software and hardware, modulo legal requirements involving third-parties. We do this because we firmly believe it is best for our users. It can be done! Suggestion: open source the portal (and other code, as applicable!) under an OSI-approved license. Anyway, that's my 2c. - Dan C. (KZ2X)