search

SpriteLink / NIPAP

Neat IP Address Planner - NIPAP is the best open source IPAM in the known universe, challenging classical IP address management (IPAM) systems in many areas.
https://spritelink.github.io/NIPAP/
MIT License
536 stars 132 forks source link

Consider renaming prefix type 'assignment' to something else #376

Open plajjan opened 11 years ago

plajjan commented 11 years ago

So the prefix type called 'assignment' seems to cause some confusion. We were probably aware that it would already back when we named it.. but perhaps we should have put more energy into considering alternative names.

The number one mixup is naturally with what RIPE calls an assignment. The day we build some RIPE integration and actually introduce a variable for this, it will probably become more apparent that NIPAPs prefix type is not to be confused with the RIPE assignment. But even so, it might be a good idea to rename it.

We should probably try to do this before 1.0. Better a little confusion now than a lot more a little later.

Could something as simple as 'network' be a better choice than 'assignment'?

ajburns commented 11 years ago

Better to simply allow the user to select the label text. This also applies to "Order ID" and node.

plajjan commented 11 years ago

@ajburns perhaps so, but I think we should have as sane of a default as we can. Letting users change what a attribute (column in the database) is called is not really something I see us doing (but I'm willing to discuss it ;). It causes confusion and IMHO it does not add much value - why would I need to rename "description" into something else?

Adding new attributes on the other hand is a different thing and if/when we have some more generic AVP store in place we could perhaps ditch the order_id and just let it be stored as an AVP in which case the user could decide to not have that column at all. I understand that IPlan does something similar with some form of configuration templates for extra values. If you have an idea, feel free to open up an issue with your suggestions or join #NIPAP on freenode to have a chat :)

malaiam commented 11 years ago

If you want to avoid confusion with the RIPE naming then renaming it to 'network' might help. I actually prefer it to 'assignment'. The rule of thumb in the help section actually helps understanding the types better: "[..] you will likely find 'assignments' in the routing table while most 'reservations' will not be in your routing table (except for large aggregates)."

Another idea would be to add the help popup (like for the country) to each of the radio buttons showing the prefix types.

giganteous commented 11 years ago

I think the name is good as it is.

After having tried to import my current administration into NIPAP, I think that the current 'assigned' is actually the same thing. If it is in the routing table, it probably should have a registration object in the whoisdatabase, and therefore it is an assignment.

I cannot find a reason to create another layer with the RIPE assignments, and have the whois administration with it, if most of these objects will have a (close to) 100% match with what is currently named 'assignment' in NIPAP.

My €0.02.

plajjan commented 10 years ago

This goes together with #530.