diff --git a/ack.rst b/ack.rst
deleted file mode 100644
index 05d3daf..0000000
--- a/ack.rst
+++ /dev/null
@@ -1,5 +0,0 @@
-Acknowledgment
---------------
-
-This NDN packet format specification is adapted from the CCNx specification described in `<http://www.ccnx.org/releases/latest/doc/technical/index.html>`_ as of October 2013.
-However we have made a number of packet format changes based on our deepened understanding about NDN design through experimentation with NDN over the last three years, and based on the inputs from NDN research community at large. In particular, this specification adopted a TLV encoding format that has been championed by cisco NDN project team.  We list the major protocol format changes from the CCNx specification at the end of each section.
diff --git a/conf.py b/conf.py
index 0a778ce..039bfb0 100644
--- a/conf.py
+++ b/conf.py
@@ -50,7 +50,7 @@
 # The short X.Y version.
 version = '0.2'
 # The full version, including alpha/beta/rc tags.
-release = '0.2-alpha-3'
+release = '0.2-alpha-4'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.
diff --git a/data.rst b/data.rst
index b06d4f1..c6b4d59 100644
--- a/data.rst
+++ b/data.rst
@@ -32,21 +32,6 @@
                    FreshnessPeriod?
                    FinalBlockId?
 
-Compared with CCNx, three fields are removed: PublisherPublicKeyDigest, ExtOpt, and Timestamp for the following reasons.
-
-
-- PublisherPublicKeyDigest is supposed to be used in selecting data packets signed by a particular key.
-  We replace PublisherPublicKeyDigest with KeyLocator, which is part of the Signature block (see :ref:`Signature Section <Signature>`), due to the following consideration.
-  First, PublisherPublicKeyDigest requires data consumer to acquire a *valid* public key, as opposed to the key locator, before sending the Interest out.
-  Second, if a router is to verify the content objects, it must have other means to locate the keys first.
-  Further, PublisherPublicKeyDigest may require publishers to maintain their public keys and certificates by their public key digests instead of names.
-
-- ExtOpt was intended for extending XML-based ccnb format.  Since we are now using TLV, ExtOpt is no longer needed.
-
-- Timestamp can be useful meta information for applications, but does not need to be processed at the network layer.
-  Therefore, if desired, applications should encode such meta information as part of the content.
-
-
 ContentType
 +++++++++++
 
@@ -70,11 +55,6 @@
 | NACK            | 3              | application-level NACK                                       |
 +-----------------+----------------+--------------------------------------------------------------+
 
-Compared with CCNx, ENCR and GONE types are removed.
-ENCR means the content is encrypted, and since the network layer should not care whether content is encrypted or not, this type is not needed.
-GONE was a placeholder for implementing cache purging, however the research is yet to be carried out on how to accomplish this goal, if it is feasible to achieve, it is not included in this version of NDN specification.
-
-
 FreshnessPeriod
 +++++++++++++++
 
diff --git a/index.rst b/index.rst
index cbe426d..1fb1b6e 100644
--- a/index.rst
+++ b/index.rst
@@ -4,7 +4,6 @@
 
 
 .. toctree::
-   ack
    intro
    tlv
    name
diff --git a/intro.rst b/intro.rst
index 9659c85..3acb3f9 100644
--- a/intro.rst
+++ b/intro.rst
@@ -1,18 +1,20 @@
 Introduction
 ------------
 
-This version 0.1 specification aims to describe the NDN packet format only, a much narrower scope than a full NDN protocol specification. Our plan is to circulate and finalize the packet format first, then write down the full protocol specification. 
+This version of specification aims to describe the NDN packet format only, a much narrower scope than a full NDN protocol specification.
+Full protocol specification will be published as a separate document.  For more information about the overall protocol refer to `"Named Data Networking" by Lixia Zhang, Alexander Afanasyev, Jeffrey Burke, Van Jacobson, kc claffy, Patrick Crowley, Christos Papadopoulos, Lan Wang, and Beichuan Zhang, ACM SIGCOMM Computer Communication Review (CCR), July 2014.`__ and other publications on `Named Data Networking website <https://named-data.net>`__.
 
-In addition to this protocol specification draft, we are also in the process of putting out a set of technical memos that document our reasoning behind the design choices of important issues.  The first few to come out will address the following issues:
+In addition to the packet format and full protocol specification, we have published a set of technical memos and papers that explain the reasoning behind the design choices:
 
-- Packet fragmentation: end-to-end versus hop-by-hop;
+- `NDN Protocol Design Principles <https://named-data.net/project/ndn-design-principles/>`__
 
-- Understanding the tradeoffs of (not) handling Interest selectors;
+- `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
 
-- NDN Name discovery: why do we need it?
+- `"SNAMP: Secure Namespace Mapping to Scale NDN Forwarding" by Alexander Afanasyev, Cheng Yi, Lan Wang, Beichuan Zhang, and Lixia Zhang, 18th IEEE Global Internet Symposium, April 2015 <http://named-data.net/publications/snamp-ndn-scalability/>`__
 
-- NDN naming convention; and
+- `"NDN Technical Memo: Naming Conventions" by NDN Project Team. NDN, Technical Report NDN-0022 <http://named-data.net/publications/techreports/ndn-tr-22-ndn-memo-naming-conventions/>`__
 
-- Scaling NDN routing.
+Acknowledgment
+--------------
 
-In the rest of the document, we assume readers are familiar with how NDN/CCN works in general. For a description of the current CCNx protocol definition, please refer to `<http://www.ccnx.org/releases/latest/doc/technical/CCNxProtocol.html>`_.
+This NDN packet format specification is evolution of the `CCNx 0.7.2 specification <https://github.com/named-data/ndnx/releases/tag/ccnx-0.7.2-ndn-1>`_ as of May 2013.
diff --git a/tlv.rst b/tlv.rst
index 0182f36..1564d8f 100644
--- a/tlv.rst
+++ b/tlv.rst
@@ -9,7 +9,7 @@
 There is also no packet fragmentation support at network level.
 Whenever needed, NDN packets may be fragmented and reassembled hop-by-hop. [#f1]_
 
-.. [#f1] Today's IP networks provide point-to-point packet delivery and perform end-to-end fragmentation. An NDN network, on the other hand, may fetch requested data from any in-network storage, thus the notion of data flowing along an end-to-end path does not apply.
+.. [#f1] `"Packet Fragmentation in NDN: Why NDN Uses Hop-By-Hop Fragmentation (NDN Memo)" by A. Afanasyev, J. Shi, L. Wang, B. Zhang, and L. Zhang., NDN Memo, Technical Report NDN-0032 <http://named-data.net/publications/techreports/ndn-0032-1-ndn-memo-fragmentation/>`__
 
 Variable Size Encoding for type (T) and length (L)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -90,16 +90,14 @@
 
 
 TLV-TYPE SHOULD be unique at all nested levels.
-The TLV Type number space and initial assignments will be specified in the later revision of the current document.
-NDN packet design will try best to keep the length of T staying with a single byte.
+The TLV Type number space and initial assignments listed in Section :ref:`types` of this document.
 
 The ``TLV-LENGTH`` value represents number of bytes that ``TLV-VALUE`` uses.
 It **does not** include number of bytes that ``TLV-TYPE`` and ``TLV-LENGTH`` fields themselves occupy.
 In particular, empty payload TLV will carry ``TLV-LENGTH`` equal to 0.
 
-
 This encoding offers a reasonable balance between compactness and flexibility.
-Most common, standardized Type codes will be allocated from a small-integer number-space, and these common Types will be able to use the compact, single-byte encoding.
+Most common, standardized Type codes will be allocated from a small-integer number-space, and these common types will be able to use the compact, single-byte encoding.
 
 Non Negative Integer Encoding
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~