[44net] Re: Comments and questions welcome: Portal Features Requirements Document

Hi Rosy and the group, Thanks for sending this, I'm looking forward to trying the new portal and seeing its improvements. I have read the document and made some observations, which I have written here in no particular order, and with the relevant section where I thought that would be helpful: 1. 3.2.1.9: 2FA - can I please request FIDO U2F support? 2. 3.2.1.10: Maidenhead - is there a requirement to gather this, alongside other already identifying information? Users may have different reasons for keeping their location private (i.e. not having to divulge) alongside any other PII that is gathered and appropriately governed in the Portal. 3. 3.2.5 BGP assignments: Perhaps this falls under RADB objects, but my suggestion is to incorporate IRR record management. It would be ideal to incorporate this as an optional part of the portal-based process. 4. 3.2.6 and the mention of '<callsign>ampr.org' reads to me as if call signs are being used as the primary identifier on the Portal. If this is the case, it may prove more versatile and useful to employ some other sort of identifier (username?) as a primary identifier, and allow multiple call-signs to be explicitly supported across the services offered. Users then may easily change or obtain additional callsigns throughout their life, without impact to the services they run. To address the specific point around a callsign subdomain in relation to multiple callsign holders, this would allow users to manage their own cutover without their hosted services stopping abruptly upon changing to a new callsign in the Portal. To make this point clearer in the requirements, 2.2.1.1.1.1 could change to mention callsign(s) (plural) as all associated to a user may need to be verified. 5. I understand that to date the Portal has required a regular login to verify the ongoing interest of the account holder in maintaining their account. Currently the requirements do not distinguish between web-based and API-based access in determining the last time the Portal was accessed. My personal preference is that API-based access be included in the determination of last access time, as any server making an API request on my behalf is likely to perish alongside my interest in maintaining my IP space. Ultimately it would good to clarify the expected behaviour one way or the other, so that all are clear if API-access counts in 'resetting the clock' for access invalidation. 5. Perhaps this is covered by other accessibility requirements, but I would suggest a specific requirement to ensure that the website will support and provide full functionality across typical device sizes (e.g. phone, tablet, desktop web browser). 6. I wondered if prescribing that all work will be in alignment with open source best practices --- without defining these --- might provide a point of contention later, if a user doesn't like the way something is being done, and given the proposed public nature of the codebase. Given too that best practices tend to be dynamic and that it may require some additional work to bring the codebase into line with this requirement whenever a change is made, it might be worthwhile to soften this expectation slightly without undermining its intent. 7. Point 2.1.2.1 may have been intended to enumerate accessibility standards (there is a hanging colon). I may have missed or misunderstood some sections of the document, in which case I beg your pardon if my suggestions are addressed elsewhere in the document or otherwise moot. The requirements document reads very well and it is clear much thought and work has gone into its production. My thanks to the team behind it who are obviously striving to make the Portal an improved experience for all. Regards, -- Joel Buckley VK3LE/VK2VRO On Tue, Sep 27, 2022 at 05:37:31PM -0400, Rosy Schechter - KJ7RYV via 44net wrote: