RIPE NCC to remove mnt-lower RIPE-NCC-END-MNT from ASSIGNED PI objects
Dear colleagues, Sub-assignments of ASSIGNED PI objects are technically possibly in the RIPE Database, but not allowed by RIPE policy. And to prevent that such sub-assignments are created, the RIPE NCC has been including "mnt-lower: RIPE-NCC-END-MNT" on ASSIGNED PI Objects. Nowadays however we prefer to enforce such policy restrictions by the use of special "business rules" and a rule has already been implemented for this particular case. Therefore the RIPE NCC would like to do a bulk change on all ASSIGNED PI objects in the RIPE Database and remove "mnt-lower: RIPE-NCC-END-MNT" where it's present. Since we feel that this operation does not significantly alter the affected objects we plan to suppress sending out notify messages regarding this change, and we will make sure that this change is excluded when the "last-modified:" attribute is added in future. Please let us know if you have any questions or comments. Kind regards, Tim Bruijnzeels Assistant Manager Software Engineering RIPE NCC
On Feb 25, Tim Bruijnzeels <tim@ripe.net> wrote:
Please let us know if you have any questions or comments. Good idea. Is the up to date business logic of the database available somewhere?
-- ciao, Marco
Hi Marco, WG, On 25 Feb 2015, at 13:27, Marco d'Itri <md@Linux.IT> wrote:
On Feb 25, Tim Bruijnzeels <tim@ripe.net> wrote:
Please let us know if you have any questions or comments. Good idea. Is the up to date business logic of the database available somewhere?
The business logic is how we typically implement RIPE policy restrictions on the RIPE database. These restrictions are documented in RIPE policy documents and implementation plans. We understand that this means that the documentation can be somewhat implicit and scattered. Providing a central overview of these rules, the restrictions and reasons (references to policy), in the RIPE database documentation itself was already on our radar, albeit not with the highest priority. If you and the WG indicate that they value having this soon though, we are happy to give this more priority. Regards, Tim Bruijnzeels
Hi Tim, having a document providing a central overview of the business rules, restrictions and the reasons would be very useful to me and all the other database users. regards, elvis On 25/02/15 17:21, Tim Bruijnzeels wrote:
Hi Marco, WG,
On 25 Feb 2015, at 13:27, Marco d'Itri <md@Linux.IT> wrote:
On Feb 25, Tim Bruijnzeels <tim@ripe.net> wrote:
Please let us know if you have any questions or comments. Good idea. Is the up to date business logic of the database available somewhere? The business logic is how we typically implement RIPE policy restrictions on the RIPE database. These restrictions are documented in RIPE policy documents and implementation plans.
We understand that this means that the documentation can be somewhat implicit and scattered. Providing a central overview of these rules, the restrictions and reasons (references to policy), in the RIPE database documentation itself was already on our radar, albeit not with the highest priority. If you and the WG indicate that they value having this soon though, we are happy to give this more priority.
Regards,
Tim Bruijnzeels
Hello,
On 25 Feb 2015, at 13:27, Marco d'Itri <md@Linux.IT> wrote:
Good idea. Is the up to date business logic of the database available somewhere?
On 02/25/2015 06:21 PM, Tim Bruijnzeels wrote:
The business logic is how we typically implement RIPE policy restrictions on the RIPE database. These restrictions are documented in RIPE policy documents and implementation plans.
I think what Marco d'Itri wanted, and what I want in any case, is to see the programme code or logic statements that implement the restrictions documented in RIPE policy documents etc. We as a community want to verify that our wishes are implemented correctly and transparently. Some may even want to point out inaccuracies or offer corrections or performance enhancements. As long as they are within the scope of agreed policy I don't see why this could be a problem. The RIPE DB software is sufficiently large that we'd like a pointer to where we should start looking for said code, instead of going through the whole thing ourselves. Yours sincerely, -- Aleksi Suhonen Let bogons be bogons.
Dear Aleksi, WG,
On 06 Mar 2015, at 04:17, Aleksi Suhonen <ripe-ml-2012@ssd.axu.tm> wrote:
Hello,
On 25 Feb 2015, at 13:27, Marco d'Itri <md@Linux.IT> wrote:
Good idea. Is the up to date business logic of the database available somewhere?
On 02/25/2015 06:21 PM, Tim Bruijnzeels wrote:
The business logic is how we typically implement RIPE policy restrictions on the RIPE database. These restrictions are documented in RIPE policy documents and implementation plans.
I think what Marco d'Itri wanted, and what I want in any case, is to see the programme code or logic statements that implement the restrictions documented in RIPE policy documents etc.
We as a community want to verify that our wishes are implemented correctly and transparently. Some may even want to point out inaccuracies or offer corrections or performance enhancements. As long as they are within the scope of agreed policy I don't see why this could be a problem.
The RIPE DB software is sufficiently large that we'd like a pointer to where we should start looking for said code, instead of going through the whole thing ourselves.
The code for all these additional validations applied to updates can be found here: https://github.com/RIPE-NCC/whois/tree/master/whois-update/src/main/java/net... <https://github.com/RIPE-NCC/whois/tree/master/whois-update/src/main/java/net/ripe/db/whois/update/handler/validator> However, implementation details may not always be obvious without knowing the larger code base, and not everyone can read Java code. For this reason we are also working on a text document listing the existing rules per object type, plus the reasoning and references behind each rule. Doing this properly takes some time, but we are fully committed to providing transparency on these rules to everyone in an easy to understand format. Kind regards, Tim Bruijnzeels
Yours sincerely,
-- Aleksi Suhonen Let bogons be bogons.
participants (4)
-
Aleksi Suhonen -
Elvis Daniel Velea -
md＠Linux.IT -
Tim Bruijnzeels