Just adding more and more files

.gitignore

@@ -0,0 +1 @@
+*~

FAQ.md

@@ -1,27 +1,62 @@
 # Frequently Asked Questions
 
-## Focus
+## "Focus on IPv6!"
 
-## It will take too long
+The trivial amount of effort required to improve IPv4 pales in comparison
+to the amount of effort to make IPv6 universal.
 
-## These addresses will never work
+## "It will take too long to deploy!"
 
-## We could allocate all these addresses
+Any rational assessment of IPv4's continued existence stretches out
+another 20 years, or longer. 
 
-## IPv6
+Increasing the amount of even semi-usable IPv4 addresses better
+enables innovation and newcomers to the field, to at least "get
+something" on IPv4 when it would otherwise be cost prohibitive or
+impossible.
 
-## Class-E is easy
+## "These addresses will never work globally"
 
-## globally routable
+They won't unless we try. They already work fine with the patchsets we
+have on linux, freebsd, & osx, on a local lan, in tunnels, and via the two major routing daemons we've patched, and nearly every IOT OS we've tried.
 
-why try to make 0/8 and 240/4 globally routable
+## "We could allocate all these addresses in a year!"
 
-any attempt stumbles on the fact that manufacturers, users need to be
-incented to - some piece of gear will inevitably not allow ipv4 addresses
-in this range unless a standard exists. 
+If "normal" IPv4 allocation policies were followed, yes. However:
 
-Limited use IPv4 address spaces 
+* A market is emerging for "regular" IPv4 addresses to be reallocated.
+
+* As semi-useless addresses, these can be addresses of "last resort" when IPv6 is the primary transport and IPv4 is only the backup. Think of this as the reverse of "happy eyeballs", in the long term.
+
+## "IPv6 is better! Just use that!"
+
+IPv4 is universal, moreover, IPv4 is needed everywhere IPv6 hasn't
+quite deployed. Wherever IPv6 coverage cracks 100%, IPv6 should
+certainly be used. We certainly applaud every attempt to make
+IPv6 more generally available.
+
+## "Class-E is easy!"
+
+It is.
+
+So far in our testing, technically, extending IPv4 systems to do Class E (240/4), 0/8, 127/8, and taking out chunks of multicast is a few very short patches.
+
+There is a huge installed base of course, but the majority of the billions of systems to be deployed in the future already "just work" with 240/4, it's just a few cleanups and pieces of infrastructure that need fixes. Doing the other address ranges is also a matter of trivial fixes that can take place at the
+same time, as part of the same effort.
+
+## Why try to make 0/8 and 240/4 globally routable?
+
+Any attempt to make these address ranges fully usable stumbles on the
+fact that manufacturers, data centers, ISPs, corporations, and users
+need to be incented to support them. Some piece of gear will
+inevitably not allow ipv4 addresses in this range unless a formal, and
+not just defacto, standard also exists.
+
+Plenty of limited use IPv4 address spaces exist - not just RFC1918,
+but CGN networks are wildly popular.
+
+As a totally new address range, making class-e in particular globally
+routable makes it more possible to address other long-standing bugs in
+ipv4 implementations like [zeroth networks](ZEROTH), attempt to make
+more protocols available through NAT (such as udp-lite, sctp), 
 
-Making class-e in particular globally routable makes it more possible
-to address other long-standing bugs in ipv4 implementations like zeroth
-networks, 

PEOPLE.md

@@ -0,0 +1,10 @@
+# Participants
+
+## John Gilmore
+
+## Dave Taht
+
+## Paul Wouters
+
+## Rob Landley
+

ZERO.md

@@ -0,0 +1,2 @@
+# 0.0.0.0/8
+

ZEROTH.md

@@ -6,15 +6,9 @@ Is generally restricted to
 
 made in the early 80s, that made 0 the broadcast address in BSD 4.3. BSD
 4.3 has long since been retired and we know of no operating system made
-in the last 3 decades that uses '0' for broadcast. 
+in the last 3 decades that uses '0' for broadcast. Why continue restricting it?
 
-finding and eliminating the last remaining vestiges of zeroth
+Finding and eliminating the last remaining vestiges of zeroth problems. So far, the "zeroth" problem, is generally limited to some variant "ping", where an attempt to ping the zeroth network address still results in "Did you want to ping broadcast? use -b to specify".
 
-Is generally limited to "ping", where an attempt to ping the zeroth
-network address still results in 
+So: fixing ping is not a problem: patches
 
-fixing ping is not a problem: patches
-
-Any rational assessment of IPv4's continued existence stretches out
-another 20 years.
-That by increasing the range of usable ipv4 addresses

rfcs/Makefile

@@ -0,0 +1,21 @@
+SOURCE=draft-ietf-aqm-fq-codel-xx.mkd
+
+title=$(shell grep 'docname: ' $(SOURCE) | sed 's/docname: //')
+
+objects=draft-ietf-aqm-fq-codel-??.{xml,html,txt}
+
+all: $(title).html $(title).txt
+
+
+$(title).xml: $(SOURCE)
+	kramdown-rfc2629 $(SOURCE) > $(title).xml
+
+$(title).html: $(title).xml
+	xml2rfc $(title).xml --html
+
+$(title).txt: $(title).xml
+	xml2rfc $(title).xml --text
+
+.PHONY: clean
+clean:
+	rm -f $(objects)