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] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Carlos Friacas
cfriacas at fccn.pt
Thu Apr 27 10:57:35 CEST 2017
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 > >
- 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] 2017-01 New Policy Proposal (Publish statistics on Intra-RIR Legacy updates)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]