retext section 3. Sentinel Mechanism to make it clearer

[pspacek]

Section 3. Sentinel Mechanism gave me hard time while implementing this mechanism, so I'm proposing to overhaul the section into something with more structure.

Proposal:
(Feel free tp change and restructure it as you see fit, I'm not native English speaker ...)

3.  Sentinel Mechanism

   DNSSEC-Validating resolvers that implement this mechanism MUST be
   performing validation of responses in accordance with the DNSSEC
   response validation specification [RFC4035].

   This sentinel mechanism makes use of 2 special labels:
   -  "kskroll-sentinel-is-ta-<tag-index>.
   -  "kskroll-sentinel-not-ta-<tag-index>.
   <tag-index> is: 4 hexadecimal digits encoding number in range
<0,2^16-1> + TODO: ABNF, zero padded from the left

   These labels trigger special processing in the resolver as specified
bellow. Labels containing "is-ta" and "not-ta" are used to answer
questions "Is (or is not, respectivaly) this the key tag a trust anchor
which the validating DNS resolver is currently trusting?"

   Processing of both labels has the very same preconditions for both
labels and differs only in last step.

3.1. Preconditions
   All following conditions must be met to trigger special processing
inside resolver code:

   a) DNS response for particular query is DNSSEC validated and result
of validation is SECURE
   b) QTYPE is A or AAAA
// TODO: what about QCLASS? Maybe we can ignore it as DNSSEC is (I
believe) class independent ...
// TODO: OPCODE == QUERY ? It would not hurt to specify it explicitly.

   c) leftmost label must be one of "kskroll-sentinel-is-ta-<tag-index>.
// TODO: Clarify if it is okay to alter responses if:
- QNAME owner holds CNAME
- RCODE != NOERROR

   If all preconditions are not met, the resolver MUST NOT alter the DNS
response.


3.2 Special processing

   Responses which fullfill all preconditions in section 3.1 are subject
of special processing, depending on leftmost label of the QNAME.

   First, the resolver determines if the numerical value of <tag-index>
equals to keytag of a Root Zone Key Signing Key which is currently
trusted by the local resolver and is stored in its store of trusted keys.

   As second step, the resolver alters response depending on meaning of
the label and presence of key with given keytag among trusted keys. Two
labels and two possible states of the keytag generate four possible
combinations summarized in the table:

                           Keytag trusted
label type |       yes               |       no
--------------------------------------------------------------
is-ta      | return original answer  | return SERVFAIL
not-ta     | return SERVFAIL         | return original answer


// TODO: clear up interaction with caching, CD bit, AD bit, ...

I would be happy to work more on this particular section because I've already felt pain while implementing this.