-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for "::" notation to GraphQL API #917
Comments
I raised a PR because after a brief look at the code, I discovered this wouldn't be much work 👍 |
Based on #918 (comment), it seems like the idea is to abandon the :: syntax and make an enhancement to the available graphql queries. Can we rename this issue to reflect the change in direction? Incidentally, this is something I would definitely use. My preferred source ordering (RPKI, auth RIR, auth NIR, nonauth) chooses empty or incorrect objects in several cases (notably, AS-GOOGLE). In the meantime, my alternative for pinning the root object when doing a recursive AS-SET query is to query for the direct members of the AS-SET with the specific known-correct source I manually set, then recursively resolve prefixes from all returned member objects with my normal selection of sources. Not ideal and not very efficient. The ability to do this in a single query would be much better! |
I finally have some time to work on this request again. I have updated the name of this issue and will look into this soon. |
Is your feature request related to a problem? Please describe.
members
but the RADB AS-SET is empty)sources
option, this is used no only to get this AS-SET but also for the recursive expansion of all of the members of the AS-SET. There is no way to specify the source for the root object only.EDIT: Another example is that AS-FOO exists in two or more IRR-DBs, and let's say the one in ARIN is the real one (created by the network operator) and the one in ALTDB is someone trying to hijack the AS-SET name. Or another example, AS-FOO exists in two IRR-DBs but the operator lost access to one and it doesn't have all the information the second one does. So we need a way to specify which IRR-DB should be used.
Describe the solution you'd like
Describe alternatives you've considered
None.
Additional context
I would be happy to look into the code base to see if this is something I could create a pull request for. I want to check before hand what you think before I spend a load of time on this.
The text was updated successfully, but these errors were encountered: