From ingrid at ripe.net Mon Aug 1 09:12:05 2016 From: ingrid at ripe.net (Ingrid Wijte) Date: Mon, 1 Aug 2016 09:12:05 +0200 Subject: [address-policy-wg] New AS Number Blocks allocated to the RIPE NCC Message-ID: Dear Colleagues, The RIPE NCC has received the following AS Number Blocks from the IANA on 29 July 2016. 64396-64495 204288-205211 205212-206235 206236-207259 You may want to update your records accordingly. Best regards, Ingrid Wijte Registration Services Assistant Manager RIPE NCC From ingrid at ripe.net Thu Aug 4 09:39:24 2016 From: ingrid at ripe.net (Ingrid Wijte) Date: Thu, 4 Aug 2016 09:39:24 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Message-ID: Dear colleagues, During RIPE 72, the RIPE NCC was asked to suggest a way forward with regards to the unclear situation arising from address blocks in the RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. We want to give you an update on this work and ask for your input. BACKGROUND Although PI assignments made by LIRs have the same status in the RIPE Database, it is not clear if resource holders with assignments from LIRs have the same rights as resource holders with those issued by the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to clarify the situation. In the early days of the RIPE NCC, a small number of LIRs received allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. From these address blocks, LIRs could assign ranges with the status ASSIGNED PI. The RIPE community later decided that the RIPE NCC should be the only party assigning ranges with ASSIGNED PI to End Users. It was not clear what the status of the assignments that had already been made should be. ACTION TAKEN At RIPE 71, the Address Policy Working Group asked the RIPE NCC to check the actual assignment status with the holders of these allocations. We contacted all of the LIRs involved and around 50% said they had no contact with holders of assignments with the status ASSIGNED PI within their allocations. Several allocations containing only PA assignments were converted from ALLOCATED UNSPECIFIED to ALLOCATED PA following communication with LIRs. The RIPE NCC presented these results to the Address Policy Working Group at RIPE 72. The WG stressed that data accuracy must have the highest priority. It was further suggested that the RIPE NCC should follow up with the LIRs on a case-by-case basis, following the principles outlined below. The WG agreed that, where the LIR can document a mutual agreement that they administer the address space, a conversion from PI to PA should take place. In all other cases, assignments with the status ASSIGNED PI should be treated as being assigned by the RIPE NCC. It was also stated that LIRs should not register any new assignments with the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments (with the exception of IXP PI assignments from our reserved address pool). APPROACH The RIPE NCC will contact the 38 LIRs holding allocations that contain address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). In the following months, these LIRs will check if their RIPE Database entries are still correct. Each LIR will check their records and with their customers to see under what conditions the assignments were originally provided. After the LIRs have finished their research, the RIPE NCC will: - Convert assignments to ASSIGNED PA if it can be documented that the administrative responsibility lies with the LIR - Follow up directly with resource holders of ASSIGNED PI to apply the RIPE policy, ?Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region?. The PI assignments will become part of the address space managed by the RIPE NCC just like all other PI space. Once the resource holders have fulfilled the contractual requirements, they will have the same rights and obligations as any other End User of PI space. - Split the allocations to separate the PI assignments and convert the blocks that remain with an LIR to ALLOCATED PA. We suggest giving these LIRs until the end of January 2017 to clarify the status of the assignments within their ALLOCATED PI/UNSPECIFIED allocations. In situations where a dispute arises between the LIR and the assignment holder about the administrative responsibility, the RIPE NCC will do its best to support a fair solution. We welcome your feedback on this suggested approach. Please provide your input before 12 September 2016. Kind regards, Ingrid Wijte Assistant Manager Registration Services RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at velder.li Thu Aug 4 10:12:09 2016 From: lists at velder.li (Patrick Velder) Date: Thu, 4 Aug 2016 10:12:09 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: Message-ID: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> Hello Ingrid That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an "Independent Assignment Request and Maintenance Agreement" with the LIR, like end users which got their assignment direct from RIPE NCC, this assignment will become an assignment which is managed directly by RIPE NCC? Best regards Patrick On 04.08.2016 09:39, Ingrid Wijte wrote: > Dear colleagues, > > During RIPE 72, the RIPE NCC was asked to suggest a way forward with > regards to the unclear situation arising from address blocks in the > RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. > We want to give you an update on this work and ask for your input. > > BACKGROUND > > Although PI assignments made by LIRs have the same status in the RIPE > Database, it is not clear if resource holders with assignments from > LIRs have the same rights as resource holders with those issued by the > RIPE NCC. The community, mainly End Users, has asked the RIPE NCC to > clarify the situation. > > In the early days of the RIPE NCC, a small number of LIRs received > allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. > From these address blocks, LIRs could assign ranges with the status > ASSIGNED PI. > The RIPE community later decided that the RIPE NCC should be the only > party assigning ranges with ASSIGNED PI to End Users. It was not clear > what the status of the assignments that had already been made should be. > > ACTION TAKEN > > At RIPE 71, the Address Policy Working Group asked the RIPE NCC to > check the actual assignment status with the holders of these > allocations. We contacted all of the LIRs involved and around 50% said > they had no contact with holders of assignments with the status > ASSIGNED PI within their allocations. Several allocations containing > only PA assignments were converted from ALLOCATED UNSPECIFIED to > ALLOCATED PA following communication with LIRs. > > The RIPE NCC presented these results to the Address Policy Working > Group at RIPE 72. The WG stressed that data accuracy must have the > highest priority. It was further suggested that the RIPE NCC should > follow up with the LIRs on a case-by-case basis, following the > principles outlined below. > > The WG agreed that, where the LIR can document a mutual agreement that > they administer the address space, a conversion from PI to PA should > take place. In all other cases, assignments with the status ASSIGNED > PI should be treated as being assigned by the RIPE NCC. > > It was also stated that LIRs should not register any new assignments > with the status ASSIGNED PI, as policy no longer allows for new IPv4 > PI assignments (with the exception of IXP PI assignments from our > reserved address pool). > > APPROACH > > The RIPE NCC will contact the 38 LIRs holding allocations that > contain address blocks with the status ASSIGNED PI (3,600 inetnum > objects in total). > > In the following months, these LIRs will check if their RIPE Database > entries are still correct. Each LIR will check their records and with > their customers to see under what conditions the assignments were > originally provided. > > After the LIRs have finished their research, the RIPE NCC will: > > - Convert assignments to ASSIGNED PA if it can be documented that > the administrative responsibility lies with the LIR > - Follow up directly with resource holders of ASSIGNED PI to apply > the RIPE policy, ?Contractual Requirements for Provider Independent > Resource Holders in the RIPE NCC Service Region?. The PI assignments > will become part of the address space managed by the RIPE NCC just > like all other PI space. Once the resource holders have fulfilled the > contractual requirements, they will have the same rights and > obligations as any other End User of PI space. > - Split the allocations to separate the PI assignments and convert > the blocks that remain with an LIR to ALLOCATED PA. > > We suggest giving these LIRs until the end of January 2017 to clarify > the status of the assignments within their ALLOCATED PI/UNSPECIFIED > allocations. > > In situations where a dispute arises between the LIR and the > assignment holder about the administrative responsibility, the RIPE > NCC will do its best to support a fair solution. > > We welcome your feedback on this suggested approach. Please provide > your input before 12 September 2016. > > Kind regards, > > Ingrid Wijte > Assistant Manager Registration Services > RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From l.yurkina at ripn.net Thu Aug 4 12:36:30 2016 From: l.yurkina at ripn.net (Larisa Yurkina) Date: Thu, 04 Aug 2016 13:36:30 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> Message-ID: <57A31AAE.6060305@ripn.net> Patrick Velder ????? 04.08.2016 11:12: Hi > > Hello Ingrid > > That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has > an "Independent Assignment Request and Maintenance Agreement" with the > LIR, like end users which got their assignment direct from RIPE NCC, > this assignment will become an assignment which is managed directly by > RIPE NCC? > > Best regards > Patrick > > My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 years ago, according to those days policy. Some part of address space was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them have agreement with the LIR, which also was within the policy, at least not against. Why should we change anything here? Just because some LIRs lost their control over 50% of the address space allocated to them? Perhaps there are some other ways to restore it? With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina at ripn.net / www.ripn.net ?.: +7 495 737-0604 > On 04.08.2016 09:39, Ingrid Wijte wrote: >> Dear colleagues, >> >> During RIPE 72, the RIPE NCC was asked to suggest a way forward with >> regards to the unclear situation arising from address blocks in the >> RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >> We want to give you an update on this work and ask for your input. >> >> BACKGROUND >> >> Although PI assignments made by LIRs have the same status in the RIPE >> Database, it is not clear if resource holders with assignments from >> LIRs have the same rights as resource holders with those issued by >> the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC >> to clarify the situation. >> >> In the early days of the RIPE NCC, a small number of LIRs received >> allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >> From these address blocks, LIRs could assign ranges with the status >> ASSIGNED PI. >> The RIPE community later decided that the RIPE NCC should be the only >> party assigning ranges with ASSIGNED PI to End Users. It was not >> clear what the status of the assignments that had already been made >> should be. >> >> ACTION TAKEN >> >> At RIPE 71, the Address Policy Working Group asked the RIPE NCC to >> check the actual assignment status with the holders of these >> allocations. We contacted all of the LIRs involved and around 50% >> said they had no contact with holders of assignments with the status >> ASSIGNED PI within their allocations. Several allocations containing >> only PA assignments were converted from ALLOCATED UNSPECIFIED to >> ALLOCATED PA following communication with LIRs. >> >> The RIPE NCC presented these results to the Address Policy Working >> Group at RIPE 72. The WG stressed that data accuracy must have the >> highest priority. It was further suggested that the RIPE NCC should >> follow up with the LIRs on a case-by-case basis, following the >> principles outlined below. >> >> The WG agreed that, where the LIR can document a mutual agreement >> that they administer the address space, a conversion from PI to PA >> should take place. In all other cases, assignments with the status >> ASSIGNED PI should be treated as being assigned by the RIPE NCC. >> >> It was also stated that LIRs should not register any new assignments >> with the status ASSIGNED PI, as policy no longer allows for new IPv4 >> PI assignments (with the exception of IXP PI assignments from our >> reserved address pool). >> >> APPROACH >> >> The RIPE NCC will contact the 38 LIRs holding allocations that >> contain address blocks with the status ASSIGNED PI (3,600 inetnum >> objects in total). >> >> In the following months, these LIRs will check if their RIPE Database >> entries are still correct. Each LIR will check their records and with >> their customers to see under what conditions the assignments were >> originally provided. >> >> After the LIRs have finished their research, the RIPE NCC will: >> >> - Convert assignments to ASSIGNED PA if it can be documented that >> the administrative responsibility lies with the LIR >> - Follow up directly with resource holders of ASSIGNED PI to apply >> the RIPE policy, ?Contractual Requirements for Provider Independent >> Resource Holders in the RIPE NCC Service Region?. The PI assignments >> will become part of the address space managed by the RIPE NCC just >> like all other PI space. Once the resource holders have fulfilled the >> contractual requirements, they will have the same rights and >> obligations as any other End User of PI space. >> - Split the allocations to separate the PI assignments and convert >> the blocks that remain with an LIR to ALLOCATED PA. >> >> We suggest giving these LIRs until the end of January 2017 to clarify >> the status of the assignments within their ALLOCATED PI/UNSPECIFIED >> allocations. >> >> In situations where a dispute arises between the LIR and the >> assignment holder about the administrative responsibility, the RIPE >> NCC will do its best to support a fair solution. >> >> We welcome your feedback on this suggested approach. Please provide >> your input before 12 September 2016. >> >> Kind regards, >> >> Ingrid Wijte >> Assistant Manager Registration Services >> RIPE NCC > -- From lists at velder.li Thu Aug 4 12:59:35 2016 From: lists at velder.li (Patrick Velder) Date: Thu, 4 Aug 2016 12:59:35 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <57A31AAE.6060305@ripn.net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: <715b024c-a684-3a08-a74a-d99d9beb172c@velder.li> Hi PI (Provider Independent) should be "Provider Independent" - any space which is assigned by a LIR is not really "provider independent". I think it's a good idea to change that. Regards Patrick On 04.08.2016 12:36, Larisa Yurkina wrote: > Patrick Velder ????? 04.08.2016 11:12: > > Hi >> >> Hello Ingrid >> >> That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) >> has an "Independent Assignment Request and Maintenance Agreement" >> with the LIR, like end users which got their assignment direct from >> RIPE NCC, this assignment will become an assignment which is managed >> directly by RIPE NCC? >> >> Best regards >> Patrick >> >> > My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about > 20 years ago, according to those days policy. Some part of address > space was not aggregated and was used as "ASSIGNED PI within ALLOCATED > PI", all of them have agreement with the LIR, which also was within > the policy, at least not against. Why should we change anything here? > Just because some LIRs lost their control over 50% of the address > space allocated to them? Perhaps there are some other ways to restore it? > > With respect, > *Larisa Yurkina* > RosNIIROS > Internet Number Resources Group / Chief Manager > l.yurkina at ripn.net / www.ripn.net > > ?.: +7 495 737-0604 > >> On 04.08.2016 09:39, Ingrid Wijte wrote: >>> Dear colleagues, >>> >>> During RIPE 72, the RIPE NCC was asked to suggest a way forward with >>> regards to the unclear situation arising from address blocks in the >>> RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >>> We want to give you an update on this work and ask for your input. >>> >>> BACKGROUND >>> >>> Although PI assignments made by LIRs have the same status in the >>> RIPE Database, it is not clear if resource holders with assignments >>> from LIRs have the same rights as resource holders with those issued >>> by the RIPE NCC. The community, mainly End Users, has asked the RIPE >>> NCC to clarify the situation. >>> >>> In the early days of the RIPE NCC, a small number of LIRs received >>> allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >>> From these address blocks, LIRs could assign ranges with the status >>> ASSIGNED PI. >>> The RIPE community later decided that the RIPE NCC should be the >>> only party assigning ranges with ASSIGNED PI to End Users. It was >>> not clear what the status of the assignments that had already been >>> made should be. >>> >>> ACTION TAKEN >>> >>> At RIPE 71, the Address Policy Working Group asked the RIPE NCC to >>> check the actual assignment status with the holders of these >>> allocations. We contacted all of the LIRs involved and around 50% >>> said they had no contact with holders of assignments with the status >>> ASSIGNED PI within their allocations. Several allocations containing >>> only PA assignments were converted from ALLOCATED UNSPECIFIED to >>> ALLOCATED PA following communication with LIRs. >>> >>> The RIPE NCC presented these results to the Address Policy Working >>> Group at RIPE 72. The WG stressed that data accuracy must have the >>> highest priority. It was further suggested that the RIPE NCC should >>> follow up with the LIRs on a case-by-case basis, following the >>> principles outlined below. >>> >>> The WG agreed that, where the LIR can document a mutual agreement >>> that they administer the address space, a conversion from PI to PA >>> should take place. In all other cases, assignments with the status >>> ASSIGNED PI should be treated as being assigned by the RIPE NCC. >>> >>> It was also stated that LIRs should not register any new assignments >>> with the status ASSIGNED PI, as policy no longer allows for new IPv4 >>> PI assignments (with the exception of IXP PI assignments from our >>> reserved address pool). >>> >>> APPROACH >>> >>> The RIPE NCC will contact the 38 LIRs holding allocations that >>> contain address blocks with the status ASSIGNED PI (3,600 inetnum >>> objects in total). >>> >>> In the following months, these LIRs will check if their RIPE >>> Database entries are still correct. Each LIR will check their >>> records and with their customers to see under what conditions the >>> assignments were originally provided. >>> >>> After the LIRs have finished their research, the RIPE NCC will: >>> >>> - Convert assignments to ASSIGNED PA if it can be documented that >>> the administrative responsibility lies with the LIR >>> - Follow up directly with resource holders of ASSIGNED PI to >>> apply the RIPE policy, ?Contractual Requirements for Provider >>> Independent Resource Holders in the RIPE NCC Service Region?. The PI >>> assignments will become part of the address space managed by the >>> RIPE NCC just like all other PI space. Once the resource holders >>> have fulfilled the contractual requirements, they will have the same >>> rights and obligations as any other End User of PI space. >>> - Split the allocations to separate the PI assignments and >>> convert the blocks that remain with an LIR to ALLOCATED PA. >>> >>> We suggest giving these LIRs until the end of January 2017 to >>> clarify the status of the assignments within their ALLOCATED >>> PI/UNSPECIFIED allocations. >>> >>> In situations where a dispute arises between the LIR and the >>> assignment holder about the administrative responsibility, the RIPE >>> NCC will do its best to support a fair solution. >>> >>> We welcome your feedback on this suggested approach. Please provide >>> your input before 12 September 2016. >>> >>> Kind regards, >>> >>> Ingrid Wijte >>> Assistant Manager Registration Services >>> RIPE NCC >> > > From netmaster at de.kpn-eurorings.net Thu Aug 4 13:05:27 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Thu, 4 Aug 2016 11:05:27 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: Message-ID: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> On 04.08.2016 09:39, Ingrid Wijte wrote: > It was also stated that LIRs should not register any new assignments with > the status ASSIGNED PI, as policy no longer allows for new IPv4 PI assignments > (with the exception of IXP PI assignments from our reserved address pool). Does the current policy really states, that new IPv4 PI can't be made out of those assignments? I only read "The RIPE NCC no longer allocates or assigns PI address space". > APPROACH > The RIPE NCC will contact the 38 LIRs holding allocations that contain > address blocks with the status ASSIGNED PI (3,600 inetnum objects in total). > In the following months, these LIRs will check if their RIPE Database entries > are still correct. Each LIR will check their records and with their customers > to see under what conditions the assignments were originally provided. Before that you said 50% don't have any contacts with the end-user, holding the PI. Who will be in the lead to contact those parties? > Split the allocations to separate the PI assignments and convert the blocks > that remain with an LIR to ALLOCATED PA. That's the ugly part I don't like, but I'm biased. For those few of us being long enough around to have such allocations and with my current reading of the policy, you take away from us the possibility to assign PIs to end-users ... fair enough, if my reading is incorrect, this is not relevant anyway. But splitting current A-PI/-U is as such not really a nice thing. It will leave the initial holders of the ranges with little fragments. True, nothing which cannot be handled, but if I announce e.g. a /16 or have to announce 50+ (or more or less) /20-/24s, it makes a difference (operational and financially). Yes, more filters, reverse zones, ROAs, ... Yes, everything is possible, but I don't like it. OTOH, I understand the wish of the community -and support it-, to treat all PI owners equal ("Contractual Requirements for Provider Independent Resource Holders in the RIPE NCC Service Region") and the end-users request to maintain their PI inetnum on their own. Even for the party with the A-PI/-U it might be a relieve no longer discussing and maintaining the PIs of non-customers. If I would have a choice, I would prefer RIPE NCC to think about how to lock PIs within these special allocations to allow the end-user to manage their PIs directly, force them to comply to the "Contractual Requirements", locking out the A-PI/-U owner to touch the inetnums of PIs ... but this probably will not work out or be too "complicated" or come with side effects someone will complain about later (e.g. the less-specific route object of the A-PI/-U holder, the A-PI/-U holder's ROA for it). TBC Markus PS: Yes, KPN's LIR have A-U. Thus I'm biased. But I know how bad it feels suddenly having to announce and handle smaller fragments instead of the full allocation, as a lot of address space (most of the AS517/AS286, Xlink/ EUnet allocations) moved to other KPN departments, leaving us (AS286) with some more specifics ... and yes, sometimes you have to pay per prefix ... -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From randy at psg.com Thu Aug 4 13:12:56 2016 From: randy at psg.com (Randy Bush) Date: Thu, 04 Aug 2016 20:12:56 +0900 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <57A31AAE.6060305@ripn.net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: > My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about > 20 years ago, according to those days policy. Some part of address space > was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", > all of them have agreement with the LIR, which also was within the > policy, at least not against. Why should we change anything here? Just > because some LIRs lost their control over 50% of the address space > allocated to them? Perhaps there are some other ways to restore it? > >>> After the LIRs have finished their research, the RIPE NCC will: >>> >>> - Convert assignments to ASSIGNED PA if it can be documented that >>> the administrative responsibility lies with the LIR >>> - Follow up directly with resource holders of ASSIGNED PI to apply >>> the RIPE policy, ?Contractual Requirements for Provider >>> Independent Resource Holders in the RIPE NCC Service Region?. The >>> PI assignments will become part of the address space managed by >>> the RIPE NCC just like all other PI space. Once the resource >>> holders have fulfilled the contractual requirements, they will >>> have the same rights and obligations as any other End User of PI >>> space. >>> - Split the allocations to separate the PI assignments and convert >>> the blocks that remain with an LIR to ALLOCATED PA. i am perennially confused by the different colors of integers. as you know, i prefer magenta and comic sans. ingrid/ncc can you explain in terms an antique router geek can understand what the actual pragmatic effect would be on these PI/PA holders? does it alter holders' rights? costs? processes? ... i suspect that you, larisa, already understand that. in this case, why, in pragmatic terms a router geek can understand (yes, i know that's a high bar, sorry), do you not like it? randy From hank at efes.iucc.ac.il Thu Aug 4 13:21:25 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 4 Aug 2016 14:21:25 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> Message-ID: <4b8870d9-f490-c43d-7aaa-d753aa6f7ddb@efes.iucc.ac.il> > On 04.08.2016 09:39, Ingrid Wijte wrote: >> Dear colleagues, >> >> During RIPE 72, the RIPE NCC was asked to suggest a way forward with >> regards to the unclear situation arising from address blocks in the >> RIPE Database with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >> We want to give you an update on this work and ask for your input. >> >> BACKGROUND >> >> Although PI assignments made by LIRs have the same status in the RIPE >> Database, it is not clear if resource holders with assignments from >> LIRs have the same rights as resource holders with those issued by >> the RIPE NCC. The community, mainly End Users, has asked the RIPE NCC >> to clarify the situation. I had all my ASSIGNED PIs changed to status:LEGACY. If it was done to all my legacy allocations why can't it be done for these as well? -Hank >> >> In the early days of the RIPE NCC, a small number of LIRs received >> allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >> From these address blocks, LIRs could assign ranges with the status >> ASSIGNED PI. >> The RIPE community later decided that the RIPE NCC should be the only >> party assigning ranges with ASSIGNED PI to End Users. It was not >> clear what the status of the assignments that had already been made >> should be. >> >> ACTION TAKEN >> >> At RIPE 71, the Address Policy Working Group asked the RIPE NCC to >> check the actual assignment status with the holders of these >> allocations. We contacted all of the LIRs involved and around 50% >> said they had no contact with holders of assignments with the status >> ASSIGNED PI within their allocations. Several allocations containing >> only PA assignments were converted from ALLOCATED UNSPECIFIED to >> ALLOCATED PA following communication with LIRs. >> >> The RIPE NCC presented these results to the Address Policy Working >> Group at RIPE 72. The WG stressed that data accuracy must have the >> highest priority. It was further suggested that the RIPE NCC should >> follow up with the LIRs on a case-by-case basis, following the >> principles outlined below. >> >> The WG agreed that, where the LIR can document a mutual agreement >> that they administer the address space, a conversion from PI to PA >> should take place. In all other cases, assignments with the status >> ASSIGNED PI should be treated as being assigned by the RIPE NCC. >> >> It was also stated that LIRs should not register any new assignments >> with the status ASSIGNED PI, as policy no longer allows for new IPv4 >> PI assignments (with the exception of IXP PI assignments from our >> reserved address pool). >> >> APPROACH >> >> The RIPE NCC will contact the 38 LIRs holding allocations that >> contain address blocks with the status ASSIGNED PI (3,600 inetnum >> objects in total). >> >> In the following months, these LIRs will check if their RIPE Database >> entries are still correct. Each LIR will check their records and with >> their customers to see under what conditions the assignments were >> originally provided. >> >> After the LIRs have finished their research, the RIPE NCC will: >> >> - Convert assignments to ASSIGNED PA if it can be documented that >> the administrative responsibility lies with the LIR >> - Follow up directly with resource holders of ASSIGNED PI to apply >> the RIPE policy, ?Contractual Requirements for Provider Independent >> Resource Holders in the RIPE NCC Service Region?. The PI assignments >> will become part of the address space managed by the RIPE NCC just >> like all other PI space. Once the resource holders have fulfilled the >> contractual requirements, they will have the same rights and >> obligations as any other End User of PI space. >> - Split the allocations to separate the PI assignments and convert >> the blocks that remain with an LIR to ALLOCATED PA. >> >> We suggest giving these LIRs until the end of January 2017 to clarify >> the status of the assignments within their ALLOCATED PI/UNSPECIFIED >> allocations. >> >> In situations where a dispute arises between the LIR and the >> assignment holder about the administrative responsibility, the RIPE >> NCC will do its best to support a fair solution. >> >> We welcome your feedback on this suggested approach. Please provide >> your input before 12 September 2016. >> >> Kind regards, >> >> Ingrid Wijte >> Assistant Manager Registration Services >> RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Thu Aug 4 13:25:02 2016 From: gert at space.net (Gert Doering) Date: Thu, 4 Aug 2016 13:25:02 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <4b8870d9-f490-c43d-7aaa-d753aa6f7ddb@efes.iucc.ac.il> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <4b8870d9-f490-c43d-7aaa-d753aa6f7ddb@efes.iucc.ac.il> Message-ID: <20160804112502.GI79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 02:21:25PM +0300, Hank Nussbacher wrote: > I had all my ASSIGNED PIs changed to status:LEGACY. If it was done to > all my legacy allocations why can't it be done for these as well? I assume that your allocations actually have been legacy allocations all along, pre-dating the RIPE NCC. These had been converted to "PI" at one point, but the legacy policy gave you the option to convert them back to "legacy". *This* is about PIs that came from the RIPE NCC's stock, so, no "legacy" in the sense of "pre-NCC allocations from Internic" here. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From gert at space.net Thu Aug 4 13:37:10 2016 From: gert at space.net (Gert Doering) Date: Thu, 4 Aug 2016 13:37:10 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: <20160804113710.GJ79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 08:12:56PM +0900, Randy Bush wrote: > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. Not all prefixes belong to R?diger, so, magenta is out... > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... Right now, there are two different shades of "PI colour" - "real PI" and "not really real PI". The first shade has the full obligations and protection of 2007-01 - namely, a contractual relationship (via a sponsoring LIR) with the NCC that clearly identifies who has "rights" to that prefix. The other shade is also labeled "PI", but whether or not contracts exist, and who is the legitimate holder, is less well defined. This proposal aims to unify all PI into one colour, which I think is good for the resource holders (no uncertainity) - but there is potential fallout, like "we've been doing IPv4 PI assignments all the years, and nobody bothered!" - which technically could be done from "ALLOCATED UNSPECIFIED" blocks, but was always outside RIPE policies - and if these are now properly labeled and tagged, certain business practices might no longer be possible. Also, it might lead to deaggs (Markus' case) where a /14 that was originally "in one LIR" would be "3x /16, plus some smaller fragments in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 won't get a ROA, and he'll have to announce more-specifics. There is no "truly nice" solution to this. It's swampy space that will smell when you try to clean it up (but some people insist that parts of that swamp is *theirs* and want all the titles that come with that...). So, to answer your question: for those "swampy PI", it would alter their rights (contracts according to 2007-01), costs (50 EUR/year), processes (sponsoring LIR, instead of "no clear process"). Quite some change. Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From l.yurkina at ripn.net Thu Aug 4 13:39:48 2016 From: l.yurkina at ripn.net (Larisa Yurkina) Date: Thu, 04 Aug 2016 14:39:48 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: <57A32983.4010703@ripn.net> Randy Bush ????? 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address space >> was not aggregated and was used as "ASSIGNED PI within ALLOCATED PI", >> all of them have agreement with the LIR, which also was within the >> policy, at least not against. Why should we change anything here? Just >> because some LIRs lost their control over 50% of the address space >> allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, ?Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region?. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, why, > in pragmatic terms a router geek can understand (yes, i know that's a > high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina at ripn.net / www.ripn.net ?.: +7 495 737-0604 From erey at ernw.de Thu Aug 4 13:52:43 2016 From: erey at ernw.de (Enno Rey) Date: Thu, 4 Aug 2016 13:52:43 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <57A32983.4010703@ripn.net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <57A32983.4010703@ripn.net> Message-ID: <20160804115243.GQ44950@ernw.de> Hi, On Thu, Aug 04, 2016 at 02:39:48PM +0300, Larisa Yurkina wrote: > [...] creates a lot of additional job for my LIR. > > That is why I'd prefer not to change anything here. wow. that's a really (RIPE) community-oriented statement. and a technically sound argument, too. cheers Enno > > -- > With respect, > > *Larisa Yurkina* > RIPN > Internet Number Resources Group / Chief Manager > l.yurkina at ripn.net / www.ripn.net > > ??.: +7 495 737-0604 > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From randy at psg.com Thu Aug 4 13:59:07 2016 From: randy at psg.com (Randy Bush) Date: Thu, 04 Aug 2016 20:59:07 +0900 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804113710.GJ79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: > Right now, there are two different shades of "PI colour" - "real PI" > and "not really real PI". is there a list of all the colors and what they mean? > This proposal aims to unify all PI into one colour, which I think is > good for the resource holders (no uncertainity) - but there is > potential fallout, like "we've been doing IPv4 PI assignments all the > years, and nobody bothered!" - which technically could be done from > "ALLOCATED UNSPECIFIED" blocks, but was always outside RIPE policies - > and if these are now properly labeled and tagged, certain business > practices might no longer be possible. are certain business practices to be compared to uncertain business practices? :) i have this feeling you are trying to say something here. i.e. if i am the LIR, can i move "not really real PI" between customers and no one knows? > Also, it might lead to deaggs (Markus' case) where a /14 that was > originally "in one LIR" would be "3x /16, plus some smaller fragments > in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 > won't get a ROA, and he'll have to announce more-specifics. lemme see if i get this. to have the owner registration correct, some address space will have to be broken up and owned by multiple IRs, thus fragmenting routing? i like correct registration, but the commons has become pretty polluted. > So, to answer your question: for those "swampy PI", it would alter > their rights (contracts according to 2007-01), costs (50 EUR/year) whoops. that's gonna cause unhappiness. randy From gert at space.net Thu Aug 4 14:10:33 2016 From: gert at space.net (Gert Doering) Date: Thu, 4 Aug 2016 14:10:33 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: <20160804121033.GK79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 08:59:07PM +0900, Randy Bush wrote: > > Right now, there are two different shades of "PI colour" - "real PI" > > and "not really real PI". > is there a list of all the colors and what they mean? I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", and those are well-defined. Add "Legacy" to it (outside RIR framework). We have learned that there are more interesting shades, namely "ALLOCATED PI", "ALLOCATED UNSPECIFIED" and "ASSIGNED PI (not really)" - these are not seen often, and their meaning is not all that clear. [..] > i have this feeling you are trying to say something here. i.e. if i am > the LIR, can i move "not really real PI" between customers and no one > knows? Maybe. "not really real PI" is happening outside the RIPE policy framework - namely, no 2007-01 contracts, the NCC has no idea who the "real" address holder is, and the holder cannot complain to the NCC if all of a sudden "his" address space is registered to someone else... There seems to be "old stuff that happened 15+ years ago" and "new stuff that is still ongoing", so there won't be "one solution" either. > > Also, it might lead to deaggs (Markus' case) where a /14 that was > > originally "in one LIR" would be "3x /16, plus some smaller fragments > > in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 > > won't get a ROA, and he'll have to announce more-specifics. > > lemme see if i get this. to have the owner registration correct, some > address space will have to be broken up and owned by multiple IRs, thus > fragmenting routing? i like correct registration, but the commons has > become pretty polluted. I leave the definite answer to Ingrid to answer. My understanding of "normal" NCC<->LIR stockkeeping is that PI is never living inside blocks that "belong" to a given LIR. So, the LIR would never be able to get a ROA covering PI space. For some of these "old" blocks, there is a /16 which covers regular LIR/PA space, and "not real PI" space, and the LIR can get a ROA that covers their PA space, and also these "not real PI" blocks (because according to the NCC records, the /16 "belongs" to the LIR). From an aggregation PoV, this is ok-ish - but from a routing security PoV, I wonder if that's what we want (the "not real PI" block might be routed totally elsewhere now). > > So, to answer your question: for those "swampy PI", it would alter > > their rights (contracts according to 2007-01), costs (50 EUR/year) > > whoops. that's gonna cause unhappiness. Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all the other PI holders, and the amount of unhappiness was not very big. Those cases that I was involved with my "LIR admin-c" hat on, PI holders seemed to be happy to have a clear contract with a known entity (us), and the assurance that this would ensure that nobody else could make claims to their address space. Gert Doering -- assorted hats -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From netmaster at de.kpn-eurorings.net Thu Aug 4 14:15:18 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Thu, 4 Aug 2016 12:15:18 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: <6B20EA9786AB8640A0F6330A6312A0160151866CE4@UNCLE.kpn.DE> On 04.08.2016 13:59, Randy Bush wrote: > i have this feeling you are trying to say something here. i.e. if i > am the LIR, can i move "not really real PI" between customers and no > one knows? These PIs are real PIs (at least thought to be), but not "fully registered" with RIPE as other PIs. Yes, in theory the LIR could withdraw these PIs, but certainly will run into trouble and get complaints doing so. If such a PI is returned to the LIR, the LIR could re-assign them to other end-users. Or create new PIs even RIPE itself does not longer issue PIs (as Gert wrote "but was always outside RIPE policies", but IMHO also not explicitly prohibited). Markus -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From erey at ernw.de Thu Aug 4 14:43:50 2016 From: erey at ernw.de (Enno Rey) Date: Thu, 4 Aug 2016 14:43:50 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804121033.GK79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: <20160804124350.GA46270@ernw.de> Hi, On Thu, Aug 04, 2016 at 02:10:33PM +0200, Gert Doering wrote: > Hi, > > [Randy]> whoops. that's gonna cause unhappiness. > > Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all the > other PI holders, and the amount of unhappiness was not very big. > > Those cases that I was involved with my "LIR admin-c" hat on, PI holders > seemed to be happy to have a clear contract with a known entity (us), and > the assurance that this would ensure that nobody else could make claims > to their address space. Acting, amongst other tasks on the LIR side of the table, as a consultant to/representative of an organization holding & actively using several PI assignments from AU space I can fully second that. We can happily live with the fees. But not being able to "act fully autonomously" with regard to those netblocks is considered quite annoying and has even hindered some network redesign efforts in the past ("how can we be sure $NETBLOCK will still be routed properly once we touch sth?" etc.). So leaving that uncertainty behind us and having a clear contractual relationship with RIPE NCC would be very welcome, from this specific common's perspective. Me seems a cleaned up RIPE DB is a good thing, too. best Enno -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From l.yurkina at ripn.net Thu Aug 4 15:31:55 2016 From: l.yurkina at ripn.net (Larisa Yurkina) Date: Thu, 04 Aug 2016 16:31:55 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <715b024c-a684-3a08-a74a-d99d9beb172c@velder.li> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <715b024c-a684-3a08-a74a-d99d9beb172c@velder.li> Message-ID: <57A343C9.3000106@ripn.net> Patrick Velder ????? 04.08.2016 13:59: > Hi > > PI (Provider Independent) should be "Provider Independent" - any space > which is assigned by a LIR is not really "provider independent". > I think it's a good idea to change that. > > Regards > Patrick > Thanks for explanation Patrick :) Let's change 'status' from 'ASSIGNED PI', 'ASSIGNED PA' to 'ASSIGNED-BY-LIR', 'ASSIGNED-BY-RIPE NCC' since this is the same. 'Aggregatable', 'Independent', are very much obsoleted words only confusing people. > > On 04.08.2016 12:36, Larisa Yurkina wrote: >> Patrick Velder ????? 04.08.2016 11:12: >> >> Hi >>> >>> Hello Ingrid >>> >>> That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) >>> has an "Independent Assignment Request and Maintenance Agreement" >>> with the LIR, like end users which got their assignment direct from >>> RIPE NCC, this assignment will become an assignment which is managed >>> directly by RIPE NCC? >>> >>> Best regards >>> Patrick >>> >>> >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address >> space was not aggregated and was used as "ASSIGNED PI within >> ALLOCATED PI", all of them have agreement with the LIR, which also >> was within the policy, at least not against. Why should we change >> anything here? Just because some LIRs lost their control over 50% of >> the address space allocated to them? Perhaps there are some other >> ways to restore it? >> >> With respect, >> *Larisa Yurkina* >> RosNIIROS >> Internet Number Resources Group / Chief Manager >> l.yurkina at ripn.net / www.ripn.net >> >> ?.: +7 495 737-0604 >> >>> On 04.08.2016 09:39, Ingrid Wijte wrote: >>>> Dear colleagues, >>>> >>>> During RIPE 72, the RIPE NCC was asked to suggest a way forward >>>> with regards to the unclear situation arising from address blocks >>>> in the RIPE Database with the status ALLOCATED PI or ALLOCATED >>>> UNSPECIFIED. We want to give you an update on this work and ask for >>>> your input. >>>> >>>> BACKGROUND >>>> >>>> Although PI assignments made by LIRs have the same status in the >>>> RIPE Database, it is not clear if resource holders with assignments >>>> from LIRs have the same rights as resource holders with those >>>> issued by the RIPE NCC. The community, mainly End Users, has asked >>>> the RIPE NCC to clarify the situation. >>>> >>>> In the early days of the RIPE NCC, a small number of LIRs received >>>> allocations with the status ALLOCATED PI or ALLOCATED UNSPECIFIED. >>>> From these address blocks, LIRs could assign ranges with the status >>>> ASSIGNED PI. >>>> The RIPE community later decided that the RIPE NCC should be the >>>> only party assigning ranges with ASSIGNED PI to End Users. It was >>>> not clear what the status of the assignments that had already been >>>> made should be. >>>> >>>> ACTION TAKEN >>>> >>>> At RIPE 71, the Address Policy Working Group asked the RIPE NCC to >>>> check the actual assignment status with the holders of these >>>> allocations. We contacted all of the LIRs involved and around 50% >>>> said they had no contact with holders of assignments with the >>>> status ASSIGNED PI within their allocations. Several allocations >>>> containing only PA assignments were converted from ALLOCATED >>>> UNSPECIFIED to ALLOCATED PA following communication with LIRs. >>>> >>>> The RIPE NCC presented these results to the Address Policy Working >>>> Group at RIPE 72. The WG stressed that data accuracy must have the >>>> highest priority. It was further suggested that the RIPE NCC should >>>> follow up with the LIRs on a case-by-case basis, following the >>>> principles outlined below. >>>> >>>> The WG agreed that, where the LIR can document a mutual agreement >>>> that they administer the address space, a conversion from PI to PA >>>> should take place. In all other cases, assignments with the status >>>> ASSIGNED PI should be treated as being assigned by the RIPE NCC. >>>> >>>> It was also stated that LIRs should not register any new >>>> assignments with the status ASSIGNED PI, as policy no longer allows >>>> for new IPv4 PI assignments (with the exception of IXP PI >>>> assignments from our reserved address pool). >>>> >>>> APPROACH >>>> >>>> The RIPE NCC will contact the 38 LIRs holding allocations that >>>> contain address blocks with the status ASSIGNED PI (3,600 inetnum >>>> objects in total). >>>> >>>> In the following months, these LIRs will check if their RIPE >>>> Database entries are still correct. Each LIR will check their >>>> records and with their customers to see under what conditions the >>>> assignments were originally provided. >>>> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented >>>> that the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to >>>> apply the RIPE policy, ?Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region?. The >>>> PI assignments will become part of the address space managed by the >>>> RIPE NCC just like all other PI space. Once the resource holders >>>> have fulfilled the contractual requirements, they will have the >>>> same rights and obligations as any other End User of PI space. >>>> - Split the allocations to separate the PI assignments and >>>> convert the blocks that remain with an LIR to ALLOCATED PA. >>>> >>>> We suggest giving these LIRs until the end of January 2017 to >>>> clarify the status of the assignments within their ALLOCATED >>>> PI/UNSPECIFIED allocations. >>>> >>>> In situations where a dispute arises between the LIR and the >>>> assignment holder about the administrative responsibility, the RIPE >>>> NCC will do its best to support a fair solution. >>>> >>>> We welcome your feedback on this suggested approach. Please provide >>>> your input before 12 September 2016. >>>> >>>> Kind regards, >>>> >>>> Ingrid Wijte >>>> Assistant Manager Registration Services >>>> RIPE NCC >>> >> >> > > -- With respect, *Larisa Yurkina* RosNIIROS Internet Number Resources Group / Chief Manager l.yurkina at ripn.net / www.ripn.net ?.: +7 495 737-0604 From netmaster at de.kpn-eurorings.net Thu Aug 4 15:31:57 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Thu, 4 Aug 2016 13:31:57 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: <6B20EA9786AB8640A0F6330A6312A0160151867DA9@UNCLE.kpn.DE> Randy Bush wrote: >> Gert Doering wrote: >> Also, it might lead to deaggs (Markus' case) where a /14 that was >> originally "in one LIR" would be "3x /16, plus some smaller fragments >> in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 >> won't get a ROA, and he'll have to announce more-specifics. > > lemme see if i get this. to have the owner registration correct, some > address space will have to be broken up and owned by multiple IRs, thus > fragmenting routing? i like correct registration, but the commons has > become pretty polluted Well, my example was for a /16 (not the /14, which comes with another story), currently announced by the LIR as /16 and partially as /17, with 6 smaller ranges announced by another entity of this LIR and 23 PIs announced out of 38 (so much for "accuracy" ...) by other ASes. Breaking up the /16 into PIs and PAs would end up with 42 new prefixes in the routing table (beside the current 3+6+38 seen ones). OTOH, at least the 23 announced prefixes would become PIs as the others (50? for the LIR or a direct agreement with RIPE) and the remaining 15 PIs would be either returned or registered as the rest. @Ingrid: Have you made an analysis, how many new prefixes would show up in the routing table by de-aggregation the A-PI/A-U allocations (best case/ worst case), how many of the PIs in there are currently seen (or not) as separate announcement? Just to get a feeling ... (yes, everyone can do this, but everyone is busy ... ;-). Markus -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From sergey at devnull.ru Thu Aug 4 16:29:59 2016 From: sergey at devnull.ru (Sergey Myasoedov) Date: Thu, 4 Aug 2016 16:29:59 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804121033.GK79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: Hi Gert, > We (the RIPE community and the NCC) rolled out 2007-01 to all the > other PI holders, and the amount of unhappiness was not very big. No. It was big. But you prefer not to mention that. That?s your perception, please don?t say ?we?. > Those cases that I was involved with my "LIR admin-c" hat on, PI holders > seemed to be happy to have a clear contract with a known entity (us), and > the assurance that this would ensure that nobody else could make claims > to their address space. By the way, 2007-01 has produced a new market with ~2 MEUR/yr volume. Do you really think that PI holders were happy to pay such amount? -- Kind regards, Sergey Myasoedov From randy at psg.com Thu Aug 4 16:37:48 2016 From: randy at psg.com (Randy Bush) Date: Thu, 04 Aug 2016 23:37:48 +0900 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804121033.GK79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: > I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", > and those are well-defined. Add "Legacy" to it (outside RIR framework). inetnum: 198.180.150.0 - 198.180.153.255 netname: RG79-198-180-150 country: US org: ORG-RG79-RIPE sponsoring-org: ORG-SSP3-RIPE admin-c: RB366-ARIN tech-c: RB366-ARIN status: LEGACY mnt-by: MAINT-RGNET mnt-domains: MAINT-RGNET mnt-by: RIPE-NCC-LEGACY-MNT created: 2016-03-16T15:13:51Z last-modified: 2016-04-14T10:44:25Z source: RIPE randy From Andre.Chapuis at swisscom.com Thu Aug 4 15:14:46 2016 From: Andre.Chapuis at swisscom.com (Andre.Chapuis at swisscom.com) Date: Thu, 4 Aug 2016 13:14:46 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <57A32983.4010703@ripn.net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <57A32983.4010703@ripn.net> Message-ID: <749383045.240517.1470316489087.JavaMail.totemomail@ss007565.tauri.ch> Hi Everybody, I agree with Larisa. As a LIR 'responsible for ALLOCATED UNSPECIFIED blocks, the amount of work to change all that would be huge compared to the gain. Back in 2002, I did a review of these blocks and managed to get a good number of assignments back, that we re-used as ASSIGNED PA. It also allowed us to update the real PI records. But this was quite a time-intensive exercise I'd prefer not to do again. Furthermore, knowing that our allocations are full to 90%, there's not much room for 'misuse' the PI policy (which actually does not apply in this case!) by assigning PI ourselves -> so benefit is quite inexistent Regards, Andr? -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Larisa Yurkina Sent: Thursday, August 04, 2016 1:40 PM To: Randy Bush Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Randy Bush ????? 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address >> space was not aggregated and was used as "ASSIGNED PI within >> ALLOCATED PI", all of them have agreement with the LIR, which also >> was within the policy, at least not against. Why should we change >> anything here? Just because some LIRs lost their control over 50% of >> the address space allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, ?Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region?. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, > why, in pragmatic terms a router geek can understand (yes, i know > that's a high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina at ripn.net / www.ripn.net ?.: +7 495 737-0604 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5540 bytes Desc: S/MIME Cryptographic Signature URL: From stolpe at resilans.se Thu Aug 4 17:58:26 2016 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 4 Aug 2016 17:58:26 +0200 (CEST) Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <57A31AAE.6060305@ripn.net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: On Thu, 4 Aug 2016, Larisa Yurkina wrote: > Patrick Velder ????? 04.08.2016 11:12: > > Hi >> >> Hello Ingrid >> >> That means, if a resource holder (ASSIGNED PI within ALLOCATED PI) has an >> "Independent Assignment Request and Maintenance Agreement" with the LIR, >> like end users which got their assignment direct from RIPE NCC, this >> assignment will become an assignment which is managed directly by RIPE >> NCC? >> >> Best regards >> Patrick >> >> > My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about 20 > years ago, according to those days policy. Some part of address space was not > aggregated and was used as "ASSIGNED PI within ALLOCATED PI", all of them > have agreement with the LIR, which also was within the policy, at least not > against. Why should we change anything here? Just because some LIRs lost > their control over 50% of the address space allocated to them? Perhaps there > are some other ways to restore it? Yes, if it aint broken, don't try to fix it. However Ingrid is right that "data accuracy must have the highest priority" and if the status tag causes confusion maybe something have to be done. The problem is that we aim for a very binary black and white world and forget that all of these labels were not there in the beginning. In our particular case we have been handling address space for three decades and the line between legacy in 1991 and the NCC era in 1992 was not very sharp. First none of the space had any status. Then (still in the 1990's) a colleague arbitrarily put the "ALLOCATED PI/ASSIGNED PI" status everywhere. Then (a couple of years ago) the NCC decided some blocks where LEGACY (assignments were made before 1992) and some not (assignments were made in 1992 or shortly afterwards), however all of the space have been treated both as LEGACY and PA earlier on. The use of PI was obviously based on a misunderstanding and the non-legacy blocks have been PA all the time so apparently you learn as long as you live. I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes the database more readable but I still agree with you Larisa that if we have been going on like this for decades, why the sudden urge to change it now? The end users will certainly be a bit worried by the sudden change. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From erey at ernw.de Thu Aug 4 18:16:57 2016 From: erey at ernw.de (Enno Rey) Date: Thu, 4 Aug 2016 18:16:57 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> Message-ID: <20160804161657.GJ46785@ernw.de> Hi, On Thu, Aug 04, 2016 at 05:58:26PM +0200, Daniel Stolpe wrote: > > > I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes > the database more readable but I still agree with you Larisa that if we > have been going on like this for decades, why the sudden urge to change it > now? The end users will certainly be a bit worried by the sudden change. maybe, maybe not. Quite some won't be reachable or won't exist any more and won't even know that the assignment ever existed (or, for that matter, what an IP address is). Still I expect that a few of those being aware of the issue and actively running services in those netblocks will not be worried. I can only speak for one (ex-) end user organization (albeit one holding several [AU] PI assignments from different [covering] LIRs, so probaly a "large one" in those terms) but I can state that we will be not be worried but in fact *very relieved* once clarity wrt administrative responsibility is reached. It might be noteworthy that these assignments were handed out in the 90s as part of "Internet service" contracts in the corporate space, hence usually (not too tiny) amounts of money were involved. I leave the conclusions to the reader... best Enno > > Cheers, > Daniel > > _________________________________________________________________________________ > Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se > Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ > Box 45 094 556741-1193 > 104 30 Stockholm > > -- Enno Rey ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 173 6745902 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net || Conference: www.troopers.de Twitter: @Enno_Insinuator ======================================================= From leo.vegoda at icann.org Thu Aug 4 18:33:48 2016 From: leo.vegoda at icann.org (Leo Vegoda) Date: Thu, 4 Aug 2016 16:33:48 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804113710.GJ79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: Hi Gert, Gert Doering wrote: [...] > Right now, there are two different shades of "PI colour" - "real PI" > and "not really real PI". The first shade has the full obligations and > protection of 2007-01 - namely, a contractual relationship (via a > sponsoring LIR) with the NCC that clearly identifies who has "rights" > to that prefix. The other shade is also labeled "PI", but whether or > not contracts exist, and who is the legitimate holder, is less well > defined. Can you please expand on this? What are the risks that registrants of "not really real PI" face? Andrea's slide included a bullet stating that: "Many LIRs do not have contact with ASSIGNED PI customers anymore" Should I understand that to mean that there is a risk the LIR could take back the assignment? Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4968 bytes Desc: not available URL: From stolpe at resilans.se Thu Aug 4 18:34:13 2016 From: stolpe at resilans.se (Daniel Stolpe) Date: Thu, 4 Aug 2016 18:34:13 +0200 (CEST) Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804161657.GJ46785@ernw.de> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804161657.GJ46785@ernw.de> Message-ID: On Thu, 4 Aug 2016, Enno Rey wrote: > Hi, > > On Thu, Aug 04, 2016 at 05:58:26PM +0200, Daniel Stolpe wrote: >> >> >> I think we can live with changing ASSIGNED PI to ASSIGNED PA if it makes >> the database more readable but I still agree with you Larisa that if we >> have been going on like this for decades, why the sudden urge to change it >> now? The end users will certainly be a bit worried by the sudden change. > > maybe, maybe not. Quite some won't be reachable or won't exist any more > and won't even know that the assignment ever existed (or, for that > matter, what an IP address is). > Still I expect that a few of those being aware of the issue and actively > running services in those netblocks will not be worried. I can only > speak for one (ex-) end user organization (albeit one holding several > [AU] PI assignments from different [covering] LIRs, so probaly a "large > one" in those terms) but I can state that we will be not be worried but > in fact *very relieved* once clarity wrt administrative responsibility > is reached. > > It might be noteworthy that these assignments were handed out in the 90s > as part of "Internet service" contracts in the corporate space, hence > usually (not too tiny) amounts of money were involved. I leave the > conclusions to the reader... You are right. "Mixed reactions" is probably a better description of the forecast. We have hundreds of customers/end users in theese blocks. Some will know and understand. Some will not. As always. Cheers, Daniel _________________________________________________________________________________ Daniel Stolpe Tel: 08 - 688 11 81 stolpe at resilans.se Resilans AB Fax: 08 - 55 00 21 63 http://www.resilans.se/ Box 45 094 556741-1193 104 30 Stockholm From gert at space.net Thu Aug 4 20:03:40 2016 From: gert at space.net (Gert Doering) Date: Thu, 4 Aug 2016 20:03:40 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> Message-ID: <20160804180340.GN79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 04:33:48PM +0000, Leo Vegoda wrote: > Gert Doering wrote: > > [...] > > Can you please expand on this? What are the risks that registrants of "not > really real PI" face? Andrea's slide included a bullet stating that: > > "Many LIRs do not have contact with ASSIGNED PI customers anymore" > > Should I understand that to mean that there is a risk the LIR could take > back the assignment? This is one potential risk, or someone else could try to grab it and claim "this is mine", with no contractual data at the NCC to settle the dispute. Without a clear agreement and clear policies to govern these numbers, it's hard to rely on anything. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5082 bytes Desc: not available URL: From oliver at bartels.de Thu Aug 4 21:57:34 2016 From: oliver at bartels.de (Oliver Bartels GmbH) Date: Thu, 4 Aug 2016 21:57:34 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> References: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> Message-ID: Am 04.08.2016 um 13:05 schrieb Netmaster (KPN Eurorings B.V. Germany): > But splitting current A-PI/-U is as such not really a nice thing. It will > leave the initial holders of the ranges with little fragments. True, > nothing which cannot be handled, but if I announce e.g. a /16 or have to > announce 50+ (or more or less) /20-/24s, it makes a difference (operational > and financially). Yes, more filters, reverse zones, ROAs, ... Yes, everything > is possible, but I don't like it. I represent one of the PI resource holders especially in one of "your" /14 unspecified blocks, thus let me point out some things, I of course have the resource hold hat on, too: - It is not on the side of the resource holders that they can't be contacted, it is just that it is difficult to us to find a LIR contact that is responsive. You probably know about the dificulties with big organisations and there have been no approach to contact us in the last years. - At the time your company received the /14 from the *liquidator* of KPNQwest, the unspecified and PI attributes were already installed. This means: Your company knew, what they bought, and they knew, that there were third party rights *already*. This means: These third party PI has to be respected (and in our case: We got a statement from RIPE NCC that we received and use it in good favor, and yes, we still use it and do not intend to change this). - There are of course no contracts any more, bankrupt LIR means bankrupt LIR means bankrupt LIR (in this case: KPNQwest had been *liquidated*, *no* transfer of rights, because otherwise KPN would have had to pay the old KPNQwest debts what they didn't). - Thus in general: If the solution is to split, if there is *no other* agreement and the RIPE NCC wants to separate this spaces, it has to. "Big companies effort" is no reason to interfere with third party rights or just grab them. - *However*: Reasonable people typically find reasonable solutions. The current /24 over /14 works for us - as long as KPN routes any traffic misrouted then to correct destination, provides RDNS (this is a thing that should be discussed how to handle), does not block maintainers (dto.!) etc. - For us it is just important to clarify that the current situation does not give the unspecified "holder" any specific rights, which means: Any solution like that above works as long as the third party rights are *respected* by the big party, too. It is on the side of the "unspecified" holder (LIR) to reach mutual agreement, because they want to reduce the effort. - It is as with all resources: At the end, organization rules here or there, it ends up that resources are something important to individuals or organisations and resources that have been registered as independent for more than 15 years are obviously covered by EU law, thus this is not a decision that can be done just by majority vote or company policy or whatever, it is as with other resources something that is protected by law. With respect Oliver -- Bartels System GmbH + 80935 M?nchen, Germany + Ust. Id. DE129296210 oliver at bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG M?nchen HRB85259 + Gesch?ftsf?hrer Oliver Bartels From gert at space.net Thu Aug 4 22:15:19 2016 From: gert at space.net (Gert Doering) Date: Thu, 4 Aug 2016 22:15:19 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: <20160804201519.GO79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 11:37:48PM +0900, Randy Bush wrote: > > I used to assume there is "ALLOCATED PA", "ASSIGNED PA" and "ASSIGNED PI", > > and those are well-defined. Add "Legacy" to it (outside RIR framework). > > inetnum: 198.180.150.0 - 198.180.153.255 > netname: RG79-198-180-150 > country: US > org: ORG-RG79-RIPE > sponsoring-org: ORG-SSP3-RIPE > admin-c: RB366-ARIN > tech-c: RB366-ARIN > status: LEGACY Well. Sorry for not being precise in my wording. What I tried to say is that LEGACY is a special status that acknowledges that these prefixes have been given out before the RIRs existed. They live "outside the RIR framework" as far as being subject to RIPE policy is concerned - except in well-defined documents, RIPE policy does not apply to LEGACY space. They *do* live "within" the RIR framework as far as documentation is concerned, and this is very good :-) In any case, they have a very distinct shade of grey... ;-) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From netmaster at de.kpn-eurorings.net Thu Aug 4 23:50:07 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Thu, 4 Aug 2016 21:50:07 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> Message-ID: <6B20EA9786AB8640A0F6330A6312A0160151869424@UNCLE.kpn.DE> Further below some comments on Oliver's statement, which (*) probably do not contribute much to this discussion, but I felt some words are needed. (*) which = the comments, if the majority of statements do, I leave up to you to decide. But Oliver brought up indeed one interesting aspect (beside the operational question on how to secure RDNS): What about legal aspects (for both "sides")? Oliver Bartels wrote: > It is as with all resources: At the end, organization rules here or > there, it ends up that resources are something important to individuals > or organisations and resources that have been registered as independent > for more than 15 years are obviously covered by EU law, thus this is > not a decision that can be done just by majority vote or company policy > or whatever, it is as with other resources something that is protected > by law. Have there at all ever been a case where a LIR holding A-PI/-U space withdraw an end user's PI on purpose and against the will/without the agreement of the end user and the end user went to court as RIPE NCC couldn't have this sorted out? Markus Oliver Bartels wrote: > It is not on the side of the resource holders that they can't be > contacted, it is just that it is difficult to us to find a LIR > contact that is responsive. You probably know about the dificulties > with big organisations and there have been no approach to contact us > in the last years. I agree that finding the right contacts in big organizations might be difficult. But if you state, it's always easy to find contacts for PIs, I do not agree at all ... you've probably never tried to do some "cleanups". BTW: the email address you had last contact with K* about your address ranges back in 2002 still works ... so at least you should have had no problems ... > - At the time your company received the /14 from the *liquidator* > of KPNQwest, the unspecified and PI attributes were already > installed. > [...] > This means: [...] Just to make it clear, as your statements could be read quite negative: KPN always respected (and will continue to respect) the "rights" of the PI owners out of the former de.xlink allocations. Further, all main contact email addresses of Xlink, KPNQwest in regards to address management still work. > If the solution is to split, if there is *no other* agreement > and the RIPE NCC wants to separate this spaces, it has to. > "Big companies effort" is no reason to interfere with third party > rights or just grab them. Who is grabbing which rights? > - *However*: Reasonable people typically find reasonable solutions. > The current /24 over /14 works for us - as long as KPN routes any > traffic misrouted then to correct destination, provides RDNS (this > is a thing that should be discussed how to handle), does not block > maintainers (dto.!) etc. The routing ... where should we route the traffic to if the Internet does not already do this and you are not connected to KPN? (The only thing I could think of would be the case where some networks in the middle do filter on some questionable allocation sizes and traffic ends up within our network AND there's a known path from us to you.) RDNS is indeed a very valid point as the /16 is delegated to KPN and we delegate further. I do understand the concerns and consider this as well a non-optimal solution. About the "does not block maintainers". This is an agreement / out- come of an old discussion between RIPE NCC and us as LIR years ago. It has been re-verified recently and RIPE NCC confirmed: "yes, don't give out maintainers". So whom are you blaming for what? -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From cfriacas at fccn.pt Fri Aug 5 01:54:13 2016 From: cfriacas at fccn.pt (Carlos Friacas) Date: Fri, 5 Aug 2016 00:54:13 +0100 (WEST) Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <6B20EA9786AB8640A0F6330A6312A0160151867DA9@UNCLE.kpn.DE> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <6B20EA9786AB8640A0F6330A6312A0160151867DA9@UNCLE.kpn.DE> Message-ID: On Thu, 4 Aug 2016, Netmaster (KPN Eurorings B.V. Germany) wrote: (snip) > > > @Ingrid: > Have you made an analysis, how many new prefixes would show up in the > routing table by de-aggregation the A-PI/A-U allocations (best case/ > worst case), how many of the PIs in there are currently seen (or not) > as separate announcement? Just to get a feeling ... (yes, everyone > can do this, but everyone is busy ... ;-). http://www.cidr-report.org/as2.0/ 04-08-16 = 622607 It seems nobody really cares about the routing table... ;-) Cheers, Carlos > Markus > > -- > Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany > +49 (0)178 5352346 | | www.kpn.de > > KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main > Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 > Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From oliver at bartels.de Fri Aug 5 06:58:33 2016 From: oliver at bartels.de (Oliver Bartels GmbH) Date: Fri, 5 Aug 2016 06:58:33 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <6B20EA9786AB8640A0F6330A6312A0160151869424@UNCLE.kpn.DE> References: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> <6B20EA9786AB8640A0F6330A6312A0160151869424@UNCLE.kpn.DE> Message-ID: <899d17cd-2e76-fa73-d014-ca3a811dcda7@bartels.de> Am 04.08.2016 um 23:50 schrieb Netmaster (KPN Eurorings B.V. Germany): > Further below some comments on Oliver's statement, which (*) probably > do not contribute much to this discussion, but I felt some words are > needed. (*) which = the comments, if the majority of statements do, I > leave up to you to decide. They contribute a lot, because your reaction including the "co not contribute" statement is a nice demonstration of the problems arising regarding from the nearly non-existing relation between "unspecified" and PI holders. There *are* different interests. Period. > But Oliver brought up indeed one interesting aspect (beside the > operational question on how to secure RDNS): What about legal > aspects (for both "sides")? That *is* a point. With IPv4 we are no longer talking about administrative issues only, like it was in the times when I administered a full LIR. The only way to obtain IPv4 space except for the initial /22 is to use money and buy it on the free market. This is why RIPE changed their policies. And when money is involved, standard commercial law applies. > Have there at all ever been a case where a LIR holding A-PI/-U space > withdraw an end user's PI on purpose and against the will/without the > agreement of the end user and the end user went to court as RIPE NCC > couldn't have this sorted out? I believe you that *you* won't withdraw or grab such resource. However, the company you work for belongs to the free share market, a lot of shares currently belong thru a holding to a single person who already decided to sell Eplus to Telefonice, which then decided to "integrate" (means: take customers and some base stations, liquidate/close the remaining stuff) it. Besides the liquidation act of KPNQwest. There is no gurantee at all that not tomorrow someone decides to sell your divsion to an x far east hedge fonds, which then decides to close the german NOC including your position, monetarize everything regardless of the rights of PI holders etc. We as as small company survived big XLINK, big KPNqwest, big KPN as a state owned company (now: 0% Netherlands), we survived several big equipment vendors (last: Alcatel, sad enough) etc. We want true *independence* on our resources. And this is why the issue should be solved formally by registering PI as PI, which it is, and not as "dependend from the good will of x until bought by hedge fonds y". This means: PI should be *independent* in the database, from what I read from your statement, you do not like the current RDNS solution, too, thus there should be some independent (RIPE based) solution. We can talk about not splitting the routing table, your company will probably see our announcement and thus forwarding in case of (typically not used) more specific filters should work. > About the "does not block maintainers". This is an agreement / out- > come of an old discussion between RIPE NCC and us as LIR years ago. > It has been re-verified recently and RIPE NCC confirmed: "yes, don't > give out maintainers". So whom are you blaming for what? PI space should show up in the database as: mnt-by: RIPE-NCC-END-MNT mnt-by: resource-holder-MNT and there is no reason to lock out the resource holder as it is practiced. Regardless who says this, there are rules. Kind Regards Oliver -- Bartels System GmbH + 80935 M?nchen, Germany + Ust. Id. DE129296210 oliver at bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG M?nchen HRB85259 + Gesch?ftsf?hrer Oliver Bartels From netmaster at de.kpn-eurorings.net Fri Aug 5 07:17:49 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Fri, 5 Aug 2016 05:17:49 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: Message-ID: <6B20EA9786AB8640A0F6330A6312A0160151869D3B@UNCLE.kpn.DE> Returning to the initial discussion ... Ingrid Wijte wrote: > The WG agreed that, where the LIR can document a mutual agreement > that they administer the address space, a conversion from PI to PA > should take place. In all other cases, assignments with the status > ASSIGNED PI should be treated as being assigned by the RIPE NCC. It reads like this is already written in stone ... is it ??? If this would be the case, the only way to achieve this (to have PIs out of A-PI/-U to be treated as all other PIs, give their holders the same rights, "safety" and obligations) is - to split up the A-PI/-U as you proposed or - move all PIs out of the A-PI/-U (or convert them to PA and move some PIs) => renumbering PI holder, address space win for LIR or - have the LIR even return the full A-PI/-U (and if wanted get back a same sized PA) => renumbering LIR, "loss" of A-PI/-U (which brings up again the question, if assigning "new" PIs out of A-PI/-U would be really against currently policy) Did I miss anything? Even if the object could be locked within the RIPE DB, contractual everything could be secured and e.g. RDNS is fixed as well: the PI as being a more specific within LIR's A-PI/-U and the issues arising of this could probably never be solved within other ways (or it's too early). If things suddenly don't work out any more like they did the last 15++ years and the consensus is to have it "solved", it's the question what is the best approach, what does it mean, what are the drawbacks, is it worth taking multiple approaches and who at the end pays the bill. Markus -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From netmaster at de.kpn-eurorings.net Fri Aug 5 07:44:05 2016 From: netmaster at de.kpn-eurorings.net (Netmaster (KPN Eurorings B.V. Germany)) Date: Fri, 5 Aug 2016 05:44:05 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <899d17cd-2e76-fa73-d014-ca3a811dcda7@bartels.de> References: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> <6B20EA9786AB8640A0F6330A6312A0160151869424@UNCLE.kpn.DE> <899d17cd-2e76-fa73-d014-ca3a811dcda7@bartels.de> Message-ID: <6B20EA9786AB8640A0F6330A6312A0160151869D85@UNCLE.kpn.DE> Oliver Bartels wrote: > There *are* different interests. Period. Agree. You and some others like "a true independence resource", others really don't care as long as it works, some don't like to pay money as long is not needed, some don't like to pick up the work, some probably don't like changes, some others probably don't like the outcome and what it does mean and others ... This is why we are talking about it. While you are open to swap your PIs out of our A-U, others would never consider renumbering as an option. Different interests, different approaches ... > There is no gurantee at all that not tomorrow someone decides > to sell your divsion to an x far east hedge fonds, which then > decides to close the german NOC including your position, > monetarize everything regardless of the rights of PI holders > etc. Either PI holders have rights or they don't. In your other email you stated > This means: Your company knew, what they bought, and they knew, > that there were third party rights *already*. Why wouldn't this be valid for Far East hedge funds? >> About the "does not block maintainers". This is an agreement / >> outcome of an old discussion between RIPE NCC and us as LIR >> years ago. [...] > PI space should show up in the database as: > mnt-by: RIPE-NCC-END-MNT > mnt-by: resource-holder-MNT > and there is no reason to lock out the resource holder as it is > practiced. Regardless who says this, there are rules. This should be discussed with RIPE NCC (again) as source of this "lock out" rule ... rule vs. rule ... but eventually not needed as the final approach should cover this. Markus -- Darmst?dter Landstrasse 184 | 60598 Frankfurt | Germany +49 (0)178 5352346 | | www.kpn.de KPN EuroRings Germany B.V. | Niederlassung Frankfurt am Main Amtsgericht Frankfurt HRB99781 | USt.IdNr. DE 815496855 Gesch?ftsf?hrer Jesus Martinez & Jacob Leendert Hage From gert at space.net Fri Aug 5 08:25:10 2016 From: gert at space.net (Gert Doering) Date: Fri, 5 Aug 2016 08:25:10 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: <20160805062510.GP79185@Space.Net> Hi, On Thu, Aug 04, 2016 at 04:29:59PM +0200, Sergey Myasoedov wrote: > > We (the RIPE community and the NCC) rolled out 2007-01 to all the > > other PI holders, and the amount of unhappiness was not very big. > > No. It was big. But you prefer not to mention that. That???s your > perception, please don???t say ???we???. "We" was related to "we rolled out 2007-01", and yes, that was "all of us". It might be that *you* were unhappy about it, but that's not the general sentiment I heard from other markets. > > Those cases that I was involved with my "LIR admin-c" hat on, PI holders > > seemed to be happy to have a clear contract with a known entity (us), and > > the assurance that this would ensure that nobody else could make claims > > to their address space. > > By the way, 2007-01 has produced a new market with ~2 MEUR/yr volume. > Do you really think that PI holders were happy to pay such amount? In this thread, you've seen statements from PI holders, clearly stating that they do not care at all for 50 EUR/year if they get clear contractual rights in return. As a network administrator, I do have my "own" /24 PI (... dating back to 1993 or so), and I also pay 50 EUR/year for it. I have considered whether that is enough of an annoyance to return it to the IPv4 pool, and decided that it has enough sentimental value for me to keep it. So yes, PI holders are OK with that. Note that I did not say "everybody was happy and celebrated". I said "the amount of unhappiness was not very big" - which translates to "a bit of grumbling and cursing here and there, but nobody decided to raise a big stink in the AGM or ask their regulator to take over from the RIPE NCC". Right? Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From oliver at bartels.de Fri Aug 5 08:50:52 2016 From: oliver at bartels.de (Oliver Bartels GmbH) Date: Fri, 5 Aug 2016 08:50:52 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <6B20EA9786AB8640A0F6330A6312A0160151869D85@UNCLE.kpn.DE> References: <6B20EA9786AB8640A0F6330A6312A016015186676C@UNCLE.kpn.DE> <6B20EA9786AB8640A0F6330A6312A0160151869424@UNCLE.kpn.DE> <899d17cd-2e76-fa73-d014-ca3a811dcda7@bartels.de> <6B20EA9786AB8640A0F6330A6312A0160151869D85@UNCLE.kpn.DE> Message-ID: Am 05.08.2016 um 07:44 schrieb Netmaster (KPN Eurorings B.V. Germany): > Oliver Bartels wrote: >> This means: Your company knew, what they bought, and they knew, >> that there were third party rights *already*. > Why wouldn't this be valid for Far East hedge funds? In *theory* it is valid. In *theory* if you have deposits in Icelandic banks, you have the right to get them back, covered by international agreements. You may even take Hypo Alpe Adria/HETA bank bonds *guaranteed* by the Austrian (!) federal state Kaernten, that is not too far away. A state gurantee says and means: 100% money back plus interest. In *theory* Great Britain is a stable member of the European Union and your big investements there should give you access to the EU common market under *current* GB and EU law. In *practice*: Good luck ... And: Have you ever tried to handle a dificult non-scheme problem calling your mobile operators call center located in India ... We are living in difficult and unstable times, and RIPE NCC provides international services, it is quite easy to move resources between different countries, it is quite difficult to apply a constant legislation on them. Thus the party insuring the resources should be RIPE and no one else. KInd Regards Oliver -- Bartels System GmbH + 80935 M?nchen, Germany + Ust. Id. DE129296210 oliver at bartels.de + http://www.bartels.de + Tel. +49-(0)89-856305-0 Handelsregister AG M?nchen HRB85259 + Gesch?ftsf?hrer Oliver Bartels From ripe-wgs at radu-adrian.feurdean.net Fri Aug 5 15:11:16 2016 From: ripe-wgs at radu-adrian.feurdean.net (Radu-Adrian FEURDEAN) Date: Fri, 05 Aug 2016 15:11:16 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160805062510.GP79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> <20160805062510.GP79185@Space.Net> Message-ID: <1470402676.3279875.686900377.6C40F4B8@webmail.messagingengine.com> On Fri, Aug 5, 2016, at 08:25, Gert Doering wrote: > of grumbling and cursing here and there, but nobody decided to raise > a big stink in the AGM or ask their regulator to take over from the > RIPE NCC". Right? Hi, Wasn't this also because those that were unhappy did not have access to the AGM ? I am aware of cases where "someones" lost pretty big chunks of PI (up to /21) because they wanted way to much independence (including independence from RIPE and RIPE NCC).... except they were too small and were missing some local administrativia for the regulator to even read their complaint. I do agree that those cases were a minority for the whole service area, but there were cases where things were less clear (e.g. dating back to a time where some of us were stuck to "NIR"s a.k.a "last resort registries" which could do whatever they wanted). From ingrid at ripe.net Fri Aug 5 15:41:11 2016 From: ingrid at ripe.net (Ingrid Wijte) Date: Fri, 5 Aug 2016 15:41:11 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <20160804121033.GK79185@Space.Net> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: Dear colleagues, >>> Also, it might lead to deaggs (Markus' case) where a /14 that was >>> originally "in one LIR" would be "3x /16, plus some smaller fragments >>> in the LIR" and "lots of /24 PI managed by the NCC" now - so the /14 >>> won't get a ROA, and he'll have to announce more-specifics. >> lemme see if i get this. to have the owner registration correct, some >> address space will have to be broken up and owned by multiple IRs, thus >> fragmenting routing? i like correct registration, but the commons has >> become pretty polluted. The main issue that we (the WG and the RIPE NCC) are trying to resolve is the lack of clarity around the status and rights of these assignments. It?s not necessarily the case that the End User registration is incorrect. In many cases LIRs have put a lot of effort into keeping this information up to date. If there is a /16 ?ALLOCATED UNSPECIFIED? block that contains "real" Provider Independent assignments, that /16 would indeed be split in order to carve out that assignment. The LIR would end up with multiple PA allocations instead of one /16. The PI resource holder would be able to decide who their sponsoring LIR should be. It is possible that they would remain with that same LIR, or they could move to another sponsoring LIR and take their PI assignment with them. If the resource holder is an LIR themselves, the PI assignment could be registered under their own LIR account. This means that route and domain objects would need to be updated. It?s also relevant to mention that several LIRs already allow for more specific routes for the assignments. The LIRs will be able to request a new ROA for their remaining blocks. The sponsoring LIR can request a ROA on behalf of the PI resource holder, or the PI holder can do that themselves if they wish. I hope this answers your questions. Ingrid Wijte RIPE NCC > I leave the definite answer to Ingrid to answer. > > My understanding of "normal" NCC<->LIR stockkeeping is that PI is never > living inside blocks that "belong" to a given LIR. So, the LIR would > never be able to get a ROA covering PI space. > > For some of these "old" blocks, there is a /16 which covers regular > LIR/PA space, and "not real PI" space, and the LIR can get a ROA that > covers their PA space, and also these "not real PI" blocks (because > according to the NCC records, the /16 "belongs" to the LIR). > > From an aggregation PoV, this is ok-ish - but from a routing security > PoV, I wonder if that's what we want (the "not real PI" block might > be routed totally elsewhere now). > > >>> So, to answer your question: for those "swampy PI", it would alter >>> their rights (contracts according to 2007-01), costs (50 EUR/year) >> whoops. that's gonna cause unhappiness. > Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all the > other PI holders, and the amount of unhappiness was not very big. > > Those cases that I was involved with my "LIR admin-c" hat on, PI holders > seemed to be happy to have a clear contract with a known entity (us), and > the assurance that this would ensure that nobody else could make claims > to their address space. > > Gert Doering > -- assorted hats From Andre.Chapuis at swisscom.com Fri Aug 5 16:39:00 2016 From: Andre.Chapuis at swisscom.com (Andre.Chapuis at swisscom.com) Date: Fri, 5 Aug 2016 14:39:00 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <57A32983.4010703@ripn.net> Message-ID: <1437317490.466540.1470407942840.JavaMail.totemomail@ss007564.tauri.ch> Once again since it seems not to have gone through... -----Original Message----- From: Chapuis Andr?, INI-ON-EPC-IPE Sent: Thursday, August 04, 2016 3:15 PM To: 'l.yurkina at ripn.net' ; Randy Bush Cc: address-policy-wg at ripe.net Subject: RE: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Hi Everybody, I agree with Larisa. As a LIR 'responsible for ALLOCATED UNSPECIFIED blocks, the amount of work to change all that would be huge compared to the gain. Back in 2002, I did a review of these blocks and managed to get a good number of assignments back, that we re-used as ASSIGNED PA. It also allowed us to update the real PI records. But this was quite a time-intensive exercise I'd prefer not to do again. Furthermore, knowing that our allocations are full to 90%, there's not much room for 'misuse' the PI policy (which actually does not apply in this case!) by assigning PI ourselves -> so benefit is quite inexistent Regards, Andr? -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Larisa Yurkina Sent: Thursday, August 04, 2016 1:40 PM To: Randy Bush Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Randy Bush ????? 04.08.2016 14:12: >> My LIR have got ALLOCATED PI and ALLOCATED UNSPECIFIED blocks about >> 20 years ago, according to those days policy. Some part of address >> space was not aggregated and was used as "ASSIGNED PI within >> ALLOCATED PI", all of them have agreement with the LIR, which also >> was within the policy, at least not against. Why should we change >> anything here? Just because some LIRs lost their control over 50% of >> the address space allocated to them? Perhaps there are some other ways to restore it? >> >>>> After the LIRs have finished their research, the RIPE NCC will: >>>> >>>> - Convert assignments to ASSIGNED PA if it can be documented that >>>> the administrative responsibility lies with the LIR >>>> - Follow up directly with resource holders of ASSIGNED PI to apply >>>> the RIPE policy, ?Contractual Requirements for Provider >>>> Independent Resource Holders in the RIPE NCC Service Region?. The >>>> PI assignments will become part of the address space managed by >>>> the RIPE NCC just like all other PI space. Once the resource >>>> holders have fulfilled the contractual requirements, they will >>>> have the same rights and obligations as any other End User of PI >>>> space. >>>> - Split the allocations to separate the PI assignments and convert >>>> the blocks that remain with an LIR to ALLOCATED PA. > i am perennially confused by the different colors of integers. as you > know, i prefer magenta and comic sans. > > ingrid/ncc can you explain in terms an antique router geek can > understand what the actual pragmatic effect would be on these PI/PA > holders? does it alter holders' rights? costs? processes? ... > > i suspect that you, larisa, already understand that. in this case, > why, in pragmatic terms a router geek can understand (yes, i know > that's a high bar, sorry), do you not like it? > > randy Hi Randy, 1. Manual update inetnums from ASSIGNED PI into ASSIGNED PA in two /16 blocks creates a lot of additional job for my LIR. 2. Lack of reasonable explanations for customers why this should be done. That is why I'd prefer not to change anything here. -- With respect, *Larisa Yurkina* RIPN Internet Number Resources Group / Chief Manager l.yurkina at ripn.net / www.ripn.net ?.: +7 495 737-0604 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5540 bytes Desc: S/MIME Cryptographic Signature URL: From sander at steffann.nl Fri Aug 5 17:03:41 2016 From: sander at steffann.nl (Sander Steffann) Date: Fri, 5 Aug 2016 17:03:41 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: <1F9E3BE6-DD3B-4B03-B5F2-EE38A8604FEE@steffann.nl> Hi Ingrid, > If there is a /16 ?ALLOCATED UNSPECIFIED? block that contains "real" Provider Independent assignments, that /16 would indeed be split in order to carve out that assignment. The LIR would end up with multiple PA allocations instead of one /16. The PI resource holder would be able to decide who their sponsoring LIR should be. It is possible that they would remain with that same LIR, or they could move to another sponsoring LIR and take their PI assignment with them. If the resource holder is an LIR themselves, the PI assignment could be registered under their own LIR account. So in the current situation such a PI resource holder has "Provider Independent" space, but only if they stay with the LIR that holds the ALLOCATED UNSPECIFIED. After the change the PI holder will have a normal PI assignment that they can register with any sponsoring LIR they want. So I guess that PI holders will be happy about this, it turns their "kind-of" PI into "real" PI. And the affected LIRs might be less happy because they lose some grip on their customers. And then there seem to be cases where the ALLOCATED PI/UNSPECIFIED is used more like PA space (managed, aggregated and routed by the LIR) in which case converting it to ALLOCATED PA might be more reasonable (for route objects, ROAs etc) but that might make the "PI" holder less happy. Although in such a case it seems to me that the address space isn't really independent to begin with, so in reality things will probably remain the same for them, just better formally documented. Cheers, Sander -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nick at foobar.org Fri Aug 5 23:11:46 2016 From: nick at foobar.org (Nick Hilliard) Date: Sat, 6 Aug 2016 00:11:46 +0300 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <1470402676.3279875.686900377.6C40F4B8@webmail.messagingengine.com> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> <20160805062510.GP79185@Space.Net> <1470402676.3279875.686900377.6C40F4B8@webmail.messagingengine.com> Message-ID: > On 5 Aug 2016, at 16:11, Radu-Adrian FEURDEAN wrote: > dating back to a time where some of us were stuck to "NIR"s a.k.a > "last resort registries" which could do whatever they wanted) Registries of last resort were allocated their own blocks, separate to the main lir allocations. Fwir, all cc.zz assignments should have been from these blocks and were assigned pi. Nick From gert at space.net Tue Aug 16 15:59:12 2016 From: gert at space.net (Gert Doering) Date: Tue, 16 Aug 2016 15:59:12 +0200 Subject: [address-policy-wg] 2016-03 decision at end of discussion period (Locking Down the Final /8 Policy) In-Reply-To: References: Message-ID: <20160816135911.GA91623@Space.Net> Dear APWG, On Thu, Jun 16, 2016 at 03:58:47PM +0200, Marco Schmidt wrote: > The Discussion Period for the policy proposal 2016-03, "Locking Down the Final /8 Policy" has been extended until 15 July 2016. It took me quite a while, but I've re-read all the 247(!) e-mails that have been sent on the topic of this policy proposal. To sum it up, you as a community need to do MUCH better - this was a huge waste of human life time and attention. Many mails have been very repetitive - as Sander already pointed out during the discussion, things that have been answered and dismissed do not get more relevant because they are repeated 10 times more. Also, many mails have been very long, without actually having a clear point - and whole subthreads of 30+ mails did not even refer to something in this policy proposal at all but about "how can we do something else?". The summary of positions that I could extract to the best of my abilities (I spent almost a day on this) is attached below. Only comments sent after v2 was announced have been included, but I did read all of the mails, including v1, to see if it would make a difference. The proposer and a few other community members have done a very thorough job actually addressing the concerns raised. Purely counting numbers, we could have done with a few more voices of support, though. But anyway: this is not the final call on this proposal, but the end of the discussion phase, and the PDP has the following to say on this: "At the end of the Discussion Phase, the proposer, with the agreement of the WG chair, decides whether the proposal will move to the next phase (Review Phase) or if it should be withdrawn from the RIPE PDP, depending on the feedback received." I discussed this with Remco, and he wants to go ahead with the proposal, taking into account suggestions made regarding textual improvements and clarity of language. The WG chairs agree, so this will now go into impact analysis, and based on that, into review phase. At the end of the review phase, we need to have consensus, though - which doesn't mean "everyone has to agree", but at least we need to have *strong* support, and of course have to address all opposing arguments. So the WG chairs and the proposer have agreed that the proposal would needs be withdrawn if there is no stronger support in the review phase. Now you can argue about the process, if you want - but please read the PDP document first: https://www.ripe.net/publications/docs/ripe-642 before making statements what we can and should do. We do not enter another round of discussion on the proposal itself now - this will have to wait until Marco posts the impact analysis and announces the start of the review phase, in a few weeks' time. Gert Doering -- APWG chair ---------------------------- Summary on 2016-03 v2 Discussion period for v1 started: April 28, 2016 Discussion period for v2 started: June 15, 2016 Discussion period ended: July 15, 2016 (after extention) Mails: 247 (only looking at those with "2016-03" in the Subject: line) Only mails sent after June 16 (announcement of version 2.0) have been considered - v1.0 was very clearly refused by a large number of voices. Supportive voices William Waites - "the new version suits us just fine" Jan Ingvoldstad - "all the extremely bad opposing non-arguments kindof have convinced me that 2016-03 is needed, and should probably be implemented." Sebastian Wiesinger - "support, because /22 policy is there to enable ISP business, not to make profit by selling it" (shortened) Ondrej.Caletka - "support, /22 [..] should be used to operate a network or returned to the RIPE NCC" Neutral / comments James Blessing Stefan Prager - "long mail, no clear statement wrt supporting 2016-03" (but claiming it's "inconceivable that this proposal is allowed to go forward", and starting a sub-thread about costs and voting) sub-thread with Sander Steffan, Denis Fondras, Remco van Mook, Radu-Adrian FEURDEAN, Jan Ingvoldstad "I do agree, though, with the repeated criticism about how M&A is handled" Peter Hessler "+1 on 'giving up on this and calling a ban on further changes to the IPv4 policy'" Randy Bush - "RIR stands for Rinse and Infinite Repeat" Peter Koch - "v2 is better, but more work on the text and references is needed to achieve clarity" (answered by Remco van Mook, and "noted") Tore Anderson - explicitely neutral on v2, "maybe not a good idea or worth the trouble, but neutral/abstaining" Payam Poursaied - long post about unfairness in the old days between some LIRs receiving more space than others, but no clear statement wrt 2016-03 (starting a sub-thread about IPv4, IPv6, regional impossibilities, all not related to 2016-03) Questions James Blessing - question about "what sort of transfers do we need?" (expressing neutrality on the proposal) Patrick Velder - "status: for assignments from ALOCATED FINAL?" (answered by Sander Steffann) Ian.Dickinson - "what about pre-existing transfers?" Opposition considered addressed Riccardo Gori - opposition on the basis that this takes away some legitimate rights from LIRs currently having a /22 and numbering customers from it (considered addressed: if a LIR is *using* a /22, nothing changes except the label on the inetnum) and that it would put him at a market disadvantage if he cannot potentially *sell* his business, including the /22, in the future (considered addressed by v2: M&A are permitted, only transfers are not, so selling a business has no impact) "this would create CLASS E unusable LIRs" (considered out-of-scope - IPv4 is coming to an end, and without a very restrictive last-/8 policy, these LIRs would not have any IPv4 today - so don't complain about the restrictions) sub-thread with Nick Hilliard, Sander Steffann (addressing the points), more Riccardo Gori, and more sub-threats, in a very repetitive way - main point is "disadvantages class-b LIRs", repeated many times, and answered many times by different persons Radu-Adrian FEURDEAN - objects to disallowing only transfers of "after 14 September 2012" allocations, that it would create "heavily disadvantaged members" and that the intention to make IPv4 last as long as possible is only "... meant to be the new equivalent of gold" and that new LIRs are not forced to deploy IPv6 answered in detail by Remco van Mook and Sebastian Wiesinger Yuri @ NTX NOC - "not needed, there is enough free v4" "RIPE is not there to limit abilities of members to use v4" "too complicated" (DB changes) first two addressed by Jan Ingvoldstadt, 3rd left unanswered Alexey Galaev - "because it limit in rights all new LIRs" (should use IPv4 more effectively and stipulate using IPv6) need "simple rules and right for all" (DB changes) answered by Jan Ingvoldstadt Arash Naderpour - "gives more advantage to the old LIRs, which is not fair" Stefan Prager - "because it *selectively* strips PA resource holders of their rights ..." -> transfer restrictions should be done equally to all PA blocks, or none (repetitive "class-b LIR" argument) Daniel Suchy - "because it's unfair to new LIRs" answered by Jan Ingvoldstadt Nick Hilliard - "because it will create underground and unregistered transfers of non-transferrable /22s" answered by Sander Steffan Elvis Velea - "opposing for the same reasons as Nick Hilliard" (which makes this "addressed by Sander's response to Nick") "retroactive" aspect answered by Tore Anderson, pointing to NCC SSA Storch Matei - agrees with Nick and Elvis, and because it's retroactive +1 from Patrick Velder Aleksey Bulgakov - opposes because "when you close down your business, you can no longer sell your IP addresses" answered by Jim Reid, sub-thread about returning addresses Daniel Baeza "there is already 2015-01 to prevent abusing..." Radu Gheorghiu 'I do not want to restrict transfers of /22s from the "last /18" (sic!)' Opposition considered not directly addressed yet Jim Reid - "further tweaks are needed" - clear statement needed that the policy applies to ALL future allocations, not just 185/8 (plus: make clearer that M&A are no longer disallowed by v2) Sascha Luck - not trusting M&A process to solve "real existant" business cases properly, if transfer policy cannot be used anymore -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From nick at foobar.org Tue Aug 16 16:55:20 2016 From: nick at foobar.org (Nick Hilliard) Date: Tue, 16 Aug 2016 15:55:20 +0100 Subject: [address-policy-wg] 2016-03 decision at end of discussion period (Locking Down the Final /8 Policy) In-Reply-To: <20160816135911.GA91623@Space.Net> References: <20160816135911.GA91623@Space.Net> Message-ID: <57B32958.1030802@foobar.org> Gert Doering wrote: > Nick Hilliard - "because it will create underground and unregistered > transfers of non-transferrable /22s" > > answered by Sander Steffan I should have replied at the time because Sander's response was, in my opinion, inadequate: Sander Steffann wrote: > Not transferring the resources means keeping the LIR running to hold > them. If the LIR closes then the resources go back to the NCC and the > unregistered new holder will end up with empty hands. Both the cost > of keeping the LIR open (which will rise beyond the cost of "legally" > buying space after a few years) and the risk for the receiver to lose > their address space if the seller stops paying the NCC membership fee > are strong incentives to just stop trading in ALLOCATED FINAL space. This just means that the price stays higher, not that underground transfers / rentals won't happen or become a problem. > And M&A is still possible if people really want to move this address > space around, and that will make sure the registration is updated. This subverts the intention of 2016-03: 1. register company for ?12 at the UK Companies Registration Office 2. open LIR in the name of this company 3. sell company to existing LIR and handle under M&A Net cost difference: ?12. I.e. if you have it one way, the intent of the proposal is subverted; if you have it the other, the charter for the RIPE database is violated. Nick From gert at space.net Tue Aug 16 19:15:40 2016 From: gert at space.net (Gert Doering) Date: Tue, 16 Aug 2016 19:15:40 +0200 Subject: [address-policy-wg] 2016-03 decision at end of discussion period (Locking Down the Final /8 Policy) In-Reply-To: <57B32958.1030802@foobar.org> References: <20160816135911.GA91623@Space.Net> <57B32958.1030802@foobar.org> Message-ID: <20160816171540.GF79185@Space.Net> Hi Nick, On Tue, Aug 16, 2016 at 03:55:20PM +0100, Nick Hilliard wrote: > Gert Doering wrote: > > Nick Hilliard - "because it will create underground and unregistered > > transfers of non-transferrable /22s" > > > > answered by Sander Steffan > > I should have replied at the time because Sander's response was, in my > opinion, inadequate: I found it convincing, but most likely I'm not as pessimistic yet regarding what people might be willing to do for a bit of extra money. (I do also see the risk for the buyer as totally inacceptable, as long as there are "official and documentable" transfers available) Anyway: formally we're outside any phase where opposition to the proposal would be recorded, so I take this as clarification regarding my summary (thanks). Please do not let us stop you from repeating your concerns in the review phase, of course - but of course, please do take the impact analysis into account (the NCC might see the same risk, or not). Gert Doering -- APWG chair -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From herve.clement at orange.com Thu Aug 18 11:36:54 2016 From: herve.clement at orange.com (herve.clement at orange.com) Date: Thu, 18 Aug 2016 09:36:54 +0000 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> Message-ID: <14344_1471513015_57B581B7_14344_1806_1_2AF4C0655C93DD4D9A005252D465A8082F85D8A0@OPEXCLILM21.corporate.adroot.infra.ftgroup> Dear all, >From my point of view I support this initiative of the RIPE NCC as it brings more clarity and simplicity regarding IPv4 resources management. Herv? Cl?ment Orange -----Message d'origine----- De : address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De la part de Ingrid Wijte Envoy? : vendredi 5 ao?t 2016 15:41 ? : Gert Doering; Randy Bush Cc : Larisa Yurkina; address-policy-wg at ripe.net Objet : Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED Dear colleagues, >>> Also, it might lead to deaggs (Markus' case) where a /14 that was >>> originally "in one LIR" would be "3x /16, plus some smaller >>> fragments in the LIR" and "lots of /24 PI managed by the NCC" now - >>> so the /14 won't get a ROA, and he'll have to announce more-specifics. >> lemme see if i get this. to have the owner registration correct, >> some address space will have to be broken up and owned by multiple >> IRs, thus fragmenting routing? i like correct registration, but the >> commons has become pretty polluted. The main issue that we (the WG and the RIPE NCC) are trying to resolve is the lack of clarity around the status and rights of these assignments. It's not necessarily the case that the End User registration is incorrect. In many cases LIRs have put a lot of effort into keeping this information up to date. If there is a /16 "ALLOCATED UNSPECIFIED" block that contains "real" Provider Independent assignments, that /16 would indeed be split in order to carve out that assignment. The LIR would end up with multiple PA allocations instead of one /16. The PI resource holder would be able to decide who their sponsoring LIR should be. It is possible that they would remain with that same LIR, or they could move to another sponsoring LIR and take their PI assignment with them. If the resource holder is an LIR themselves, the PI assignment could be registered under their own LIR account. This means that route and domain objects would need to be updated. It's also relevant to mention that several LIRs already allow for more specific routes for the assignments. The LIRs will be able to request a new ROA for their remaining blocks. The sponsoring LIR can request a ROA on behalf of the PI resource holder, or the PI holder can do that themselves if they wish. I hope this answers your questions. Ingrid Wijte RIPE NCC > I leave the definite answer to Ingrid to answer. > > My understanding of "normal" NCC<->LIR stockkeeping is that PI is > never living inside blocks that "belong" to a given LIR. So, the LIR > would never be able to get a ROA covering PI space. > > For some of these "old" blocks, there is a /16 which covers regular > LIR/PA space, and "not real PI" space, and the LIR can get a ROA that > covers their PA space, and also these "not real PI" blocks (because > according to the NCC records, the /16 "belongs" to the LIR). > > From an aggregation PoV, this is ok-ish - but from a routing security > PoV, I wonder if that's what we want (the "not real PI" block might be > routed totally elsewhere now). > > >>> So, to answer your question: for those "swampy PI", it would alter >>> their rights (contracts according to 2007-01), costs (50 EUR/year) >> whoops. that's gonna cause unhappiness. > Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all > the other PI holders, and the amount of unhappiness was not very big. > > Those cases that I was involved with my "LIR admin-c" hat on, PI > holders seemed to be happy to have a clear contract with a known > entity (us), and the assurance that this would ensure that nobody else > could make claims to their address space. > > Gert Doering > -- assorted hats _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From st at sct.de Mon Aug 22 10:11:48 2016 From: st at sct.de (Stefan Schiele) Date: Mon, 22 Aug 2016 10:11:48 +0200 Subject: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED In-Reply-To: <14344_1471513015_57B581B7_14344_1806_1_2AF4C0655C93DD4D9A005252D465A8082F85D8A0@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <0a0dcd8a-a685-ed25-6837-0d807c370c21@velder.li> <57A31AAE.6060305@ripn.net> <20160804113710.GJ79185@Space.Net> <20160804121033.GK79185@Space.Net> <14344_1471513015_57B581B7_14344_1806_1_2AF4C0655C93DD4D9A005252D465A8082F85D8A0@OPEXCLILM21.corporate.adroot.infra.ftgroup> Message-ID: <3fc958d9-57bf-34b2-33e0-dcbac03690eb@sct.de> Dear all, I also support RIPE NCC's initiative for dealing with those ALLOCATED PI/UNSPECIFIED assignments. By the way, our company holds one of these PIs in KPN's /16. And as far as we are concerned an annual fee of 50 EUR would be okay, too. Kind Regards Stefan Schiele Am 18.08.2016 um 11:36 schrieb herve.clement at orange.com: > > Dear all, > > From my point of view I support this initiative of the RIPE NCC as it > brings more clarity and simplicity regarding IPv4 resources management. > > Herv? Cl?ment > > Orange > > -----Message d'origine----- > De : address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] De > la part de Ingrid Wijte > Envoy? : vendredi 5 ao?t 2016 15:41 > ? : Gert Doering; Randy Bush > Cc : Larisa Yurkina; address-policy-wg at ripe.net > Objet : Re: [address-policy-wg] Update on ALLOCATED PI/UNSPECIFIED > > Dear colleagues, > > >>> Also, it might lead to deaggs (Markus' case) where a /14 that was > > >>> originally "in one LIR" would be "3x /16, plus some smaller > > >>> fragments in the LIR" and "lots of /24 PI managed by the NCC" now - > > >>> so the /14 won't get a ROA, and he'll have to announce more-specifics. > > >> lemme see if i get this. to have the owner registration correct, > > >> some address space will have to be broken up and owned by multiple > > >> IRs, thus fragmenting routing? i like correct registration, but the > > >> commons has become pretty polluted. > > The main issue that we (the WG and the RIPE NCC) are trying to resolve > is the lack of clarity around the status and rights of these > assignments. It?s not necessarily the case that the End User > registration is incorrect. In many cases LIRs have put a lot of effort > into keeping this information up to date. > > If there is a /16 ?ALLOCATED UNSPECIFIED? block that contains "real" > Provider Independent assignments, that /16 would indeed be split in > order to carve out that assignment. The LIR would end up with multiple > PA allocations instead of one /16. The PI resource holder would be > able to decide who their sponsoring LIR should be. It is possible that > they would remain with that same LIR, or they could move to another > sponsoring LIR and take their PI assignment with them. If the resource > holder is an LIR themselves, the PI assignment could be registered > under their own LIR account. > > This means that route and domain objects would need to be updated. > It?s also relevant to mention that several LIRs already allow for more > specific routes for the assignments. > > The LIRs will be able to request a new ROA for their remaining blocks. > The sponsoring LIR can request a ROA on behalf of the PI resource > holder, or the PI holder can do that themselves if they wish. > > I hope this answers your questions. > > Ingrid Wijte > > RIPE NCC > > > I leave the definite answer to Ingrid to answer. > > > > > > My understanding of "normal" NCC<->LIR stockkeeping is that PI is > > > never living inside blocks that "belong" to a given LIR. So, the LIR > > > would never be able to get a ROA covering PI space. > > > > > > For some of these "old" blocks, there is a /16 which covers regular > > > LIR/PA space, and "not real PI" space, and the LIR can get a ROA that > > > covers their PA space, and also these "not real PI" blocks (because > > > according to the NCC records, the /16 "belongs" to the LIR). > > > > > > From an aggregation PoV, this is ok-ish - but from a routing security > > > PoV, I wonder if that's what we want (the "not real PI" block might be > > > routed totally elsewhere now). > > > > > > > > >>> So, to answer your question: for those "swampy PI", it would alter > > >>> their rights (contracts according to 2007-01), costs (50 EUR/year) > > >> whoops. that's gonna cause unhappiness. > > > Dunno. We (the RIPE community and the NCC) rolled out 2007-01 to all > > > the other PI holders, and the amount of unhappiness was not very big. > > > > > > Those cases that I was involved with my "LIR admin-c" hat on, PI > > > holders seemed to be happy to have a clear contract with a known > > > entity (us), and the assurance that this would ensure that nobody else > > > could make claims to their address space. > > > > > > Gert Doering > > > -- assorted hats > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: