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
Extend authentication to include parent/related objects #127
Comments
@job Can you verify that the above is correct for the phase 2 part 1a improvements to authorisation? |
We can schedule this one for |
this example workflow has too many authorisation barriers compared to what RIPE NCC's IRR auth model looks like these days:
Lifting some restrictions (compared to original RPSL) should make the system user friendlier, without reducing its effectiveness. Is what I propose as authorization workflow amendment possible? |
Yes, definitely. That covers route(6) objects, how about aut-num, *-set, domain and inetnum(6)? |
@job In #376 there is an implementation of this. Quoting from the new docs:
If authorisation fails on the parent object, a notification is sent to the Sound good? |
Other thought: should including this check be a setting, default enabled? I wonder whether there are some use cases where people don't want this check. Making it opt-out is fairly simple. |
this sounds great |
Some of the work discussed in #92 was determined out of scope for phase 1, and therefore #21. This will be part of a proposed phase 2.
Here are the docs that were already written to describe the desired process for phase 2:
The text was updated successfully, but these errors were encountered: