This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
- Previous message (by thread): [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
- Next message (by thread): [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Daniel Velea
elvis at v4escrow.net
Fri Apr 28 13:36:12 CEST 2017
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
- Previous message (by thread): [address-policy-wg] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
- Next message (by thread): [address-policy-wg] [Ext] Re: 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]