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/address-policy-wg@ripe.net/
[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Mon Sep 30 18:41:14 CEST 2013
* Elvis Velea > There are only two paths, from the RIPE NCC to LIR and from the RIPE NCC > to End user (we may decide to change the name) via the Sponsoring LIR. Hi Elvis, Just thinking out loud here, so don't mistake this for opposition to the current proposal, it's not, but we are in the bikeshe^Wdiscussion phase after all... I'm thinking that the "Sponsoring LIR" concept is an NCC operational issue that perhaps doesn't really belong in address policy to begin with. Perhaps it would result in a more concise and elegant policy if instead of "unifying" PA with PI, this proposal simply just removed the PI concept altogether? Simply just delete section 7 of the policy document and leave it at that - as far as the policy document goes anyway. Then you would have only one path and no confusion: RIR[RIPE NCC] -> LIR -> End User Everything that follows below could be considered operational issues that's for the NCC/AGM/Board to decide on...but just to elaborate a bit more on where I'm thinking something like this could lead to: Q: But what about existing PI holders and their blocks? A: Just start considering them to be LIRs. Upon implementation of the new policy, the NCC could automatically convert all existing inet6num in the database with status ASSIGNED PI to ones with status "ASSIGNED" (PA), and add a congruent object with status ALLOCATED-BY-RIR. Q: They wouldn't want to pay the full membership price for being LIRs! A: We don't have to make them. It could be possible to be a RIPE region LIR even though you're not a direct/full member of the RIPE NCC. RIPE NCC members could be seen as "sponsors of LIR status" instead of "sponsors for PI blocks". It could even cost the same €50 as before. Q: How would that work? A: We could end up with two levels of RIPE NCC membership, e.g. "full" like we have today, and "associate". Both would be fully-blown LIRs, but to keep the operational overhead in NCC billing/finance low, the membership fee for these "associate" members would be charged by the NCC to the full members who are sponsoring them (just like with PI). Q: Why would anyone want to be a full member then? A: Access to certain NCC services such as the LIR Portal, Atlas credit boost, etc. could be limited to full members only. In any case - those would be operational and mercantile issues we could leave out of the policy (but perhaps provide suggestions/guidance on in the supporting notes). Maybe I'm off my rocker, but this is what was going through my head on the bus back home today... :-) Tore
- Previous message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Next message (by thread): [address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]