Portal: Difference between revisions
No edit summary |
No edit summary |
||
| Line 11: | Line 11: | ||
Some manual intervention is encouraged, for example the second, and all subsequent reminder emails and de-activation emails are cc'd to the co-ordinator responsible for the next higher subnet, so they could attempt a more manual approach to remind the person to login - this is to be encouraged as sometimes emails (especially automated ones) can be blocked in spam folders, people change their email address and forget to update the portal, etc. | Some manual intervention is encouraged, for example the second, and all subsequent reminder emails and de-activation emails are cc'd to the co-ordinator responsible for the next higher subnet, so they could attempt a more manual approach to remind the person to login - this is to be encouraged as sometimes emails (especially automated ones) can be blocked in spam folders, people change their email address and forget to update the portal, etc. | ||
== API == | |||
The Portal has an associated [[API]] | |||
Revision as of 18:23, 19 November 2014
We have developed a Portal that allows users of the 44/8 address space to manage their allocations, configure gateway information and manage their entries in the ampr.org domain. The portal can be found here:
If you are looking to get an IP allocation within 44/8 please register on the portal and place your request.
Background
The main problem we faced with the old setup was how to ensure the data we have is accurate and up to date.
The new portal is our answer to that problem: folks register and are allocated an IP or subnet of IP's that they are responsible for. The system doesn't then just let them get on with it - the system is designed to actively ensure that each allocation is still being used, the person must login to the portal on a regular basis, or if they do not, an email will be sent automatically to them asking them to confirm their continued use of the IP(s). If no response is received from the emailed request, two further attempts are made to contact the person, after which the system places their allocation in a de-activated state. The person is able to login and re-activate the allocation for a certain time after de-activation, beyond that time period the allocation will be deleted from the database - thus keeping it all as up to date as is possible.
Some manual intervention is encouraged, for example the second, and all subsequent reminder emails and de-activation emails are cc'd to the co-ordinator responsible for the next higher subnet, so they could attempt a more manual approach to remind the person to login - this is to be encouraged as sometimes emails (especially automated ones) can be blocked in spam folders, people change their email address and forget to update the portal, etc.
API
The Portal has an associated API