Colleagues For many years people have been asking for a way to assign a whole allocation without having to create 2 smaller assignments. The situation is more relevant now with so many /24 allocations. After the RIPE NCC rejected the idea of a dual primary key, for technical reasons, there were two options on the table. Making the "status:" attribute multiple or creating a new status value 'ALLOCATED-ASSIGNED PA'. No one has objected to either of these options. The co-chairs therefore recommend the option put forward by the RIPE NCC to add a new status value 'ALLOCATED-ASSIGNED PA'. Of the two options, this is probably the simplest and likely to cause less problems with user's scripts that parse objects. If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report. cheers denis co-chair DB-WG
denis walker via db-wg wrote on 04/04/2022 13:38:
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use.
Denis, This came up in an email of yours from February: https://www.ripe.net/ripe/mail/archives/db-wg//2022-February/007295.html
The chairs make no recommendation on this item. But if there is no discussion we will simply mark NWI-4 as cancelled.
and here: https://www.ripe.net/ripe/mail/archives/db-wg//2022-February/007314.html
Is this a problem that you think needs to be solved? If 'yes' then we need to hear your thoughts. If 'no' then the chairs will cancel NWI-4 and move on...
Was there any discussion about why this changed from: "not going to implement" to "going to implement"? Separately, has there been any discussion about this new status value, "ALLOCATED-ASSIGNED PA"? This is a significant change to the semantics of this key, and it's one which will cause breakage in the wild. Nick
Hi Nick Many people have asked for a solution to this problem over recent years. The chairs have tried to get some discussion on the topic many times. Perhaps now we can have that discussion... Cheers denis Co-chair DB-WG On Mon, 4 Apr 2022, 14:55 Nick Hilliard, <nick@foobar.org> wrote:
denis walker via db-wg wrote on 04/04/2022 13:38:
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use.
Denis,
This came up in an email of yours from February:
https://www.ripe.net/ripe/mail/archives/db-wg//2022-February/007295.html
The chairs make no recommendation on this item. But if there is no discussion we will simply mark NWI-4 as cancelled.
and here:
https://www.ripe.net/ripe/mail/archives/db-wg//2022-February/007314.html
Is this a problem that you think needs to be solved? If 'yes' then we need to hear your thoughts. If 'no' then the chairs will cancel NWI-4 and move on...
Was there any discussion about why this changed from: "not going to implement" to "going to implement"?
Separately, has there been any discussion about this new status value, "ALLOCATED-ASSIGNED PA"? This is a significant change to the semantics of this key, and it's one which will cause breakage in the wild.
Nick
denis walker wrote on 04/04/2022 16:16:
Many people have asked for a solution to this problem over recent years. The chairs have tried to get some discussion on the topic many times. Perhaps now we can have that discussion...
Sounds good - so long as the discussion comes before the solution! :-) Nick
On Mon, 4 Apr 2022 at 17:41, Nick Hilliard <nick@foobar.org> wrote:
denis walker wrote on 04/04/2022 16:16:
Many people have asked for a solution to this problem over recent years. The chairs have tried to get some discussion on the topic many times. Perhaps now we can have that discussion...
Sounds good - so long as the discussion comes before the solution! :-)
Maybe you can start by explaining why this change 'will' cause breakage in the wild and how significant that breakage will be. cheers denis co-chair DB-WG
Nick
denis walker wrote on 04/04/2022 17:00:
Maybe you can start by explaining why this change 'will' cause breakage in the wild and how significant that breakage will be.
Denis, you were clear in your email earlier today that you believe that your proposed solution for NWI-4 will cause problems. This is a good thing to put on the table because it allows for the possibility of discussing what level of breakage you think may be involved with your proposal. The more important issue is that as chair, you previously said that if there were no interest expressed in progressing NWI-4, that it would be dropped. But this turned into a request to the RIPE NCC to produce an impact / implementation report on a specific proposed solution, without any community discussion or any indication of consensus. If you want to propose some technical solutions to deal with this issue, I'm sure everyone would welcome this - although it would be normal to recuse yourself from the consensus call in this sort of situation. Nick
Hi Denis, That would be great to have a way to assign a whole allocation without splitting it to smaller assignments. I support the idea of having a new status value. Regards, Arash Naderpour On Mon, Apr 4, 2022 at 10:39 PM denis walker via db-wg <db-wg@ripe.net> wrote:
Colleagues
For many years people have been asking for a way to assign a whole allocation without having to create 2 smaller assignments. The situation is more relevant now with so many /24 allocations. After the RIPE NCC rejected the idea of a dual primary key, for technical reasons, there were two options on the table. Making the "status:" attribute multiple or creating a new status value 'ALLOCATED-ASSIGNED PA'. No one has objected to either of these options. The co-chairs therefore recommend the option put forward by the RIPE NCC to add a new status value 'ALLOCATED-ASSIGNED PA'. Of the two options, this is probably the simplest and likely to cause less problems with user's scripts that parse objects.
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report.
cheers denis co-chair DB-WG
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi, On Mon, Apr 4, 2022 at 5:39 AM denis walker via db-wg <db-wg@ripe.net> wrote: [...]
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report.
I don't object to addressing this. But I think there are some implicit assumptions in the text from 2016. I'd like to understand if there is a technical need for exact match assignments that duplicate all the contact and other information from the /24 allocation. Or is the issue that there is some policy or administrative need? Kind regards, Leo
Hi Leo On Mon, 4 Apr 2022 at 19:08, Leo Vegoda <leo@vegoda.org> wrote:
Hi,
On Mon, Apr 4, 2022 at 5:39 AM denis walker via db-wg <db-wg@ripe.net> wrote:
[...]
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report.
I don't object to addressing this. But I think there are some implicit assumptions in the text from 2016.
I'd like to understand if there is a technical need for exact match assignments that duplicate all the contact and other information from the /24 allocation. Or is the issue that there is some policy or administrative need?
This suggestion avoids the need to duplicate any contact or other details. No additional objects need to be created. The status is changed from 'ALLOCATED PA' to 'ALLOCATED-ASSIGNED PA' in the allocation object. "descr:' and "country:" are multiple attributes so the end user can be identified here. If the end user has their own abuse contact that can be represented with an "abuse-c:" in the allocation object. The resource holder's abuse contact is still referenced through their referenced ORGANISATION object. So it allows a whole allocation to be documented in the database as an assignment without having to duplicate any data or create multiple objects. cheers denis co-chair DB-WG
Kind regards,
Leo
HI Denis, On Mon, Apr 4, 2022 at 10:45 AM denis walker <ripedenis@gmail.com> wrote:
On Mon, 4 Apr 2022 at 19:08, Leo Vegoda <leo@vegoda.org> wrote:
[...]
If there are no objections to this, the co-chairs now ask the RIPE NCC to produce an impact/implementation report to add this new status value and include the business rules to restrict it's use. We will then seek a final approval from the community on the report.
I don't object to addressing this. But I think there are some implicit assumptions in the text from 2016.
I'd like to understand if there is a technical need for exact match assignments that duplicate all the contact and other information from the /24 allocation. Or is the issue that there is some policy or administrative need?
This suggestion avoids the need to duplicate any contact or other details. No additional objects need to be created. The status is changed from 'ALLOCATED PA' to 'ALLOCATED-ASSIGNED PA' in the allocation object. "descr:' and "country:" are multiple attributes so the end user can be identified here. If the end user has their own abuse contact that can be represented with an "abuse-c:" in the allocation object. The resource holder's abuse contact is still referenced through their referenced ORGANISATION object. So it allows a whole allocation to be documented in the database as an assignment without having to duplicate any data or create multiple objects.
I think we might be misunderstanding each other. I am trying to understand the reason two layers of registration are needed if everything being registered is identical. In the olden days, some ISPs offered static IP dial-up accounts and we'd just add a description to that effect in the inetnum for the allocation. No need to create any extra registrations. I'd like to understand if there is any technical or business need for an exact match registration that couldn't be accommodated with a simple change to business rules. Thanks, Leo
On Mon, 4 Apr 2022 at 20:42, Leo Vegoda <leo@vegoda.org> wrote:
HI Denis,
On Mon, Apr 4, 2022 at 10:45 AM denis walker <ripedenis@gmail.com> wrote:
On Mon, 4 Apr 2022 at 19:08, Leo Vegoda <leo@vegoda.org> wrote:
[...]
I'd like to understand if there is a technical need for exact match assignments that duplicate all the contact and other information from the /24 allocation. Or is the issue that there is some policy or administrative need?
This suggestion avoids the need to duplicate any contact or other details. No additional objects need to be created. The status is changed from 'ALLOCATED PA' to 'ALLOCATED-ASSIGNED PA' in the allocation object. "descr:' and "country:" are multiple attributes so the end user can be identified here. If the end user has their own abuse contact that can be represented with an "abuse-c:" in the allocation object. The resource holder's abuse contact is still referenced through their referenced ORGANISATION object. So it allows a whole allocation to be documented in the database as an assignment without having to duplicate any data or create multiple objects.
I think we might be misunderstanding each other. I am trying to understand the reason two layers of registration are needed if everything being registered is identical.
In the olden days, some ISPs offered static IP dial-up accounts and we'd just add a description to that effect in the inetnum for the allocation. No need to create any extra registrations.
I'd like to understand if there is any technical or business need for an exact match registration that couldn't be accommodated with a simple change to business rules.
I think you are arguing here for deleting assignments...that is another discussion... cheers denis co-chair DB-WG
Thanks,
Leo
On Mon, Apr 4, 2022 at 12:34 PM denis walker <ripedenis@gmail.com> wrote: [...]
I think you are arguing here for deleting assignments...that is another discussion...
I'm not arguing for deleting anything. People have stated that they need to register an assignment which is an exact duplicate of the allocation. The only difference would be the value of the status attribute. I don't understand why they need to register an exact match assignment. Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it? What am I missing? Thanks, Leo
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it?
What am I missing?
it's a fly in the ointment. There are three options to handle this situation, possibly more: 1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view. This is what we have at the moment. 2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view. 3. use a different status: value for inetnum objects which are both allocations and assignments. This is, I understand, what Denis was proposing. I.e. the choice is about which fly in the ointment is the least problematic, rather than whether there's a fly in the ointment. Nick
I think the only thing that would really offer a proper solution here is to change the primary key to inetnum + status. (as mentioned in option 2 of Nick's email) Quite a few LIRs do lease out address space and some of them will probably be /24s that are leased out in their entirety. While there is the argument to not encourage this behaviour, I would say that it is going to happen anyways and we should instead try to make sure the database is as accurate as possible. This would require the ability to also set the org attribute and possible admin-c/tech-c, and as such I think being able to have two different inetnum objects for the same prefix is the only solution to this case. Disclaimer: While I am writing this email in a personal capacity and think this is the right thing to do to ensure DB accuracy, sometimes I represent a LIR (towards the RIPE NCC) that would potentially benefit from the idea I am suggesting here. -Cynthia On Mon, Apr 4, 2022 at 10:19 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it?
What am I missing?
it's a fly in the ointment.
There are three options to handle this situation, possibly more:
1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view. This is what we have at the moment.
2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view.
3. use a different status: value for inetnum objects which are both allocations and assignments. This is, I understand, what Denis was proposing.
I.e. the choice is about which fly in the ointment is the least problematic, rather than whether there's a fly in the ointment.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Cynthia On Mon, 4 Apr 2022 at 23:48, Cynthia Revström via db-wg <db-wg@ripe.net> wrote:
I think the only thing that would really offer a proper solution here is to change the primary key to inetnum + status. (as mentioned in option 2 of Nick's email)
Forget this option. It cuts too deeply into the data model design. The RIPE NCC has already waved many red flags about this and said it is not feasible.
Quite a few LIRs do lease out address space and some of them will probably be /24s that are leased out in their entirety.
While there is the argument to not encourage this behaviour, I would say that it is going to happen anyways and we should instead try to make sure the database is as accurate as possible.
A large proportion of the /24 allocations made by the RIPE NCC went to existing Members who set up multiple subsidiary (shell) companies, each with multiple LIRs specifically to get as much of the available, remaining IPv4 address space as possible. A lot of these allocations are currently rented out to other LIRs. Some Members are now operating as commercial RIRs below the level of the RIPE NCC. This rented address space is not at all accurately represented in the RIPE Database. The current system does not accommodate commercial RIRs. The status of these resources and the usage is all wrong in the database and many of the contacts are pretty much useless.
This would require the ability to also set the org attribute and possible admin-c/tech-c, and as such I think being able to have two different inetnum objects for the same prefix is the only solution to this case.
To do it right, accepting that there are now commercial RIRs operating in the region with resources being 're-alllocated' from resource holder to LIR, would be a very complex task. Adding the status value 'ALLOCATED-ASSIGNED PA' is just the low hanging fruit to cover one situation. cheers denis co-chair DB-WG
Disclaimer: While I am writing this email in a personal capacity and think this is the right thing to do to ensure DB accuracy, sometimes I represent a LIR (towards the RIPE NCC) that would potentially benefit from the idea I am suggesting here.
-Cynthia
On Mon, Apr 4, 2022 at 10:19 PM Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it?
What am I missing?
it's a fly in the ointment.
There are three options to handle this situation, possibly more:
1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view. This is what we have at the moment.
2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view.
3. use a different status: value for inetnum objects which are both allocations and assignments. This is, I understand, what Denis was proposing.
I.e. the choice is about which fly in the ointment is the least problematic, rather than whether there's a fly in the ointment.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
Hi Nick, Leo,
On 4 Apr 2022, at 22:19, Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it? What am I missing?
it's a fly in the ointment.
There are three options to handle this situation, possibly more:
1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view. This is what we have at the moment.
2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view.
After Carsten Schiefner first suggested this approach last year, the DB team investigated how to implement a prefix+status tuple for inet(6)num types. The RIPE database already contains a primary key tuple, i.e. the route and route6 object types combine the prefix and origin as the primary key. So it's possible to extend this to inet(6)num types. A primary key tuple must be optional for inet(6)num types, so the existing prefix (only) as primary key continues to work for the common case, but allow the prefix & status tuple to differentiate an identically-sized ALLOCATED PA / ASSIGNED PA hierachy as a special case. However this means supporting *two* forms of primary key which increases complexity (a key could match a single object or multiple objects, currently a key can only match a single object). Adding support for an optional status in the primary key means significant re-work in the Whois application. The code base is currently built around the inet(6)num prefix as the primary key, and a given key matches only a single object. Changing this will involve significant effort and risk of changing core functionality. For route(6) authorisation, there is an ambiguity in which prefix to use, if there are multiple matches of the same size. Do we allow authorisation against either the ALLOCATED PA prefix or the ASSIGNED PA prefix, or both? Clients will also need to be updated. If a client queries by prefix alone, this can match one or multiple objects. A client will need to include the status when querying to identify a single object. Including a space in the primary key tuple (due to the status value) will also increase complexity, as a space can't be used as a separator but it's part of the key. In summary, adding support for a primary key and status tuple will be a very expensive (time and effort) change on the Whois server side, and will also necessitate client-side changes. Regards Ed Shryane RIPE NCC
Colleagues Over the years we have made many changes to the status values. For the INETNUM status we added 'LIR-PARTITIONED PA' and 'LIR-PARTITIONED PI', then later removed 'LIR-PARTITIONED PI'. We added and then later removed another status similar to the partitioned (can't remember the name now). We deprecated 'ALLOCATED PI'. We changed the rules on 'LEGACY' so that the whole hierarchy became 'LEGACY'. We changed the rules on assignments to prevent hierarchies of assignments. For the INET6NUM I think 'ASSIGNED PI' was not available originally and was added later. We added "status:" as a new attribute to the AUT-NUM object with three values. I don't remember discussions about anything breaking with any of these changes we made over the years. So can Nick, or anyone, tell us what will break now, that didn't break before, if we add a new status value 'ALLOCATED-ASSIGNED PA'? cheers denis co-chair DB-WG On Mon, 4 Apr 2022 at 22:19, Nick Hilliard via db-wg <db-wg@ripe.net> wrote:
Leo Vegoda via db-wg wrote on 04/04/2022 20:50:
Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it?
What am I missing?
it's a fly in the ointment.
There are three options to handle this situation, possibly more:
1. don't allow an allocation + an assignment to encompass exactly the same space. This is a function of the data model, which states that inetnum: is the primary key. This stops organisations from having a 1:1 mapping between their internal assignment databases and the public ripedb view. This is what we have at the moment.
2. change the ripedb data model to key on inetnum+status. This would allow an assignment and an allocation to have the same inetnum, which would allow organisations to have a 1:1 mapping between their internal assignment databases and the public ripedb view.
3. use a different status: value for inetnum objects which are both allocations and assignments. This is, I understand, what Denis was proposing.
I.e. the choice is about which fly in the ointment is the least problematic, rather than whether there's a fly in the ointment.
Nick
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/db-wg
On Mon, 4 Apr 2022 at 21:50, Leo Vegoda <leo@vegoda.org> wrote:
On Mon, Apr 4, 2022 at 12:34 PM denis walker <ripedenis@gmail.com> wrote:
[...]
I think you are arguing here for deleting assignments...that is another discussion...
I'm not arguing for deleting anything.
People have stated that they need to register an assignment which is an exact duplicate of the allocation. The only difference would be the value of the status attribute. I don't understand why they need to register an exact match assignment. Why do they need to register this assignment? Why can the allocation not be left as it is and assumed to be used by the organisation holding it?
What am I missing?
What you are missing is that many, many, many of these /24 allocations are not being used by the resource holder';s organisation. They are assigned to end users. cheers denis co-chair DB-WG
Thanks,
Leo
On Mon, Apr 4, 2022 at 1:43 PM denis walker <ripedenis@gmail.com> wrote: [...]
What am I missing?
What you are missing is that many, many, many of these /24 allocations are not being used by the resource holder';s organisation. They are assigned to end users.
Thanks for stating this clearly. I agree with everyone else that ensuring the published contact data are accurate is most important. Does that require a software solution? Could it be accomplished with a process change? For instance, if an LIR leases a block to a network operator and shares some kind of documentation with the RIPE NCC, could the RIPE NCC delegate control of the contact data to the network operator for the duration of the lease? Kind regards, Leo
On Tue, 5 Apr 2022 at 17:51, Leo Vegoda <leo@vegoda.org> wrote:
On Mon, Apr 4, 2022 at 1:43 PM denis walker <ripedenis@gmail.com> wrote:
[...]
What am I missing?
What you are missing is that many, many, many of these /24 allocations are not being used by the resource holder';s organisation. They are assigned to end users.
Thanks for stating this clearly.
I agree with everyone else that ensuring the published contact data are accurate is most important. Does that require a software solution? Could it be accomplished with a process change? For instance, if an LIR leases a block to a network operator and shares some kind of documentation with the RIPE NCC, could the RIPE NCC delegate control of the contact data to the network operator for the duration of the lease?
It is not only the contact details that are wrong. If an allocation is leased/rented to another LIR how should this be documented in the RIPE Database? Currently many of these blocks are being assigned to the receiving LIR. But they most likely use this address space in the same way as they use all their other allocations. It is quite possible many of these blocks are being sub-assigned by the receiving LIR. But that is not allowed with the database syntax. So the true nature and usage of this address space is unknown. Leasing address space is becoming more common now. Perhaps we need yet another status value for INETNUM objects like 'ALLOCATED-BY-LIR'. So it is possible to reflect that an allocation has been re-allocated to another LIR, who can then assign it. But of course with so many /24 allocations now we are back to the original problem of re-allocation of a whole allocation... cheers denis co-chair DB-WG
Kind regards,
Leo
Hi Denis, On Tue, Apr 5, 2022 at 12:17 PM denis walker <ripedenis@gmail.com> wrote: [...]
I agree with everyone else that ensuring the published contact data are accurate is most important. Does that require a software solution? Could it be accomplished with a process change? For instance, if an LIR leases a block to a network operator and shares some kind of documentation with the RIPE NCC, could the RIPE NCC delegate control of the contact data to the network operator for the duration of the lease?
It is not only the contact details that are wrong. If an allocation is leased/rented to another LIR how should this be documented in the RIPE Database?
What needs to be accomplished and why? Do we need to know the ownership/lease status of address space in the RIPE Database, or is accurate contact and IRR data enough?
Currently many of these blocks are being assigned to the receiving LIR. But they most likely use this address space in the same way as they use all their other allocations. It is quite possible many of these blocks are being sub-assigned by the receiving LIR. But that is not allowed with the database syntax. So the true nature and usage of this address space is unknown.
The RIPE Registry should hold the full set of data - however we define that. But the RIPE Database can display a subset. That is why I am asking whether it makes sense to approach this from the perspective of registering the fact of a lease with the RIPE Registry. That way, we could avoid making changes to the RIPE Database that risk breaking widely deployed tools that rely on the existing data model. And maybe we do need to change the RIPE Database model. But it's worth checking if there's a less disruptive change that could work well for everyone first. Kind regards, Leo
participants (6)
-
Arash Naderpour -
Cynthia Revström -
denis walker -
Edward Shryane -
Leo Vegoda -
Nick Hilliard