diff --git a/i2p2www/pages/site/docs/spec/ssu.html b/i2p2www/pages/site/docs/spec/ssu.html
index 3e06f8f3eafe9ed86361413ae4f1925cade54f93..54274cf529a7b8a5dd6dfa8b0af61ad34d02e1c1 100644
--- a/i2p2www/pages/site/docs/spec/ssu.html
+++ b/i2p2www/pages/site/docs/spec/ssu.html
@@ -913,6 +913,14 @@ the message ID must be an actual random number.
 Because there are no sequence numbers, there is no way to be sure an ACK was received.
 The current implementation routinely sends a large amount of duplicate ACKs.
 Duplicate ACKs should not be taken as an indication of congestion.
+</li><li>
+ACK Bitfield notes:
+The receiver of a data packet does not know how many fragments are in the message unless it has
+received the last fragment. Therefore, the number of bitfield bytes sent in response may be less or
+more than the number of fragments divided by 7.
+For example, if the highest fragment the receiver has seen is number 4, only
+one byte is required to be sent, even if there may be 13 fragments total.
+Up to 10 bytes (i.e. (64 / 7) + 1) may be included for each message ID acked.
 </li></ul>
 
 
diff --git a/i2p2www/pages/site/docs/transport/index.html b/i2p2www/pages/site/docs/transport/index.html
index 2814e1e0e2553803cc89e00aa66e48d60149ed5a..6f23a61e2f5edd26c78c0fcec081079960515778 100644
--- a/i2p2www/pages/site/docs/transport/index.html
+++ b/i2p2www/pages/site/docs/transport/index.html
@@ -1,7 +1,7 @@
 {% extends "global/layout.html" %}
 {% block title %}{% trans %}Transport Overview{% endtrans %}{% endblock %}
-{% block lastupdated %}{% trans %}December 2013{% endtrans %}{% endblock %}
-{% block accuratefor %}0.9.9{% endblock %}
+{% block lastupdated %}{% trans %}September 2014{% endtrans %}{% endblock %}
+{% block accuratefor %}0.9.15{% endblock %}
 {% block content %}
 <h2>{% trans %}Transports in I2P{% endtrans %}</h2>
 
@@ -39,6 +39,7 @@ Reliable delivery of <a href="{{ i2np }}">I2NP</a> messages.
 Transports support I2NP message delivery ONLY.
 They are not general-purpose data pipes.
 {%- endtrans %}</li>
+<li>{% trans %}In-order delivery of messages is NOT guaranteed by all transports.{% endtrans %}</li>
 <li>{% trans -%}
 Maintain a set of router addresses, one or more for each transport,
 that the router publishes as its global contact information (the RouterInfo).
@@ -80,6 +81,10 @@ These addresses constitute the advertised contact points, and are published by t
 Addresses may also contain an arbitrary set of additional options.
 {%- endtrans %}</p>
 
+<p>{% trans -%}
+Each transport method may publish multiple router addresses.
+{%- endtrans %}</p>
+
 <p>{% trans %}Typical scenarios are:{% endtrans %}
 <ul>
 <li>{% trans %}A router has no published addresses, so it is considered "hidden" and cannot receive incoming connections{% endtrans %}</li>
@@ -145,6 +150,7 @@ Additional transports may be developed, including:
 <ul>
 <li>{% trans %}A TLS/SSH look-alike transport{% endtrans %}</li>
 <li>{% trans %}An "indirect" transport for routers that are not reachable by all other routers (one form of "restricted routes"){% endtrans %}</li>
+<li>{% trans %}Tor-compatible pluggable transports{% endtrans %}</li>
 </ul>
 
 <p>{% trans -%}