On 11 July 2014 15:20, Janos Zsako <zsako@iszt.hu> wrote: Hi Janos,
My understanding is, and I think this is how the RIPE NCC interpreted it as well, that the requester may simply state that their network is expected to become multi-homed in the future, and this would be a good reason (i.e. one that the RIPE NCC should accept) for receiving an ASN.
If there is no time limit when the requester is expected to become multi-homed, and/or the RIPE NCC is not expected to check this and ask for the ASN to be returned if the network is not multi-homed by that date, then I feel this part of the proposed policy is equivalent to saying that you simply have to ask for an ASN and the RIPE NCC must assign you one.
Am I wrong?
Yes. Option for multihoming easily does not imply it will ever happen, just that if need arises it's simple. Same goes for never having plans to multihome, but want to have easy, independent ability to switch providers on demand. You may also benefit from public ASN in scenarios where it's not even visible in the Internet (same goes for public IP addresses). Personally I would have wanted YRC to ASN and have no rules, lack of YRC make the policy soft and ambiguous, but I've bene told this is not a problem as many other RIPE policies are soft and ambiguous. In practice many RIPE members lie in ASN applications, because their use-case, which is commonly agreed to be valid, is not covered by current policy. This policy intends to align implied policy with written policy. I'd love to hear suggestion how to make it harder without YRC. Should there be strict list of valid use-cases? Should we expect RIPE NCC hostmasters to have understanding what is common/accepted use-case?
If this is how the policy proposal has to be interpreted, I do not support it.
-- ++ytti