[address-policy-wg] 2014-03 New Draft Document and Impact Analysis Published (Remove Multihoming Requirement for AS Number Assignments)

Hey,

You seem to give critic on many aspects, but offer solution to one aspect. You believe the magic 1k should be replaced by small fee. Well, that is what the 1k does, it gives non-zero fee to ASN, so that you dont want to request 32b of them. Same functionality without changes to billing procedure.

The requirement for reason to request is for those who come after us, so that they will have data to work with. Why are ASNs needed? Does this seem problematic or wrong?

I'm ambivalent on the RPSL aspect. How should it be remedied? Removed?

Thanks,
-- 
  ++ytti


> On 24 Dec 2014, at 23:18, Nick Hilliard <nick at inex.ie> wrote:
> 
>> On 24/12/2014 18:14, Gert Doering wrote:
>> So do I take that as support of the policy, or opposition?  And if the
>> latter, what are you unhappy about which couldn't be brought up in the 
>> previous round already (since this new version really tries to incorporate 
>> all feedback that has been given)?
> 
> It's the evening of dec 24 so I'm not going to go into a whole rigmarole
> about the theory of bureaucratic policy.  But as a general rule, most ripe
> community addressing policy over the last couple of years has been veering
> towards relaxation and simplification of rules rather than making them more
> complicated.  This is particularly the case with ipv4, and almost the same
> with ipv6 from most practical viewpoints.  As a community, we're pretty
> much together that this is a good thing.
> 
> Then this proposal happens.
> 
> It invents a magic number - one thousand. Yes, I'm aware of the distant
> practical basis for this, but let's not pretend that in every other respect
> the number isn't pulled straight out of the air because it happens to be an
> ordinal power of the number of fingers on most peoples' hands.  Magical,
> nay divine, power is assigned to this number: thus far shalt thou abuse and
> no further!
> 
> It creates a policy requirement to invoke RPSL, possibly one of the most
> inscrutably ill-defined languages ever devised, but the requirement is so
> poorly defined that anything could be credibly hurled into the database.
> E.g. "from AS23456 import AS-NULL".
> 
> It creates a requirement to state a need for the ASN which the RIPE NCC
> will forbidden from evaluating.
> 
> It also creates a requirement for the RIPE NCC to police this need.  Not
> evaluate, mind you - just police it without evaluation.  I'm trying to
> understand how this could possibly work, so in the unlikely event that
> there are no further emails from this address, you can assume that my brain
> has imploded due to a neural singularity.
> 
> It conveniently ignores the awkward reality that in the event that an
> organisation might ever want 1001 ASNs, they could spend 10 euros
> registering a second company and continuing on their merry way.  Guys and
> gals, I have shocking news for you: if someone is dishonest enough to abuse
> the rules using one organisation, they can just as easily abuse the rules
> with two different organisations and perpetrate twice as much abuse.
> Application of iteration theory indicates that this abuse may even scale
> linearly.
> 
> The sensible approach to this is to relax the policy requirements for asn
> assignment - in exactly the same way that the ripe community has relaxed
> the policy requirements for other number resources - and then apply a small
> fee to help prevent egregious abuse.  Note: not stop, because it is not
> possible to completely people abusing arbitrary rulesets without harming
> the common good.
> 
> This is far simpler, most manageable, smaller, more internally consistent
> and generally more beneficial for the community than proposing byzantine
> policy.
> 
> Look I'm sorry, but this policy draft is absurd and flies in the face of
> reality, common sense and practical application.  Please kill it with fire.
> 
> Nick
> 
>