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] 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 ]
Nick Hilliard
nick at inex.ie
Wed Dec 24 22:18:22 CET 2014
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
- 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 ]