Improve the document structure in several places

Change-Id: Icea6d0b0d9628eb171f5673b397f1db7f1c5c5b8
diff --git a/tlv.rst b/tlv.rst
index 7047d36..060ea57 100644
--- a/tlv.rst
+++ b/tlv.rst
@@ -14,17 +14,21 @@
 Variable Size Encoding for Type (T) and Length (L)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-(Both the text below and that in :ref:`TLV encoding section <TLV>` are adopted from an earlier packet specification draft by Mark Stapp)
+.. note::
+   The text below and that in the :ref:`TLV` section are adapted from an earlier packet specification draft by Mark Stapp.
 
 To minimize the overhead during early deployment and to allow flexibility of future protocol extensions to meet unforeseeable needs, both type (T) and length (L) take a variable size format.
 For implementation simplicity, both type and length take the same encoding format.
 
 We define a variable-length encoding for numbers in NDN as follows::
 
-     VAR-NUMBER-1 = %x00-FC
-     VAR-NUMBER-3 = %xFD 2OCTET
-     VAR-NUMBER-5 = %xFE 4OCTET
-     VAR-NUMBER-9 = %xFF 8OCTET
+    VAR-NUMBER-1 = %x00-FC
+    VAR-NUMBER-3 = %xFD 2OCTET
+    VAR-NUMBER-5 = %xFE 4OCTET
+    VAR-NUMBER-9 = %xFF 8OCTET
+
+.. note::
+   The formal grammar of NDN packet format in this specification is given using :rfc:`Augmented BNF for Syntax Specifications <5234>`.
 
 The first octet of the number either carries the actual number, or signals that a multi-octet encoding is present, as defined below:
 
@@ -42,9 +46,6 @@
 A number MUST be encoded in the shortest format.
 For example, the number 1024 is encoded as %xFD0400 in VAR-NUMBER-3 format, not %xFE00000400 in VAR-NUMBER-5 format.
 
-.. note::
-   The formal grammar of NDN packet format in this specification is given using `Augmented BNF for Syntax Specifications <https://tools.ietf.org/html/rfc5234>`__
-
 .. _TLV:
 
 NDN TLV Encoding
@@ -109,6 +110,7 @@
 - TLV-TYPE numbers 0-31 (inclusive) are "grandfathered" and are all designated as "critical" for the purposes of packet processing.
 
 .. note::
-    A recognized element is considered out-of-order if it appears in the element order that violates a specification.  For example,
-    - when a specification defines a sequence {``F1`` ``F2`` ``F3``}, an element ``F3`` would be out-of-order in the sequence {``F1`` ``F3`` ``F2``};
-    - for {``F1`` ``F2?`` ``F3``} specification (i.e., when ``F2`` is optional, ``F2`` would be out-of-order in the same sequence {``F1`` ``F3`` ``F2``}.
+   A recognized element is considered out-of-order if it appears in the element order that violates a specification. For example:
+
+   - when a specification defines a sequence {``F1`` ``F2`` ``F3``}, an element ``F3`` would be out-of-order in the sequence {``F1`` ``F3`` ``F2``};
+   - for {``F1`` ``F2?`` ``F3``} specification (i.e., when ``F2`` is optional, ``F2`` would be out-of-order in the same sequence {``F1`` ``F3`` ``F2``}.