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] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
- Previous message (by thread): [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
- Next message (by thread): [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Elvis Daniel Velea
elvis at v4escrow.net
Tue Jan 13 18:23:09 CET 2015
Hi Nick, On 13/01/15 16:57, Nick Hilliard wrote: > On 13/01/2015 14:46, Gert Doering wrote: >> So your suggestion would be to stall this proposal until we know what >> comes out of the next AGM, and then see if we need the clause in >> question at all, anymore? > yes, that was my suggestion. The current configuration is stable, so there > are no pressing operational reasons to change things in a hurry. If we're > going to change, we need to do that's best for N years down the road, not > what's best for a couple of months during 2015. I do not think it is a good idea to stall a policy proposal in order to see if the Board/AGM decides to take into consideration or ignore in the future your presentation/proposal from the previous AGM. I think your suggestion sets a very dangerous precedent where a policy proposal would be stalled pending a decision that may or not be taken at the next AGM. Regarding the current configuration, well.. it requires the requester of the ASN to come up with a reason that can not be verified by the RIPE NCC and with a predicted set of peers that may or not peer with the assigned ASN. For example, see the e-mail sent to the members-discuss mailing list yesterday by Shahin Gharghi; the current policy requires the requester to list the two ASNs they will peer with, what if some companies can not peer with two ASNs because of local regulations. Do you think that company should not receive the ASN they need? Also, from your e-mail I understand that you are sure the AGM will vote within 'a couple of months' to charge for ASNs. Do you know something that I don't? :) >> What if the AGM decides to bring back a yearly recurring charge for >> ASNs, we loosen up our policy, the AGM decides to remove the charge once >> again, > from previous email: > >>> As a more general issue, we need to accept as a community that there >>> is a crossover between RIPE Community policy and RIPE NCC membership >>> policy, and that this is one of those intersections. > Both the RIPE NCC membership and the AP working group tend to end up with > reasonable policies. I'm pretty confident that this isn't going to change > any time soon. It has already changed from a year to the other and that is why I did not like the proposal you made at the previous AGM. We need to have a charging scheme that is predictable and will not change from a year to the other. I think that if this policy proposal becomes policy and too many companies start requesting 1000 ASNs, the AGM can react and start charging (either from the first, the second or the 100th ASN) based on numbers that the RIPE NCC will provide. I do not like the idea that a policy proposal can be stalled because someone can imagine a way the proposal/policy could be abused. If it does get abused, we react on that and not on predictions. > Nick > > Regards, Elvis -- <http://v4escrow.net> Elvis Daniel Velea Chief Executive Officer Email: elvis at V4Escrow.net <mailto:elvis at v4escrow.net> US Phone: +1 (702) 475 5914 EU Phone: +31 (0) 61458 1914 Recognised IPv4 Broker/Facilitator in: This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received this email in error, please notify the sender immediately and delete the original.Any other use of this email is strictly prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/address-policy-wg/attachments/20150113/45b99293/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 5043 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20150113/45b99293/attachment.png> -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 11971 bytes Desc: not available URL: </ripe/mail/archives/address-policy-wg/attachments/20150113/45b99293/attachment-0001.png>
- Previous message (by thread): [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
- Next message (by thread): [address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]