but, why wouldn't something like formally requiring
customers/peers/transits/etc to have radb objects as a 'requirement'
for peering/customer bgp services
'Cause there ain't nobody out there to "formally require" this.
Other than ISPs, of course. And that means there will be umpteen
different sets of rules, one set for each ISP.
if you are a new customer and you sign up for bgp, it is
clearly stated in the contract, the customer/provider
requesting this service must maintain objects radb..
In that case, no problem. But what about the contracts that
do NOT state this? Who will change them? What language will
they use? Who will coordinate the changes so that there is
something halfway consistent?
This is the problem Randy refers to when he talks about
if larger networks adapted to something like this, i think
people would start to follow, as they would have no choice
because they would be cut off from certain routes
Larger peers started this way back about 15 years ago. Very
few followed suit. What makes you think this will change?
Operationally, the Internet is an anarchy. There is no formal
organization of network providers that will set up working
groups to define best practices in routing, in peering, etc.
Instead, we have some areas where there *ARE* organizations
applying formal rigor like email with MAAWG but that only
happens with the real hot button issues. Everything else is
left to simmer away in the anarchy.
In Europe, the network operators that are also in the telecoms
business, formed an organization called ETSI http://www.etsi.org
to address a whole raft of inter-operator issues primarily
focused on standards. There is no good reason why operators
with Internet transit businesses should not form a similar
organization to tackle the problems that come back again and
again on the NANOG list, with only half measure and short term
bandaid fixes being developed.
You will note, that when ETSI was formed there was already an
international telecom standards organization in operation called
the ITU. But it had issues, and so folks went off and set up
something that was more workable. When will NANOG participants
smell the coffee and do likewise? The FCC will not rescue you.