diff --git a/i2p2www/spec/proposals/001-process.rst b/i2p2www/spec/proposals/001-process.rst
index 6fd6800b95d3fb40e489cbc9316b0a856ad36196..400007dfe5805ad77a7d750d60532ad299c7d5f4 100644
--- a/i2p2www/spec/proposals/001-process.rst
+++ b/i2p2www/spec/proposals/001-process.rst
@@ -6,7 +6,7 @@ The I2P Proposal Process
     :created: 2016-04-10
     :thread: http://zzz.i2p/topics/1980
     :lastupdated: 2016-04-10
-    :status: Draft
+    :status: Meta
 
 .. contents::
 
diff --git a/i2p2www/spec/proposals/100-restricted-routes.rst b/i2p2www/spec/proposals/100-restricted-routes.rst
index 0c7e90ce4f6a41cd710260bfc6b562442ee632d2..99ac670dd16bd866e472b79cc259cdfc55df2830 100644
--- a/i2p2www/spec/proposals/100-restricted-routes.rst
+++ b/i2p2www/spec/proposals/100-restricted-routes.rst
@@ -6,7 +6,7 @@ Restricted Routes
     :created: 2008-09-14
     :thread: http://zzz.i2p/topics/114
     :lastupdated: 2008-10-13
-    :status: Draft
+    :status: Reserve
 
 .. contents::
 
diff --git a/i2p2www/spec/proposals/101-multicast.rst b/i2p2www/spec/proposals/101-multicast.rst
index 9de714ff50954bc207301a153b24b4dcafbbcd4c..9917359f3d03f74b7d4ebed478eb528e3ec58eb6 100644
--- a/i2p2www/spec/proposals/101-multicast.rst
+++ b/i2p2www/spec/proposals/101-multicast.rst
@@ -6,20 +6,20 @@ Multicast
     :created: 2008-12-08
     :thread: http://zzz.i2p/topics/172
     :lastupdated: 2009-03-25
-    :status: Draft
+    :status: Dead
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
 Basic idea: Send one copy through your outbound tunnel, outbound endpoint
 distributes to all the inbound gateways. End-end encryption precluded.
 
 
-Thoughts
-========
+Design
+======
 
 - New multicast tunnel message type (delivery type = 0x03)
 - Outbound endpoint multicast distribute
diff --git a/i2p2www/spec/proposals/102-service-directory.rst b/i2p2www/spec/proposals/102-service-directory.rst
index 5e890e2a2350fc4fb5e1b22c9fe01ac9bdde6b11..e88b1a9b710e8fd34c12ec3ef1a115f8f97ca60d 100644
--- a/i2p2www/spec/proposals/102-service-directory.rst
+++ b/i2p2www/spec/proposals/102-service-directory.rst
@@ -6,13 +6,23 @@ Service Directory
     :created: 2009-01-01
     :thread: http://zzz.i2p/topics/180
     :lastupdated: 2009-01-06
-    :status: Draft
+    :status: Rejected
+    :supercededby: 122
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is for a protocol apps could use to register and look up services
+in a directory.
+
+
+Motivation
+==========
+
+The most straightforward way to support onioncat is with a service directory.
 
 This is similar to a proposal Sponge had a while back on IRC. I don't think he
 wrote it up, but his idea was to put it in the netDb. I'm not in favor of that,
@@ -23,8 +33,8 @@ I could probably hack this up pretty quickly using HTTP and the collection of
 perl scripts I use for the add key form.
 
 
-Directory Interface
-===================
+Specification
+=============
 
 Here's how an app would interface with the directory:
 
diff --git a/i2p2www/spec/proposals/103-bigger-i2np-messages.rst b/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
index 9b84e5003ddb7c6a36780e962811117d7e23097b..539b544603d3430f762ae88b41109e4f90b4a9d5 100644
--- a/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
+++ b/i2p2www/spec/proposals/103-bigger-i2np-messages.rst
@@ -6,20 +6,26 @@ Bigger I2NP Messages
     :created: 2009-04-05
     :thread: http://zzz.i2p/topics/258
     :lastupdated: 2009-05-27
-    :status: Draft
+    :status: Dead
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about increasing the size limit on I2NP messages.
+
+
+Motivation
+==========
 
 iMule's use of 12KB datagrams exposed lots of problems. The actual limit today
 is more like 10KB.
 
 
-Thoughts
-========
+Design
+======
 
 To do:
 
diff --git a/i2p2www/spec/proposals/104-tls-transport.rst b/i2p2www/spec/proposals/104-tls-transport.rst
index c9128d07ef693c9e86e491ed566ef4e8c5569079..b3c86d15675092ebe83f0b35a49dcd6ff395ec27 100644
--- a/i2p2www/spec/proposals/104-tls-transport.rst
+++ b/i2p2www/spec/proposals/104-tls-transport.rst
@@ -11,8 +11,14 @@ TLS Transport
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing a TLS-based transport.
+
+
+Motivation
+==========
 
 It's a frequently-suggested-suggestion that we have a snoop-resistant transport
 so that we are resistant to fingerprinting and blocking by ISPs and state-level
@@ -20,7 +26,7 @@ adversaries, like what Tor has (i.e. tries to look like a Firefox HTTPS
 session).
 
 
-Proposal
-========
+Design
+======
 
 TBD
diff --git a/i2p2www/spec/proposals/105-garlicat-name-translation.rst b/i2p2www/spec/proposals/105-garlicat-name-translation.rst
index 2a2ce6131be7b8a3f36b369ad1c0baab6e19784f..45c2fea1367b547dc8f3b0e4726c613cf8e664dc 100644
--- a/i2p2www/spec/proposals/105-garlicat-name-translation.rst
+++ b/i2p2www/spec/proposals/105-garlicat-name-translation.rst
@@ -6,11 +6,17 @@ Name Translation for GarliCat
     :created: 2009-12-04
     :thread: http://zzz.i2p/topics/453
     :lastupdated: 2009-12-04
-    :status: Draft
+    :status: Dead
 
 .. contents::
 
 
+Overview
+========
+
+This proposal is about adding support for DNS reverse lookups to I2P.
+
+
 Current Translation Mechanism
 =============================
 
diff --git a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst b/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
index 72704e416e95885c8ca3513f99d7283f742139d9..ab9dafe902f6433e9d16da02cfa22fbd54d4e399 100644
--- a/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
+++ b/i2p2www/spec/proposals/106-ntcp-obfuscation.rst
@@ -12,8 +12,15 @@ NTCP Obfuscation
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about overhauling the NTCP transport to improve its resistance
+to automated identification.
+
+
+Motivation
+==========
 
 NTCP data is encrypted after the first message (and the first message appears to
 be random data), thus preventing protocol identification through "payload
diff --git a/i2p2www/spec/proposals/107-bep9-information-recovery.rst b/i2p2www/spec/proposals/107-bep9-information-recovery.rst
index 553002aebbed0972640c9681cadd30030f7be7d8..b60c75de5158deda7f9d30a1c4329e5be1a16983 100644
--- a/i2p2www/spec/proposals/107-bep9-information-recovery.rst
+++ b/i2p2www/spec/proposals/107-bep9-information-recovery.rst
@@ -6,13 +6,20 @@ BEP9 Information Recovery
     :created: 2011-02-23
     :thread: http://zzz.i2p/topics/860
     :lastupdated: 2011-02-23
-    :status: Draft
+    :status: Dead
 
 .. contents::
 
 
-Problem
-=======
+Overview
+========
+
+This proposal is about adding full information recovery to I2P's implementation
+of BEP9.
+
+
+Motivation
+==========
 
 BEP9 does not send the entire torrent file, thus losing several important
 dictionary items, and changes the torrent files total SHA1. This is bad for
diff --git a/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst b/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
index f656a8619ee51b7bd9beba3030b41fdab5e2086a..1fbdd2e05b3fd7a6ec86f24b5fdf826ad74c08cd 100644
--- a/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
+++ b/i2p2www/spec/proposals/108-multipath-tcp-for-streaming.rst
@@ -11,8 +11,15 @@ Multipath TCP for Streaming
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about extending streaming to use multiple tunnels per
+connection, similar to multipath TCP.
+
+
+Motivation
+==========
 
 Client tunnels are used by the streaming lib in a fairly standard TCP manner.
 
@@ -24,7 +31,7 @@ tunnels are used based on individual characteristics like:
 - Availability
 
 
-Proposal
-========
+Design
+======
 
 TBD
diff --git a/i2p2www/spec/proposals/109-pt-transport.rst b/i2p2www/spec/proposals/109-pt-transport.rst
index 44ac53428ffc13c9baf1b708481433c79f9c62be..9a91e4d06e2e7624b0bab9a13ff1404e8f741789 100644
--- a/i2p2www/spec/proposals/109-pt-transport.rst
+++ b/i2p2www/spec/proposals/109-pt-transport.rst
@@ -6,21 +6,32 @@ PT Transport
     :created: 2014-01-09
     :thread: http://zzz.i2p/topics/1551
     :lastupdated: 2014-09-28
-    :status: Draft
+    :status: Open
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
-The general idea is to use Pluggable Transports (PTs) as an I2P transport for
-communication between routers. It would be an easy way to experiment with
-alternative protocols, and get ready for I2P blocking resistance.
+This proposal is for creating an I2P transport that connects to other routers
+through Pluggable Transports.
 
 
-Thoughts
-========
+Motivation
+==========
+
+Pluggable Transports (PTs) were developed by Tor as a way to add obfuscation
+transports to Tor bridges in a modular way.
+
+I2P already has a modular transport system that decreases the barrier to adding
+alternative transports. Adding support for PTs would provide I2P with an easy
+way to experiment with alternative protocols, and get ready for blocking
+resistance.
+
+
+Design
+======
 
 There are a few potential layers of implementation:
 
diff --git a/i2p2www/spec/proposals/110-leaseset-2.rst b/i2p2www/spec/proposals/110-leaseset-2.rst
index 16150ea73319d2feb1f0637ae7a70efc14883fe0..73cbd6113e68032b8689c7a07097644a1bdfcc92 100644
--- a/i2p2www/spec/proposals/110-leaseset-2.rst
+++ b/i2p2www/spec/proposals/110-leaseset-2.rst
@@ -6,13 +6,21 @@ LeaseSet 2
     :created: 2014-01-22
     :thread: http://zzz.i2p/topics/1560
     :lastupdated: 2016-04-04
-    :status: Draft
+    :status: Rejected
+    :supercededby: 123
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about a new LeaseSet format with support for newer encryption
+types.
+
+
+Motivation
+==========
 
 The end-to-end cryptography used through I2P tunnels has separate encryption and
 signing keys. The signing keys are in the tunnel Destination, which has already
@@ -27,8 +35,8 @@ will be guaranteed to have support for any encryption types introduced alongside
 it.
 
 
-Format
-======
+Specification
+=============
 
 The basic LS2 format would be like this:
 
diff --git a/i2p2www/spec/proposals/111-ntcp-2.rst b/i2p2www/spec/proposals/111-ntcp-2.rst
index c052a2354ab4bdfd5580bc8e5b256528989f9c07..b69bff060249f19b78a02122284de9af28c67aa9 100644
--- a/i2p2www/spec/proposals/111-ntcp-2.rst
+++ b/i2p2www/spec/proposals/111-ntcp-2.rst
@@ -6,14 +6,21 @@ NTCP 2
     :created: 2014-02-13
     :thread: http://zzz.i2p/topics/1577
     :lastupdated: 2014-09-21
-    :status: Draft
+    :status: Open
     :supercedes: 106
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about overhauling the NTCP transport to improve its resistance
+to various forms of automated identification and attacks.
+
+
+Motivation
+==========
 
 NTCP data is encrypted after the first message (and the first message appears to
 be random data), thus preventing protocol identification through "payload
@@ -25,8 +32,8 @@ By adding random amounts of random data to each of the messages, we can make it
 a lot harder.
 
 
-Goals
-=====
+Design Goals
+============
 
 - Support NTCP 1 and 2 on a single port, auto-detect.
 - Add random padding to all NTCP messages including handshake and data messages
diff --git a/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst b/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
index 5e3a683129401ec46f30b0184563798a6412f15f..fd2409f4b682793f0f58ede45af78abf9eeeb4fe 100644
--- a/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
+++ b/i2p2www/spec/proposals/112-addressbook-subscription-feed-commands.rst
@@ -6,7 +6,7 @@ Addressbook Subscription Feed Commands
     :created: 2014-09-15
     :thread: http://zzz.i2p/topics/1704
     :lastupdated: 2016-04-17
-    :status: Draft
+    :status: Open
 
 .. contents::
 
diff --git a/i2p2www/spec/proposals/113-leaseset-key-persistence.rst b/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
index 03882b6bc22d77d6578bb084b8fd9246432c3134..19624e578fa9e5c31ee78c3d0977a5b3c2064ad5 100644
--- a/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
+++ b/i2p2www/spec/proposals/113-leaseset-key-persistence.rst
@@ -11,8 +11,15 @@ LeaseSet Key Persistence
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about persisting additional data in the LeaseSet that is
+currently ephemeral.
+
+
+Motivation
+==========
 
 In 0.9.17 persistence was added for the netDb slicing key, stored in
 i2ptunnel.config. This helps prevent some attacks by keeping the same slice
diff --git a/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst b/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
index a632bce9eaa6a08833110d188f78655f453fb73a..632d717981885605f83509bd34b23b6053fea485 100644
--- a/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
+++ b/i2p2www/spec/proposals/114-encrypted-streaming-flag.rst
@@ -6,19 +6,26 @@
     :created: 2015-01-21
     :thread: http://zzz.i2p/topics/1795
     :lastupdated: 2015-01-21
-    :status: Draft
+    :status: Needs-Research
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about adding a flag to streaming that specifies the type of
+end-to-end encryption being used.
+
+
+Motivation
+==========
 
 High-loaded apps can encounter a shortage of ElGamal/AES+SessionTags tags.
 
 
-Proposal
-========
+Design
+======
 
 Add a new flag somewhere within the streaming protocol. If a packets comes with
 this flag it means payload is AES encrypted by key from private key and peer's
diff --git a/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst b/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
index 7591b3007178ae658e6ffb7eff31229fb338a2b3..285522b6fddd189230aca5f2f124e3fba1a4b329 100644
--- a/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
+++ b/i2p2www/spec/proposals/115-batch-multiple-data-cloves-in-garlic.rst
@@ -6,15 +6,22 @@ Batch Multiple Data Cloves in Garlic
     :created: 2015-01-22
     :thread: http://zzz.i2p/topics/1797
     :lastupdated: 2015-01-22
-    :status: Draft
+    :status: Needs-Research
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about sending multiple Data Garlic Cloves inside an end-to-end
+Garlic Message, instead of just one.
+
 
+Motivation
+==========
 
+Not clear.
 
 
 Required Changes
@@ -26,9 +33,6 @@ necessary. Any batching would have to honor a max garlic size to minimize
 dropping. Perhaps 3KB? Would want to instrument things first to measure how
 often this would get used.
 
-This is backward-compatible, as the garlic receiver will already process all
-cloves it receives.
-
 
 Thoughts
 ========
@@ -43,3 +47,10 @@ uncompressible. What does this leave? I2pd doesn't currently do the x-i2p-gzip
 compression so it may help there a lot more. But stated goal of not running out
 of tags is better fixed with proper windowing implementation in his streaming
 library.
+
+
+Compatibility
+=============
+
+This is backward-compatible, as the garlic receiver will already process all
+cloves it receives.
diff --git a/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst b/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
index c2877a5f0317321d1ee256f771e2513bcb8b72b5..e4b320abac4c0e5ec793fbf30c240f71f64995c2 100644
--- a/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
+++ b/i2p2www/spec/proposals/116-prefer-near-in-keyspace.rst
@@ -6,20 +6,30 @@ Prefer Nearby Routers in Keyspace
     :created: 2015-04-25
     :thread: http://zzz.i2p/topics/1874
     :lastupdated: 2015-04-25
-    :status: Draft
+    :status: Needs-Research
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
-This is an idea to improve tunnel build success, by organizing peers so that
-they prefer connecting to other peers that are close to them in keyspace.
+This is a proposal to organize peers so that they prefer connecting to other
+peers that are close to them in keyspace.
 
 
+Motivation
+==========
+
+The idea is to improve tunnel build success, by increasing the probability that
+a router is already connected to another.
+
+
+Design
+======
+
 Required Changes
-================
+----------------
 
 This change would require:
 
@@ -29,7 +39,7 @@ This change would require:
 
 
 Advantages for Tunnel Building
-==============================
+------------------------------
 
 If you build a tunnel::
 
diff --git a/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst b/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
index 3c06c40a778a2bf4eaae63ec9c604483a82b0010..7b9cd5335acd6a1b4e7e66371e39be105af326a5 100644
--- a/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
+++ b/i2p2www/spec/proposals/117-opt-in-statistics-collection.rst
@@ -11,8 +11,15 @@ Opt-in Statistics Collection
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about an opt-in automated reporting system for network
+statistics.
+
+
+Motivation
+==========
 
 Currently there are several network parameters which have been determined by
 educated guessing. It is suspected that some of those can be tweaked to improve
@@ -20,8 +27,8 @@ the overall performance of the network in terms of speed, reliability and so on.
 However, changing them without proper research is very risky.
 
 
-Proposal
-========
+Design
+======
 
 The router supports vast collection of stats which can be used to analyze
 network-wide properties. What we need is an automated reporting system which
diff --git a/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst b/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
index a0e33821a3c3c6165e6ea70587db6bb334f1bfb5..2b3b4b79b6ef8202397d509dfeb60a76418ca378 100644
--- a/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
+++ b/i2p2www/spec/proposals/118-i2pcontrol-api-2.rst
@@ -6,15 +6,15 @@ I2PControl API 2
     :created: 2016-01-23
     :thread: http://zzz.i2p/topics/2030
     :lastupdated: 2016-02-01
-    :status: Draft
+    :status: Open
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
-This page will outline the API2 for i2pcontrol
+This proposal outlines API2 for I2PControl.
 
 
 Developer headsup!
@@ -25,8 +25,8 @@ compatibility with API1 implementations. The reasons for this is to provide
 users of >=API2 with simplest most coherent possible API.
 
 
-API 2
-=====
+API 2 Specification
+===================
 
 .. raw:: html
 
diff --git a/i2p2www/spec/proposals/119-bidirectional-tunnels.rst b/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
index 2d52af5eb46d8dcfa68aea67dbb22c8579f76823..98ea916cef3f231d9e057c392aed69b4119910f4 100644
--- a/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
+++ b/i2p2www/spec/proposals/119-bidirectional-tunnels.rst
@@ -6,32 +6,42 @@ Bidirectional Tunnels
     :created: 2016-01-07
     :thread: http://zzz.i2p/topics/2041
     :lastupdated: 2016-01-07
-    :status: Draft
+    :status: Needs-Research
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing bidirectional tunnels in I2P.
+
+
+Motivation
+==========
 
 i2pd is going to introduce bi-directional tunnels build through other i2pd
 routers only for now. For the network their will appear as regular inbound and
 outbound tunnels.
 
+
+Design
+======
+
 Goals
-=====
+-----
 
 1. Reduce network and CPU usage by reducing number of TunnelBuild messages
 2. Ability to know instantly if a participant has gone away.
 3. More accurate profiling and stats
 4. Use other darknets as intermediate peers
 
+
 Tunnel modifications
-====================
+--------------------
 
 TunnelBuild
------------
-
+```````````
 Tunnels are built the same way as inbound tunnels. No reply message is required.
 There is special type of participant called "entrance" marked by flag, serving
 as IBGW and OBEP at the same time. Message has the same format as
@@ -49,8 +59,7 @@ It will also contain field mentioning what darknet next peer belong to and some
 additional information if it's not I2P.
 
 TunnelTermination
------------------
-
+`````````````````
 If peer want to go away it creates TunnelTermination messages encrypts with
 layer key and send in "in" direction. If a participant receive such message it
 encrypts it over with it's layer key and send to next peer. Once a messsage
diff --git a/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst b/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
index faf1446273cd5d365d01663338e9b50ff9aae18c..926a1383562d319e71ffe74dea3a6859aac6c808 100644
--- a/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
+++ b/i2p2www/spec/proposals/120-meta-leaseset-for-multihoming.rst
@@ -6,13 +6,21 @@ Meta-LeaseSet for Multihoming
     :created: 2016-01-09
     :thread: http://zzz.i2p/topics/2045
     :lastupdated: 2016-01-11
-    :status: Draft
+    :status: Rejected
+    :supercededby: 123
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about implementing proper multihoming support in I2P that can
+scale up to large sites.
+
+
+Motivation
+==========
 
 Multihoming is a hack and presumably won't work for e.g. facebook.i2p at scale.
 Say we had 100 multihomes each with 16 tunnels, that's 1600 LS publishes every
@@ -24,10 +32,10 @@ would be long-lived, a lot longer than 10 minutes. So it's a two-stage lookup
 for the LS, but the first stage could be cached for hours.
 
 
-Format
-======
+Specification
+=============
 
-::
+The meat-LeaseSet would have the following format::
 
   - Destination
   - Published Time stamp
diff --git a/i2p2www/spec/proposals/121-encrypted-leaseset.rst b/i2p2www/spec/proposals/121-encrypted-leaseset.rst
index 7201ea7be1204041a470a25681d72901313d9a17..9e1443aa474bf30359b289d65c4eb91d2663757f 100644
--- a/i2p2www/spec/proposals/121-encrypted-leaseset.rst
+++ b/i2p2www/spec/proposals/121-encrypted-leaseset.rst
@@ -6,13 +6,20 @@ Encrypted LeaseSet
     :created: 2016-01-11
     :thread: http://zzz.i2p/topics/2047
     :lastupdated: 2016-01-12
-    :status: Draft
+    :status: Rejected
+    :supercededby: 123
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about redesigning the mechanism for encrypting LeaseSets.
+
+
+Motivation
+==========
 
 Current encrypted LS is horrendous and insecure. I can say that, I designed and
 implemented it.
@@ -25,22 +32,34 @@ Reasons:
 - Encryption pubkey still exposed
 
 
+Design
+======
+
 Goals
-=====
+-----
 
 - Make entire thing opaque
 - Keys for each recipient
 
 
 Strategy
-========
+--------
 
 Do like GPG/OpenPGP does. Asymmetrically encrypt a symmetric key for each
 recipient. Data is decrypted with that asymmetric key. See e.g. [RFC-4880-S5.1]_
 IF we can find an algo that's small and fast.
 
-LS2 contents
-------------
+Trick is finding an asymmetric encryption that's small and fast. ElGamal at 514
+bytes is a little painful here. We can do better.
+
+See e.g. http://security.stackexchange.com/questions/824...
+
+This works for small numbers of recipients (or actually, keys; you can still
+distribute keys to multiple people if you like).
+
+
+Specification
+=============
 
 - Destination
 - Published timestamp
@@ -52,14 +71,6 @@ LS2 contents
 
 Encrypted data could be prefixed with some enctype specifier, or not.
 
-Trick is finding an asymmetric encryption that's small and fast. ElGamal at 514
-bytes is a little painful here. We can do better.
-
-See e.g. http://security.stackexchange.com/questions/824...
-
-This works for small numbers of recipients (or actually, keys; you can still
-distribute keys to multiple people if you like).
-
 
 References
 ==========
diff --git a/i2p2www/spec/proposals/122-service-lookup.rst b/i2p2www/spec/proposals/122-service-lookup.rst
index dea004c251b41c53e0a469099db4a07bb7f054a9..30cf154f33e8154f4ad512282403d8403ef3bafe 100644
--- a/i2p2www/spec/proposals/122-service-lookup.rst
+++ b/i2p2www/spec/proposals/122-service-lookup.rst
@@ -6,17 +6,23 @@ Service Lookup
     :created: 2016-01-13
     :thread: http://zzz.i2p/topics/2048
     :lastupdated: 2016-01-13
-    :status: Draft
+    :status: Rejected
+    :supercedes: 102
+    :supercededby: 123
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
 This is the full-monty bombastic anything-goes-in-the-netdb proposal. AKA
 anycast. This would be the 4th proposed LS2 subtype.
 
+
+Motivation
+==========
+
 Say you wanted to advertise your destination as an outproxy, or a GNS node, or a
 Tor gateway, or a Bittorrent DHT or imule or i2phex or Seedless bootstrap, etc.
 You could store this information in the netDB instead of using a separate
@@ -51,8 +57,8 @@ When somebody did a lookup, they would get back a list of those records:
 Expirations would be relatively long, hours at least.
 
 
-Considerations
-==============
+Security implications
+=====================
 
 The downside is that this could turn into the Bittorrent DHT or worse. At a
 minimum, the floodfills would have to severely rate- and capacity-limit the
diff --git a/i2p2www/spec/proposals/123-new-netdb-entries.rst b/i2p2www/spec/proposals/123-new-netdb-entries.rst
index 6c93c28694a4da316782b0dcfd55b87b929c75d9..d200571ada36d05ae98e8343aeb38415997d6c9c 100644
--- a/i2p2www/spec/proposals/123-new-netdb-entries.rst
+++ b/i2p2www/spec/proposals/123-new-netdb-entries.rst
@@ -6,20 +6,21 @@ New netDB Entries
     :created: 2016-01-16
     :thread: http://zzz.i2p/topics/2051
     :lastupdated: 2016-01-16
-    :status: Draft
+    :status: Open
+    :supercedes: 110, 120, 121, 122
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
 
 This is an update and aggregation of the following 4 proposals:
 
-- LS2
-- Encrypted LS2
-- Meta LS2 for massive multihoming
-- Unauthenticated service lookup (anycasting)
+- 110 LS2
+- 120 Meta LS2 for massive multihoming
+- 121 Encrypted LS2
+- 122 Unauthenticated service lookup (anycasting)
 
 These proposals are mostly independent, but for sanity we define and use a
 common format for several of them.
diff --git a/i2p2www/spec/proposals/124-session-tags-reset-message.rst b/i2p2www/spec/proposals/124-session-tags-reset-message.rst
index 6a64863f1ab7cd66ebe2fcdc0d697f1bb3c26355..17665135bd16faa936326b75ac1e953e2dfef16f 100644
--- a/i2p2www/spec/proposals/124-session-tags-reset-message.rst
+++ b/i2p2www/spec/proposals/124-session-tags-reset-message.rst
@@ -6,13 +6,20 @@ Reset Message for ElGamal/AES+SessionTags
     :created: 2016-01-24
     :thread: http://zzz.i2p/topics/2056
     :lastupdated: 2016-01-26
-    :status: Draft
+    :status: Open
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is for an I2NP message that can be used to reset the session tags
+between two Destinations.
+
+
+Motivation
+==========
 
 Imagine some destination has bunch of confirmed tags to another destination. But
 that destination got restarted or lost these tags some other way. First
@@ -22,8 +29,11 @@ decrypt. Second destination should have a way to tell first destination to reset
 updated LeaseSet.
 
 
+Design
+======
+
 Proposed Message
-================
+----------------
 
 This new clove must contain delivery type "destination" with a new I2NP message
 called like "Tags reset" and containing sender's ident hash. It should include
@@ -33,7 +43,7 @@ Can be sent at any time if a destination can't decrypt messages.
 
 
 Usage
-=====
+-----
 
 If I restart my router and try to connect another destination, I send a clove
 with my new LeaseSet, and I would send additional clove with this message
diff --git a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
index b0dfc24855fd93af754b89d88773bffbd21e21c9..5760f3d036f315e69323b415221d889ab5d3c050 100644
--- a/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
+++ b/i2p2www/spec/proposals/125-obep-to-one-of-many-tunnels.rst
@@ -6,18 +6,32 @@ OBEP Delivery to One-of-Many Tunnels
     :created: 2016-03-10
     :thread: http://zzz.i2p/topics/2099
     :lastupdated: 2016-03-10
-    :status: Draft
+    :status: Open
 
 .. contents::
 
 
-Introduction
-============
+Overview
+========
+
+This proposal is about delegating IBGW selection to the OBEP by providing it
+with a list of alternatives instead of a single option.
+
+
+Motivation
+==========
+
+The idea is to reduce connection congestion, by giving the OBEP flexibility in
+how it connects to IBGWs.
+
 
-To reduce connection congestion, give the OBEP a list of id/hash pairs (i.e.
-leases) to deliver the message to rather than just one. The OBEP would select
-one of those to deliver to. The OBEP would select, if available, one that it is
-already connected to, or already knows about.
+Design
+======
+
+Give the OBEP a list of id/hash pairs (i.e. leases) to deliver the message to
+rather than just one. The OBEP would select one of those to deliver to. The OBEP
+would select, if available, one that it is already connected to, or already
+knows about.
 
 The originator (OBGW) would stick some (all?) of the target leases in the
 delivery instructions instead of picking just one.
@@ -25,14 +39,15 @@ delivery instructions instead of picking just one.
 This would make the OBEP-IBGW path faster and more reliable, and reduce overall
 network connections.
 
-Proposal
-========
-
 We have one unused delivery type (0x03) and two remaining bits 0 and 1) in the
 flags. Because we've previously discussed multicast at the OBEP (deliver to all
 specified leases), we could plan for that feature as well at the same time.
 
-So the specification proposal is::
+
+Specification
+=============
+
+::
 
   Flag byte:
     Delivery type 0x03: count byte and multiple id/hash pairs follow