Cleanups
authorPavel Šimerda <pavlix@pavlix.net>
Wed, 23 May 2012 16:22:23 +0000 (18:22 +0200)
committerPavel Šimerda <pavlix@pavlix.net>
Wed, 23 May 2012 16:23:06 +0000 (18:23 +0200)
Thanks to cyphermox.

draft-gont-6man-slaac-dns-config-issues-00.xml

index 69b1a8e..fb9277b 100644 (file)
@@ -158,7 +158,7 @@ Pavel
         </list>
     </section>
 
-    <section title="Use Router Solicitations as a last resort">
+    <section title="Use Router Solicitations as a last resort" anchor="router-solicitations">
         <t>According to RFC 6106, host MAY use Router Solicitation
         to avoid expiry of RDNSS and DNSSL lifetimes. This technique
         can be already used as a last resort.</t>
@@ -206,7 +206,7 @@ Pavel
         in RFC 6106 entirely.</t>
     </section>
 
-    <section title="Use DNS even after Lifetime">
+    <section title="Use DNS even after Lifetime" anchor="use-after-lifetime">
         <t>TODO: This is maybe the most controversial technique
         presented in this document. See below. It is a workaround
         because it ignores the basic feature of a lifetime. This
@@ -247,7 +247,7 @@ Pavel
             the local host.</t>
         </list>
 
-        <t>The rationale for the suggested change is as follows:
+        <t>The rationale for the suggested change is as follows:</t>
 
         <list style="symbols">
             <t>It is a backwards-compatible local-policy change that solves the
@@ -261,11 +261,11 @@ Pavel
             same router in different Router Advertisement messages, the updated
             semantics of the 'Lifetime' parameter prevents oscillations in network
             configuration.</t>
-        <list style="hanging">
+        </list>
     </section>
-<section>
+</section>
 
-<section title="Unnecessary configuration oscillation">
+<section title="Unnecessary configuration oscillation" anchor="oscillations">
     <t>TODO: DNS configurations lists have a unique feature that they
     are limited to very short lists. Newest items push out the
     oldest ones. This can cause unneeded oscillation or circulation
@@ -325,7 +325,7 @@ Pavel
     use servers automatically configured in other networks.</t>
 
     <section title="Do not provide excessive amount of information to hosts">
-        </t>The easiest possible solution can be performed by the network
+        <t>The easiest possible solution can be performed by the network
         administrators. Network administrators SHOULD NOT configure
         network routers and DHCP servers in a way that causes hosts
         to recieve repeatedly more RDNSS or DNSSL options they can actually
@@ -338,7 +338,7 @@ Pavel
     </section>
 </section>
 
-<section title="Explicit expiration">
+<section title="Explicit expiration" anchor="explicit-expiration">
     <t>TODO: Zero lifetimes are often used to perform explicit
     expiration of configured items (including items in RDNSS and DNSSL lists).
     The current practice is to advertise a zero lifetime in one Router
@@ -394,11 +394,10 @@ Pavel
 
 <section title="Analysis of other possible solutions" anchor="alt-solutions">
 
-
 <t>As part of the recent discussion on the 6man mailing-list, it has been suggested that recommended 'Lifetime' value of RDNSS and DNSSL options be increased, as one of the possible solutions to the problem described in <xref target="intro"/>. The reasons for which such approach is not recommended in this document are:
 <list style="symbols">
 <t>It would require an update to router software, something that might be harder to perform (if at all possible) than an update to the corresponding host software.</t>
-<t>This 'solution' does not address the potential network configuration oscillation issue discussed in <xref target="solution"/> and <xref target="additional-notes"/>.</t>
+<t>This 'solution' does not address the potential network configuration oscillation issue discussed in <xref target="oscillations"/> and <xref target="additional-notes"/>.</t>
 </list>
 </t>
 </section>
@@ -428,7 +427,7 @@ When the IPv6 host has gathered a sufficient number (e.g., three) of RDNSS addre
 </t>
 </list>
 </t>
-<t>As noted earlier in this document, this policy could lead (in some scenarios) to network configuration oscillations. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="solution"/>.
+<t>As noted earlier in this document, this policy could lead (in some scenarios) to network configuration oscillations. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="alt-solutions"/>.
 </t>
 
 
@@ -447,7 +446,7 @@ When the IPv6 host has gathered a sufficient number (e.g., three) of RDNSS addre
 </t>
 </list>
 
-This policy could lead to the same network configuration oscillation problems as described above for the RDNSS addresses. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="solution"/>.
+This policy could lead to the same network configuration oscillation problems as described above for the RDNSS addresses. Therefore, it would be sensible to enforce some minimum stability of the configured information, such as that resulting from the update in <xref target="oscillations"/>.
 </t>
 </section>