From leo.vegoda at icann.org Mon May 1 17:06:48 2017 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 1 May 2017 15:06:48 +0000 Subject: [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <20170428171750.GW25069@Space.Net> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> <6999bf87ef254085ad3e8a41f1cd96c7@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> <20170428171750.GW25069@Space.Net> Message-ID: <63ee7ae2d03c4bfdac5d2f917e2472fa@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi Gert, Gert Doering wrote: > 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. Thanks for the explanation! Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4988 bytes Desc: not available URL: From leo.vegoda at icann.org Mon May 1 19:38:22 2017 From: leo.vegoda at icann.org (Leo Vegoda) Date: Mon, 1 May 2017 17:38:22 +0000 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: <517bd5fe0faa467c9ba20b4531e7dd81@PMBX112-W1-CA-1.PEXCH112.ICANN.ORG> Hi Erik, Erik Bais wrote: [...] > 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. I did not realize the RIPE NCC's AUP had been changed to allow users to make copies of the database. This is an interesting change! Regards, Leo -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4988 bytes Desc: not available URL: From jkennedy at libertyglobal.com Tue May 2 12:49:19 2017 From: jkennedy at libertyglobal.com (Kennedy, James) Date: Tue, 2 May 2017 10:49:19 +0000 Subject: [address-policy-wg] 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: <13E63C78A6256E4A857726374FBF926E12AA7F41@NLAMSPEXMB022.upcit.ds.upc.biz> Hi Elvis Daniel, All, Though I would like to read the Impact Analysis before committing, I am in general support of this policy change. Improving transparency of basic IP transfer data is a good thing for the community for the aforementioned reasons. Particularly to improve the accuracy of transfer activity stats, trends and analysis. And I like that LRHs are not forced to opt-in, though there will be a clear incentive to do so in order to have a LR transfer verified by the RIPE NCC. Regards, James Kennedy -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Elvis Daniel Velea Sent: 28 April 2017 13:36 To: Carlos Friacas Cc: address-policy-wg at ripe.net Subject: Re: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) 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 elvis at v4escrow.net Tue May 2 14:21:26 2017 From: elvis at v4escrow.net (Elvis Daniel Velea) Date: Tue, 02 May 2017 12:21:26 +0000 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <13E63C78A6256E4A857726374FBF926E12AA7F41@NLAMSPEXMB022.upcit.ds.upc.biz> References: <3684f7e0-56ac-4bb7-7b0d-3d21fa2c4f3d@v4escrow.net> <7a113ce6-2440-3b58-258a-fcc1e7b1fc1f@v4escrow.net> <13E63C78A6256E4A857726374FBF926E12AA7F41@NLAMSPEXMB022.upcit.ds.upc.biz> Message-ID: Hi James, On Tue, May 2, 2017 at 1:49 PM Kennedy, James wrote: > Hi Elvis Daniel, All, > > Though I would like to read the Impact Analysis before committing, I am in > general support of this policy change. Improving transparency of basic IP > transfer data is a good thing for the community for the aforementioned > reasons. Particularly to improve the accuracy of transfer activity stats, > trends and analysis. > thank you for your support. I hope that the IA will convince you to provide your strong support to this policy proposal. > > And I like that LRHs are not forced to opt-in, though there will be a > clear incentive to do so in order to have a LR transfer verified by the > RIPE NCC. > I expected to see opposition from the LRHs if this proposal would have included any limitations. That is why, on purpose, this policy proposal does not limit any of the rights of the LRHs. Kind regards, Elvis > > Regards, > James Kennedy > -- Elvis Daniel Velea V4Escrow LLC Chief Executive Officer E-mail: elvis at v4escrow.net Mobile: +1 (702) 970 0921 Excuse the briefness of this mail, it was sent from a mobile device. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ebais at a2b-internet.com Tue May 2 15:39:39 2017 From: ebais at a2b-internet.com (Erik Bais) Date: Tue, 2 May 2017 15:39:39 +0200 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: References: Message-ID: <010701d2c349$8c11a040$a434e0c0$@a2b-internet.com> Hi Elvis, I've read the proposal and I?m not sure I see what you are trying to solve here ... besides the obvious ? Because if you look at the following URL: https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/tran sfers/inter-rir-transfers/inter-rir-ipv4-transfer-statistics There is a specific section for Inter-RIR transfers .. with a to RIPE and >From RIPE tab.. And in the To tab, you will see the following (as an example.. ) 157.97.0.0/16 ARIN A&F Networks B.V. 17/03/2016 147.28.0.0/16 ARIN RGnet, LLC 16/03/2016 192.83.230.0/24 ARIN RGnet, LLC 16/03/2016 198.133.206.0/24 ARIN RGnet, LLC 16/03/2016 And these are all Legacy Prefixes inter-rir transfers done .. and published.. So if the RIPE NCC is already registering the prefixes as part of the Inter RIR transfers .. even before they are marked as a Legacy prefix.. in the RIPE DB .. How will this policy make a difference ? And the change in the transfer document that the RIPE NCC is currently still implementing .. it clearly states the following : https://www.ripe.net/publications/docs/ripe-682#4-0-transfer-statistics * 4.0 Transfer Statistics * The RIPE NCC will publish a list of all transfers. This publication shall occur on a monthly basis or more frequently if the RIPE NCC so chooses. * This list will contain information about approved changes. The following information will be published: * The name of the offering party * The resource originally held by the offering party * The name(s) of the receiving party or parties * Each subdivided prefix (each partial block derived from that original block) or resource received * The date each resource was transferred * Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition) And I like to put the emphasis on : * The RIPE NCC will publish a list of all transfers. And * Whether it was a transfer according to this policy or a transfer due to changes to an organisation's business structure (such as a merger or acquisition) This paragraph 4 isn?t a part of the paragraph 3.. (3.0 Inter-RIR Transfers ) ? or the limitations in paragraph 2 (2.0 Transfers within the RIPE NCC Service Region) And there is also no difference between RIPE PA or Legacy space in that section ? So how I read (and wrote) the policy is that the Transfer statistics should be published on all transfers. * A transfer can be a change of resources from company name A to company name B .. (via the M&A process) * Or via the actual Transfer procedure ? * Or a company name change .. ( company A is now known as company B, but same company, same owners etc. ) This is the least interesting one imho. There is no limitation for legacy resources .. and it doesn?t affect their legacy status .. under this policy. There is a difference between the RIPE DB and the RIPE registry.. if you want to update the DB, the LRH can do that themselves.. But if the LRH wants to update the registry (the RIPE NCC internal system), they should provide the proper documentation. And that is already in place in procedures.. So the actual change that you are asking is : In the Services to Legacy Resource Holder policy (https://www.ripe.net/publications/docs/ripe-639) .. Have Legacy Holders to agree to sign a document, that the RIPE NCC already has in the operational procedure. In which case the name of the policy is incorrect .. as it isn?t about Inter-RIR legacy updates .. or transfers .. but about the Services to LRH?s .. Perhaps we should see first what the RIPE NCC will implement with the 2015-04 ? before we go look into additional policy ? Regards, Erik Bais A2B Internet -----Oorspronkelijk bericht----- Van: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] Namens Marco Schmidt Verzonden: dinsdag 25 april 2017 14:40 Aan: address-policy-wg at ripe.net Onderwerp: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) 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 < address-policy-wg at ripe.net> before 24 May 2017. Regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue May 2 23:06:25 2017 From: farmer at umn.edu (David Farmer) Date: Tue, 2 May 2017 16:06:25 -0500 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <66bc99c7-b982-cccc-2a21-ce77881662f3@v4escrow.net> References: <20170425161057.GZ93886@cilantro.c4inet.net> <20170425222627.GA93886@cilantro.c4inet.net> <66bc99c7-b982-cccc-2a21-ce77881662f3@v4escrow.net> Message-ID: On Tue, Apr 25, 2017 at 5:41 PM, Elvis Daniel Velea wrote: > 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. > Currently as written it's voluntary from the perspective of RIPE policy, but if almost all sophisticated buyers expect it, is it truly voluntary? Furthermore, doesn't having it be voluntary unnecessary expose unsophisticated buyers to a higher risk from fraudulent actors? Is caveat emptor really the fundamental concept we want enshrined in policy for the transfer of Legacy Resources? Then, what about any LRHs that want the additional protection of RIPE validating any and all attempted transfers of their resource by possibly fraudulent actors. It may be an additional requirement, but that can also be seen as additional layer of protection for both sides. For buyers there is some protection they not dealing with a fraudulent seller. For LRHs it makes it a little harder for someone to fraudulently sell their resources out from under them. We can't eliminate fraud, but making this mandatory seems like a minimal level of protection for both buyers and LRHs. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From mschmidt at ripe.net Fri May 5 15:09:07 2017 From: mschmidt at ripe.net (Marco Schmidt) Date: Fri, 05 May 2017 15:09:07 +0200 Subject: [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates) In-Reply-To: <010701d2c349$8c11a040$a434e0c0$@a2b-internet.com> Message-ID: Hello Erik, We would like to provide some clarification regarding your point on publishing transfer statistics for legacy updates. On 2017-05-02 15:39:39 CET, Erik Bais wrote: > And I like to put the emphasis on : > > > * The RIPE NCC will publish a list of all transfers. > > And > > * Whether it was a transfer according to this policy or a transfer > due to changes to an organisation's business structure (such as a merger or > acquisition) > > This paragraph 4 isn?t a part of the paragraph 3.. (3.0 Inter-RIR Transfers > ) or the limitations in paragraph 2 (2.0 Transfers within the RIPE NCC > Service Region) > > And there is also no difference between RIPE PA or Legacy space in that > section > > So how I read (and wrote) the policy is that the Transfer statistics should > be published on all transfers. > > * A transfer can be a change of resources from company name A to > company name B .. (via the M&A process) > > * Or via the actual Transfer procedure > > * Or a company name change .. ( company A is now known as company B, > but same company, same owners etc. ) This is the least > interesting one imho. > > There is no limitation for legacy resources .. and it doesn?t affect their > legacy status .. under this policy. > The current Transfer Policy does not include the publishing of legacy updates within the RIPE NCC service region. The RIPE Policy, "RIPE NCC Services to Legacy Internet Resource Holders", clearly states that "Any existing or future RIPE policy referring to resources shall not apply to legacy resources unless the policy explicitly includes legacy resources in its scope." https://www.ripe.net/publications/docs/ripe-639#1-2-scope Legacy resources are mentioned in the scope of the Transfer Policies for inter-RIR transfers, but not for updates within our service region or transfer statistics. Of course, another difficulty is that the RIPE NCC is not involved in many of these legacy updates. Therefore, we would not be able to distinguish whether a legacy update relates to a resource transfer, a merger, or a company name change in any statistics that we published. We hope this is helpful. Kind regards, Marco Schmidt Policy Development Officer RIPE NCC Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From randy at psg.com Thu May 11 06:54:18 2017 From: randy at psg.com (Randy Bush) Date: Thu, 11 May 2017 06:54:18 +0200 Subject: [address-policy-wg] recantation Message-ID: at yesterday's address policy statement, i was quite incorrect when i said that updated or obsoleted rfcs were marked. they are not. the index entry is marked. the rfcB obsoliting rfcA is marked as such. but rfcA is not marked as modified. apologies. randy From phessler at theapt.org Tue May 23 14:10:06 2017 From: phessler at theapt.org (Peter Hessler) Date: Tue, 23 May 2017 14:10:06 +0200 Subject: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0 Message-ID: <20170523121006.GL30896@gir.theapt.org> Hi All https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ripe-ncc-service-region I saw this restriction: """ Allocated resources may only be transferred to another RIPE NCC member. Provider Independent resources may be transferred to: * A RIPE NCC member; or * An entity that has a contractual relationship with a RIPE NCC member in accordance with the RIPE Policy, """ Note the difference between Allocated (PA) and Provider Independent (PI). Is this split intentional? Would a proposal to unify both under the existing PI rules be welcome? -peter From Ian.Dickinson at sky.uk Tue May 23 14:12:40 2017 From: Ian.Dickinson at sky.uk (Dickinson, Ian) Date: Tue, 23 May 2017 12:12:40 +0000 Subject: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0 In-Reply-To: <20170523121006.GL30896@gir.theapt.org> References: <20170523121006.GL30896@gir.theapt.org> Message-ID: <9B3BFE0A18160E40BAF1950414D10FAE8989FEC6@WPMBX010.bskyb.com> PA addressing is always bound to being an LIR, so I would say this is both intentional and desired. Ian -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces at ripe.net] On Behalf Of Peter Hessler Sent: 23 May 2017 13:10 To: address-policy-wg at ripe.net Subject: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0 Hi All https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ripe-ncc-service-region I saw this restriction: """ Allocated resources may only be transferred to another RIPE NCC member. Provider Independent resources may be transferred to: * A RIPE NCC member; or * An entity that has a contractual relationship with a RIPE NCC member in accordance with the RIPE Policy, """ Note the difference between Allocated (PA) and Provider Independent (PI). Is this split intentional? Would a proposal to unify both under the existing PI rules be welcome? -peter Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky plc and Sky International AG and are used under licence. Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075) and Sky Subscribers Services Limited (Registration No. 2340150) are direct or indirect subsidiaries of Sky plc (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD. From gert at space.net Tue May 23 14:35:01 2017 From: gert at space.net (Gert Doering) Date: Tue, 23 May 2017 14:35:01 +0200 Subject: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0 In-Reply-To: <20170523121006.GL30896@gir.theapt.org> References: <20170523121006.GL30896@gir.theapt.org> Message-ID: <20170523123501.GD25069@Space.Net> Hi, On Tue, May 23, 2017 at 02:10:06PM +0200, Peter Hessler wrote: > https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ripe-ncc-service-region > > I saw this restriction: > > """ > Allocated resources may only be transferred to another RIPE NCC member. > Provider Independent resources may be transferred to: > > * A RIPE NCC member; or > * An entity that has a contractual relationship with a RIPE NCC member > in accordance with the RIPE Policy, > """ > > Note the difference between Allocated (PA) and Provider Independent (PI). > > Is this split intentional? Would a proposal to unify both under the > existing PI rules be welcome? This split is intentional - a PA holder can only be a LIR, while a PI can be held by a LIR or by a non-LIR end user, provided they have a contractual relationship with a LIR. So unless we change the whole model of "who can hold which address space" (and abandon the PA/PI distinction while at it) the transfer policy document just reflects what address policy always required for the initial holder of a given "bag of numbers". 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 phessler at theapt.org Tue May 23 14:38:49 2017 From: phessler at theapt.org (Peter Hessler) Date: Tue, 23 May 2017 14:38:49 +0200 Subject: [address-policy-wg] clarification on RIPE Resource Transfer Policies (ripe-682) Section 2.0 In-Reply-To: <20170523123501.GD25069@Space.Net> References: <20170523121006.GL30896@gir.theapt.org> <20170523123501.GD25069@Space.Net> Message-ID: <20170523123849.GM30896@gir.theapt.org> On 2017 May 23 (Tue) at 14:35:01 +0200 (+0200), Gert Doering wrote: :Hi, : :On Tue, May 23, 2017 at 02:10:06PM +0200, Peter Hessler wrote: :> https://www.ripe.net/publications/docs/ripe-682#2-0-transfers-within-the-ripe-ncc-service-region :> :> I saw this restriction: :> :> """ :> Allocated resources may only be transferred to another RIPE NCC member. :> Provider Independent resources may be transferred to: :> :> * A RIPE NCC member; or :> * An entity that has a contractual relationship with a RIPE NCC member :> in accordance with the RIPE Policy, :> """ :> :> Note the difference between Allocated (PA) and Provider Independent (PI). :> :> Is this split intentional? Would a proposal to unify both under the :> existing PI rules be welcome? : :This split is intentional - a PA holder can only be a LIR, while a PI :can be held by a LIR or by a non-LIR end user, provided they have a :contractual relationship with a LIR. : :So unless we change the whole model of "who can hold which address space" :(and abandon the PA/PI distinction while at it) the transfer policy :document just reflects what address policy always required for the :initial holder of a given "bag of numbers". : :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 Right now I don't feel like trying to change the whole model, so the policy makes sense as it is. Thanks! -- A day for firm decisions!!!!! Or is it?