From Laurens.Hoogendoorn at ripe.net Mon Apr 3 16:18:01 2017 From: Laurens.Hoogendoorn at ripe.net (Laurens Hoogendoorn) Date: Mon, 3 Apr 2017 16:18:01 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> Message-ID: <9dac789a-d81e-c481-8235-6f5bfc40ac2b@ripe.net> Dear colleagues, Thank you for the feedback and questions. We do want to emphasise that the goal of the suggested project is not to reclaim AS Numbers that are in use, but to clean up out-of-date registrations. At the moment, there is not really an incentive to return unused AS Numbers, because the registration of ASNs is free of charge. We see quite often that (sponsoring) LIRs forget AS Numbers if they are requesting changes. Our current proposal is a one-time project and we will archive the responses so that we only send one email. Some people suggested that we should perform these checks on a regular basis and this is possible if the community wants us to do so. During Assisted Registry Checks (ARCs), or if an ASN is changing sponsor, we already ask to some extent if the resources are still needed. The reason for contacting the sponsor and not the admin-c or tech-c is that the sponsoring LIR has the responsibility to liaise with the End User (and can do this in the language of the resource holder). From experience, we know that a lot of End Users are not aware that AS Numbers are distributed by the RIPE NCC, they are only aware of the contractual relationship that they have with their sponsor. During the deregistration process, we try to the contact the resource holder directly in different ways. This usually starts by contacting the admin-c and tech-c. Please let us know if there are any further questions before Thursday 6 April 2017. Regards, Laurens Hoogendoorn Registration Services RIPE NCC On 23/03/2017 13:18, Laurens Hoogendoorn wrote: > > > Dear colleagues, > > As previously mentioned at RIPE 73, we are planning a project to clean > up unused AS Numbers. You can find this presentation here: > https://ripe73.ripe.net/archives/video/1456/ > > According to ripe-679, "Autonomous System (AS) Number Assignment > Policies" if an organisation no longer uses as AS Number, it should be > returned to the free pool so it can be reassigned: > https://www.ripe.net/publications/docs/ripe-679 > > There are currently around 6,600 ASNs in our service region (held or > sponsored by 2,682 LIRs) that are not being advertised in the routing > system. This represents around 22% of the ~30,000 ASNs assigned by the > RIPE NCC. > > There are a number of legitimate reasons why an ASN might not be > advertised in the routing system. However, it is also possible that > the holder doesn't exist anymore or the ASN is no longer needed. Not > only should unused ASNs be returned, but it's important to clean up > out of date registrations, which affect the quality of data in the > RIPE Registry. > > > Our Proposal > > We plan to email the LIR or sponsoring LIR for each unannounced ASN > and ask if the resource is still needed. We will group together ASNs > that are sponsored or held by the same LIR to minimise the number of > emails. > > We will ask if the ASN is currently being used or if there are plans > to start using the ASN in the coming three months. Organisations can > always request a new ASN in the future if they need one. > > If we do not receive a reply or if the ASN will not be used within > three months, we will start the process of returning the ASN to the > free pool. The deregistration process will take three months, during > which time the LIR can still indicate that the ASN is needed. If the > ASN is still needed, the validity of the assignment (such as the > multihoming requirement) will not be re-evaluated. > > We do not expect any significant cost or impact on other services, as > most of this process will be automated and we will not need to > re-evaluate the assignments. Contacting all relevant LIRs will take > less than six months. > > Please review this proposal and send any comments or other feedback > before Thursday 6 April to . > > Regards, > > Laurens Hoogendoorn > Registration Services > RIPE NCC > -------------- next part -------------- An HTML attachment was scrubbed... URL: From shane at time-travellers.org Wed Apr 5 21:58:28 2017 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 5 Apr 2017 19:58:28 +0000 Subject: [address-policy-wg] Cleaning up Unused AS Numbers In-Reply-To: <9dac789a-d81e-c481-8235-6f5bfc40ac2b@ripe.net> References: <9570203a-051f-0c92-64c9-41713110a2c5@ripe.net> <9dac789a-d81e-c481-8235-6f5bfc40ac2b@ripe.net> Message-ID: <20170405195828.7e3165a7@earth.zonnestelsel.tk> Laurens, At 2017-04-03 16:18:01 +0200 Laurens Hoogendoorn wrote: > Our current proposal is a one-time project and we will archive the > responses so that we only send one email. Some people suggested that we > should perform these checks on a regular basis and this is possible if > the community wants us to do so. During Assisted Registry Checks (ARCs), > or if an ASN is changing sponsor, we already ask to some extent if the > resources are still needed. My own suggestion would indeed be to perform regular (mostly or totally automated) checks, otherwise the number of unused AS numbers will increase over time and another one-time project will be necessary. Every system needs some way to fight against entropy. ;) Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digitale handtekening URL: From sbalogh5 at icloud.com Sun Apr 9 18:00:25 2017 From: sbalogh5 at icloud.com (Stephen Balogh) Date: Sun, 09 Apr 2017 12:00:25 -0400 Subject: [address-policy-wg] Password Message-ID: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> Need password From randy at psg.com Sun Apr 9 18:35:25 2017 From: randy at psg.com (Randy Bush) Date: Sun, 09 Apr 2017 09:35:25 -0700 Subject: [address-policy-wg] Password In-Reply-To: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> References: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> Message-ID: > Need password ofBogDog8\9buw4bXLoGvn. From vladimir at quick-soft.net Sun Apr 9 18:39:01 2017 From: vladimir at quick-soft.net (=?utf-8?B?0JLQu9Cw0LTQuNC80LjRgCDQkNC90LTRgNC10LXQsg==?=) Date: Sun, 09 Apr 2017 19:39:01 +0300 Subject: [address-policy-wg] Password In-Reply-To: References: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> Message-ID: <7204981491755941@web25g.yandex.ru> An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Sun Apr 9 18:40:50 2017 From: ebais at a2b-internet.com (Erik Bais - A2B Internet) Date: Sun, 9 Apr 2017 18:40:50 +0200 Subject: [address-policy-wg] Password In-Reply-To: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> References: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> Message-ID: <14B400F6-54D9-4F73-83E6-B956E5196192@a2b-internet.com> Pick one in the list : https://www.random.org/passwords/?num=5&len=18&format=html&rnd=new Verstuurd vanaf mijn iPad > Op 9 apr. 2017 om 18:00 heeft Stephen Balogh het volgende geschreven: > > Need password > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nick at foobar.org Sun Apr 9 23:51:57 2017 From: nick at foobar.org (Nick Hilliard) Date: Sun, 9 Apr 2017 23:51:57 +0200 Subject: [address-policy-wg] Password In-Reply-To: References: <220F566B-855B-4326-8F21-EF2229D83CD4@icloud.com> Message-ID: <34720FB9-DE3E-4654-A49C-12D0C8B65D11@foobar.org> On 9 Apr 2017, at 18:35, Randy Bush wrote: >> Need password > > ofBogDog8\9buw4bXLoGvn. It's more secure if you change all the "o" characters to "0". Nick From shane at time-travellers.org Thu Apr 13 21:46:48 2017 From: shane at time-travellers.org (Shane Kerr) Date: Thu, 13 Apr 2017 19:46:48 +0000 Subject: [address-policy-wg] FYI: policy proposal in AFRINIC Message-ID: <20170413194648.46468d0b@earth.zonnestelsel.tk> All, This just crossed my news feeds: https://www.theregister.co.uk/2017/04/12/no_ip_addresses_for_countries/ Cheers, -- Shane -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digitale handtekening URL: From richih.mailinglist at gmail.com Thu Apr 13 23:43:11 2017 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Thu, 13 Apr 2017 23:43:11 +0200 Subject: [address-policy-wg] FYI: policy proposal in AFRINIC In-Reply-To: <20170413194648.46468d0b@earth.zonnestelsel.tk> References: <20170413194648.46468d0b@earth.zonnestelsel.tk> Message-ID: It would be hard to miss this one, by now. The actual text is crude, but it raises a point the RIPE community might not be able to avoid forevermore. Richard Sent by mobile; excuse my brevity and the wall of text Gmail appends by default. -------------- next part -------------- An HTML attachment was scrubbed... URL: From netravnen+nanog at gmail.com Fri Apr 14 02:45:33 2017 From: netravnen+nanog at gmail.com (netravnen+nanog at gmail.com) Date: Fri, 14 Apr 2017 02:45:33 +0200 Subject: [address-policy-wg] FYI: policy proposal in AFRINIC In-Reply-To: References: <20170413194648.46468d0b@earth.zonnestelsel.tk> Message-ID: Am 13.04.2017 11:43 nachm. schrieb "Richard Hartmann" < richih.mailinglist at gmail.com>: It would be hard to miss this one, by now. The actual text is crude, but it raises a point the RIPE community might not be able to avoid forevermore. I dare say: '*Cannot (and will not) *be able to avoid (before the internet is no more).' Regards, Christoffer, Happy Easter to those who celebrate it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sander at steffann.nl Wed Apr 19 16:32:28 2017 From: sander at steffann.nl (Sander Steffann) Date: Wed, 19 Apr 2017 16:32:28 +0200 Subject: [address-policy-wg] Cleaning up Unused AS Numbers Message-ID: <8EC7867F-D7A8-47D7-8B02-E0150D22DEB6@steffann.nl> Hi working group, After reviewing the discussions on this mailing list about cleaning up unused AS numbers we think that the concerns and questions that came up have been addressed by the RIPE NCC. Therefore the working group chairs have asked the RIPE NCC to take the feedback into account and proceed with the cleanup. Cheers, Sander Steffann APWG co-chair -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: Message signed with OpenPGP URL: From Laurens.Hoogendoorn at ripe.net Thu Apr 20 14:01:46 2017 From: Laurens.Hoogendoorn at ripe.net (Laurens Hoogendoorn) Date: Thu, 20 Apr 2017 14:01:46 +0200 Subject: [address-policy-wg] Policy Proposal Implemented: 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies" Message-ID: <661c7f23-b212-4c47-94a1-76ea2af161d2@ripe.net> Dear colleagues, We are pleased to announce that we have implemented policy proposal 2016-05, "Synchronising the Initial and Subsequent IPv6 Allocation Policies". The criteria used to evaluate the size of subsequent IPv6 allocations has been expanded to include: - Hierarchical and geographical structuring of the organisation - Planned longevity of the allocation - Segmentation of infrastructure for security You can find more information about the expanded evaluation criteria here: https://www.ripe.net/manage-ips-and-asns/ipv6/request-ipv6/assessment-criteria-for-ipv6-allocations The archived policy proposal can be found here: https://www.ripe.net/participate/policies/proposals/2016-05 The RIPE Document, "IPv6 Address Allocation and Assignment Policy", is available here: https://www.ripe.net/publications/docs/ripe-684 -- Kind regards, Laurens Hoogendoorn RIPE NCC Registration Services From mschmidt at ripe.net Tue Apr 25 14:39:43 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Tue, 25 Apr 2017 14:39:43 +0200 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) Message-ID: Dear colleagues, A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. You can find the full proposal at: https://www.ripe.net/participate/policies/proposals/2017-01 As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. We encourage you to review this proposal and send your comments to before 24 May 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From apwg at c4inet.net Tue Apr 25 18:10:57 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 25 Apr 2017 17:10:57 +0100 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: <20170425161057.GZ93886@cilantro.c4inet.net> All, On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote: > >A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. > >The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. > >You can find the full proposal at: >https://www.ripe.net/participate/policies/proposals/2017-01 It would be nice if the initial email for a new proposal could contain the textual changes to policy documents. It would make it infintely easier to comment inline on the changed sections. > 4.0 Transfer Statistics [...] > This list will contain information about approved changes. The > following information will be published: [...] > Whether it was a transfer according to this policy, a transfer > due to changes to an organisation's business structure (such as a > merger or acquisition) or a change in the RIPE Database to the > organisation holding a Legacy Internet Resource. Since when has the RIPE NCC a mandate to "approve" changes in legacy objects? (Except perhaps where a contractual relationship exists) > RIPE NCC Services to Legacy Internet Resource Holders [...] > 1.1 Definitions [...] > Registry services [...] > Transfer services as per RIPE Resource Transfer Policies. Any > change in the RIPE Database updating the organisation holding the > Legacy Internet Resource can only be finalised once the RIPE NCC > has received and verified a written request signed by authorised > representatives of both the current holder and the new holder. Since when does the RIPE NCC have the mandate to impose such a process on legacy resource holders? > Rationale > a. Arguments supporting the proposal > Providing complete statistics about IPv4 transfers and updates to > the holdership of legacy resources would clearly show the whole > picture of a young, unpredictable and volatile transfer market. > We currently see only partial information and it is difficult to > understand the real dimensions of the size and number of IPv4 > transfers. > Over the past few years, this update has been requested by > everyone analysing the IPv4 marketplace and presenting at RIPE, > ARIN or APNIC conferences. The RIPE NCC already publishes > statistics on inter-RIR transfers and adding this last bit > (updates on who holds legacy resources) would be consistent with > the community's requests around transparency and consistency. Read this as: "This is the latest attempt to instrumentalise the (membership-funded) RIPE NCC as a free business intelligence resource for IPv4 address brokers." > In order to identify all legacy changes, a confirmation will be > sent to the RIPE NCC to finalise the process (currently this is > only checked for legacy resources that have a contractual > relationship with the RIPE NCC or sponsoring LIR). This > verification requirement does not impact the transfer of legacy > resources or the updates in the RIPE Database. It only adds an > additional step to increase the registration quality. What makes you think imposing a bureaucratic requirement on legacy holders out of the blue will not be resisted? I remember the discussions around formalising the legacy resource relationship with the NCC and how the voluntary nature of any such relationship was emphasized in order to get any sort of consensus. In short, this proposal has the potential to: - benefit the few at a cost to all members, - sour relations with legacy resource holders, - have a deletorious effect on registry quality where resource holders do not wish to submit to a "verification" process, and therefore I, strenuously, object to this proposal (for whatever that may be worth) rgds, Sascha Luck From elvis at v4escrow.net Tue Apr 25 18:42:12 2017 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 25 Apr 2017 19:42:12 +0300 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <20170425161057.GZ93886@cilantro.c4inet.net> References: <20170425161057.GZ93886@cilantro.c4inet.net> Message-ID: Hi Sascha, please see inline: On 4/25/17 7:10 PM, Sascha Luck [ml] wrote: > All, > > On Tue, Apr 25, 2017 at 02:39:43PM +0200, Marco Schmidt wrote: >> >> A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR >> Legacy updates" is now available for discussion. >> >> The goal of this proposal is to require the RIPE NCC to publish all >> changes to the holdership of legacy resources in the existing >> transfer statistics. >> >> You can find the full proposal at: >> https://www.ripe.net/participate/policies/proposals/2017-01 > > It would be nice if the initial email for a new proposal could > contain the textual changes to policy documents. It would make it > infintely easier to comment inline on the changed sections. additions to the current policy documents in *bold*: RIPE Resource Transfer Policies (currently ripe-682): * Whether it was a transfer according to this policy, a transfer due to changes to an organisation's business structure (such as a merger or acquisition) *or a change in the RIPE Database to the organisation holding a Legacy Internet Resource.* RIPE NCC Services to Legacy Internet Resource Holders (currently ripe-674): * *Transfer services as per****RIPE Resource Transfer Policies **. Any change in the RIPE Database updating the organisation holding the Legacy Internet Resource can only be finalised once the RIPE NCC has received and verified a written request signed by authorised representatives of both the current holder and the new holder.* > >> 4.0 Transfer Statistics > [...] >> This list will contain information about approved changes. The >> following information will be published: > [...] >> Whether it was a transfer according to this policy, a transfer >> due to changes to an organisation's business structure (such as a >> merger or acquisition) or a change in the RIPE Database to the >> organisation holding a Legacy Internet Resource. > > Since when has the RIPE NCC a mandate to "approve" changes in > legacy objects? (Except perhaps where a contractual relationship > exists) It does not. And this policy proposal does not intend to give more 'power' to the RIPE NCC over the Legacy holders. What it will do is, for 'transfers' of Legacy space where both the old and the new holder want to have it verified by the RIPE NCC, both parties will need to sign a document where parties authorised to sign will confirm the change of the legacy holder (basically, a transfer). Transfers where the legacy holders do not want the RIPE NCC to acknowledge the change in the legacy holder will be marked as such. This policy proposal does not require both parties to sign such a document in order to complete a transfer. > >> RIPE NCC Services to Legacy Internet Resource Holders > [...] >> 1.1 Definitions > [...] >> Registry services > [...] >> Transfer services as per RIPE Resource Transfer Policies. Any >> change in the RIPE Database updating the organisation holding the >> Legacy Internet Resource can only be finalised once the RIPE NCC >> has received and verified a written request signed by authorised >> representatives of both the current holder and the new holder. > > Since when does the RIPE NCC have the mandate to impose such a > process on legacy resource holders? This is what the policy proposal will add. It currently does not have a mandate and the mandate will be given once this proposal becomes policy. It only requires the RIPE NCC to verify that authorised representatives sign a template where they accept and acknowledge the change of the legacy block and the fact that a new legacy holder now holds this block. If this policy proposal is approved and if the two organizations do not want to sign such a document, the RIPE NCC will mark the updated legacy resource in some way (maybe a remarks attribute) signaling that the IP block has been updated and the RIPE NCC has not been notified of such change. Therefore, the transfer is not 'finalised'. >> Rationale > >> a. Arguments supporting the proposal > >> Providing complete statistics about IPv4 transfers and updates to >> the holdership of legacy resources would clearly show the whole >> picture of a young, unpredictable and volatile transfer market. >> We currently see only partial information and it is difficult to >> understand the real dimensions of the size and number of IPv4 >> transfers. > >> Over the past few years, this update has been requested by >> everyone analysing the IPv4 marketplace and presenting at RIPE, >> ARIN or APNIC conferences. The RIPE NCC already publishes >> statistics on inter-RIR transfers and adding this last bit >> (updates on who holds legacy resources) would be consistent with >> the community's requests around transparency and consistency. > > Read this as: > "This is the latest attempt to instrumentalise the > (membership-funded) RIPE NCC as a free business intelligence > resource for IPv4 address brokers." Please elaborate how this would be a business intelligence for the IPv4 address brokers. I represent an IPv4 address broker and can not see how this is going to help my business. I am also a RIPE NCC member and I pay my yearly membership, just as you do. I can already see who is a legacy resource holder and I can already see the changes in the RIPE Database; how would publishing the statistics of IP transfers of legacy resources be of any help to my company? >> In order to identify all legacy changes, a confirmation will be >> sent to the RIPE NCC to finalise the process (currently this is >> only checked for legacy resources that have a contractual >> relationship with the RIPE NCC or sponsoring LIR). This >> verification requirement does not impact the transfer of legacy >> resources or the updates in the RIPE Database. It only adds an >> additional step to increase the registration quality. > > What makes you think imposing a bureaucratic requirement on > legacy holders out of the blue will not be resisted? Why would someone resist it? It would add a security layer to the Buyer by having the RIPE NCC verify that the IP block transferred has the approval of the management of the original legacy holder. It would also prevent hijackers (that may have gotten their hands on the password of a maintainer of a legacy resource) from transferring IP blocks they do not hold. > I remember > the discussions around formalising the legacy resource > relationship with the NCC and how the voluntary nature of any > such relationship was emphasized in order to get any sort of > consensus. And, based on those discussions, this policy proposal does not require the RIPE NCC to approve the transfer of a Legacy. Where both parties request it by signing a transfer template, the RIPE NCC will confirm the transfer. > In short, this proposal has the potential to: > > - benefit the few at a cost to all members, what will be that cost? > - sour relations with legacy resource holders, how so? > - have a deletorious effect on registry quality where resource > holders do not wish to submit to a "verification" process, they can still update the object, the RIPE NCC will only mark the update as not yet verified. The current situation already has a negative impact on the registry and this policy proposal could fix it when both the old and the new legacy holder will sign a transfer template and the RIPE NCC verifies the authenticity of the signatories. > > and therefore I, strenuously, object to this proposal (for > whatever that may be worth) Even after the comments above, do you still object to the proposal? Is there any method to achieve the end goal (publishing complete transfer statistics) you would not object to? > > rgds, > Sascha Luck > > > Kind regards, Elvis -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis at v4escrow.net Mobile: +1 (702) 970 0921 -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfriacas at fccn.pt Tue Apr 25 23:12:48 2017 From: cfriacas at fccn.pt (Carlos Friacas) Date: Tue, 25 Apr 2017 22:12:48 +0100 (WEST) Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: Greetings, While the proposal's title seems to be a positive approach, as i read it, its main goal is to add extra requirements for LRH by changing ?RIPE NCC Services to Legacy Internet Resource Holders?. I think protection (or just better alarms in place!) for Legacy address space is a good thing, however, i'm not sure an extra workload for the NCC and the LRH in the case they want to transfer their asset(s) is the way to go. I also agree with Sascha Luck's previous comment about LRH having to submit to an extra verification process. In its current terms, i also object to this proposal. Best Regards, Carlos Fria?as On Tue, 25 Apr 2017, Marco Schmidt wrote: > Dear colleagues, > > A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR Legacy updates" is now available for discussion. > > The goal of this proposal is to require the RIPE NCC to publish all changes to the holdership of legacy resources in the existing transfer statistics. > > You can find the full proposal at: > https://www.ripe.net/participate/policies/proposals/2017-01 > > As per the RIPE Policy Development Process (PDP), the purpose of this four week Discussion Phase is to discuss the proposal and provide feedback to the proposer. > > At the end of the Discussion Phase, the proposer, with the agreement of the WG Chairs, will decide how to proceed with the proposal. > > We encourage you to review this proposal and send your comments to before 24 May 2017. > > Regards, > > Marco Schmidt > Policy Development Officer > RIPE NCC > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From elvis at v4escrow.net Tue Apr 25 23:48:59 2017 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 26 Apr 2017 00:48:59 +0300 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> Hi Carlos, On 4/26/17 12:12 AM, Carlos Friacas wrote: > > Greetings, > > While the proposal's title seems to be a positive approach, as i read > it, its main goal is to add extra requirements for LRH by changing > ?RIPE NCC Services to Legacy Internet Resource Holders?. The way I see it, this policy proposal does not add extra requirements, it adds an extra service. > > I think protection (or just better alarms in place!) for Legacy > address space is a good thing, however, i'm not sure an extra workload > for the NCC and the LRH in the case they want to transfer their > asset(s) is the way to go. the extra workload is a document signed by the representatives of the two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on a daily basis so I doubt that would be a whole lot of extra workload - they will confirm during the Impact Analysis. > > I also agree with Sascha Luck's previous comment about LRH having to > submit to an extra verification process. As mentioned in my response to Sascha's e-mail, the LRH can and will still be able to update their objects in the RIPE Database even without any document signed. All this policy proposal does is that when the two parties want to finalise the transfer and request RIPE NCC's confirmation, they will need to sign a document. - the RIPE NCC would then verify the old holder is the legitimate LRH and - the RIPE NCC will also verify the transfer document is signed by authorised signatories on both the old and the new LRH. > > In its current terms, i also object to this proposal. Would there be any version that you would agree to, one that would consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy resources? They currently publish all but these. > > Best Regards, > Carlos Fria?as > thank you, elvis From apwg at c4inet.net Wed Apr 26 00:26:27 2017 From: apwg at c4inet.net (Sascha Luck [ml]) Date: Tue, 25 Apr 2017 23:26:27 +0100 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: <20170425161057.GZ93886@cilantro.c4inet.net> Message-ID: <20170425222627.GA93886@cilantro.c4inet.net> Hi Elvis, On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote: > >What it will do is, for 'transfers' of Legacy space where both the >old and the new holder want to have it verified by the RIPE NCC, both >parties will need to sign a document where parties authorised to sign >will confirm the change of the legacy holder (basically, a transfer). Oh, this is *voluntary*? This is not obvious from the language of the proposed changes and one does not, perhaps, expect to see anything non-mandatory in a RIPE policy document ;p So let me see if I have this right: - Transfers of legacy space stay outside the NCC's purview to the extent they do now? - LRH who *want* to have a resource transfer verified can do so by submitting verification paperwork of some description? - Changes in the db wrt legacy resources where the LRHs do *not* want this are marked as "non-verified by NCC" or something like that but they are not rejected? >Even after the comments above, do you still object to the proposal? If my above understanding is correct, and an updated proposal would insert some language to make the voluntary nature of the transaction clearer, I'll withdraw my objection on that point. As for the cost of it and possible defrayment of same, I'll wait for the Impact Statement before making a decision. Sorry for the misunderstanding, if that it was, and best regards, Sascha Luck From elvis at v4escrow.net Wed Apr 26 00:41:57 2017 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Wed, 26 Apr 2017 01:41:57 +0300 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <20170425222627.GA93886@cilantro.c4inet.net> References: <20170425161057.GZ93886@cilantro.c4inet.net> <20170425222627.GA93886@cilantro.c4inet.net> Message-ID: <66bc99c7-b982-cccc-2a21-ce77881662f3@v4escrow.net> Hi Sascha, On 4/26/17 1:26 AM, Sascha Luck [ml] wrote: > Hi Elvis, > > On Tue, Apr 25, 2017 at 07:42:12PM +0300, Elvis Daniel Velea wrote: >> >> What it will do is, for 'transfers' of Legacy space where both the >> old and the new holder want to have it verified by the RIPE NCC, both >> parties will need to sign a document where parties authorised to sign >> will confirm the change of the legacy holder (basically, a transfer). > > Oh, this is *voluntary*? kinda... I am expecting all Buyers to request this process when they decide to receive a Legacy Resource. I would definitely request it if I knew the RIPE NCC can provide an additional confirmation. > This is not obvious from the language of > the proposed changes and one does not, perhaps, expect to see > anything non-mandatory in a RIPE policy document ;p hehe I tried to make this change as simple and as easy as possible for the LRHs. I knew that some would not agree with having additional requirements added, so I tried to make it as such that it would not be mandatory. I don't like to add barriers that could affect the registry in the long run. Maybe we will need to have a version where the wording is more clear. Let's see what the others say and what will be the RIPE NCC's understanding of the text once they make the Impact Analysis. > > So let me see if I have this right: > > - Transfers of legacy space stay outside the NCC's purview to > the extent they do now? > > - LRH who *want* to have a resource transfer verified can do so > by submitting verification paperwork of some description? In an ideal world, all LRHs would want this as it would 'secure' their 'transfer'. > > - Changes in the db wrt legacy resources where the LRHs do *not* > want this are marked as "non-verified by NCC" or something like > that but they are not rejected? correct. A legacy resource that has been updated to reflect an other LRH will be marked somewhere in the lines of 'changed but not verified'. > >> Even after the comments above, do you still object to the proposal? > > If my above understanding is correct, and an updated proposal > would insert some language to make the voluntary nature of the > transaction clearer, I'll withdraw my objection on that point. ok, thank you for your understanding. > As > for the cost of it and possible defrayment of same, I'll wait for > the Impact Statement before making a decision. I doubt there will be any significant cost. We'll have to wait for the NCC to complete their Impact Analysis. > > Sorry for the misunderstanding, if that it was, and best regards, > Sascha Luck > thank you, Elvis From randy at psg.com Wed Apr 26 01:46:56 2017 From: randy at psg.com (Randy Bush) Date: Wed, 26 Apr 2017 08:46:56 +0900 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: > A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR > Legacy updates" is now available for discussion. > > The goal of this proposal is to require the RIPE NCC to publish all > changes to the holdership of legacy resources in the existing transfer > statistics. that is not a goal, but rather the means. but a means to what end? i.e. what is the goal of this proposal; what problem does it intend to solve, or what wonderful opportunity does it hope to exploit? the written proposal says In addition to introducing greater transparency, this policy change would also protect legacy holders from potential hijacks. why is this true only for legacy space? randy From hank at efes.iucc.ac.il Wed Apr 26 07:17:35 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 26 Apr 2017 08:17:35 +0300 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: <20a41620-3e16-d2ee-a604-e55f4403adac@efes.iucc.ac.il> On 26/04/2017 02:46, Randy Bush wrote: >> A new RIPE Policy proposal, 2017-01, "Publish statistics on Intra-RIR >> Legacy updates" is now available for discussion. >> >> The goal of this proposal is to require the RIPE NCC to publish all >> changes to the holdership of legacy resources in the existing transfer >> statistics. > that is not a goal, but rather the means. but a means to what end? > i.e. what is the goal of this proposal; what problem does it intend > to solve, or what wonderful opportunity does it hope to exploit? > > the written proposal says > > In addition to introducing greater transparency, this policy change > would also protect legacy holders from potential hijacks. > > why is this true only for legacy space? Further to this point: can RIPE NCC provide statistics for the past 3 years of the number of IP resource hijacks that have taken place? Thanks, Hank > > randy > > From mschmidt at ripe.net Wed Apr 26 15:20:29 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Wed, 26 Apr 2017 15:20:29 +0200 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <20a41620-3e16-d2ee-a604-e55f4403adac@efes.iucc.ac.il> Message-ID: Dear Hank, On 2017-04-26 07:17:35 CET, Hank Nussbacher wrote: > > why is this true only for legacy space? > Further to this point: can RIPE NCC provide statistics for the past 3 > years of the number of IP resource hijacks that have taken place? > Thank you for your question. We are happy to provide some information here. Firstly, it?s important to note that the following numbers mainly refer to resources that are under a contractual relationship with the RIPE NCC. The RIPE Database contains several thousand parent legacy ranges that are not covered by a contractual relationship. Whoever has access to the maintainer can update all details of the resource object. We would only notice hijacks of these resources if the resource holder reports the hijack or the hijacker asks us to update our internal records. Since 2014, the RIPE NCC has concluded around 300 hijack cases for all types of resources, another 16 cases are still being investigated. We reported on resource hijacking in our 2016 Annual Report. As we mentioned there, legacy resources remain susceptible to hijacks using fraudulently provided statements and several cases are under active investigation. You can find this on page 18 here (PDF): https://www.ripe.net/participate/meetings/gm/meetings/may-2017/supporting-documents/ripe-ncc-annual-report-2016.pdf I hope this clarifies your question. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From gert at space.net Wed Apr 26 19:49:56 2017 From: gert at space.net (Gert Doering) Date: Wed, 26 Apr 2017 19:49:56 +0200 Subject: [address-policy-wg] APWG meeting agenda 0.2 Message-ID: <20170426174956.GX25069@Space.Net> Hi APWG folks, below you can find a second draft for the RIPE address policy WG meeting's agenda, which will take place in Budapest in the following time slots: Wednesday, May 10, 09:00 - 10:30 Wednesday, May 10, 11:00 - 12:30 If you have anything else you want to see on the agenda, or if we need to change anything, please let us know. Depending on the amount of "not yet known" things to show up on the agenda, we might only need one time slot. In which case, we can all join the Connect WG for a change :-) Notable changes in the second version: Item "E" added (this was prompted by a reference to an updated-behind-our-back RFC in the AS number policy), and due to "more policy proposals", item "F" moved to second slot. HEADS UP: side room. regards, Gert Doering & Sander Steffann, APWG chairs ---------------------------------------------------------------------- Wednesday, 09:00-10:30 - main room ---------------------------------------------------------------------- A. Administrative Matters 5 min (welcome, thanking the scribe, approving the minutes, etc.) B. WG Chair Selection 10 min - longest-serving chair (Gert D?ring) stepping down - willing to be re-appointed and serve another term C. Current Policy Topics - Marco Schmidt, NCC PDO 20 min - global policy overview "what's going on?" - common policy topics in all regions (end of IPv4, transfers, ...) - overview over concluded proposals in the RIPE region since RIPE 72 - brief overview over new proposals (if any) D. Feedback From NCC Registration Service - Andrea Cima 25 min (+ discussion with the group) E. outdated references in policy documents - Marco Schmidt 15 min (+ discussion with the group) ---------------------------------------------------------------------- Wednesday, 12:00-13:30 - side room (HEADS UP!) ---------------------------------------------------------------------- Welcome back F. Discussion of open policy proposals 40 min 2016-04 IPv6 PI Sub-assignment Clarification Maximilian Wilhelm 2017-01 Publish statistics on Intra-RIR Legacy updates Elvis Daniel Velea Y. Open Policy Hour 5 min The Open Policy Hour is a showcase for your policy ideas. If you have a policy proposal you'd like to debut, prior to formally submitting it, here is your opportunity. Z. AOB 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: 833 bytes Desc: not available URL: From cfriacas at fccn.pt Thu Apr 27 10:57:35 2017 From: cfriacas at fccn.pt (Carlos Friacas) Date: Thu, 27 Apr 2017 09:57:35 +0100 (WEST) Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> Message-ID: On Wed, 26 Apr 2017, Elvis Daniel Velea wrote: > Hi Carlos, Hi, > On 4/26/17 12:12 AM, Carlos Friacas wrote: >> >> Greetings, >> >> While the proposal's title seems to be a positive approach, as i read it, >> its main goal is to add extra requirements for LRH by changing ?RIPE NCC >> Services to Legacy Internet Resource Holders?. > The way I see it, this policy proposal does not add extra requirements, it > adds an extra service. Which is exactly? and who will benefit from it? - only LRHs? - the whole community? - non-LRHs? >> I think protection (or just better alarms in place!) for Legacy address >> space is a good thing, however, i'm not sure an extra workload for the NCC >> and the LRH in the case they want to transfer their asset(s) is the way to >> go. > the extra workload is a document signed by the representatives of the two LRH > (the Seller and the Buyer). The RIPE NCC verifies these kind of documents on > a daily basis so I doubt that would be a whole lot of extra workload - they > will confirm during the Impact Analysis. Sure. And what would exactly configures a failed verification? >> I also agree with Sascha Luck's previous comment about LRH having to >> submit to an extra verification process. > As mentioned in my response to Sascha's e-mail, the LRH can and will still be > able to update their objects in the RIPE Database even without any document > signed. You mean the "selling LRH"...? If my memory doesn't fail me, there are already some words about transfers on the current services' policy -- i need to double-check that. > All this policy proposal does is that when the two parties want to finalise > the transfer Is there a need for that...? How many LRH have expressed concerns about such a gap? > and request RIPE NCC's confirmation, LRHs currently don't need to do this...? > they will need to sign a document. > - the RIPE NCC would then verify the old holder is the legitimate LRH and If the current holder has a services agreement in place with the NCC, this is already covered, right? > - the RIPE NCC will also verify the transfer document is signed by authorised > signatories on both the old and the new LRH. Here, i think the NCC will only need to get a new services agreement signed with the *new* holder, if the new holder wishes to... >> In its current terms, i also object to this proposal. > Would there be any version that you would agree to, one that would > consistently allow the RIPE NCC to publish the transfers of Intra-RIR legacy > resources? As i previously said, stats (and potential hijack alarms) are a good thing. But this version still needs a lot of work, and especially also strong support from the LRHs -- otherwise, this verification mechanism you're trying to suggest will not add anything... And again, the NCC only has business regarding the services it provides to LRHs, but not over the address space itself... i think we are all aware about that bit. Best Regards, Carlos > They currently publish all but these. >> >> Best Regards, >> Carlos Fria?as >> > thank you, > elvis > > From elvis at v4escrow.net Fri Apr 28 13:36:12 2017 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Fri, 28 Apr 2017 14:36:12 +0300 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> Message-ID: <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> Hi, On 4/27/17 11:57 AM, Carlos Friacas wrote: > > On Wed, 26 Apr 2017, Elvis Daniel Velea wrote: [...] > The way I see it, this policy proposal does not add extra > requirements, it adds an extra service. > > Which is exactly? Transfer services according to the transfer policy. > and who will benefit from it? the whole community > - only LRHs? LRH will have the option to register the transfer. > - the whole community? the community will see better stats on how much is transferred. > - non-LRHs? > non-LRHs who want to purchase a LR will have the confirmation of the RIPE NCC that the IP block transfer has been verified by a third-party (the NCC) > >>> I think protection (or just better alarms in place!) for Legacy >>> address >>> space is a good thing, however, i'm not sure an extra workload for >>> the NCC >>> and the LRH in the case they want to transfer their asset(s) is the >>> way to >>> go. >> the extra workload is a document signed by the representatives of the >> two LRH (the Seller and the Buyer). The RIPE NCC verifies these kind >> of documents on a daily basis so I doubt that would be a whole lot of >> extra workload - they will confirm during the Impact Analysis. > > Sure. And what would exactly configures a failed verification? A representative not having the proper authority to sign on behalf of the LRH. Or someone that has the maintainer password pretending to act on behalf of the LRH and trying to hijack the resource. > > >>> I also agree with Sascha Luck's previous comment about LRH having to >>> submit to an extra verification process. >> As mentioned in my response to Sascha's e-mail, the LRH can and will >> still be able to update their objects in the RIPE Database even >> without any document signed. > > You mean the "selling LRH"...? yes > If my memory doesn't fail me, there are already some words about > transfers on the current services' policy -- i need to double-check that. LRH can be updated to point to an other company but a transfer in the real sense would only be confirmed once the RIPE NCC receives a signed document and can verify the signatory has the authority. > > >> All this policy proposal does is that when the two parties want to >> finalise the transfer > > Is there a need for that...? How many LRH have expressed concerns > about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry. > > >> and request RIPE NCC's confirmation, > > LRHs currently don't need to do this...? LRHs who have a contract with the RIPE NCC may need to request it, the ones that have opted not to have a contract are not required to present the RIPE NCC any kind of documentation, they can just update the object in the RIPE Database and that's it. > > >> they will need to sign a document. >> - the RIPE NCC would then verify the old holder is the legitimate LRH >> and > > If the current holder has a services agreement in place with the NCC, > this is already covered, right? yes, I think. > > >> - the RIPE NCC will also verify the transfer document is signed by >> authorised signatories on both the old and the new LRH. > > Here, i think the NCC will only need to get a new services agreement > signed with the *new* holder, if the new holder wishes to... > it's not that simple. What if the previous LRH does not have a services agreement? What if the new LRH does not want to sign one? > >>> In its current terms, i also object to this proposal. >> Would there be any version that you would agree to, one that would >> consistently allow the RIPE NCC to publish the transfers of Intra-RIR >> legacy resources? > > As i previously said, stats (and potential hijack alarms) are a good > thing. But this version still needs a lot of work, and especially also > strong support from the LRHs -- otherwise, this verification mechanism > you're trying to suggest will not add anything... What would you like me to work on? What is unclear. The mechanism will provide the Buyer an option to request the RIPE NCC to verify and confirm (finalise) the transfer. I expect this requirement to become the standard for transfers of LR. > > And again, the NCC only has business regarding the services it > provides to LRHs, but not over the address space itself... i think we > are all aware about that bit. I am aware of this and this policy proposal does not aim to give the RIPE NCC additional powers over the LR. > > > Best Regards, > Carlos > > Kind regards, Elvis -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis at v4escrow.net Mobile: +1 (702) 970 0921 From leo.vegoda at icann.org Fri Apr 28 18:20:31 2017 From: leo.vegoda at icann.org (Leo Vegoda) Date: Fri, 28 Apr 2017 16:20:31 +0000 Subject: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> Message-ID: <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi Elvis, Elvis Daniel Velea wrote: [...] > Is there a need for that...? How many LRH have expressed concerns > about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry. If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services). Kind regards, Leo Vegoda -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4988 bytes Desc: not available URL: From ebais at a2b-internet.com Fri Apr 28 18:40:29 2017 From: ebais at a2b-internet.com (Erik Bais) Date: Fri, 28 Apr 2017 18:40:29 +0200 Subject: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <01f801d2c03e$295c8400$7c158c00$@a2b-internet.com> Hi Leo, Let me provide some insight on how Inter-RIR legacy transfer go from, for instance ARIN to RIPE. Once a ticket has been submitted via the ARIN system for a transfer, by the originating party, ARIN will process the transfer, verify the legitimacy of the holdership etc. and they will forward the ticket to RIPE NCC. The RIPE NCC will do the check with the receiving party if they are eligible for the transfer and can justify the needs assessment that is required. The RIPE NCC will request the parties (received and originating party) to indemnify the RIPE NCC for any changes in the RIPE DB .. the word is that it isn't a contract, but there are legal words involved and signatures required on paper and the RIPE NCC is the third party beneficiary of the paper that isn't a contract. ( the indemnification .. ) And then they will also request a copy of the company registration of the receiving party and the originating party for the correct documentation in the Registry (the RIPE NCC internal system). The RIPE NCC has a very strict verification system in place for transfers, so your assumption that they don't verify or approve transfers ... ( Specifically Legacy resources.. ) is not correct. They do verify and check . . . and check .. and check again .. And I rather have them do this once to many times. And this is almost similar for regular Legacy transfers if a parent prefix needs to be split .. as that can only be done by the RIPE NCC and the updating of the registry of the RIPE NCC for holdership changes must also be documented properly.. So if you ask the RIPE NCC to update the registry after a legacy transfer, they will ask you for some documents to proof who you are and to indemnify the RIPE NCC for any mistakes in the updating of the info if needed.. I never had ANY LHR ask me why they are not listed in the RIPE stats for transfer as a Legacy holder. Most of the sending and receiving parties would rather not be listed instead of being published on the transfer stats page. However for completion of the data about transfers, it could be interesting for some (mostly researchers and probably brokers.. ) to get an idea about the current market.. However if you maintain your own versioning of the RIPE database, you can also do this yourself internally and just diff the DB between last week and today if needed. As on your remark on the services WG as the Go-To WG for LHR .. that might swing both ways.. as most Transfer policy discussions have been done here. But I'm not arguing that you are incorrect on the point. Regards, Erik Bais A2B Internet & Prefix Broker -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Leo Vegoda Verzonden: vrijdag 28 april 2017 18:21 Aan: elvis at v4escrow.net; Carlos Friacas CC: address-policy-wg at ripe.net Onderwerp: Re: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) Hi Elvis, Elvis Daniel Velea wrote: [...] > Is there a need for that...? How many LRH have expressed concerns > about such a gap? It is not a gap in the policies. Transfers of legacy space are currently not verified and/or approved by the RIPE NCC. Any update of a LR in the database object does not require the RIPE NCC to update the registry. If there is no gap in the policies and what you are proposing is service, why was this introduced to the Address Policy WG? The charter for the RIPE NCC Services Working Group makes it clear that it is the home for discussions about the introduction of new services and tools (https://www.ripe.net/participate/ripe/wg/services). Kind regards, Leo Vegoda From gert at space.net Fri Apr 28 19:17:50 2017 From: gert at space.net (Gert Doering) Date: Fri, 28 Apr 2017 19:17:50 +0200 Subject: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Message-ID: <20170428171750.GW25069@Space.Net> Hi, On Fri, Apr 28, 2017 at 04:20:31PM +0000, Leo Vegoda wrote: > If there is no gap in the policies and what you are proposing is service, why > was this introduced to the Address Policy WG? The charter for the RIPE NCC > Services Working Group makes it clear that it is the home for discussions > about the introduction of new services and tools > (https://www.ripe.net/participate/ripe/wg/services). The AP and NCC Services WG chairs debated this, and it's "sitting on the fence" - legacy stuff / NCC services obviously go to the NCC Services WG, but since it was felt that APWG "owns" the transfer policy document, which is potentially subject to change here, the proposal ended here. We've sent a heads up to the NCC Service WG so they are informed. Gert -- 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: 3603 bytes Desc: not available URL: From randy at psg.com Sat Apr 29 04:46:38 2017 From: randy at psg.com (Randy Bush) Date: Sat, 29 Apr 2017 11:46:38 +0900 Subject: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <01f801d2c03e$295c8400$7c158c00$@a2b-internet.com> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <01f801d2c03e$295c8400$7c158c00$@a2b-internet.com> Message-ID: > Let me provide some insight on how Inter-RIR legacy transfer go from, > for instance ARIN to RIPE. i think there was a presentation on the actualy reality of this at some yuroopian ops meeting. see https://archive.psg.com/160524.ripe-transfer.pdf randy