DRAFT: Simplifying Number Resource Status
Dear colleagues, following up on my presentation at RIPE 88, please find below a draft version of the policy proposal for simplifying the status of number resource records. I wanted to get this out much earlier, my apologies for the delay. Looking forward to your constructive feedback ahead of next week’s session. Kind regards, Remco van Mook —— Number: (assigned by the RIPE NCC) Policy Proposal Name: Simplifying Number Resource Status Author: Remco van Mook \<remco.vanmook@gmail.com\> Proposal Version: (assigned by the RIPE NCC) Submission Date: TBD Suggested RIPE WG for discussion and publication: Address Policy Proposal Type: modification or deletion Policy Term: Indefinite Summary of proposal: There is about 30 years of history reflected, sometimes poorly, in the status field describing IPv4 and IPv6 resources in the database. This proposal seeks to simplify and harmonise the contents of the status field between IPv4 and IPv6 and limits the field to what has operational relevance, and removes any implied contractual relationship from the status field itself. (Remnants of) address policy define a very rigid model for the RIPE NCC to follow for the structure of its membership, mostly based on rules about the distribution of IPv4. If we want to give the RIPE NCC membership room to evolve its membership structure based on today’s reality we need a clean break with policy and a database that no longer prescribes the RIPE NCC membership model, but rather allows it to accurately reflect reality. Policy text: a. Current policy text (if modification) RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: 5.3 Sub-allocations Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0. LIRs may make sub-allocations to multiple downstream network operators. The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. 7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are: ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist. ALLOCATED-ASSIGNED PA: This address space has been allocated to an LIR and entirely assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider. LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered. LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries. ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. The purpose and the contact details must be consistent throughout the whole assignment. It cannot be kept when terminating services provided by the LIR. ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties. ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services. Registering an inetnum object with a status of “ALLOCATED-ASSIGNED PA” or "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status. Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate. In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. b. New policy text RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region: 5.3 Sub-allocations LIRs may make sub-allocations to multiple downstream network operators. The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations. Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator. 7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered. Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning: Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re-configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses. In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses. The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1. Any allocated or assigned address space status must be registered in accordance with the policy document ‘Address Allocation and Assignment Status’. RIPE-NEW \- Address Allocation and Assignment Status: Abstract This document defines the content of the status field for the assignment and allocation of globally unique IP addresses to Internet Service Providers (ISPs) and other organisations. It exists together with the IPv6 Address Allocation and Assignment Policy which is harmonised between the RIPE, ARIN and APNIC regions as well as the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region. While the status field of inet6num records in the RIPE Database has been mostly inferred from the IPv4 inetnum record as it existed when the first provisional IPv6 Allocation and Assignment policy was defined in RIPE-196, there was no equivalent for Chapter 7 of the IPv4 Address Allocation and Assignment Policy “Types of Address Space” in defined policy. To prevent duplication, this document applies equally to IPv4 inetnum and IPv6 inet6num records. 1.0 Status of Address Space resource records LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum or inet6num object in the RIPE Database for IPv4 and IPv6 registrations, respectively.. The possible values of this attribute are: ALLOCATED: This address space has been allocated to an LIR or downstream network operator and no assignments or sub-allocations made from it are portable. More specific objects may exist in the RIPE database. ASSIGNED: This address space has been assigned to the issuing LIR infrastructure or an End User. More specific objects do not exist in the RIPE database. AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. Each End User has been assigned a block the size of the assignment size in the object. More specific objects do not exist in the RIPE database. 2.0 Mapping of Legacy Status Attributes The following mapping is used to update legacy status attributes: ALLOCATED: - ALLOCATED PA - SUB-ALLOCATED PA - LIR-PARTITIONED PA - ALLOCATED UNSPECIFIED - ALLOCATED-BY-RIR - ALLOCATED-BY-RIR \# This block was actually allocated by the IANA - ALLOCATED-BY-LIR ASSIGNED - ASSIGNED PA - ASSIGNED PI - LEGACY - ASSIGNED ANYCAST Unchanged but added for completeness: AGGREGATED-BY-LIR - AGGREGATED-BY-LIR Rationale: a. Arguments supporting the proposal - Reduces complexity of the status of number resources - Removes the need to attribute origin in the status attribute as that’s inferred from the structure of the database - Focus the database on more accurately reflecting operational reality - Special case/historical documentation is better suited elsewhere - Harmonises IPv4 and IPv6 registrations - Less confusion about usage caused by status \- e.g. most operational anycast space is not in the database as ‘ASSIGNED ANYCAST’ - Facilitates a future decoupling of address policy and NCC membership structure b. Arguments opposing the proposal - Loss of public visibility of contractual relationship - Loss of public visibility of historic/legacy assignments/special cases
Moin, from the top of my head, i see three major issues with the proposal: - No updates RIP-738 as well, leading to a gap between v4 and v6 - Transferring LEGACY to ASSIGNED in the DB might imply that the NCC attempts to gain authority over LEGACY - Moving ASSIGNED PA to ASSIGNED and SUB-ALLOCATED PA to ALLOCATED may imply that the resource holder is the one having received the assignment. Given that this means that they received the assignment not directly from the NCC but still via an LIR through the RIR system, I would argue that this means that the holder is eligible to transfer the resources. I am not really convinced that the proposal actually makes things easier, esp. given the dependent policies. With best regards, Tobias On Thu, 2024-10-24 at 12:31 +0200, Remco van Mook wrote:
Dear colleagues,
following up on my presentation at RIPE 88, please find below a draft version of the policy proposal for simplifying the status of number resource records. I wanted to get this out much earlier, my apologies for the delay.
Looking forward to your constructive feedback ahead of next week’s session.
Kind regards,
Remco van Mook
——
Number: (assigned by the RIPE NCC)
Policy Proposal Name: Simplifying Number Resource Status
Author: Remco van Mook \<remco.vanmook@gmail.com\>
Proposal Version: (assigned by the RIPE NCC)
Submission Date: TBD
Suggested RIPE WG for discussion and publication: Address Policy
Proposal Type: modification or deletion
Policy Term: Indefinite
Summary of proposal:
There is about 30 years of history reflected, sometimes poorly, in the status field describing IPv4 and IPv6 resources in the database. This proposal seeks to simplify and harmonise the contents of the status field between IPv4 and IPv6 and limits the field to what has operational relevance, and removes any implied contractual relationship from the status field itself. (Remnants of) address policy define a very rigid model for the RIPE NCC to follow for the structure of its membership, mostly based on rules about the distribution of IPv4. If we want to give the RIPE NCC membership room to evolve its membership structure based on today’s reality we need a clean break with policy and a database that no longer prescribes the RIPE NCC membership model, but rather allows it to accurately reflect reality.
Policy text: a. Current policy text (if modification)
RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region:
5.3 Sub-allocations Sub-allocations are intended to aid the goal of routing aggregation and can only be made from allocations with a status of "ALLOCATED PA". LIRs holding "ALLOCATED PI" or "ALLOCATED UNSPECIFIED" allocations may be able to convert them to PA allocations if there are no ASSIGNED PI networks within it. The meanings of the various "status:" attribute values are described in Section 7.0.
LIRs may make sub-allocations to multiple downstream network operators.
The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.
Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.
7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.
Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:
Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re- configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.
LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum object in the RIPE Database. The possible values of this attribute are:
ALLOCATED PA: This address space has been allocated to an LIR and no assignments or sub-allocations made from it are portable. Assignments and sub-allocations cannot be kept when moving to another provider. ALLOCATED UNSPECIFIED: This address space has been allocated to the RIPE NCC or other RIRs for further distribution. If the address space is administered by the RIPE NCC, more specific objects with other values may exist. ALLOCATED-ASSIGNED PA: This address space has been allocated to an LIR and entirely assigned to the LIR infrastructure or for use by an End User with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. SUB-ALLOCATED PA: This address space has been sub-allocated by an LIR to a downstream network operator that will make assignments from it. All assignments made from it are PA. They cannot be kept when moving to a service provided by another provider. LIR-PARTITIONED PA: This allows an LIR to document distribution and delegate management of allocated space within their organisation. Address space with a status of LIR-PARTITIONED is not considered used. When the addresses are used, a more specific inetnum must be registered. LEGACY: This indicates the Internet number resource was obtained prior to or otherwise outside the current system of hierarchical distribution (by allocation or assignment) through the Regional Internet Registries. ASSIGNED PA: This address space has been assigned to the issuing LIR infrastructure or an End User for use with services provided by the issuing LIR. It cannot be kept when terminating services provided by the LIR. AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. The purpose and the contact details must be consistent throughout the whole assignment. It cannot be kept when terminating services provided by the LIR. ASSIGNED PI: This address space has been assigned to an End User for a specific purpose. It cannot be used to make further assignments to other parties. ASSIGNED ANYCAST: This address space has been assigned for use in TLD anycast networks. It cannot be kept when no longer used for TLD anycast services. Registering an inetnum object with a status of “ALLOCATED-ASSIGNED PA” or "ASSIGNED PA" or "ASSIGNED PI" is only possible if there is no less specific or more specific inetnum object with an "ASSIGNED" status.
Address space without an explicit type in the "status:" attribute is assumed to be PI. LIRs must clearly mark all new assignments in the RIPE Database with either "PA" or "PI" as appropriate.
In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.
The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.
b. New policy text
RIPE-826 \- IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region:
5.3 Sub-allocations
LIRs may make sub-allocations to multiple downstream network operators.
The LIR is contractually responsible for ensuring the address space allocated to it is used in accordance with the RIPE community's policies. It is recommended that LIRs have contracts requiring downstream network operators to follow the RIPE community's policies when those operators have sub-allocations.
Sub-allocations form part of an LIR's aggregatable address space. As such, an LIR may want to ensure that the address space is not retained by a downstream network if the downstream network operator ceases to receive connectivity from the LIR's network. LIRs not wishing to lose address space in this way are responsible for ensuring that the status of the sub-allocation is clear in any contracts between the LIR and the downstream network operator.
7.0 Types of Address Space LIRs are allocated Provider Aggregatable (PA) address space. They sub-allocate and assign this to downstream networks. If a downstream network or End User changes its service provider, the address space assigned or sub-allocated by the previous service provider must be returned and the network renumbered.
Clear contractual arrangements are mandatory for PA space. End Users requesting PA space must be given this or a similar warning:
Assignment of this IP space is valid as long as the criteria for the original assignment are met and only for the duration of the service agreement between yourself and us. We have the right to reassign the address space to another user upon termination of this agreement or an agreed period thereafter. This means that you will have to re- configure the addresses of all equipment using this IP space if you continue to require global uniqueness of those addresses.
In the past, some LIRs assigned address space that was de facto aggregated but not formally PA because there were no clear contractual arrangements for termination of the assignment. LIRs must ask leaving customers to voluntarily release this address space upon termination of service. Where possible, LIRs should work to make contractual arrangements to convert PI addresses into PA addresses.
The RIPE NCC no longer allocates or assigns PI address space, except for assignments to Internet Exchange Points as described in section 6.1.
Any allocated or assigned address space status must be registered in accordance with the policy document ‘Address Allocation and Assignment Status’.
RIPE-NEW \- Address Allocation and Assignment Status:
Abstract This document defines the content of the status field for the assignment and allocation of globally unique IP addresses to Internet Service Providers (ISPs) and other organisations. It exists together with the IPv6 Address Allocation and Assignment Policy which is harmonised between the RIPE, ARIN and APNIC regions as well as the IPv4 Address Allocation and Assignment Policies for the RIPE NCC Service Region. While the status field of inet6num records in the RIPE Database has been mostly inferred from the IPv4 inetnum record as it existed when the first provisional IPv6 Allocation and Assignment policy was defined in RIPE-196, there was no equivalent for Chapter 7 of the IPv4 Address Allocation and Assignment Policy “Types of Address Space” in defined policy. To prevent duplication, this document applies equally to IPv4 inetnum and IPv6 inet6num records.
1.0 Status of Address Space resource records
LIRs will register the type of any assigned address space using the "status:" attribute of the inetnum or inet6num object in the RIPE Database for IPv4 and IPv6 registrations, respectively.. The possible values of this attribute are:
ALLOCATED: This address space has been allocated to an LIR or downstream network operator and no assignments or sub-allocations made from it are portable. More specific objects may exist in the RIPE database.
ASSIGNED: This address space has been assigned to the issuing LIR infrastructure or an End User. More specific objects do not exist in the RIPE database.
AGGREGATED-BY-LIR: This address space has been assigned to different parts of the issuing LIR infrastructure or to End Users for use with services provided by the issuing LIR. Each End User has been assigned a block the size of the assignment size in the object. More specific objects do not exist in the RIPE database.
2.0 Mapping of Legacy Status Attributes
The following mapping is used to update legacy status attributes:
ALLOCATED:
- ALLOCATED PA - SUB-ALLOCATED PA - LIR-PARTITIONED PA - ALLOCATED UNSPECIFIED - ALLOCATED-BY-RIR - ALLOCATED-BY-RIR \# This block was actually allocated by the IANA - ALLOCATED-BY-LIR
ASSIGNED
- ASSIGNED PA - ASSIGNED PI - LEGACY - ASSIGNED ANYCAST
Unchanged but added for completeness: AGGREGATED-BY-LIR
- AGGREGATED-BY-LIR
Rationale: a. Arguments supporting the proposal
- Reduces complexity of the status of number resources - Removes the need to attribute origin in the status attribute as that’s inferred from the structure of the database - Focus the database on more accurately reflecting operational reality - Special case/historical documentation is better suited elsewhere - Harmonises IPv4 and IPv6 registrations - Less confusion about usage caused by status \- e.g. most operational anycast space is not in the database as ‘ASSIGNED ANYCAST’ - Facilitates a future decoupling of address policy and NCC membership structure
b. Arguments opposing the proposal
- Loss of public visibility of contractual relationship - Loss of public visibility of historic/legacy assignments/special cases
----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Hi, On Thu, Oct 24, 2024 at 02:02:39PM +0200, Tobias Fiebig via address-policy-wg wrote:
I am not really convinced that the proposal actually makes things easier, esp. given the dependent policies.
"real world is complicated, how annoying, so let's make it look simple to computers". No? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Moin, sorry, can't parse this atm; is this agreement or disagreement with my point? With best regards, Tobias On Thu, 2024-10-24 at 14:04 +0200, Gert Doering wrote:
Hi,
On Thu, Oct 24, 2024 at 02:02:39PM +0200, Tobias Fiebig via address- policy-wg wrote:
I am not really convinced that the proposal actually makes things easier, esp. given the dependent policies.
"real world is complicated, how annoying, so let's make it look simple to computers". No?
Gert Doering -- NetMaster
-- Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.nl
Hi, On Thu, Oct 24, 2024 at 02:06:50PM +0200, Tobias Fiebig wrote:
sorry, can't parse this atm; is this agreement or disagreement with my point?
I'm agreeing with you (surprise) ;-) gert -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Remco van Mook wrote on 24/10/2024 11:31:
Dear colleagues,
following up on my presentation at RIPE 88, please find below a draft version of the policy proposal for simplifying the status of number resource records. I wanted to get this out much earlier, my apologies for the delay.
Remco, the policy change you're proposing describes only the technical change itself, but doesn't include any assessment of the potential downstream consequences of the proposal. Can you provide any insight into what specific outcomes you intend here? Nick
Hi, On Thu, Oct 24, 2024 at 12:31:33PM +0200, Remco van Mook wrote:
following up on my presentation at RIPE 88, please find below a draft version of the policy proposal for simplifying the status of number resource records. I wanted to get this out much earlier, my apologies for the delay.
My understanding of the current status: values is to document contractual relationships regarding a particular database object - did the NCC assign this? Is this a hierarchical LIR structure? Is this some legacy space that is under a particular contract framework with the RIPE NCC? Who is the authority on what can or can not be done with a given bunch of numbers? I do like this interpretation of status: and want to keep it. Thus, simplification of status: values would either take away documentation (bad) or would need a simplification of contractual variants (not covered by this proposal, because not APWG merits). We might consider changing the contract structure (like, doing away with indirect contracts through a sponsoring LIR) - which is NCC services or AGM - but discussion about the consequences for status: needs to come afterwards, not before that. Short form: do not try to press complex reality into simple database formats, because that does not yield useful results, even if tempting. Oppose. Gert Doering -- having an o-with-dots in his name... -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
Short form: do not try to press complex reality into simple database formats, because that does not yield useful results, even if tempting. Oppose.
yup. to put it another way. we have made a complex reality, and a mapping to db objects that attempts to capture it. changing db object definition without an explicit, rigorous, and well thought out change to the social and contractual realities is naïve at best. randy
Hi For once Randy I actually agree with you. On Fri, 25 Oct 2024 at 21:02, Randy Bush <randy@psg.com> wrote:
Short form: do not try to press complex reality into simple database formats, because that does not yield useful results, even if tempting. Oppose.
yup. to put it another way. we have made a complex reality, and a mapping to db objects that attempts to capture it. changing db object definition without an explicit, rigorous, and well thought out change to the social and contractual realities is naïve at best.
Unfortunately the same argument applies to the aggregated-by-lir status that was recently added. Most people were so focused on making assignments optional, no thought went into the consequences of adding this status value. Technically it was a simple change. The reality is a mess. cheers denis ======================================================== DISCLAIMER Everything I said above is my personal, professional opinion. It is what I believe to be honest and true to the best of my knowledge. No one in this industry pays me anything. I have nothing to gain or lose by any decision. I push for what I believe is for the good of the Internet, in some small way. Nothing I say is ever intended to be offensive or a personal attack. Even if I strongly disagree with you or question your motives. Politicians question each other's motives all the time. RIPE discussion is often as much about politics and self interest as it is technical. I have a style of writing that some may not be familiar with, others sometimes use it against me. I also have OCD. It makes me see the world slightly differently to others. It drives my mind's obsessive need for detail. I can not change the way I express my detailed opinions. People may choose how to interpret them. ========================================================
randy ----- To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/ As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
participants (6)
-
denis walker -
Gert Doering -
Nick Hilliard -
Randy Bush -
Remco van Mook -
Tobias Fiebig