plajjan
commented
10 years ago Naturally, we should try to make our support as RIR neutral as possible but given that RIPE is the only one that I have experience with, it's a natural place to start at least. While routes and AS-numbers would be nice to support, this issue should focus on inetnum & inet6nums as that is what is most needed.
Inetnum;
inetnum: [mandatory] [single] [primary/lookup key]
netname: [mandatory] [single] [lookup key]
descr: [mandatory] [multiple] [ ]
country: [mandatory] [multiple] [ ]
geoloc: [optional] [single] [ ]
language: [optional] [multiple] [ ]
org: [optional] [single] [inverse key]
admin-c: [mandatory] [multiple] [inverse key]
tech-c: [mandatory] [multiple] [inverse key]
status: [mandatory] [single] [ ]
remarks: [optional] [multiple] [ ]
notify: [optional] [multiple] [inverse key]
mnt-by: [mandatory] [multiple] [inverse key]
mnt-lower: [optional] [multiple] [inverse key]
mnt-domains: [optional] [multiple] [inverse key]
mnt-routes: [optional] [multiple] [inverse key]
mnt-irt: [optional] [multiple] [inverse key]
changed: [mandatory] [multiple] [ ]
source: [mandatory] [single] [ ]We will need to introduce a few more attributes for our prefixes to be able to do this.
- inetnum / inet6num: obviously we have this value, just need to output it in a different format
- netname: this is the name of the assignment RIPE has granted a LIR. Should probably be free text but we could do completion (based on previously entered values) to simplify things for users.
- descr: Could be the description of the prefix, perhaps by default it should be but I think it should be possible to override it.
- org: Need new value. Text type. Completion as for netname.
- admin-c: Need new value. Text type. Completion as for netname.
- tech-c: Need new value. Text type. Completion as for netname.
- status: Needs new value. Could be text or perhaps an enum. NIPAP could possibly help filling this in based on what the parent is, ie if parent is ASSIGNED PA, it is very likely the child should be ASSIGNED PA. How do other RIRs handle it?
- mnt-by: Needs new value. Text type. Completion as for netname.
- mnt-lower: Needs new value. Text type. Completion as for netname.
- mnt-routes: Needs new value.
- mnt-domains: Needs new value.
- changed: We should be able to figure out the change line automatically. It is typically the email address of the user that did the change. We could perhaps fetch email from LDAP. What about local auth engine? What if no email is entered in LDAP or local auth engine? Should we have a fallback?
- source: Name of the RIR, simply "RIPE" for our RIPE support.
How should we handle fields that can take multiple values? Simply an array of texts?
The descr value could potentially also be a multi-line value, so perhaps the same thing with an array of text. If the prefix description is long, should we automatically wrap it into multiple descr lines? Need to store a flag (boolean) if the user overrides the value of descr manually or if it should be copied.
Given that the inetnum object for a prefix could already exist in the RIPE whois db, we need a way to fetch the current object and store that somewhere and then use some of the values from it when we push an update for our new object. For example, RIPE typically puts RIPE-NCC-HM-PI-MNT for all PI assignments and they become rather unhappy if it is removed.
I think it's okay that the output format is fixed, as in the order of fields could be in the same order at all times. Having a custom order would make things a lot more complex without adding much.
fischa
Support for pushing updates to RIPE about inetnums, routes and so forth would be pretty sweet.