MediaWiki API result
This is the HTML representation of the JSON format. HTML is good for debugging, but is unsuitable for application use.
Specify the format parameter to change the output format. To see the non-HTML representation of the JSON format, set format=json.
See the complete documentation, or the API help for more information.
{
"batchcomplete": "",
"query": {
"pages": [
{
"ns": 0,
"title": "API",
"missing": ""
},
{
"pageid": 1,
"ns": 0,
"title": "Main Page",
"revisions": [
{
"user": "Dataroads mxj000",
"timestamp": "2017-05-10T21:35:36Z",
"comment": "",
"contentformat": "text/x-wiki",
"contentmodel": "wikitext",
"*": "== Data Roads Foundation ==\n\n'''All roads should lead to all people.'''\n\n<ul class=\"c4 lst-kix_list_1-0 start\"><li class=\"c12\"><span class=\"c0\">"Information Surface Streets" (ISS) routing and protocols. </span></li></ul><ul class=\"c4 lst-kix_list_2-1 start\"><li class=\"c2\"><span class=\"c0\">Open source hardware and software projects.</span></li><li class=\"c2\"><span class=\"c0\">A new set of networking protocols and routing methods, designed bottom-up as people-centric instead of institution-centric.</span></li><li class=\"c2\"><span class=\"c0\">Learn from existing IETF standards, but better suit or alter them to serve person-person communications first, and institutional communications last.</span></li><li class=\"c2\"><span class=\"c0\">More emphasis on both data security and privacy from the start.</span></li></ul><ul class=\"c4 lst-kix_list_3-2 start\"><li class=\"c1\"><span class=\"c0\">Data roads should be open and fair to everyone, but data vehicles are in complete control of the sender, especially the vehicle identity and contents.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Router project: provides seamless path traversal from a dense Neighborhood Area Network (NAN) scale, to main street level Metropolitan Area Network (MAN) scale. </span></li></ul><ul class=\"c4 lst-kix_list_4-2 start\"><li class=\"c1\"><span class=\"c0\">Provide a big enough address space (minimum 64 bit) and robust enough navigation to efficiently traverse a global-scale (WAN) mesh.</span></li><li class=\"c1\"><span class=\"c0\">Physical geographic routing analogies may be the most useful. 32-bit longitude and 32-bit latitude provide a 64-bit unique address value, assessed by fixed and confirmed physical position, instead of arbitrary central assignment. </span></li><li class=\"c1\"><span class=\"c0\">Packet hop count survival based on distance, not arbitrary anti-loop counts. </span></li></ul><ul class=\"c4 lst-kix_list_5-3 start\"><li class=\"c3\"><span class=\"c0\">Loops are prevented by destination reachability assessment only near the end of a route.</span></li></ul><ul class=\"c4 lst-kix_list_4-2\"><li class=\"c1\"><span class=\"c0\">Each routing node provides a minimum of 8 connections, for traversal in 8 (or multiple of 8) cardinal directions.</span></li></ul><ul class=\"c4 lst-kix_list_6-3 start\"><li class=\"c3\"><span class=\"c0\">More cardinal directions are useful (in multiples of 2), but an 8 cardinal direction minimum provides interesting parallels to raster graphics processing methods.</span></li></ul><ul class=\"c4 lst-kix_list_7-4 start\"><li class=\"c5\"><span class=\"c0\">Potentially enables GPGPU route processing techniques. A modern low cost gaming PC with 8 or more network connections could become a powerful ISS router.</span></li></ul><ul class=\"c4 lst-kix_list_6-3\"><li class=\"c3\"><span class=\"c0\">When directions of connections < number of connection links, multiple links in a single direction can be trunked, to help alleviate route congestion problems created by a lack of connection in an adjacent cardinal direction.</span></li><li class=\"c3\"><span class=\"c0\">8 (and multiples 16, 24, 32, 48, 72, and 96) seems to be a "magic number" for commercial network hardware chip production.</span></li></ul><ul class=\"c4 lst-kix_list_8-4 start\">\n<li class=\"c5\"> http://www.broadcom.com/products/BCM5682 </li>\n<li class=\"c5\"> http://www.theregister.co.uk/2008/05/02/broadcom_interop_2008/ </li>\n<li class=\"c5\"> http://www.fulcrummicro.com/products/focalpoint/index.htm </li>\n<li class=\"c5\"> http://www.intelcommsalliance.com/kshowcase/view/view_item/bc21d64da6d22d4daa7ca667f78846ec267fad36 </li>\n<li class=\"c5\"> http://www.broadcom.com/press/release.php?id=s453172 </li>\n<li class=\"c5\"> http://www.aristanetworks.com/en/products/7500series/technology </li>\n</ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Home Area Network (HAN)-ISS gateways designed for all residential or stand-alone property uses. </span></li></ul><ul class=\"c4 lst-kix_list_9-2 start\"><li class=\"c1\"><span class=\"c0\">Can and should be embedded in any Internet direct access device.</span></li><li class=\"c1\"><span class=\"c0\">Supports continuous address space provided for trivial ISS-HAN traversal.</span></li></ul><ul class=\"c4 lst-kix_list_a-3 start\"><li class=\"c3\"><span class=\"c0\">64-bit geographic address space allows roughly one unique address per each square centimeter of the Earth's surface.</span></li><li class=\"c3\"><span class=\"c0\">HAN "subnet" range(s) determined by lot size and convex space corners.</span></li></ul><ul class=\"c4 lst-kix_list_9-2\"><li class=\"c1\"><span class=\"c0\">Last-chance whitelist and blacklist "firewall" control point.</span></li><li class=\"c1\"><span class=\"c0\">Allows NAT and port obfuscation for HAN-ISS transmission conversion.</span></li><li class=\"c1\"><span class=\"c0\">The most trusted ISS node for HAN-owned devices and security policy.</span></li><li class=\"c1\"><span class=\"c0\">Negotiates web-of-trust (WoT) relationship values with all directly-linked neighbor ISS nodes.</span></li><li class=\"c1\"><span class=\"c0\">More distant WoT nodes and ratings are all provided by the confirmed HAN owner manually.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Support efficient routing on cheap hardware, via ad-hoc protocols with limited network state knowledge, i.e. GPSR.</span></li><li class=\"c2\"><span class=\"c0\">Allow a variety of routing capability levels throughout the ISS mesh network.</span></li></ul><ul class=\"c4 lst-kix_list_b-2 start\"><li class=\"c1\"><span class=\"c0\">The most trivial case routing nodes can assume that received traffic from one direction is intended to be pushed to the connected node in the most opposite direction.</span></li></ul><ul class=\"c4 lst-kix_list_c-3 start\"><li class=\"c3\"><span class=\"c0\">This can be done via consistent wiring standards alone, aided via junction connection labeling by cardinal direction.</span></li><li class=\"c3\"><span class=\"c0\">Trivial case junctions do not get labeled as routing nodes. They are treated more like wiring junctions or signal distribution amplifiers. This treatment may be the literal truth in many deployment scenarios.</span></li><li class=\"c3\"><span class=\"c0\">Trivial case junctions do not receive routable addresses, or their address is ignored until a minimum "dumb" router state can be achieved by a node. </span></li></ul><ul class=\"c4 lst-kix_list_b-2\"><li class=\"c1\"><span class=\"c0\">"Dumb" store-and-forward router nodes can read the destination address in a packet header, and blindly choose from any active connections in roughly the same cardinal direction as the destination.</span></li></ul><ul class=\"c4 lst-kix_list_d-3 start\"><li class=\"c3\"><span class=\"c0\">Truly "dumb" router nodes merely forward packets to "smarter" nodes in the current best-fit cardinal direction for each packet.</span></li><li class=\"c3\"><span class=\"c0\">"Dumb" forwarding may be used as the default routing method when/where it best serves latency requirements.</span></li><li class=\"c3\"><span class=\"c0\">Even current low-cost consumer grade off-the-shelf (COTS) network hardware with 8 or more connections should be able to handle "dumb" forwarding.</span></li></ul><ul class=\"c4 lst-kix_list_b-2\"><li class=\"c1\"><span class=\"c0\">"Smart" nodes have a comprehensive knowledge of all mesh nodes comprising the interior of at least one local convex hull, with sufficient edge node information for efficient traversals into adjacent convex hulls.</span></li></ul><ul class=\"c4 lst-kix_list_e-3 start\"><li class=\"c3\"><span class=\"c0\">Cusps, averages, and deltas can be used to compress knowledge about a convex hull mesh, without having to store discreet data about every single node or link.</span></li></ul><ul class=\"c4 lst-kix_list_f-4 start\"><li class=\"c5\"><span class=\"c0\">Convex hull region cusps and edges that are created by physical border disconnection issues are good places to install "Smart" routing nodes and WAN gateways.</span></li><li class=\"c5\"><span class=\"c0\">When/where convex hull regions are defined more by router memory limits than edge border disconnections, the smartest router nodes will tend to reside in the center of their known convex hull region(s). This property makes it easier to estimate the position of the smartest router nodes in adjacent convex hulls, even when they are outside the current known region.</span></li></ul><ul class=\"c4 lst-kix_list_e-3\"><li class=\"c3\"><span class=\"c0\">"Intelligence" rating in a routing node is judged by how large a convex hull mesh map it can store. </span></li></ul><ul class=\"c4 lst-kix_list_10-4 start\"><li class=\"c5\"><span class=\"c0\">Even the dumbest routing node can store knowledge about itself and all ~8 immediate linked neighbors, comprising a filled octagon.</span></li></ul><ul class=\"c4 lst-kix_list_11-5 start\"><li class=\"c7\"><span class=\"c0\">Any retail COTS smart (marketing term) Layer 2+ switch or router sold today should have sufficient hardware to far exceed "dumb" node requirements.</span></li></ul><ul class=\"c4 lst-kix_list_10-4\"><li class=\"c5\"><span class=\"c0\">The smartest possible useful node is one that can store a world-wide map of all convex hulls, comprising all terrestrial mesh nodes, including gateway positions and metrics.</span></li></ul><ul class=\"c4 lst-kix_list_12-5 start\"><li class=\"c7\"><span class=\"c0\">Any commercial router with IPv6 BGP routing capability sold today should be able to handle efficient ISS routing over Earth-sized meshes. </span></li></ul><ul class=\"c4 lst-kix_list_13-6 start\"><li class=\"c9\"><span class=\"c0\">Faster memory and more processing power would just enable lower latency routing decision algorithms, and deeper suggested redirect lists.</span></li><li class=\"c9\"><span class=\"c0\">Storage may allow retaining knowledge of network state changes over time, for later analysis into cyclical heuristic prediction of near-future network state changes.</span></li></ul><ul class=\"c4 lst-kix_list_12-5\"><li class=\"c7\"><span class=\"c0\">A modern data-center hardware router with diverse connection link types could simultaneously handle multiple ISS overlay meshes, matching "best-fit" CoS metrics to each packet QoS by mesh scale and link medium capability.</span></li></ul><ul class=\"c4 lst-kix_list_e-3\"><li class=\"c3\"><span class=\"c0\">Smart nodes can choose to fork routing jobs off to dumber sub-processes and neighbor nodes, depending on current local traffic loads, to minimize latency.</span></li><li class=\"c3\"><span class=\"c0\">Video game AI navigation principles may be useful for "limited sight" and "aggregate terrain assessment" mesh routing situations.</span></li><li class=\"c3\"><span class=\"c0\">Packets can be re/encapsulated by smartest router nodes into redirection list header packets, which provide guidance for defined dumber downstream nodes.</span></li></ul><ul class=\"c4 lst-kix_list_14-4 start\"><li class=\"c5\"><span class=\"c0\">The smartest nodes in a given path thus give directions to packets originating from nodes unfamiliar with local convex hull territory.</span></li></ul><ul class=\"c4 lst-kix_list_e-3\"><li class=\"c3\"><span class=\"c0\">Each smart route node closer to the destination node is considered to have better route "expertise," due to closer proximity to destination node connections. </span></li></ul><ul class=\"c4 lst-kix_list_15-4 start\"><li class=\"c5\"><span class=\"c0\">Mesh connection map data quality is imbued with a natural time decay, due to time-delay of state update transmissions, and higher link hop count by farther distances.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span>Encryption provided at application, transport, </span><span class=\"c13\">and </span><span class=\"c0\">link layers.</span></li><li class=\"c2\"><span class=\"c0\">Sender anonymity.</span></li></ul><ul class=\"c4 lst-kix_list_16-2 start\"><li class=\"c1\"><span class=\"c0\">Destination-only address(es) in packet headers, and encrypted packet body contents.</span></li><li class=\"c1\"><span class=\"c0\">Encrypted sender address, decrypted only at destination node.</span></li><li class=\"c1\"><span class=\"c0\">Blind response packets sent on same route where the original requesting packet was received from, in the opposite direction. </span></li></ul><ul class=\"c4 lst-kix_list_17-3 start\"><li class=\"c3\"><span class=\"c0\">No node has specific knowledge of the sender address, just the direction.</span></li><li class=\"c3\"><span class=\"c0\">Response packet alway stops at original sender node, but the sender node can pretend to send it on randomly further to avoid detection.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Receiver anonymity. </span></li></ul><ul class=\"c4 lst-kix_list_18-2 start\"><li class=\"c1\"><span class=\"c0\">Intended receiver captures packets mid-stream via intentional "overshoot" routing, and pretends to send it on. This is only possible on some trivial routes or bottlenecks.</span></li><li class=\"c1\"><span class=\"c0\">Routing given a vague direction only, with no destination address provided. </span></li></ul><ul class=\"c4 lst-kix_list_19-3 start\"><li class=\"c3\"><span class=\"c0\">This method should prepare to incur high packet losses, unless aimed at a wide area service cluster. </span></li><li class=\"c3\"><span class=\"c0\">Traffic appears similar to multicast service subscription-by-direction data.</span></li></ul><ul class=\"c4 lst-kix_list_18-2\"><li class=\"c1\"><span class=\"c0\">"Matryoshka doll" capsule route obfuscation.</span></li></ul><ul class=\"c4 lst-kix_list_1a-3 start\"><li class=\"c3\"><span class=\"c0\">Redirection list capsule packets, with key-based node receipt. </span></li><li class=\"c3\"><span class=\"c0\">Randomized excess redirection headers serve to obfuscate the true recipient, even when unencrypted.</span></li><li class=\"c3\"><span class=\"c0\">Results in destination node ignoring further redirection header entries.</span></li><li class=\"c3\"><span class=\"c0\">All but the next-closest recipient in the redirection list can be encapsulated and/or encrypted.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Dynamic node service provision and advertisement protocols. </span></li></ul><ul class=\"c4 lst-kix_list_1b-2 start\"><li class=\"c1\"><span class=\"c0\">Service ID and URI consistency handling for multi-node clustered service protocols.</span></li><li class=\"c1\"><span class=\"c0\">Service or URI contention handling via key resolution, with neutral arbiter priority assignment.</span></li><li class=\"c1\"><span class=\"c0\">Priority given to nodes in closest local convex hull mesh.</span></li><li class=\"c1\"><span class=\"c0\">Dynamic service mirror and caching-forwarder offers, primarily from nodes in web-of-trust (WoT).</span></li></ul><ul class=\"c4 lst-kix_list_1c-3 start\"><li class=\"c3\"><span class=\"c0\">Arbitrarily deep hierarchy of service forwarding and redundancy, by successive WoT member nodes. </span></li></ul><ul class=\"c4 lst-kix_list_1d-4 start\"><li class=\"c5\"><span class=\"c0\">Provides Freenet-alike service redundancy, obfuscation, and plausible deniability where desired. </span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Routing protocols are link medium agnostic, wired or wireless.</span></li></ul><ul class=\"c4 lst-kix_list_1e-2 start\"><li class=\"c1\"><span class=\"c0\">CoS metrics are tested and stored upon initial link connection. </span></li></ul><ul class=\"c4 lst-kix_list_1f-3 start\"><li class=\"c3\"><span class=\"c0\">These metrics will naturally vary on medium used, and revise over time.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">ISS-IPv4/6 gateways for "legacy" Internet communications.</span></li></ul><ul class=\"c4 lst-kix_list_20-2 start\"><li class=\"c1\"><span class=\"c0\">BGP subnet route services with "best metric" advertisements.</span></li><li class=\"c1\"><span class=\"c0\">Per-subnet CoS estimates, including wholesale bandwidth charge estimates.</span></li><li class=\"c1\"><span class=\"c0\">Expandable Storage Area Network (SAN) access on trusted ISS nodes for caching data. </span></li></ul><ul class=\"c4 lst-kix_list_21-3 start\"><li class=\"c3\"><span class=\"c0\">Cache, but never log.</span></li></ul><ul class=\"c4 lst-kix_list_20-2\"><li class=\"c1\"><span class=\"c0\">NAT traversal, and/or anonymous port state traversal. </span></li></ul><ul class=\"c4 lst-kix_list_22-3 start\"><li class=\"c3\"><span class=\"c0\">Dynamically set by each client's ISS gate portal request parameters.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">ISS-Mobile mesh gateways for mobile device communications.</span></li></ul><ul class=\"c4 lst-kix_list_23-2 start\"><li class=\"c1\"><span class=\"c0\">Mobile nodes will have different link characteristics and timing.</span></li><li class=\"c1\"><span class=\"c0\">Mobile nodes require an emphasis on client node power efficiency.</span></li><li class=\"c1\"><span class=\"c0\">Mobile nodes require efficient fixed gateway hand-off methods.</span></li><li class=\"c1\"><span class=\"c0\">Mobile mesh node links are far less reliable over time.</span></li><li class=\"c1\"><span class=\"c0\">Mobile nodes are innately wireless, and only temporarily fixed, and thus defy fixed addressing schemes.</span></li></ul><ul class=\"c4 lst-kix_list_24-3 start\"><li class=\"c3\"><span class=\"c0\">32-bit geographic point with 16-bit directed vector prediction based temporary addressing could be a viable method, with time-decay on address trust value.</span></li></ul><ul class=\"c4 lst-kix_list_23-2\"><li class=\"c1\"><span class=\"c0\">Anonymization of mobile device MAC via address translation at gateway.</span></li><li class=\"c1\"><span class=\"c0\">Mobile devices should assist hand-off and route forwarding by advertising last known gateway connection list to new gateways. </span></li><li class=\"c1\"><span class=\"c0\">Location assist via multi-gateway signal triangulation, provided only when specifically requested.</span></li><li class=\"c1\"><span class=\"c0\">Mobile devices are able to choose between nearby gateways based on known web-of-trust (WoT) ratings.</span></li><li class=\"c1\"><span class=\"c0\">Mobile devices will tend to send lots of requests to the owner's HAN via encrypted end-to-end tunnels.</span></li><li class=\"c1\"><span class=\"c0\">ISS-Mobile device ad-hoc routing may be a viable sub-project of the primary fixed ISS router project.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Multicast send protocols.</span></li></ul><ul class=\"c4 lst-kix_list_25-2 start\"><li class=\"c1\"><span class=\"c0\">Directional aggregate (anonymized) subscription (whitelist), un-subscription, and active blocking (blacklist).</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">All protocols allow time-decay based directional blocking (blacklist), to help prevent and diffuse DDoS attacks. </span></li><li class=\"c2\"><span class=\"c0\">Nearest-node route automated security assessment, via web-of-trust (WoT) rating systems, assessed per subscriber privately.</span></li></ul><ul class=\"c4 lst-kix_list_26-2 start\"><li class=\"c1\"><span class=\"c0\">Automated acceptance of a neighbor node's blacklist and whitelist settings, depends on WoT rating and distance-decay parameters.</span></li><li class=\"c1\"><span class=\"c0\">Core service acceptance and resolution (i.e. Secure DNS) depends on WoT rating, then distance.</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Cost of Service (CoS) calculations applied to each link choice in a given route.</span></li></ul><ul class=\"c4 lst-kix_list_27-2 start\"><li class=\"c1\"><span class=\"c0\">Bandwidth costing metric (data set size).</span></li><li class=\"c1\"><span class=\"c0\">Speed costing metric (latency).</span></li><li class=\"c1\"><span class=\"c0\">Security costing metric (anonymity, trust, encryption layering).</span></li><li class=\"c1\"><span class=\"c0\">Reliability costing metric (jitter, loss).</span></li><li class=\"c1\"><span class=\"c0\">Provision billing cost metric (monetary, billing, maintenance expense).</span></li></ul><ul class=\"c4 lst-kix_list_2-1\"><li class=\"c2\"><span class=\"c0\">Some QoS reliability requirements handled via parity-encoded and striped data sent over multiple parallel routes in dense meshes.</span></li></ul><ul class=\"c4 lst-kix_list_28-2 start\"><li class=\"c1\"><span class=\"c0\">Redundant Array of Inexpensive Routes (RAIR). RAIR# ~= RAID#</span></li></ul><ul class=\"c4 lst-kix_list_29-3 start\"><li class=\"c3\"><span class=\"c0\">RAIR0: Split data over multiple parallel routes.</span></li><li class=\"c3\"><span class=\"c0\">RAIR1: Mirror data over 2 or more routes.</span></li><li class=\"c3\"><span class=\"c0\">RAIR3: Stripe data over multiple parallel routes, with a dedicated parity route.</span></li></ul><ul class=\"c4 lst-kix_list_2a-4 start\"><li class=\"c5\"><span class=\"c0\">(Probably only useful when one route is consistently more reliable than the others)</span></li></ul><ul class=\"c4 lst-kix_list_29-3\"><li class=\"c3\"><span class=\"c0\">RAIR5: Stripe data over multiple parallel routes, with parity data on a different route each stream segment.</span></li><li class=\"c3\"><span class=\"c0\">RAIR6: Stripe data over multiple parallel routes, with redundant parity data on 2 or more different routes.</span></li><li class=\"c3\"><span class=\"c0\">Combine 2 of the above for obvious desirable effects -- best akin to RAID10, RAID50, or RAID60.</span></li><li class=\"c3\"><span class=\"c0\">Increase total redundant parity or mirror route paths based on packet loss increases.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Data Roads Scholarship</span></li></ul><ul class=\"c4 lst-kix_list_2b-1 start\"><li class=\"c2\"><span class=\"c0\">Awards for best research in people-centric networking.</span></li><li class=\"c2\"><span class=\"c0\">ISS Killer-app contests.</span></li><li class=\"c2\"><span class=\"c0\">Only awarded for open source, open standards, and openly accessible research.</span></li><li class=\"c2\"><span class=\"c0\">If any patents are allowed, all patents must be assigned to the Foundation and pooled defensively.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Grant programs for regional Internet Service Cooperatives.</span></li></ul><ul class=\"c4 lst-kix_list_2c-1 start\"><li class=\"c2\"><span class=\"c0\">Grantees must use some form of stable ISS routing on their network, and provide testing nodes.</span></li><li class=\"c2\"><span class=\"c0\">Grantee upstream providers must use open access, non-discriminatory, and wholesale provision (whenever a choice is possible).</span></li><li class=\"c2\"><span class=\"c0\">Grantees must take a basic oath of service.</span></li><li class=\"c2\"><span class=\"c0\">Low income membership subsidies, only in certified Grantee Cooperatives' regions.</span></li><li class=\"c2\"><span class=\"c0\">Give-one Get-one (GOGO) style hardware distribution.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Spin off (subsidiary or independent 501(c)(4)): American Data Drivers' Club</span></li></ul><ul class=\"c4 lst-kix_list_2d-1 start\"><li class=\"c2\"><span class=\"c0\">Analogous to Automobile Clubs, except this club is for servicing and maintaining "data driving equipment."</span></li><li class=\"c2\"><span class=\"c0\">No member has to be a networking or computer expert, because the club provides all needed expertise.</span></li><li class=\"c2\"><span class=\"c0\">The club is paid only to work in the club members' best interests. All club members have a democratic vote.</span></li><li class=\"c2\"><span class=\"c0\">Rate, certify, and recommend "network mechanics."</span></li></ul><ul class=\"c4 lst-kix_list_2e-2 start\"><li class=\"c1\"><span class=\"c0\">Certified and branded partners take an oath of service.</span></li></ul><ul class=\"c4 lst-kix_list_2d-1\"><li class=\"c2\"><span class=\"c0\">Partner exclusively with independent mechanics and open access or non-profit network providers.</span></li><li class=\"c2\"><span class=\"c0\">Enforce service transparency requirements, on behalf of club members.</span></li><li class=\"c2\"><span class=\"c0\">Discounts and promotion programs.</span></li><li class=\"c2\"><span class=\"c0\">Travel related foreign network access provision.</span></li><li class=\"c2\"><span class=\"c0\">Brokerage for ancillary services.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Spin off (subsidiary, independent 501(c)(4), or international group): Data Driver's Club Federation</span></li></ul><ul class=\"c4 lst-kix_list_2f-1 start\"><li class=\"c2\"><span class=\"c0\">Consolidate services shared between regional Data Driver's Clubs, perhaps even internationally.</span></li><li class=\"c2\"><span class=\"c0\">Member clubs must pay administrative dues, pass shared certifications, and take an oath of service.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Spin off (subsidiary or independent 501(c)(12)): National Network Cooperative</span></li></ul><ul class=\"c4 lst-kix_list_30-1 start\"><li class=\"c2\"><span class=\"c0\">IPv4, IPv6, and ISS transit over a national long-range backbone mesh.</span></li><li class=\"c2\"><span class=\"c0\">Advisory bodies. </span></li><li class=\"c2\"><span class=\"c0\">Shared services provision. </span></li><li class=\"c2\"><span class=\"c0\">All downstream Cooperative member organizations must take oath.</span></li></ul><ul class=\"c4 lst-kix_list_31-2 start\"><li class=\"c1\"><span class=\"c0\">Service transparency.</span></li><li class=\"c1\"><span class=\"c0\">Resident open access (timeline provided at minimum).</span></li><li class=\"c1\"><span class=\"c0\">Network neutrality provisions.</span></li></ul><ul class=\"c4 lst-kix_list_1-0\"><li class=\"c12\"><span class=\"c0\">Spin off (international organization): International Network Cooperative</span></li></ul><ul class=\"c4 lst-kix_list_32-1 start\"><li class=\"c2\"><span class=\"c0\">IPv4, IPv6, and ISS transit over an international world-wide backbone mesh.</span></li><li class=\"c2\"><span class=\"c0\">Members comprised of various National Network Cooperatives.</span></li><li class=\"c2\"><span class=\"c0\">Possible cross-over projects with ICANN and IETF, but much more oriented toward bottom-up member control and negotiation of the world-wide ISS mesh links.</span></li></ul><ul class=\"c4 lst-kix_list_33-2 start\"><li class=\"c1\"><span class=\"c0\">Much less central control of ISS network assignments and service deployment methods. </span></li></ul><ul class=\"c4 lst-kix_list_32-1\"><li class=\"c2\"><span class=\"c0\">ISS networks are defined by their use of ISS routing methods, not by organization membership.</span></li><li class=\"c2\"><span class=\"c0\">All downstream Cooperative member organizations must take oath.</span></li></ul><ul class=\"c4 lst-kix_list_34-2 start\"><li class=\"c1\"><span class=\"c0\">Membership and service transparency.</span></li><li class=\"c1\"><span class=\"c0\">Non-discriminatory open access to membership who are willing to take a similar oath (timeline provided at minimum).</span></li><li class=\"c1\"><span class=\"c0\">Network neutrality provisions.</span></li></ul><p class=\"c8\"><span class=\"c0\"></span></p>"
}
]
}
]
}
}