Update all proposals to conform to the proposal process

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::
 

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::
 

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

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:
 

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:
 

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

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
 =============================
 

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

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

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

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:
 

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:
 

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

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::
 

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

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

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.

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::
 

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

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