clean up record processing, exising write-up failed on some corner cases and was not as well-ordered as it could have been

1 files changed, 51 insertions, 34 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 485351a..1112353 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -1913,50 +1913,67 @@ example.com = zk2
          <t>
            Upon receiving the RRBLOCK from the storage, as part of verifying the
            provided signature, the resolver MUST check that the SHA-512 hash of the
-           derived authoritative zone key zk' from the RRBLOCK matches the query q.
-           If not, the RRBLOCK MUST be ignored and, if applicable, the storage
-           lookup GET(q) MUST continue to look for other RRBLOCKs.
+           derived authoritative zone key zk' from the RRBLOCK matches the query q
+           and that the overall block is not yet expired.
+           If the signature does not match or the block is expired, the RRBLOCK MUST
+           be ignored and, if applicable, the storage lookup GET(q) MUST continue to
+           look for other RRBLOCKs.
          </t>
        </section>
        <section anchor="record_processing" numbered="true" toc="default">
          <name>Record Processing</name>
-   <t>
-           Record processing occurs at the end of a single recursion. We assume
-           that the RRBLOCK has been cryptographically verified and decrypted.
-           At this point, we must first determine if we have received a valid
-           record set in the context of the name we are trying to resolve:
+         <t>
+           Record processing occurs once a well-formed block was decrypted.
+           In record processing, only the valid records thus
+           obtained are considered.  To filter records by validity, the resolver
+           MUST at least checking the expiration time and the FLAGS of the
+           respective record.  In particular, FLAGS may exclude shadow and
+           supplemental records from being considered. The next steps depend
+           on the context of the name we are trying to resolve:
          </t>
-   <ul>
+         <ul>
          <li>
            Case 1:
-           If the remainder of the name to resolve is empty and the record set
-           does not consist of a delegation, CNAME or DNS2GNS record,
-           the record set is the result and the recursion is concluded.
+           If the filtered record set consists of a single CNAME,
+           the remainder of the name is prepended to the CNAME and the
+           recursion is started again from the resulting name.
+           Details are described in <xref target="cname_processing" />.
+         </li>
+         <li>
+           Case 2:
+           If the filtered record set consists exclusively of a one or more DNS2GNS records
+           resolution continues with DNS.
+           Details are described in <xref target="gns2dns_processing" />.
          </li>
-   <li>
-     Case 2:
-     If the name to be resolved is of the format
-     "_SERVICE._PROTO" and the record set contains one or more matching BOX
-     records, the records in the BOX records are the result and the recursion
-     is concluded (<xref target="box_processing" />).
-   </li>
          <li>
            Case 3:
-           If the remainder of the name to resolve is not empty and
-           does not match the "_SERVICE._PROTO" syntax, then the current record set
-           MUST consist of a single delegation record (<xref target="delegation_processing" />),
-           a single CNAME record (<xref target="cname_processing" />),
-           or one or more GNS2DNS records (<xref target="gns2dns_processing" />),
-           which are processed as described in the respective sections below.
-           The record set may include any number of supplemental records.
-           Otherwise, resolution fails
-           and the resolver MUST return an empty record set.
-
-     Finally, after the recursion terminates, the client preferences
-     for the record type MUST be considered and possible conversions such as
-           defined in <xref target="vpn_processing" /> MUST be performed.
-     </li>
-   </ul>
+           If the remainder of the name to resolve is empty
+           the record set (including supplemental records)
+           is the final result and the recursion is concluded.
+         </li>
+         <li>
+           Case 4:
+           If the remainder of the name to be resolved is of the format
+           "_SERVICE._PROTO" and the record set contains one or more matching BOX
+           records, the records in the BOX records are the final result and the recursion
+           is concluded (<xref target="box_processing" />).
+         </li>
+         <li>
+           Case 5:
+           If the current record set
+           consist of a single delegation record (<xref target="delegation_processing" />),
+           resolution of the remainder of the name is delegated to
+           the target zone as described in <xref target="delegation_processing" />.
+         </li>
+         <li>
+           Otherwise, resolution fails and the resolver MUST return an empty record set.
+        </li>
+        </ul>
+        <t>
+        Finally, after the recursion successfully terminates, the client preferences
+        for the record type MUST be considered and possible conversions such as
+        defined in <xref target="vpn_processing" /> MUST be attempted.
+        </t>
          <section anchor="delegation_processing" numbered="true" toc="default">
            <name>Zone Delegation Records</name>
            <t>