perfsonar development work

Author: mac
Date: 2007-10-17 06:39:20 -0400 (Wed, 17 Oct 2007)
New Revision: 291

Added:
   trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml
   trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml
   trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml
   trunk/nmwg/doc/dLS/LSControl-LeaderResponse.xml
   trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml
   trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml
   trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml
   trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml
   trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml
   trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml
   trunk/nmwg/doc/dLS/LSDiscoveryRequest.xml
   trunk/nmwg/doc/dLS/LSDiscoveryResponse.xml
   trunk/nmwg/doc/dLS/LSRing-lower.xml
   trunk/nmwg/doc/dLS/LSRing-upper.xml
Removed:
   trunk/nmwg/doc/dLS/LSControl-Join.xml
   trunk/nmwg/doc/dLS/LSControl-Leader.xml
   trunk/nmwg/doc/dLS/LSControl-Summary.xml
   trunk/nmwg/doc/dLS/LSControl-Summary2.xml
   trunk/nmwg/doc/dLS/LSControl-Token.xml
   trunk/nmwg/doc/dLS/LSDiscovery.xml
Modified:
   trunk/nmwg/doc/dLS/dLS.html
   trunk/nmwg/doc/dLS/dLS.pdf
   trunk/nmwg/doc/dLS/dLS.xml
Log:
Examples were splitted between separate files for Request and Response.

Deleted: trunk/nmwg/doc/dLS/LSControl-Join.xml

Added: trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-JoinRequest.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-JoinResponse.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Deleted: trunk/nmwg/doc/dLS/LSControl-Leader.xml

Added: trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-LeaderRequest.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-LeaderResponse.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-LeaderResponse.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Deleted: trunk/nmwg/doc/dLS/LSControl-Summary.xml

Deleted: trunk/nmwg/doc/dLS/LSControl-Summary2.xml

Added: trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-Summary2Request.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-Summary2Response.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-SummaryRequest.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-SummaryResponse.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Deleted: trunk/nmwg/doc/dLS/LSControl-Token.xml

Added: trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-TokenRequest.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml


Property changes on: trunk/nmwg/doc/dLS/LSControl-TokenResponse.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Deleted: trunk/nmwg/doc/dLS/LSDiscovery.xml

Added: trunk/nmwg/doc/dLS/LSDiscoveryRequest.xml


Property changes on: trunk/nmwg/doc/dLS/LSDiscoveryRequest.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSDiscoveryResponse.xml


Property changes on: trunk/nmwg/doc/dLS/LSDiscoveryResponse.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSRing-lower.xml


Property changes on: trunk/nmwg/doc/dLS/LSRing-lower.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Added: trunk/nmwg/doc/dLS/LSRing-upper.xml


Property changes on: trunk/nmwg/doc/dLS/LSRing-upper.xml
___________________________________________________________________
Name: svn:keywords
   + Author Date Id Revision
Name: svn:eol-style
   + native

Modified: trunk/nmwg/doc/dLS/dLS.html
===================================================================
--- trunk/nmwg/doc/dLS/dLS.html 2007-10-11 11:37:13 UTC (rev 290)
+++ trunk/nmwg/doc/dLS/dLS.html 2007-10-17 10:39:20 UTC (rev 291)
@@ -757,9 +757,12 @@
 </h2>
 <p id="rfc.section.4.3.p.1">The LSRing file represents the "state" of the LS 
cloud at either level of hierarchy (we avoid using the terms "global" and 
"local" here since the hierarchy may be much larger). This file must start 
with some static values, and will be added to/deleted from as time goes on. 
As such implementations must ensure that this file is under database control 
of some sort.</p>
 <p id="rfc.section.4.3.p.2">Each metadata description contains the usual 
service level info, as well as a "voting" parameter (labeled as 
"contentSize") used to decide who the leader is, and a flag indicating if the 
current service thinks the remote service is active. Both of these should be 
updated frequently as reality changes.</p>
-<p id="rfc.section.4.3.p.3">
+<h3 id="rfc.section.4.3.1">
+<a href="#rfc.section.4.3.1">4.3.1</a>&nbsp;<a id="LSRingLower" 
href="#LSRingLower">LS Ring lower level</a>
+</h3>
+<p id="rfc.section.4.3.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:store type="LSRing-lower"&gt;
   
   &lt;!-- dont store yourself... --&gt;
@@ -825,11 +828,15 @@
   &lt;/nmwg:metadata&gt;   
   
 &lt;/nmwg:store&gt;
-
-
-
-
-
+                    
+                  </pre>
+</p>
+<h3 id="rfc.section.4.3.2">
+<a href="#rfc.section.4.3.2">4.3.2</a>&nbsp;<a id="LSRingUpper" 
href="#LSRingUpper">LS Ring upper level</a>
+</h3>
+<p id="rfc.section.4.3.2.p.1">
+<pre>
+                    
 &lt;nmwg:store type="LSRing-upper"&gt;
   
   &lt;!-- dont store yourself... --&gt;
@@ -865,17 +872,20 @@
   &lt;/nmwg:metadata&gt;
 
 &lt;/nmwg:store&gt;
-                 
-               </pre>
+                    
+                  </pre>
 </p>
 <h2 id="rfc.section.4.4">
 <a href="#rfc.section.4.4">4.4</a>&nbsp;<a id="LSControl-Join" 
href="#LSControl-Join">LS Joining Message for Joining a Ring</a>
 </h2>
 <p id="rfc.section.4.4.p.1">This message exchange represents when a "new" LS 
instance comes online. The LS will send these messages to its "list" of known 
LS instances until it gets a hit. The message consists of metadata/data 
pair(s) that contain service information and a parameter indicating "size" of 
the data set the LS manages. This will be used for leader voting purposes 
later.</p>
 <p id="rfc.section.4.4.p.2">The response message should indicate success or 
failure via the eventType, and will contain metadata/data pair(s). The 
metadata should indicate who the service is, and its "size" for voting 
purposes. The data section is an enumeration of all of the current members of 
the ring and their votes. This information gives the new member a snapshot of 
the ring.</p>
-<p id="rfc.section.4.4.p.3">
+<h3 id="rfc.section.4.4.1">
+<a href="#rfc.section.4.4.1">4.4.1</a>&nbsp;<a id="LSControl-JoinRequest" 
href="#LSControl-JoinRequest">Request</a>
+</h3>
+<p id="rfc.section.4.4.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:message type="LSControlRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.2"&gt;
@@ -896,11 +906,15 @@
   &lt;nmwg:data id="data.2" metadataIdRef="metadata.2" /&gt;
   
 &lt;/nmwg:message&gt;
-
-
-
-
-
+                    
+                  </pre>
+</p>
+<h3 id="rfc.section.4.4.2">
+<a href="#rfc.section.4.4.2">4.4.2</a>&nbsp;<a id="LSControl-JoinResponse" 
href="#LSControl-JoinResponse">Response</a>
+</h3>
+<p id="rfc.section.4.4.2.p.1">
+<pre>
+                    
 &lt;nmwg:message type="LSControlResponse"&gt;
 
   &lt;nmwg:metadata id="metadata.6"&gt;
@@ -949,17 +963,20 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                             
+                           </pre>
 </p>
 <h2 id="rfc.section.4.5">
 <a href="#rfc.section.4.5">4.5</a>&nbsp;<a id="LSControl-Token" 
href="#LSControl-Token">LS Token Message</a>
 </h2>
 <p id="rfc.section.4.5.p.1">This message exchange represents the token that 
is passed between LS instances in a cloud. The message contains metadata/data 
pair(s) wherein the Metadata is the sending LS's info, and the data contains 
the contents of the LSRing file (lower or upper depending on the token we are 
exchanging).</p>
 <p id="rfc.section.4.5.p.2">The response to this message should indicate 
success or failure. Failure and timeouts should trigger a resend.</p>
-<p id="rfc.section.4.5.p.3">
+<h3 id="rfc.section.4.5.1">
+<a href="#rfc.section.4.5.1">4.5.1</a>&nbsp;<a id="LSControl-TokenRequest" 
href="#LSControl-TokenRequest">Request</a>
+</h3>
+<p id="rfc.section.4.5.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:message type="LSControlRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.6"&gt;
@@ -1005,11 +1022,15 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-
-
-
-
-
+                             
+                           </pre>
+</p>
+<h3 id="rfc.section.4.5.2">
+<a href="#rfc.section.4.5.2">4.5.2</a>&nbsp;<a id="LSControl-TokenResponse" 
href="#LSControl-TokenResponse">Response</a>
+</h3>
+<p id="rfc.section.4.5.2.p.1">
+<pre>
+                             
 &lt;nmwg:message type="LSControlResponse"&gt;
 
   &lt;nmwg:metadata id="metadata.2"&gt;
@@ -1033,8 +1054,8 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                                      
+                                    </pre>
 </p>
 <h2 id="rfc.section.4.6">
 <a href="#rfc.section.4.6">4.6</a>&nbsp;<a id="LSControl-Summary-lower" 
href="#LSControl-Summary-lower">LS Summary Message (Lower)</a>
@@ -1047,9 +1068,12 @@
 <dd>Update the summary info in your collection</dd>
 <dd>If you don"t know of them, add them!</dd>
 </dl>
-<p id="rfc.section.4.6.p.4">
+<h3 id="rfc.section.4.6.1">
+<a href="#rfc.section.4.6.1">4.6.1</a>&nbsp;<a 
id="LSControl-Summary2Request" href="#LSControl-Summary2Request">Request</a>
+</h3>
+<p id="rfc.section.4.6.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:message type="LSControlRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.2"&gt;
@@ -1081,10 +1105,15 @@
   
 &lt;/nmwg:message&gt;
 
-
-
-
-
+                             
+                           </pre>
+</p>
+<h3 id="rfc.section.4.6.2">
+<a href="#rfc.section.4.6.2">4.6.2</a>&nbsp;<a 
id="LSControl-Summary2Response" 
href="#LSControl-Summary2Response">Response</a>
+</h3>
+<p id="rfc.section.4.6.2.p.1">
+<pre>
+                             
 &lt;nmwg:message type="LSControlResponse"&gt;
 
   &lt;!-- whomever answers ... --&gt;
@@ -1108,8 +1137,8 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                                      
+                                    </pre>
 </p>
 <h2 id="rfc.section.4.7">
 <a href="#rfc.section.4.7">4.7</a>&nbsp;<a id="LSControl-Summary-upper" 
href="#LSControl-Summary-upper">LS Summary Message (Upper)</a>
@@ -1122,9 +1151,12 @@
 <dd>Update the summary info in your collection</dd>
 <dd>If you don't know of them, add them!</dd>
 </dl>
-<p id="rfc.section.4.7.p.4">
+<h3 id="rfc.section.4.7.1">
+<a href="#rfc.section.4.7.1">4.7.1</a>&nbsp;<a id="LSControl-SummaryRequest" 
href="#LSControl-SummaryRequest">Request</a>
+</h3>
+<p id="rfc.section.4.7.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:message type="LSControlRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.2"&gt;
@@ -1171,11 +1203,15 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-
-
-
-
-
+                             
+                           </pre>
+</p>
+<h3 id="rfc.section.4.7.2">
+<a href="#rfc.section.4.7.2">4.7.2</a>&nbsp;<a 
id="LSControl-SummaryResponse" href="#LSControl-SummaryResponse">Response</a>
+</h3>
+<p id="rfc.section.4.7.2.p.1">
+<pre>
+                             
 &lt;nmwg:message type="LSControlResponse"&gt;
 
   &lt;!-- whomever answers ... --&gt;
@@ -1199,17 +1235,20 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                                      
+                                    </pre>
 </p>
 <h2 id="rfc.section.4.8">
 <a href="#rfc.section.4.8">4.8</a>&nbsp;<a id="LSControl-Leader" 
href="#LSControl-Leader">LS Leader Message</a>
 </h2>
 <p id="rfc.section.4.8.p.1">This message exchange will be conducted between 
the Leader and Vice-Leader on some (frequent) interval. It may even become a 
part of the Leader's token exchange with the Upper Level.</p>
 <p id="rfc.section.4.8.p.2">The leader identifies itself, and sends down the 
summaries from the upper level for the Vice-Leader to store. If the leader 
should die, the vice leader will have a summary of the upper level and be 
able to continue answering lower level queries and obtaining information from 
the higher levels.</p>
-<p id="rfc.section.4.8.p.3">
+<h3 id="rfc.section.4.8.1">
+<a href="#rfc.section.4.8.1">4.8.1</a>&nbsp;<a id="LSControl-LeaderRequest" 
href="#LSControl-LeaderRequest">Request</a>
+</h3>
+<p id="rfc.section.4.8.1.p.1">
 <pre>
-                       
+                    
 &lt;nmwg:message type="LSControlRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.6"&gt;
@@ -1281,22 +1320,33 @@
   &lt;/nmwg:data&gt;
   
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                             
+                           </pre>
 </p>
+<h3 id="rfc.section.4.8.2">
+<a href="#rfc.section.4.8.2">4.8.2</a>&nbsp;<a id="LSControl-LeaderResponse" 
href="#LSControl-LeaderResponse">Response</a>
+</h3>
+<p id="rfc.section.4.8.2.p.1">
+<pre>
+                             
+&lt;nmwg:message type="LSControlRequest"&gt;
+
+    &lt;!-- tbd --&gt;
+  
+&lt;/nmwg:message&gt;
+                                      
+                                    </pre>
+</p>
 <h2 id="rfc.section.4.9">
 <a href="#rfc.section.4.9">4.9</a>&nbsp;<a id="LSControl-Discovery" 
href="#LSControl-Discovery">LS Discovery Message</a>
 </h2>
 <p id="rfc.section.4.9.p.1">Structure of the LSDiscovery Message used to 
locate info-sets. (FORMAT TBD!!!)</p>
-<p id="rfc.section.4.9.p.2">
+<h3 id="rfc.section.4.9.1">
+<a href="#rfc.section.4.9.1">4.9.1</a>&nbsp;<a id="LSDiscoveryRequest" 
href="#LSDiscoveryRequest">Request</a>
+</h3>
+<p id="rfc.section.4.9.1.p.1">
 <pre>
-                       
-&lt;!-- LSDiscovery(Request|Response)
-     
-     
-     
-     --&gt;
-
+                     
 &lt;nmwg:message type="LSDiscoveryRequest"&gt;
 
   &lt;nmwg:metadata id="metadata.1"&gt;
@@ -1308,9 +1358,15 @@
   &lt;nmwg:data id="data.1" metadataIdRef="metadata.1" /&gt;
   
 &lt;/nmwg:message&gt;
-
-
-
+                              
+                            </pre>
+</p>
+<h3 id="rfc.section.4.9.2">
+<a href="#rfc.section.4.9.2">4.9.2</a>&nbsp;<a id="LSDiscoveryResponse" 
href="#LSDiscoveryResponse">Response</a>
+</h3>
+<p id="rfc.section.4.9.2.p.1">
+<pre>
+                              
 &lt;nmwg:message type="LSDiscoveryResponse"&gt;
 
   &lt;nmwg:metadata id="metadata.1.r"&gt;
@@ -1342,8 +1398,8 @@
   &lt;/nmwg:data&gt;
 
 &lt;/nmwg:message&gt;
-                 
-               </pre>
+                                       
+                                     </pre>
 </p>
 <hr class="noprint">
 <h1 id="rfc.section.5" class="np">

Modified: trunk/nmwg/doc/dLS/dLS.pdf
===================================================================
(Binary files differ)

Modified: trunk/nmwg/doc/dLS/dLS.xml
===================================================================
--- trunk/nmwg/doc/dLS/dLS.xml  2007-10-11 11:37:13 UTC (rev 290)
+++ trunk/nmwg/doc/dLS/dLS.xml  2007-10-17 10:39:20 UTC (rev 291)
@@ -1,8 +1,6 @@
 <?xml version="1.0"?>
 <!DOCTYPE rfc SYSTEM "rfc2629.dtd">
-
 <rfc>
-
 <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
 <?rfc toc="yes" ?>
 <?rfc symrefs="yes" ?>
@@ -12,42 +10,35 @@
 <?rfc strict="no" ?>
 <!-- <?rfc-ext support-rfc2731="no"?>
 <?rfc-ext authors-section="no"?> -->
-
-  <front>
-    <title>Distributed Lookup Service (dLS) in the perfSONAR 
Framework</title>
-
-    <author initials="J" surname="Boote" fullname="Jeff Boote">
-           <organization abbrev="Internet2">Internet2
+ <front>
+  <title>Distributed Lookup Service (dLS) in the perfSONAR Framework</title>
+  <author initials="J" surname="Boote" fullname="Jeff Boote">
+   <organization abbrev="Internet2">Internet2
                                        1000 Oakbrook Drive Suite 300
                                        Ann Arbor MI 48104 </organization>
-    </author>  
-    <author initials="M" surname="Glowiak" fullname="Maciej Glowiak">
-           <organization abbrev="PSNC">Poznan Supercomputing and Networking 
Center
+  </author>
+  <author initials="M" surname="Glowiak" fullname="Maciej Glowiak">
+   <organization abbrev="PSNC">Poznan Supercomputing and Networking Center
                                   ul. Noskowskiego 10
                                   61-704 Poznan
                                   Poland</organization>
-    </author>  
-    <author initials="M" surname="Swany" fullname="D. Martin Swany">
-           <organization abbrev="UDel">University of Delaware
+  </author>
+  <author initials="M" surname="Swany" fullname="D. Martin Swany">
+   <organization abbrev="UDel">University of Delaware
                                        Department of Computer and 
Information Sciences
                                        Newark, DE 19716</organization>
-    </author>
-    <author initials="J" surname="Zurawski" fullname="Jason Zurawski">
-           <organization abbrev="Internet2">Internet2
+  </author>
+  <author initials="J" surname="Zurawski" fullname="Jason Zurawski">
+   <organization abbrev="Internet2">Internet2
                                      1000 Oakbrook Drive Suite 300
                                      Ann Arbor MI 48104 </organization>
-    </author>  
-    <date month="October" year="2007"/>
-  </front>  
-
-
-
-  <middle>
-
-    <!-- Introduction Section -->
-
-    <section anchor="intro" title="Introduction">
-      <t>
+  </author>
+  <date month="October" year="2007"/>
+ </front>
+ <middle>
+<!-- Introduction Section -->
+  <section anchor="intro" title="Introduction">
+   <t>
         This document describes the Distributed Lookup Service (dLS) in the 
perfSONAR
         (pS) system.  This functionality extends the basic Lookup Service 
(LS)
         functionality that has been present in the system for some time.  The
@@ -55,17 +46,16 @@
         information as well as metadata about data stored or gathered by a
         particular pS service instance.  
       </t>
-      <t>
+   <t>
         From clients' perspective, Lookup Service operation involves 
registration,
         deregistration, querying and obtaining query results.  Clients want 
to discover
         the services that are running in the network.  LS enables this by 
gathering 
         information from the services and then using it to fulfill client 
queries.  
         Figure below presents basic LS interactions.
       </t>
-      
-       <figure anchor="ls-op">
-           <preamble>LS Operation</preamble>
-           <artwork>
+   <figure anchor="ls-op">
+    <preamble>LS Operation</preamble>
+    <artwork>
  _____                              __________
 |     |     Register/De-register   |          |
 | LS  | &lt;------------------------&gt; | Service  |
@@ -76,45 +66,38 @@
                 Query for Services |_________________|
 
            </artwork>
-           <postamble>Services interacting with an LS</postamble>
-       </figure>      
-      
-      <t>  
+    <postamble>Services interacting with an LS</postamble>
+   </figure>
+   <t>  
         This document describes the support
         necessary to extend basic Lookup Service to a distributed mode of 
operation.
         dLS reduces overhead in a single service and maintains consistent 
information.
         There are a few key facets of this mode of operation:
       </t>
-      
-      <list style="symbols">
-        <t>Summarization - to reduce the amount of information sent over the 
+   <list style="symbols">
+    <t>Summarization - to reduce the amount of information sent over the 
            network or to anonymize sensitive data, some form of data 
reduction
            must take place.
         </t>
-        <t>Scope - to enable a hierarchy of systems, some form of scoping 
+    <t>Scope - to enable a hierarchy of systems, some form of scoping 
            must exist that forms logical communication and data exchange
            channels.
         </t>
-        <t>Search - information location is key and the way in which 
+    <t>Search - information location is key and the way in which 
            distributed location and search is handled is the crux of this
            service.
         </t>
-      </list>    
-      
-      <t>
+   </list>
+   <t>
         Additionally we present solutions to issues related to allow 
seamless 
         operation of this service including bootstrapping (i.e. how service 
find 
         other parts of the system) and domain specific concerns.  
-      </t>      
-    </section>
-
-
-    <section anchor="system" title="System Specific Operation">
-
-      <!-- Overivew Section -->
-    
-      <section anchor="overview" title="Overview">
-        <t>The first step of information flow is when a pS service registers 
with
+      </t>
+  </section>
+  <section anchor="system" title="System Specific Operation">
+<!-- Overivew Section -->
+   <section anchor="overview" title="Overview">
+    <t>The first step of information flow is when a pS service registers with
            an LS.  The service may know the name of an LS via static
            configuration (the most common case for legacy deployments), or 
            other forms of bootstrapping such as multicast may occur.  A 
service
@@ -125,8 +108,7 @@
            knowledge of. Such a record is called Lookup Information (see 
            <xref target="lookup-info" />).
          </t>
-         
-         <t>
+    <t>
            The idea is to move the metadata from a local XML data store to a 
            specialized LS with additional searching capabilities.  While a 
            service instance may support limited searching, this is not 
@@ -135,27 +117,22 @@
            are rapidly changing metadata like the most recent timestamp and 
            full details of data stored in long-term archival MAs.
         </t>
- 
-        <t>The architecture of the dLS protocol assumes the existence of 
logical
+    <t>The architecture of the dLS protocol assumes the existence of logical
                   rings of LS instances.  The current proposal involves two 
levels of rings: 
                   lower scope and upper scope.  Lower scope hides 
inter-domain relationships
                   between LS instances while upper scope hides intra-domain 
relationships.
-               </t>   
-               
-      </section>
-    
-      <!-- Summarization Section -->
-
-      <section anchor="summary" title="Summarization">
-        <t>
+               </t>
+   </section>
+<!-- Summarization Section -->
+   <section anchor="summary" title="Summarization">
+    <t>
            The LS that a service contacts to register becomes the "Home LS"
            (HLS, see <xref target="glossary" />) of that particular service.
            It is the responsibility of the HLS to make summary data about the
            all of the pS services it knows of available to the larger 
            enterprise and to draw relevant queries to itself.  
         </t>
-        
-        <t>           
+    <t>           
            The construction of such a summary is important to the overall 
            success of this service; summaries prevents other LS instances 
            from being overloaded by information, must be general enough to 
allow 
@@ -171,22 +148,19 @@
            sets closer to the source.  We present the strategies as such:
            
             <list style="symbols">
-              <t>Summarization for the "lower scope" (formerly known as 
+      <t>Summarization for the "lower scope" (formerly known as 
                  "local scope")</t>
-              <t>Summarization for the "upper scope" (formerly known as 
+      <t>Summarization for the "upper scope" (formerly known as 
                  "global scope")</t>
-            </list>
+     </list>
             
            We limit the discussion in this case to these two scopes, 
although 
            extension to "n" scopes is possible.  As the number of scopes 
            increases additional "aggregation" will be necessary to combine 
            information thus reducing the size of the data sets further.
         </t>
-        
-        
-        
-        <section anchor="lower_scope_summarization" title="Lower Scope 
Summarization"> 
-           <t>
+    <section anchor="lower_scope_summarization" title="Lower Scope 
Summarization">
+     <t>
              This first level of summarization, between HLS instances 
internal
              to a domain, consists of simply dropping superfluous information
              from the metadata descriptions provided by registered services. 
 
@@ -196,8 +170,7 @@
              actual eventType elements.  This will ensure interoperability 
with
              legacy services.
            </t>
-           
-           <t>
+     <t>
              Future iterations may choose to drop additional pieces of 
              information deemed unnecessary or private such as parts of 
              topological descriptions.  This sort of modification is 
encouraged
@@ -206,8 +179,7 @@
              be noted that such modifications will affect the searching 
              procedure and could isolate the source services. 
            </t>
-           
-           <t>
+     <t>
              The mechanics for performing this level of summarization can 
use 
              any number of technologies.  Either Extensible Stylesheet 
              Language Transformation (XSLT) documents or the XQuery language 
@@ -218,18 +190,16 @@
              employed by the individual implementations to ensure the 
              regular LS functions are not impeded.
            </t>
-           
-           <t>In order to make information available to the LS cloud, the HLS
+     <t>In order to make information available to the LS cloud, the HLS
               will advertise this summary information to other LS instances 
to 
               propagate the appropriate information.  Information exchange
               will be handled using a "taking turns" protocol such as token
               ring.  The holder of the token will then perform the 
information 
               exchange to other known instances (see <xref target="glossary" 
/>).
            </t>
-         
-           <figure anchor="hls-cloud">
-             <preamble>HLS Cloud</preamble>
-             <artwork>
+     <figure anchor="hls-cloud">
+      <preamble>HLS Cloud</preamble>
+      <artwork>
              
 A) Token passing
  _____                      _____ 
@@ -257,12 +227,11 @@
                   \_/             
              
              </artwork>
-             <postamble>HLS instances communicating via a token message (A). 
The 
+      <postamble>HLS instances communicating via a token message (A). The 
                         holder of the token (LS3) will inform everyone of 
it's 
                         summary information (B).</postamble>
-           </figure>   
-           
-           <t>Once exchanged, the details regarding storage in the XML 
database
+     </figure>
+     <t>Once exchanged, the details regarding storage in the XML database
               backend (see <xref target="glossary" />) are also left to 
               individual implementations.  It is understood that this 
               information, in the possession of non HLS instances, is 
provided 
@@ -270,11 +239,10 @@
               directly registered information is (i.e. purged on 
expiration).  
               When requested, credit must also be attributed to the HLS as 
being
               (non)authoritative for each piece of information.  
-           </t>           
-        </section>        
-        
-        <section anchor="upper_scope_summarization" title="Upper Scope 
Summarization"> 
-          <t>
+           </t>
+    </section>
+    <section anchor="upper_scope_summarization" title="Upper Scope 
Summarization">
+     <t>
             A designated member of each lower scope will be required to 
interact
             with the upper scope.  The mechanics of how we learn who is the 
             designated leader is discussed in <xref target="tokens" />.  The 
@@ -282,9 +250,8 @@
             for examining each member's summary information and building a 
             summarization/aggregation that best describes the contents of the
             ring.  
-          </t>    
-          
-          <t>  
+          </t>
+     <t>  
             The most natural summarization is based on the topology of the 
             network (like in network routing). Thus, topology-based 
             summarization will include this information as well as eventType
@@ -293,8 +260,7 @@
             as IP addresses will be summarized using algorithms basing on 
             Radix Tree (see <xref target="IP-summary" />).
           </t>
-        
-          <t>
+     <t>
             Other information can be summarized in a less programmatic 
fashion
             through the use of either Extensible Stylesheet Language 
             Transformation (XSLT) documents or the XQuery language as 
discussed
@@ -303,8 +269,7 @@
             in metadata subjects as well as additional items such as 
             eventTypes.  
           </t>
-          
-          <t>
+     <t>
             The output of this process becomes a "service summary" that 
             represents a breadth of the original  input.  See 
             <xref target="LSControl-Summary-lower" /> or 
@@ -312,10 +277,9 @@
             summary output. Additional transformations, while aggressive, 
will 
             strive to preserve as much information as possible to remain 
             useful during the search procedures.  
-          </t>  
-            
-          <section anchor="IP-summary" title="IP addresses summarization 
algorithm">
-            <t>
+          </t>
+     <section anchor="IP-summary" title="IP addresses summarization 
algorithm">
+      <t>
               To properly summarize a list of strings such as IP addresses we
               must rely on the help of special algorithms and data 
structures.  
               The <eref 
target="http://en.wikipedia.org/wiki/Radix_tree";>Radix Tree</eref>
@@ -327,8 +291,7 @@
               where it is necessary to describe a large ranges of values and 
               have few exceptions.
             </t>
-            
-            <t>
+      <t>
               A detailed explanation of the nuances of the Radix Tree is well
               beyond the scope of this document, but a brief overview is 
               presented for completeness.  The structure itself is best 
@@ -340,9 +303,9 @@
               operations:
 
               <list style="symbols">
-                <t>Lookup: Indicate that something is or is not contained in 
+        <t>Lookup: Indicate that something is or is not contained in 
                    the tree.</t>
-                <t>Insert: Like in most inserts we attempt to place something
+        <t>Insert: Like in most inserts we attempt to place something
                    into the structure.  We first start by doing a Lookup to 
                    see if it exists already; the point where we stop is 
where 
                    we will insert the object.  We are careful to utilize
@@ -350,30 +313,22 @@
                    advantage.  This last part is normally referred to as 
                    "splitting" and ensures that each node has no more than
                    two children.</t>
-                <t>Delete: Delete an object from the tree. This operation 
will
+        <t>Delete: Delete an object from the tree. This operation will
                    be complicated by "collapsing" parents that have a single
                    child and merging the edges.</t>
-              </list>
-            </t>
-
-            <t>
+       </list>
+      </t>
+      <t>
               Once constructed, it is possible to consult the structure in 
               creating IP summaries as well as constructing information 
               regarding netmasks.  
             </t>
-          </section>           
-  
-        </section>        
-  
-      </section>    
-      
-      
-         
-      <!-- Scope Section -->
-
-      <section anchor="scope" title="Scope Forming"> 
-               
-        <t>The next question is how to form the lower and upper scopes.  The 
+     </section>
+    </section>
+   </section>
+<!-- Scope Section -->
+   <section anchor="scope" title="Scope Forming">
+    <t>The next question is how to form the lower and upper scopes.  The 
            simplest answer is that the lower scope be formed based on the 
domain
            name of the participating systems.  That would allow e.g.
            internet2.edu, geant2.net, and pionier.gov.pl to potentially 
operate more
@@ -381,9 +336,8 @@
            scalability.) As LS instances come online they will invoke
            bootstrapping procedures to find and join a lower scoped group
            first.
-        </t>  
-      
-        <t>The scopes should be named based on URIs.  This will allow a
+        </t>
+    <t>The scopes should be named based on URIs.  This will allow a
            domain-level scope to take the form 
            <eref target="http://internet2.edu";>http://internet2.edu</eref>, 
            with subdomain scopes named 
@@ -393,24 +347,22 @@
            with potential for geographic divisions later if necessary for 
            performance (such as 
            <eref 
target="http://eu.perfsonar.net";>http://eu.perfsonar.net</eref>).  
-        </t>  
-
-        <t>
+        </t>
+    <t>
           The major algorithms used to form and maintain the ring structure 
of
           the dLS, no matter which scope we are talking about, are as 
follows:
             <list style="symbols">
-              <t>Join Procedure</t>
-              <t>Token Passing</t>
-              <t>Summarization Notification</t>
-            </list>
+      <t>Join Procedure</t>
+      <t>Token Passing</t>
+      <t>Summarization Notification</t>
+     </list>
           Each of these procedures is paramount to keeping members of the
           distributed "service" functioning correctly.  The algorithms will 
be 
           presented in the frame of the lower scope, but will be used in the 
           same manner for the upper scope as well.
         </t>
-
-        <section anchor="join" title="Join Procedure">
-          <t>
+    <section anchor="join" title="Join Procedure">
+     <t>
             When an LS instance comes online it will have some bootstrapping
             knowledge of potential peers (both inter and intra domain).  This
             information is contained in LSRing file (see 
@@ -418,8 +370,7 @@
             to establish a connection to an already in progress ring, or 
perhaps 
             to start a ring that may not exist yet.  
           </t>
-          
-          <t>
+     <t>
             A candidate LS will continuously search it's LSRing information 
and
             send an LSControl mesage to its know LS instances with a "join" 
eventType 
             (see <xref target="LSControl-Join" />) until a successful 
response 
@@ -433,8 +384,7 @@
             update the local copy of LSRing to add the new member to its 
             "available" list.
           </t>
-          
-          <t>
+     <t>
             After updating, the newly joined LS will broadcast another 
LSControl message with
             a "summary" eventType (see <xref 
target="LSControl-Summary-lower" />, 
             or if we are dealing with the upper level see 
@@ -447,19 +397,16 @@
             including adding this new member to their own lists (as they 
             didn't know of it's existence yet).  
           </t>
-          
-          <t>
+     <t>
             After this initial warm-up the LS will observe the rules of token
             etiquette and remain silent until it is contacted with a token, 
or 
             it has not seen one in a very long time (see <xref 
target="tokens" />).
           </t>
-          
-          <section anchor="join_algorithm" title="Join Algorithm"> 
- 
-            <t>
-            <figure anchor="join-example2">
-             <preamble>Illustration of LS Join Algorithm</preamble>
-             <artwork>
+     <section anchor="join_algorithm" title="Join Algorithm">
+      <t>
+       <figure anchor="join-example2">
+        <preamble>Illustration of LS Join Algorithm</preamble>
+        <artwork>
                           (5,6)
    ______________________________________________________
    |                                                    |
@@ -478,47 +425,44 @@
              
              
              </artwork>
-             <postamble>LS2, LS3 and LS4 are in the ring. LS1 wants to join
+        <postamble>LS2, LS3 and LS4 are in the ring. LS1 wants to join
               the dLS cloud.</postamble>
-           </figure>            
-
-           <t>The algorithm for joining the ring works as follows: 
+       </figure>
+       <t>The algorithm for joining the ring works as follows: 
            </t>
-           
-            <list type="symbols">
-                <t>1. LS1 - Candidate sends LSControlRequest message with 
+       <list type="symbols">
+        <t>1. LS1 - Candidate sends LSControlRequest message with 
                       the http://perfsonar.net/services/LS/join eventType to 
                       selected LS2 which is already a member of the ring. 
                       LS2 was found in LSRing initial file during 
bootstrapping 
                       process.</t>
-                <t>2. LS2 receives join message from L1 and decides whether 
+        <t>2. LS2 receives join message from L1 and decides whether 
                       to accept it or not.  A security policy may occur 
here.</t>
-                <t>3. LS2 sends the LSControlResponse answer indicating 
success
+        <t>3. LS2 sends the LSControlResponse answer indicating success
                       joining (result code: 
http://perfsonar.net/result/success/LS/join) 
-                      or failure (error code).</t>                
-                <t>4. After receiving the response from LS2, LS1 parses
+                      or failure (error code).</t>
+        <t>4. After receiving the response from LS2, LS1 parses
                       the results of LSControlResponse to discover all 
members 
                       of its scope.</t>
-                <t>5. LS1 broadcast its summary info (lower or upper) with
+        <t>5. LS1 broadcast its summary info (lower or upper) with
                          LSControl message with 
http://perfsonar.net/services/LS/summary
                          eventType to all of the LS instances it learns of.  
This is
                          of course "out of turn" as LS1 doesn't have the 
token yet but
                          this reasoning is twofold:
                    <list type="symbols">
-                     <t>This expedites all ring members knowing the new LS, 
+          <t>This expedites all ring members knowing the new LS, 
                         the ring will grow instantly by inserting the new
                         member into the correct position.</t>
-                     <t>This allows the information it provides to the 
leaders
+          <t>This allows the information it provides to the leaders
                         to become available for the next upper ring summary 
as 
                         soon as possible.  Worst case scenarios would place
                         this knowledge cycles away from being recognized.</t>
-                   </list>
-                </t>
-                <t>6. All members of the ring process the summaries, save
+         </list>
+        </t>
+        <t>6. All members of the ring process the summaries, save
                       the necessary information, and recognize the new peer. 
 
                       Responses are sent to LS1.</t>
-                                     
-                <!--      
+<!--      
                 <t>4. If success LS1 will be waiting for token and LS2 
                       updates its local peer list</t>
                 <t>5. In the meantime LS2 receives Token. Then it 
synchronizes 
@@ -532,14 +476,12 @@
                       sends its local summary to all peers from list and 
                       sends Token to next peer</t>
                 -->
-            </list>            
-            </t>
-          </section>
-          
-        </section>
-
-        <section anchor="tokens" title="Token Passing">
-          <t>
+       </list>
+      </t>
+     </section>
+    </section>
+    <section anchor="tokens" title="Token Passing">
+     <t>
             The "token" is an LSControlMessage (see <xref 
target="LSControl-Token" />) 
             meant to be passed around an LSRing to the various members in 
some
             order.  There are various criterion that can be used in deciding 
how
@@ -550,8 +492,7 @@
             ring as possible without burdening the LS instances too much with
             complex calculations.
           </t>
-
-          <t>  
+     <t>  
             A common method used in P2P systems such as Gnutella when 
forming 
             "ultrapeers" is to consider the size of the data that a node is
             serving.  The principle, as described 
@@ -564,8 +505,7 @@
             and share this with our friends in the form of the "contentSize"
             parameter.  
           </t>
-          
-          <t>
+     <t>
             Token passing is directly related to the concept of leader 
             election (see <xref target="Leader_Election" />), so more 
             explanation of this approach will follow.  For now we are 
justified
@@ -576,8 +516,7 @@
             We assume passing order between the LSs from smallest to 
greatest 
             "contentSize" (with wrap around at the ends).
           </t>
-           
-          <t>
+     <t>
             The token can be viewed as "permission to talk" and permits the 
             holding LS to send it's summary information to all other 
available LS
             instances (see <xref target="LSControl-Summary-lower" /> and 
@@ -585,8 +524,7 @@
             will be parsed to get any useful updated information about 
current 
             dLS cloud state.
           </t>
-          
-          <t>
+     <t>
             The holder of the token, after completing summarization, will 
wait
             some pre-determined amount of time before sending the token to 
the
             next LS instance.  In general the LS instances should not be 
overly
@@ -603,18 +541,16 @@
             the ring has grown our join algorithm will inform all interested 
             parties instantly) and the token "wait" period (should be a 
             standard value) thus calculating the expected time is not an 
issue.  
-          </t>       
-        
-
-          <section anchor="token_passing_algorithm" title="Token Passing 
Algorithm">
+          </t>
+     <section anchor="token_passing_algorithm" title="Token Passing 
Algorithm">
 <!--
           <section anchor="tokenpass_algorithm" title="Toking Passing 
Algorithm"> 
  
             <t>
 -->
-            <figure anchor="join-example">
-             <preamble>Illustration of Token Passing Algorithm</preamble>
-             <artwork>
+      <figure anchor="join-example">
+       <preamble>Illustration of Token Passing Algorithm</preamble>
+       <artwork>
                           
    _____________(3)____________
    |                          |
@@ -633,58 +569,47 @@
              
              
              </artwork>
-             <postamble>LS1, LS2 and LS3 are in the ring.  LS1 receives a 
token.</postamble>
-           </figure>            
-           
-            <t>The algorithm for token passing works as follows:</t>
-            
-            <list type="numbers">
-              <t>1. LS1 receives the token i.e. LSControlRequest message 
+       <postamble>LS1, LS2 and LS3 are in the ring.  LS1 receives a 
token.</postamble>
+      </figure>
+      <t>The algorithm for token passing works as follows:</t>
+      <list type="numbers">
+       <t>1. LS1 receives the token i.e. LSControlRequest message 
                     with the http://perfsonar.net/services/LS/token/
                     eventType from its predecessor L3.</t>
-              <t>2. LS1 updates its local peer list based on token 
content.</t>
-              <t>3. LS1 sends LSControlRequest message with the 
+       <t>2. LS1 updates its local peer list based on token content.</t>
+       <t>3. LS1 sends LSControlRequest message with the 
                  http://perfsonar.net/services/LS/summary/ eventType 
                  to all peers in the lease (excluding itself).</t>
-              <t>3. LS2 receiving this message checks its collection and 
updates it
+       <t>3. LS2 receiving this message checks its collection and updates it
                  if necessary with service info including "contentSize".</t>
-              <t>4. LS1 waits for some amount of time.</t>
-              <t>5. LS1 sends token to next LS (LS2) from the LSRing lower 
scope 
+       <t>4. LS1 waits for some amount of time.</t>
+       <t>5. LS1 sends token to next LS (LS2) from the LSRing lower scope 
                  (if it fails, try next one).</t>
-            </list> 
-            
-          </section>
-          
-        </section>
-        
-        
-        
-        
-        <section anchor="summary-blast" title="Summarization Notification">
-          <t>
+      </list>
+     </section>
+    </section>
+    <section anchor="summary-blast" title="Summarization Notification">
+     <t>
             As discussed in the prior two sections there are two acceptable
             instances to send your summary to the LSRing:
             <list style="numbers">
-              <t>When first joining</t>
-              <t>When holding the token</t>
-            </list>
-          </t>
-          
-          <t>
+       <t>When first joining</t>
+       <t>When holding the token</t>
+      </list>
+     </t>
+     <t>
             In the first case we are explicitly entering ourselves into the
             ring when we get our first message from a peer.  This ensures we
             show up in the token rotation instantly.  The second case is
             the routine exchange started when a token arrives from a peer.
           </t>
-          
-          <t>
-            <xref target="LSControl-Summary-lower" /> and 
+     <t>
+      <xref target="LSControl-Summary-lower" /> and 
             <xref target="LSControl-Summary-upper" /> contain examples of 
the 
             message format for this exchange.  It is left up to the 
             implementation when the summarization occurs (i.e. at message 
             send time, or also as a periodic event).  
           </t>
- 
 <!--         
 <t><vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace 
blankLines="1" />
   making summarization at the message send time may increase token holding 
time and 
@@ -697,12 +622,9 @@
 task.
 <vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>  
 -->
-        
-        </section>
-        
-        <section anchor="Leader_Election" title="Leader election">
-
-        <t>
+    </section>
+    <section anchor="Leader_Election" title="Leader election">
+     <t>
            The most important role of the lower scope nodes is electing a 
leader
            to serve in the upper levels.  This logical ring should consist 
of 
            one representative LS from each of the lower scopes.  This 
@@ -713,8 +635,7 @@
            on the nodes, and allows us to choose the "least busy" node for 
            performing more important work.  
         </t>
-        
-        <t>
+     <t>
           The theory behind this choice of leader is that unladen LS 
instances
           will not be as loaded processing requests and responses from 
clients
           and other services, thus the choice to name them as leaders is
@@ -723,8 +644,7 @@
           instance that does not accept registrations.  This service will 
only
           serve in the role of liaison to the upper level.  
         </t>
-
-        <t>
+     <t>
           All LS instances will have a complete view at any given time (and
           updated over time) of the values of the "contentSize" parameter for
           all peer LS instances in an LSRing.  This ensures that the "Leader"
@@ -732,8 +652,7 @@
           not required, and succession can pass between the two executives
           quickly.  
         </t>
-        
-        <t>
+     <t>
           The Leader and Vice-Leader LS instances should exchange messages 
           (see <xref target="LSControl-Leader" />)
           periodically to ensure that in the event of a failure the lower
@@ -743,8 +662,8 @@
           it has, the "Join" procedure will start to the upper level to keep 
           the hierarchy complete.
         </t>
-
-<t><vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace 
blankLines="1" />
+     <t>
+      <vspace blankLines="2" />START_NOTE (Maciej 10/3/07):<vspace 
blankLines="1" />
   Question: I am not convinced "contentSize" should be the only criterion. 
   When new LS joins the ring it may have empty database, but in some time 
   it'll get a lot of metadata. The mechanism of leader election bases on 
that, so 
@@ -752,9 +671,10 @@
   other LS-es may know about it immediately (token passing cycle) and they 
may 
   not have the same knowledge about the leader. I"d prefer more 
deterministic 
   way of leader election.
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>
-
-<t><vspace blankLines="2" />START_NOTE (Jason 10/4/07):<vspace 
blankLines="1" />
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" />
+     </t>
+     <t>
+      <vspace blankLines="2" />START_NOTE (Jason 10/4/07):<vspace 
blankLines="1" />
 I have added some more reasoning behind this, as well as a pointer to some
 literature from the Gnutella folks as to why this is a good method.  I am 
not in
 favor of something complex when calculating a leader; we must choose 
something
@@ -763,13 +683,11 @@
 any given time) how much information someone has, and the notion that an 
unburdened
 system should be given more work (as opposed to a system that may be very 
busy with
 local queries yet chosen anyway based on separate criteria) is very 
appealing.  
-<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" /></t>
-
-       </section>
-      
-      <section anchor="scopes" title="Scopes">
-        
-        <t>Scopes are named based on URIs.  The top-level domain provides a
+<vspace blankLines="1" />END_NOTE:<vspace blankLines="2" />
+     </t>
+    </section>
+    <section anchor="scopes" title="Scopes">
+     <t>Scopes are named based on URIs.  The top-level domain provides a
            natural basis for the formation of these URIs.  These URIs may be
            constructed to allow internal differentiation.  In the future, we 
may
            need a mechanism to provide another level of hierarchy above the
@@ -780,38 +698,29 @@
            following components: 
            
            <list style="numbers">
-             <t>Well-known hostname to get the current root.hints from
-                (lsls)</t> 
-             <t>A place holder for where we can break the scope between
-                organization and upper levels (master)</t> 
-             <t>A zero-conf default name for the organization
-                (internet2.edu)</t> 
-             <t>A way to sub-divide the organization (everything after
-                trailing / )</t> 
-           </list>
-        </t>  
-        
-      </section>
-    
-    </section>    
-    
-    
-    
-    
-      <!-- Search Section -->    
-    
-      <section anchor="search" title="Search">
-      
-        <t>The search operation is obviously critical to the Lookup Service's
+       <t>Well-known hostname to get the current root.hints from
+                (lsls)</t>
+       <t>A place holder for where we can break the scope between
+                organization and upper levels (master)</t>
+       <t>A zero-conf default name for the organization
+                (internet2.edu)</t>
+       <t>A way to sub-divide the organization (everything after
+                trailing / )</t>
+      </list>
+     </t>
+    </section>
+   </section>
+<!-- Search Section -->
+   <section anchor="search" title="Search">
+    <t>The search operation is obviously critical to the Lookup Service's
            function.  It is envisioned that searching could take one of two 
            major forms, iterative and recursive, analogous to those used in 
            DNS.  This design will focus exclusively on iterative initially 
as 
            the only method in the first versions of the dLS. The key act 
when 
            searching is to find what eventTypes exist for a particular
            topology element or set of topology elements.
-        </t>  
-
-        <t>As outlined above, the full data that services register to an LS 
is
+        </t>
+    <t>As outlined above, the full data that services register to an LS is
            not expected to leave the scope of that LS. The information is
            summarized before wider distribution. Therefore, a client needs to
            find an LS in the scope of the HLS to make queries about the 
complete
@@ -820,10 +729,9 @@
            instances) that contain the relevant details. This separation of 
full
            data and summary data means the overall act of searching is broken
            down into two distinct phases - Discovery and Metadata Query.     
 
-        </t>  
-
-           <section anchor="discovery" title="Discovery Phase">
-             <t>The discovery phase is used to locate the set of 
Authoritative LS 
+        </t>
+    <section anchor="discovery" title="Discovery Phase">
+     <t>The discovery phase is used to locate the set of Authoritative LS 
                 (or  LSes) for a given Subject/eventType tuple.  This 
requires a 
                 query to be constructed over the Discovery information set 
(which
                 is not described yet, but which must consist of the 3-tuple 
of
@@ -832,30 +740,25 @@
                 map the desired query into a query of the Discovery infoset 
(see 
                 <xref target="LSControl-Discovery" />).
              </t>
-             
-             <section anchor="discovery-alg" title="Discovery Algorithm">
-
-               <t>The discovery algorithm is as follows.</t>
-
-            <list style="numbers">
-                   <t>A client locates an LS of some sort (this may be known
+     <section anchor="discovery-alg" title="Discovery Algorithm">
+      <t>The discovery algorithm is as follows.</t>
+      <list style="numbers">
+       <t>A client locates an LS of some sort (this may be known
                       beforehand via a configuration value, or from
                       bootstrapping).</t>
-               
-                   <t>The client should start by making a discovery query 
(possibly
+       <t>The client should start by making a discovery query (possibly
                       using an API call) to locate an LS that contains the 
data it
                       is interested in. The results of this query will be:
                
                       <list style="numbers">
-                        <t>Failure:  Returned if there is no LS at a higher 
scope
+         <t>Failure:  Returned if there is no LS at a higher scope
                            than the current one, and nothing was found in 
the summary
                            infoset that matches the query.</t>
-               
-                        <t>Referral: This is returned when there is no match 
other
+         <t>Referral: This is returned when there is no match other
                            than a "global wildcard"
                          
-                           <list style="numbers">              
-                             <t>If this LS is not participating in the 
highest
+                           <list style="numbers">
+           <t>If this LS is not participating in the highest
                                 (upper) scope, then it returns the leader of 
its
                                 current scope (or a direct referral to an 
instance
                                 of the next-higher scope.)  This is 
effectively a
@@ -864,132 +767,103 @@
                                 registered to an LS in another scope 
(domain) is
                                 found.
                              </t>
-                           </list>
-                        </t>                         
-               
-                        <t>Success: We define success to mean at least one 
matching
+          </list>
+         </t>
+         <t>Success: We define success to mean at least one matching
                            LS has been returned. The LS must return the 
following:
                
-                           <list style="numbers">              
-                             <t>If this LS is an HLS for the discovery 
query, it
+                           <list style="numbers">
+           <t>If this LS is an HLS for the discovery query, it
                                 returns itself.</t>
-                 
-                             <t>This LS also returns any other HLS instances 
it has
+           <t>This LS also returns any other HLS instances it has
                                 found that match. An LS instance will have 
summary
                                 information from other domains when it is
                                 participating in a higher-level scope (such 
as
                                 upper).</t>
-               
-                             <t>Note: this is where recursive searches would 
be added
+           <t>Note: this is where recursive searches would be added
                                 into the discovery phase. The trail up the 
scope
                                 hierarchy would be followed by the LS itself 
instead
                                 of returning the leader LS. Ideally, this 
list would
                                 be iterated on by the LS so that only leaf LS
                                 instances are returned</t>
-                           </list>
-                         </t>
-                      </list>                    
-                   </t>
-                                       
-                   <t>The client will need to iterate through the list of 
returned
+          </list>
+         </t>
+        </list>
+       </t>
+       <t>The client will need to iterate through the list of returned
                       LS instances. If the LS returns itself, this LS can be 
used in
                       the following Metadata query phase. If the returned LS 
is
                       different, a discovery query should be made to it.</t>
-          
-            </list>
-
-               </section>            
-             
-             </section>
-
-             <section anchor="metadata-query" title="Metadata Query Phase">
-               <t>The Metadata Query Phase with an individual LS is the same 
as
+      </list>
+     </section>
+    </section>
+    <section anchor="metadata-query" title="Metadata Query Phase">
+     <t>The Metadata Query Phase with an individual LS is the same as
                   the query mechanism that is in place with the current LS
                   implementations.
           </t>
-          <t>Once we have found the HLS (or Home LSes) that contain data
+     <t>Once we have found the HLS (or Home LSes) that contain data
              in the range of our discovery query, we can pose Metadata 
Queries
              to each of them. The results will be failure or success.  
           </t>
-
-             </section>
-           
-      </section>  
-
     </section>
-
-
-
-    <!-- Bootstrapping Section -->
-
-    <section anchor="bootstrapping" title="Bootstrapping">
-
-      <t>A distributed information system such as the LS needs to address
+   </section>
+  </section>
+<!-- Bootstrapping Section -->
+  <section anchor="bootstrapping" title="Bootstrapping">
+   <t>A distributed information system such as the LS needs to address
          bootstrapping.  In this system, an LS instance needs to find other
          members of its scope (for each scope in which it participates.) To
          accomplish this we will use a similar solution to what DNS uses
          (root.hints).
       </t>
-
-      <t>We will maintain a service that maintains a list of currently known 
+   <t>We will maintain a service that maintains a list of currently known 
          LS instances. These known instances should preferably be at the 
upper
          scope. All clients can cache this list. The service will be accessed
          via a well-known hostname, and could be requested via UDP messages.
          (We can also use TCP here for some sorts of anycast.)
       </t>
-
-      <t>Initially this will be deployed on one server. We can extend this to
+   <t>Initially this will be deployed on one server. We can extend this to
          handle redundancy and load balancing in the future by using multiple
          DNS records and implementing ANYCAST with routing tricks for this 
well
          known hostname. (Additionally, we can distribute an initial file 
with
          a list of well known LS instances that are supported by the primary
          perfSONAR participants.)
       </t>
-
-      <t>The above discovery algorithm is used to find an LS within a given
+   <t>The above discovery algorithm is used to find an LS within a given
          scope. Therefore, the only piece of information an LS should need to
          be pre-configured with is the scope it belongs to. And as stated 
above,
          that can be assumed to be "global:organization-dns-name". Note: Need
          to define the specific syntax above.
       </t>
-
-
-    </section>
-    
-
-
-    <!-- Examples Section -->
-
-    <section anchor="structures-and-messages" title="Structures and 
Messages">
-           
-           <section anchor="service-metadata" title="Service metadata 
example">
-             <t>Example of metadata describing information collected and 
stored in
+  </section>
+<!-- Examples Section -->
+  <section anchor="structures-and-messages" title="Structures and Messages">
+   <section anchor="service-metadata" title="Service metadata example">
+    <t>Example of metadata describing information collected and stored in
                 Measurement Archive service</t>
-             <t>
-               <artwork>
-                       <![CDATA[
+    <t>
+     <artwork>
+<![CDATA[
                    <inline file="metadata.xml"/>
                  ]]>
-               </artwork>
-             </t>
-           </section>
-
-           <section anchor="lookup-info" title="Lookup Information">
-             <t>Example Lookup Information of Measurement Archive. The 
metadata block
+     </artwork>
+    </t>
+   </section>
+   <section anchor="lookup-info" title="Lookup Information">
+    <t>Example Lookup Information of Measurement Archive. The metadata block
                 contains basic service information and data elements 
containing
                 the metadata from the MA.</t>
-             <t>
-               <artwork>
-                       <![CDATA[
+    <t>
+     <artwork>
+<![CDATA[
                    <inline file="service.xml"/>
                  ]]>
-               </artwork>
-             </t>
-           </section> 
-           
-           <section anchor="LSRing" title="LS Ring File Structure">
-
-             <t>
+     </artwork>
+    </t>
+   </section>
+   <section anchor="LSRing" title="LS Ring File Structure">
+    <t>
                The LSRing file represents the "state" of the LS cloud at 
either 
                level of hierarchy (we avoid using the terms "global" and 
"local" 
                here since the hierarchy may be much larger).  This file must 
start 
@@ -997,25 +871,34 @@
                goes on.  As such implementations must ensure that this file 
is under
                database control of some sort.  
              </t>
-             <t>
+    <t>
           Each metadata description contains the usual service level info, 
as 
           well as a "voting" parameter (labeled as "contentSize") used to 
           decide who the leader is, and a flag indicating if the current 
           service thinks the remote service is active.  Both of these should
           be updated frequently as reality changes.  
-             </t> 
-
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSRing.xml"/>
-                 ]]>
-               </artwork>
              </t>
-           </section>      
-
-           <section anchor="LSControl-Join" title="LS Joining Message for 
Joining a Ring">
-             <t>
+    <section anchor="LSRingLower" title="LS Ring lower level">
+     <t>
+      <artwork>
+<![CDATA[
+                      <inline file="LSRing-lower.xml"/>
+                    ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSRingUpper" title="LS Ring upper level">
+     <t>
+      <artwork>
+<![CDATA[
+                      <inline file="LSRing-upper.xml"/>
+                    ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Join" title="LS Joining Message for Joining a 
Ring">
+    <t>
           This message exchange represents when a "new" LS instance
           comes online.  The LS will send these messages to its "list" of
           known LS instances until it gets a hit.  The message consists
@@ -1023,7 +906,7 @@
           and a parameter indicating "size" of the data set the LS
           manages.  This will be used for leader voting purposes later.
              </t>
-             <t>    
+    <t>    
           The response message should indicate success or failure via 
            the eventType, and will contain metadata/data pair(s).  The 
metadata 
            should indicate who the service is, and its "size" for voting
@@ -1031,186 +914,225 @@
            members of the ring and their votes.  This information gives the 
            new member a snapshot of the ring.
              </t>
-
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSControl-Join.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section>   
-           
-           <section anchor="LSControl-Token" title="LS Token Message">
-             <t>
+    <section anchor="LSControl-JoinRequest" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                      <inline file="LSControl-JoinRequest.xml"/>
+                    ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSControl-JoinResponse" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                             <inline file="LSControl-JoinResponse.xml"/>
+                             ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Token" title="LS Token Message">
+    <t>
           This message exchange represents the token that is passed between
           LS instances in a cloud.  The message contains metadata/data 
pair(s)
           wherein the Metadata is the sending LS's info, and the data 
contains
           the contents of the LSRing file (lower or upper depending on the 
           token we are exchanging). 
              </t>
-             <t>     
+    <t>     
           The response to this message should indicate success or failure.  
           Failure and timeouts should trigger a resend.   
              </t>
-           
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSControl-Token.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section> 
-
-           <section anchor="LSControl-Summary-lower" title="LS Summary 
Message (Lower)">
-           
-             <t>
+    <section anchor="LSControl-TokenRequest" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                             <inline file="LSControl-TokenRequest.xml"/>
+                             ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSControl-TokenResponse" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                                      <inline 
file="LSControl-TokenResponse.xml"/>
+                                      ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Summary-lower" title="LS Summary Message 
(Lower)">
+    <t>
           This message exchange represents when an LS instance is holding 
           the token and sharing summary information (lower scope).  The 
message 
           consists of metadata/data pair(s) that contain service information
           and a parameter indicating "size" of the data set the LS
           manages as well as the minimal (without parameters) summary.
              </t>
-             <t>
+    <t>
           The response message should indicate success or failure via 
           the eventType, and will contain metadata/data pair(s).  The 
metadata 
           should indicate who the service is, and its "size" for leader 
voting
           purposes.  The data section is message that can be used for 
logging.
              </t>
-             <t>     
+    <t>     
           When receiving the message, check your local list and update it as
           needed for:
           <list type="symbols">
-            <t>Do you know of this service?  If so make sure the vote and 
other
+      <t>Do you know of this service?  If so make sure the vote and other
                info is ok.</t>
-            <t>Update the summary info in your collection</t>
-            <t>If you don"t know of them, add them!</t>
-          </list>
-             </t>
-           
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSControl-Summary2.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section>   
-           
-           <section anchor="LSControl-Summary-upper" title="LS Summary 
Message (Upper)">
-           
-             <t>
+      <t>Update the summary info in your collection</t>
+      <t>If you don"t know of them, add them!</t>
+     </list>
+    </t>
+    <section anchor="LSControl-Summary2Request" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                             <inline file="LSControl-Summary2Request.xml"/>
+                             ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSControl-Summary2Response" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                                      <inline 
file="LSControl-Summary2Response.xml"/>
+                                      ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Summary-upper" title="LS Summary Message 
(Upper)">
+    <t>
           This message exchange represents when an LS instance is holding 
           the token and sharing summary information.  The message 
           consists of metadata/data pair(s) that contain service information
           and a parameter indicating "size" of the data set the LS
           manages.  The "data" portion is the summary info (FORMAT TBD!!!)
              </t>
-             <t>
+    <t>
           The response message should indicate success or failure via 
           the eventType, and will contain metadata/data pair(s).  The 
metadata 
           should indicate who the service is, and its "size" for leader 
voting
           purposes.  The data section is message that can be used for 
logging.
              </t>
-             <t>     
+    <t>     
           When receiving the message, check your local list and update it as
           needed for:
           <list type="symbols">
-            <t>Do you know of this service?  If so make sure the vote and 
other
+      <t>Do you know of this service?  If so make sure the vote and other
                info is ok.</t>
-            <t>Update the summary info in your collection</t>
-            <t>If you don't know of them, add them!</t>
-          </list>
-             </t>
-           
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSControl-Summary.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section>      
-
-           <section anchor="LSControl-Leader" title="LS Leader Message">
-
-             <t>
+      <t>Update the summary info in your collection</t>
+      <t>If you don't know of them, add them!</t>
+     </list>
+    </t>
+    <section anchor="LSControl-SummaryRequest" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                             <inline file="LSControl-SummaryRequest.xml"/>
+                             ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSControl-SummaryResponse" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                                      <inline 
file="LSControl-SummaryResponse.xml"/>
+                                      ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Leader" title="LS Leader Message">
+    <t>
           This message exchange will be conducted between the Leader and 
           Vice-Leader on some (frequent) interval.  It may even become a 
part 
           of the Leader's token exchange with the Upper Level.
              </t>
-             <t>
+    <t>
           The leader identifies itself, and sends down the summaries from the
           upper level for the Vice-Leader to store.  If the leader should 
die, 
           the vice leader will have a summary of the upper level and be able 
to
           continue answering lower level queries and obtaining information 
from
           the higher levels.
              </t>
-
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSControl-Leader.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section>      
-
-           <section anchor="LSControl-Discovery" title="LS Discovery 
Message">
-             <t>Structure of the LSDiscovery Message used to locate 
info-sets. 
+    <section anchor="LSControl-LeaderRequest" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                             <inline file="LSControl-LeaderRequest.xml"/>
+                             ]]>
+      </artwork>
+     </t>
+    </section>
+    <section anchor="LSControl-LeaderResponse" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                                      <inline 
file="LSControl-LeaderResponse.xml"/>
+                                      ]]>
+      </artwork>
+     </t>
+    </section>
+   </section>
+   <section anchor="LSControl-Discovery" title="LS Discovery Message">
+    <t>Structure of the LSDiscovery Message used to locate info-sets. 
                 (FORMAT TBD!!!)</t>
-             <t>
-               <artwork>
-                       <![CDATA[
-                   <inline file="LSDiscovery.xml"/>
-                 ]]>
-               </artwork>
-             </t>
-           </section>     
-              
+    <section anchor="LSDiscoveryRequest" title="Request">
+     <t>
+      <artwork>
+<![CDATA[
+                              <inline file="LSDiscoveryRequest.xml"/>
+                              ]]>
+      </artwork>
+     </t>
     </section>
-
-    
-    <!-- Result codes section -->
-    
-    <section anchor="codes" title="Result codes">
-       <list style="symbols">
-         <t>error.ls.foo - </t>
-         <t>success.ls.foo - </t>
-         <t>TBD</t>
-       </list>
-    
+    <section anchor="LSDiscoveryResponse" title="Response">
+     <t>
+      <artwork>
+<![CDATA[
+                                       <inline 
file="LSDiscoveryResponse.xml"/>
+                                       ]]>
+      </artwork>
+     </t>
     </section>
-
-    <section anchor="apdx" title="Appendices">
-
-
-           <section anchor="glossary" title="Glossary">
-             <list style="symbols">
-
-             <t>AuthoritativeLS - LS that is an authority for the perfSONAR
+   </section>
+  </section>
+<!-- Result codes section -->
+  <section anchor="codes" title="Result codes">
+   <list style="symbols">
+    <t>error.ls.foo - </t>
+    <t>success.ls.foo - </t>
+    <t>TBD</t>
+   </list>
+  </section>
+  <section anchor="apdx" title="Appendices">
+   <section anchor="glossary" title="Glossary">
+    <list style="symbols">
+     <t>AuthoritativeLS - LS that is an authority for the perfSONAR
                 services in question.  AuthoritativeLS is a result of 
                 discovery phase and can be used in the metadata query 
phase.</t>
-             
-             <t>Berkeley DB XML - Oracle Berkeley DB XML is an open source, 
+     <t>Berkeley DB XML - Oracle Berkeley DB XML is an open source, 
              embeddable XML database with XQuery-based access to documents 
              stored in containers and indexed based on their content.</t>
-             
-             <t>Bootstraping - It refers to the process of automatically 
finding 
+     <t>Bootstraping - It refers to the process of automatically finding 
                 at service startup other LS instances of the scope utilizing 
                 a previously configured registry.</t>
-             
-             <t>eXist XML DB - eXist is an Open Source native XML database 
+     <t>eXist XML DB - eXist is an Open Source native XML database 
              featuring efficient, index-based XQuery processing, automatic 
              indexing, extensions for full-text search, XUpdate support, 
              XQuery update extensions and tight integration with existing 
              XML development tools.</t>
-             
-             <t>Home LS (HLS) - The Home LS of a Service is the LS where the
+     <t>Home LS (HLS) - The Home LS of a Service is the LS where the
              Service registers its Lookup Information</t>
-             
-          <t>Lookup Service (LS) - The Lookup Service is a key element of the
+     <t>Lookup Service (LS) - The Lookup Service is a key element of the
              perfSONAR framework because it allows every independent service
              to be a visible part of the system. New services may identify
              themselves to the community and provide their detailed
@@ -1218,80 +1140,61 @@
              to the LS in order to get this data called Lookup Information.
              Basic Lookup Service supports registration, query, keepalives
              and de-registration actions (additionally updates?).</t>
-
-          <t>Lookup Information - information registered by a Service in the
+     <t>Lookup Information - information registered by a Service in the
              Lookup Service</t>
-
-          <t>Lower Scope - The scoping paradigm meant to indicate
+     <t>Lower Scope - The scoping paradigm meant to indicate
              inter-domain relationships.</t>
-             
-          <t>LSRing - Represents the state of the LS cloud listing available 
+     <t>LSRing - Represents the state of the LS cloud listing available 
              LS instances</t>
-                         
-          <t>Multidomain / Distributed Lookup Information (mLS) - Lookup
+     <t>Multidomain / Distributed Lookup Information (mLS) - Lookup
              Service which supports summarization and communication with 
other
              Lookup Services (which might be in the same domain...)</t>
-             
-          <t>P2P - network infrastucture that does not have fixed clients 
and servers,
+     <t>P2P - network infrastucture that does not have fixed clients and 
servers,
              but a number of peer nodes that function as both clients and 
servers 
              to the other nodes on the network.  This model is contrasted 
with the 
              client-server model.</t>
-                          
-          <t>Service -  A Service is an application that communicates with
+     <t>Service -  A Service is an application that communicates with
              other perfSONAR Services  via standardized protocol set
              (SOAP+XML+NMWGv2)</t>
-
-          <t>Summary Information - aggregated information from Lookup
+     <t>Summary Information - aggregated information from Lookup
              Information that is sent by one LS to another</t>
-
-                 <t>Token Ring - A ring network in which the network 
topology features 
+     <t>Token Ring - A ring network in which the network topology features 
              nodes connected to exactly two other nodes, forming a circular 
              pathway for signals: a ring. Data travels from node to node, 
              with each node handling every packet.  We use a logical ring in 
              which a "token" message is used to synchronize the 
communication 
              among the nodes.</t>
-             
-          <t>Upper (Global) Scope - The scoping paradigm meant to indicate
+     <t>Upper (Global) Scope - The scoping paradigm meant to indicate
              intra-domain relationships.</t>
-           
-          <t>XSLT - Extensible Stylesheet Language Transformations is an 
+     <t>XSLT - Extensible Stylesheet Language Transformations is an 
              XML-based language used for the transformation of XML documents 
              into other XML or "human-readable" documents. The original 
              document is not changed; rather, a new document is created 
based 
              on the content of an existing one.</t>
-          
-          <t>XQuery - A query language (with some programming language 
+     <t>XQuery - A query language (with some programming language 
              features) that is designed to query collections of XML data. It 
              is semantically similar to SQL.</t>
-             
-             </list>
-           </section>
-
-    </section>
-         
-  </middle>
-
-
-  <back>
-    <references>
-           
-           <reference anchor="tridentcom">
-             <front>
-                     <title>A Scalable Framework for Representation and 
Exchange of Network Measurements</title>
-                     <author initials="J." surname="Zurawski" 
fullname="Jason Zurawski">
-                       
<email></email>
-                     </author>
-                     <author initials="M." surname="Swany"></author>
-                     <author initials="D." surname="Gunter"></author>
-             </front>
-             <seriesInfo>In Proceedings of 2nd International IEEE/Create-Net 
+    </list>
+   </section>
+  </section>
+ </middle>
+ <back>
+  <references>
+   <reference anchor="tridentcom">
+    <front>
+     <title>A Scalable Framework for Representation and Exchange of Network 
Measurements</title>
+     <author initials="J." surname="Zurawski" fullname="Jason Zurawski">
+      
<email></email>
+     </author>
+     <author initials="M." surname="Swany"></author>
+     <author initials="D." surname="Gunter"></author>
+    </front>
+    <seriesInfo>In Proceedings of 2nd International IEEE/Create-Net 
                          Conference on Testbeds and Research Infrastructures 
                          for the Development of Networks and Communities 
                          (Tridentcom 2006)</seriesInfo>
-             <year>2006</year>
-           </reference>
-
-    </references>
-  </back>
-
+    <year>2006</year>
+   </reference>
+  </references>
+ </back>
 </rfc>