[dnsext] draft-crocker-dnssec-algo-signal-04 editorials

[Alfred Hönes <ah@TR-Sys.de>]

I have a few, mostly editorial suggestions to further improve the
most recent version of your DNSSEC 'Algorithm-Signal' draft,
    draft-crocker-dnssec-algo-signal-04.


(1)  General -- grammar

"The DNS Security Extensions ..." is plural, but the draft says
"... was developed" -- shouldn't it better say "... were developed" ?
This affects the Abstract and the Introduction (para 1, see below).


(2)  Section 1

(2a)  1st para -- textual improvement

I suggest to improve the readability by shuffling the words in the
first sentence, and apply item (1) above:

   The DNS Security Extensions (DNSSEC) was developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures [RFC4033], [RFC4034] and [RFC4035].  [...]
---
   The DNS Security Extensions ("DNSSEC", [RFC4033], [RFC4034] and
   [RFC4035]) were developed to provide origin authentication and
   integrity protection for DNS data by using digital signatures.  [...]

(2b)  paragraph shuffling

Currently, the *last* paragraph of the Introduction introduces the goal
of the memo and the proposed means to achieve it (and EDNS option),
but already the second para refers to "This proposed EDNS option".
This breaks the flow of the reasoning.  Therefore, I suggest to move
the 4th para up, making it the second one.


(3)  Section 2

(3a) 1st para -- improvement

The current text ...

|  Below shows how the signaling attribute is defined in the RDATA of
|  the OPT RR as specified in [RFC2671]:

... seems to be a bit unpleasant; "Below" usually is not conceived
as a noun.  I suggest to insert a proper noun for improved readability.
Also, the "as" in the second line seems to introduce ambiguity as to
what has been defined in RFC 2671; I suggest to drop it.

   vvvvvvvvvvvv
|  The figure below shows how the signaling attribute is defined in the
|  RDATA of the OPT RR specified in [RFC2671]:
                      ^

(3b) last para -- clarification / consistency

The current version of the text is not consistent with the subsequent
explanations; it looks like the original concept of 'staging' algo
numbers by value has survived here.  Since doing so would constrain
IANA in the allocation of new numbers and force implementations to
keep support for older algos (with numerically lower code) forever,
I thought this idea had been abandoned.
Also, the phrase "ALG-CODE is the ... algorithms" is unpleasant
and arguably bad grammar, since "ALG-CODE" designates the a single
code point in the diagram, which is then repeated arbitrarily.

So altogether I suggest the following change:

|  ALG-CODE is the assigned DNSSEC algorithm codes that the client
|  indicates as understood.  The values MUST be in descending order,
|  with the highest algorithm code first, followed by as many other
|  codes as the validator wishes to signal that it prefers.  [...]
---vvvv         vvvvvvvvvvvvvvvv
|  The ALG-CODE values designate the assigned DNSSEC algorithm codes
   that the client indicates as understood.  The values MUST be in
|  descending order of preference, with the most preferred algorithm
                   ^^^^^^^^^^^^^^           ^^^^^^^^^^^^^^
   code first, followed by as many other codes as the validator wishes
|  to signal that it understands.  [...]
                     ^^^^^^^^^^^

(4)   Section 3, 1st para

Accordingly, the text in the 1st para of Section 3 should be adjusted
for clarity and consistence:

   A validating end-system resolver sets the AU option in the OPT
   meta-RR when sending a query.  The validating end-system resolver
|  sets the value(s) in the order of preference, with highest algorithm
   value first as described in section 2.  The end-system resolver MUST
   also set the DNSSEC-OK bit [RFC4035] to indicate that it wishes to
   receive DNSSEC RRs in the response.
---
   A validating end-system resolver sets the AU option in the OPT
   meta-RR when sending a query.  The validating end-system resolver
|  sets the value(s) in the order of preference, with the most preferred
                        v                             ^^^^^^^^^^^^^^^^^^
|  algorithm value first, as described in section 2.  The end-system
   resolver MUST also set the DNSSEC-OK bit [RFC4035] to indicate that
   it wishes to receive DNSSEC RRs in the response.


(5)  Section 3.1

(5a)  1st para

The second comma separates two full sentences and should therefore
better be replaces by a semicolon (or a period, if you prefer):

   Typically, stub resolvers rely on an upstream recursive server (or
|  cache) to provide a response, any algorithm supportence on the stub
   resolver's side could be overruled by the upstream recursive server.
---
   Typically, stub resolvers rely on an upstream recursive server (or
|  cache) to provide a response; any algorithm supportence on the stub
   resolver's side could be overruled by the upstream recursive server.

(5d)  3rd para -- typo?

I suggest to  s/therefor/therefore/ .

[ My dictionary classifies the former variant as "obsolete form used in
  jurisprudence".  IANAL, but the latter indeed seems more common. :-) ]


(6)  Section 6, 2nd para -- typo

Please  s/in order ot/in order to/ .
                   ^^          ^^

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  ah@TR-Sys.de                     |
+------------------------+--------------------------------------------+