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] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)
- Previous message (by thread): [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers)
- 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 ]
Sylvain Vallerot
sylvain.vallerot at opdop.net
Sun Nov 17 20:52:01 CET 2013
On 29/10/2013 15:33, Tore Anderson wrote: > I think it would benefit the proposal's journey through the PDP if it > tried to do fewer things at once, perhaps by splitting it into multiple > proposals. Agreed. Despite i'm globally ok with the spirit the proposal but I think having a proposal that meets the "main goal" is not yet granted. A few things seem problematic to me Removing the color looks interesting, but to me question is, what does it bring apart from cosmetics ? From what I read in the proposal there sitll would be a difference between End User block and End Site bloc. Call it (sub)allocated or assign, it is the same difference. The majors points seems to be that nowadays PI blocks would (a) be bigger tomorrow and (b) able to be further sub-allocated / assigned to End Users / Sites. Yes this is the major point since it will give independance for a lot of companies. But this, only is costs from the sponsoring LIRs are not a barrier. However this should lead to an automatic shift to what used to be PI, since any End User could request a /32 that would be independant from the LIR there seems to be a risk regarding the aggregation goal (I refer to old-style routing aggregation). Next, growing automatic End-User minimum allocation to /32 is going to be a problem for routing LIRs structure and/or ressource management since they are supposed to have a IPv6 plan. This /32 frontier standard might become a problem for the smaller networks routability, leading everybody to rush to a /32 without having a need for it because of some operators taking /32 as a new filtering limit. I did not see any financial consideration here, so LIRs might will to apply financial pressure of their customers (and as Sponsoring LIRs) slow the implieds changes. So I think we lack an impact analysis here, and I wonder about the impact for LIRs, and impact for Ripe in terms if membership and workload evolutions. Sorry if some of these we already discussed, this is just for the requested feedback, I did'nt have the time to read all the 99 posts yet. Best regards, Sylvain
- Previous message (by thread): [address-policy-wg] 2013-05 Last Call for Comments (No Restrictions on End User Assignments in Intra-RIR Transfers)
- 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 ]