[address-policy-wg] Proposal 2011-02 moving to Last Call

Hi Mikael,

> I fear DFZ bloat. I have a hard time imagining that the policy group would change the PI policy even if there were an PI rate explosion, because of vested interest in keeping the policy in place from a large volume of people.
> 
> I would feel a lot more ease at mind if there were some kind of provision in it that would actually put a cap on number of PI blocks and force an mandatory re-consideration (or review or what not) of the policy (even though this might pass anyhow because of the beforementioned vested interests). This can be put quite high, let's say 100k in 10 years for the RIPE region (I haven't put too much thought into the actual number).
> 
> This would curb my doubts about it and I would fully support it, and the people saying there won't be a PI rate explosion shouldn't have much problem with it either, because if they're right, this provision would never come into effect.

I have serious doubts about setting an arbitrary cap and thereby creating 'fake' scarcity of a resource. It can also backfire: 'we see that things are going the wrong way, but we haven't reached the cap yet, so we'll wait until that happens'. The current PDP allows anyone to propose a policy change at any time, as soon as they see that something is wrong. I feel much more comfortable with that.

But I am just a co-chair here. Decisions are made by the working group (everybody on this mailing list), not by me :-)  If there is consensus that putting in a cap would be a good idea then that is what happens, and I'll give it my full support.

> I also have no problem passing the current policy so we can change IPv6 PI rules, and discuss the actual cap number during the next coming months.


That would be great.

Thanks,
Sander Steffann

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2084 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20110929/6b0ef8c8/attachment.p7s>