[address-policy-wg] question about IPv4 legacy and transfers - should we convert legacy to non-legacy with transfers?

Hi Erik,

 

I’m not sure if I’m being able to explain myself …

 

I know about ripe-639.

 

What I’m saying is that we force the change of status from non-legacy to legacy if addresses are transferred to a new member or an existing member, as both of them will have all the legal bindings already with RIPE NCC.

 

639 was defined a couple of years before the transfers policy. It may be perfectly possible that at that time it was not considered this aspect.

 

I know that every region is different, but we live in a global Internet, and it is surprising to me that we are the only out of 5 RIRs, that has not done this already.

 

Regards,

Jordi

@jordipalet

 

 

 

El 14/7/19 14:40, "address-policy-wg en nombre de Erik Bais" <address-policy-wg-bounces at ripe.net en nombre de ebais at a2b-internet.com> escribió:

 

Hi Jordy,  

 

Legacy resources don’t fall under the contractual obligations that we as a community have setup. Financial or policy, unless decided/afreed upon by legacy resources themselves. 

That is described in the policy document RIPE NCC services for legacy resource holders.  ( https://www.ripe.net/publications/docs/ripe-639 ) 

 

If you would view the RIPE NCC as a holder of IP space, that provides resources when a membership is present. If a member would not pay, the resources could be revoked. Legacy holders didn’t receive the resources from RIPE NCC and their resources can’t be revoked. As the RIPE NCC isn’t the top holder of the resource. If legacy is handed back, it would ( should ) go to IANA ..

 

With the legacy services policy it was decided that the historic rights of legacy holders are honored and only if they decide that they want to include themselves in the community and services, it is possible. But only by their own decision. 

 

Stripping the legacy resource status after a transfer, would change the holder of the resource from the seller to the rir instead of the seller to the buyer. 

 

The RIPE NCC is providing an administrative service to maintain an accurate registry, also including Legacy resources.. 

 

Changing the legal status of legacy resources by force, will open up the RIPE NCC for liability charges and due to its monopoly in the RIPE region, that is not a good plan ... and knowing some Legacy holders, that is going to be a huge no-go. 


Your last email stated that non-legacy holder to non-legacy holder transfers are outside the system .. if we regard the RIPE policies inside the system ... non-legacy resources are ‘IN’ the system.. because you would say that they would be PI holders or RIPE NCC members ( LIR’s ) ... 

Legacy holder can be outside ( no contract ) the rir status .. or by their own choice inside the system .. 

 

Hope this explains a bit. 

 

Regards,

Erik Bais 



Verstuurd vanaf mijn iPhone

Op 13 jul. 2019 om 14:49 heeft JORDI PALET MARTINEZ via address-policy-wg <address-policy-wg at ripe.net> het volgende geschreven:

Hi Gert,

If the received of the transfer is already bound by contracts with RIPE, he is the one that will "convert" the resources to non-legacy accepting that transfer.

Of course, transfers from non-legacy holders to non-legacy holders are outside of the system.

Regards,
Jordi
@jordipalet



El 13/7/19 14:43, "address-policy-wg en nombre de Gert Doering" <address-policy-wg-bounces at ripe.net en nombre de gert at space.net> escribió:

   Hi,

   On Sat, Jul 13, 2019 at 02:27:03PM +0200, JORDI PALET MARTINEZ via address-policy-wg wrote:


If legacy holders, want to transfers those resources and escape from fulfilling the policies and contractual requirements, now they can do it in RIPE, but not in other regions.


   Repeat with me: there is no contract of any sort that the RIPE community
   can use to make legacy resource holders do *anything* unless they want
   it themselves.

   (And if they *want* to bring their space under the RIPE umbrella, they
   can do it today already).

   Gert Doering
           -- NetMaster
   -- 
   have you enabled IPv6 on something today...?

   SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
   Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
   D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
   Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.







**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.theipv6company.com
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20190714/59fb2bd8/attachment.html>