NANOG as the Internet government?

http://www.networkworld.com/columnists/2005/082205johnson.html

/* ARTICLE
Did the Internet/IETF governance model work? In many respects, yes. Early
on, the IETF produced key protocols at a much faster clip than other
network standards bodies (such as the IEEE and the ITU). Although many
IETF veterans strenuously object to calling the IETF a "standards body,"
whatever you call it, the IETF did an outstanding job midwifing protocols
and accelerating the 'Net's adoption.
*/

Agree and disagree. There are still many things that need to be ironed out
within the IETF and so called standards. Let's take a look at some of the
protocols that have been broken, remodified, rebroken (slight Bushism),
patched, entirely rewritten into a new "concept", RFC, etc. I think that a
body similar to the IETF would do justice, but selection of who's on
first, would have to be done on a voting basis or sorts.

/* ARTICLE
Does the model still work? I'm not sure. In my view, the biggest concerns
facing the Internet today are regulatory and operational, rather than
technical. For example, how do we encourage providers to respect each
other's QoS tags? Is it acceptable for providers to censor traffic for
competitive advantage? Should providers be required to devote some of
their revenues toward services "for the common good," such as universal
Internet access?
*/

Model of what... Putting in an RFC, getting comments from everyone what's
the saying? "Too many indians not enough chiefs" or "Too many hands in the
pot spoil the stew". Anyhow, I say this looking at broken protocols that
are vulnerable to all sorts of mayhem and have been broken for years
because it wouldn't be in the best interest to make things right and have
everyone reconfigure their networks.

Granted rebuilding a backbone NAP would be a horror story, everyone points
to IPv6 as a solution and how grandiose it will be, yet IPv6 ("The Secure
IP!) has been broken too. Not only that how many large providers are
willing to take a hit in the pockets getting everything running the way it
should be run. Why should they when they could do some shoddy patchwork
until the next big hit. I know I'm rambling on, but come on now NANOG'ers
as the Internet government.

Some of the people here are great teachers in their own right and over the
years I've probably learned more from NANOG than I have from any book,
RFC, professor, etc., but I also know there are plenty of crybabies,
plenty of morons, and even some on the IETF who have snubbed the notion of
fixing broken protocols. I say this on the basis of me contacting quite a
few on the issues of BGP/SBGP, ICMP and how I could break it out of
boredom. Response "Shoo fly... You don't have any certs..." or "Hush... By
you releasing horribly written papers with information you're going to
cause mayhem." And other things along those lines.

/* ARTICLE
So what should we do? One answer is to call in the federal government. I'm
not a huge fan of government regulation; it can be better than the
alternatives, but regulation tends to slow down an industry's rate of
innovation. Moreover, the Internet is international, so whose federal
government would we turn to as the referee? Yet waiting for the free
market to answer these questions doesn't seem to be working, either.
*/

Problems with selecting people from any company or government are
"agendas". Who is to say that someone could be trusted from say taking a
nice little payout to hush up on a problem. Not making an accusation lest
someone at Cisco want to bore me with the threat of a lawsuit, but who is
to be certain that even if some body was selected, you wouldn't have to
worry about the big boys in industry paying to tweak "the Internet" to
their liking. What if say Cisco (who has this huge issue their trying
their best to cover up), greased the pocket of those in this body to quash
the notion of Cisco having broken routers.

Aside from that, what standards would this body set?

Ten Commandments of the Interweb

i. Thou shall route thy competitors packets fairly
ii. Thou shall not install network analyzers without international
        warrants
iii. Thou shall not allow evil traffic to pass through ones routes
iv. Thou shall give access to any authority figure with or without
        warrants
v. Thou shall maintain route tables
vi. Honor thy NEIGHBOR_AS
vii. Honor thy Backbone
viii. Thou shall not null route thy neighbor
ix. Thou shall play fairly with VoIP carries even whenst thine own's
        ILEC/CLEC loss revenue
x. Thou shall remember all routes and AS's

/* ARTICLE
Call it the International Association of Networking Service Providers
(IANSP).
*/

What about "Yet Another Acronym to Add in Some Dictionary That No One Will
Respect in the Morning" (YAAASDTNOWRM)

Ten Commandments of the Interweb

xi. Thou shalt forswear the abuse of content-free buzzwords.

Sorry, it needed saying. Unfortunately for the geeks among us, there's no
easy way to number from zero in Roman numerals....

ii. Thou shall not install network analyzers without international
       warrants

Might be a bad idea. There's a *reason* why 18 USC 2511 has specific
exemptions for network quality testing:

http://www4.law.cornell.edu/uscode/18/2511.html

iv. Thou shall give access to any authority figure with or without
       warrants

So you'll give access to an authority figure *without* a warrant, even though
this clashes with the intent, if not the letter, of (ii)?

(Or was "without warrants" veiled reference to a National Security Letter? :slight_smile:

iii. Thou shall not allow evil traffic to pass through ones routes
viii. Thou shall not null route thy neighbor

And if the two of these come into conflict, what do you do? Moral absolutism
may be nice, but it won't save you any on your car insurance or help you run
a production network. If you're selling volume-charged transit, it gets even
murkier....

This stuff is harder than it looks....

/* ARTICLE
Does the model still work? I'm not sure. In my view, the biggest concerns
facing the Internet today are regulatory and operational, rather than
technical. For example, how do we encourage providers to respect each
other's QoS tags? Is it acceptable for providers to censor traffic for
competitive advantage? Should providers be required to devote some of
their revenues toward services "for the common good," such as universal
Internet access?
*/

Not only that how many large providers are willing to take a hit in the
pockets getting everything running the way it should be run. Why should
they when they could do some shoddy patchwork until the next big hit.

It's more than just that. The article excerpt above mentions:

For example, how do we encourage providers to respect each other's QoS
tags?

This part is *not* regulatory in nature; it's financial. QoS is still (even
today) a lucrative market. Why would Tier-1 A care to carry packets from
Tier-1 B at a higher priority than anyone else's, unless Tier-1 B paid more
$$$ for the privilege? If regulation were to step into this market, you'd
have the entire industry crying foul.

The other way round, however:

Is it acceptable for providers to censor traffic for competitive
advantage?

is indeed a regulatory issue. For the most part, Tier-1s and other
providers high up the food chain don't filter because doing so is (1) too
much of a load on switching hardware, (2) too much risk of violating peers'
or downstreams' contracts, or (3) both. The issue of traffic filtering is
much more prominent with the small-fries and leaf networks.

These two rhetorical questions are pretty clear. Unfortunately, the
dividing area between regulatory and non-regulatory issues is a deep gray,
and it's much broader than most netizens realize.

I'm biased, but I think these are better and less contestable:

   1. Thou shalt above all, maintain the integrity of the network.
   2. Thou shalt have a long term strategic direction.
   3. Thou shalt always opt for quality before expediency.
   4. Thou shalt meet the requirements, exceed the expectations and anticipate
      the needs of users.
   5. Thou shalt benefit from a successful implementation by careful project
      planning.
   6. Thou shalt provide reliability, availability and serviceability.
   7. Thou shalt maintain detailed, timely and accurate documentation.
   8. Thou shalt commit to continuous training.
   9. Thou shalt test in a test environment.
  10. Thou shalt install and label cables properly.

They're about 10 years old now and seem to still hold up pretty well.

John