Re: [dnsext] WGLC on draft-ietf-dnsext-dnssec-algo-signal-05

[Alfred Hönes <[e-mail]>]

A have a few more, mostly editorial comments on
          draft-ietf-dnsext-dnssec-algo-signal-05
(trying to avoid duplicates of items already mentioned this week
in review comments on the list):


1)  General Terminology  (mostly in Section 1), and some nits

* Sect. 1, 2nd para:

"DS" should be spelled out "Delegation Signer", not "Delegated Signer"
-- cf. RFC 3034, sect. 2, "Definition of DNSSEC Terms").
Also, a comma should be placed in front of "like" in that para.

* Sect. 1, 3rd para:

The draft should not say "EDNS attribute" in one place, always more
precisely "EDNS option" (see snippet below).

* Sect. 1, 3rd para, and Sect. 8, 2nd line:

The hashes used in DNSSEC are cryptographic functions/algorithms as
well. Using "cryptographic algorithm" in some places as a substitute
for "[cryptographic|digital] signature algorithm" seems confusing.
This should be fixed.

Additionally, for enhanced clarity, I suggest to shuffle the words
a bit and improve the language in the 3rd para of Section 1:

OLD:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server which cryptographic and/or hash algorithms
   they support in a DNS query.  This is done using the EDNS attribute
   values in the OPT meta-RR [RFC2671].

NEW:
   This draft sets out to specify a way for validating end-system
   resolvers to tell a server in a DNS query which digital signature
   and/or hash algorithms they support.  This is done using the new
   EDNS options specified below in Section 2 for use in the OPT meta-RR
   [RFC2671].


2)  "EDNS" vs. "EDNS0"

The EDNS framework is designed to allow expansion while maintaining
backward compatibility, and one method to achieve this is based on
the versioning rules from RFC 2671[bis].  Therefore, we should better
avoid referring specifically to "EDNS0" or "EDNS(0)" when mentioning
facts that are expected to remain strictly unchanged in future EDNS
versions (however unlikely their occurrence may seem now).

In particular, I suggest to  s/EDNS0/EDNS/  twice in the 1st para
of Sect. 2, once in the 2nd para of Sect. 6, and once in Sect. 8.


3)  error in example ??

In the last para of Section 2, the byte counts given apparently
do not match the other information.  I suspect the figures have
inadvertently not been updated upon the change in the EDNS option
structure the draft has undergone.
IMHO, "16-24 octets" should read "24-34 octets":

OLD:

   However, in practical terms including all three options are likely to
|  take up 16-24 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

NEW:
                              v                             vv
|  However, in practical terms, including all three options is likely to
|  take up 24-34 octets (average of 6-10 digital signature algorithms,
           ^^^^^
   3-5 DS hash algorithms and 1-5 NSEC3 hash algorithms) including the
   EDNS option codes and option lengths in a reasonable potential future
   example.

(Note that "including" acts as the subject in this sentence, so the
verb "are" needs to be in singular form, "is"; I also added a comma.)

The lower bound (22) corresponds to the lower counts mentioned,
and the upper bound to the upper counts each:

-  fixed overhead for DAU:    4 octets  \
-  code list for DAU:      6-10 octets  / 10-16 octets
-  fixed overhead for DHU:    4 octets  \
-  code list for DHU:       3-5 octets  /  7-9  octets
-  fixed overhead for N3U:    4 octets  \
-  code list for N3U:       3-5 octets  /  7-9  octets
++++++++++++++++++++++++++++++++++++++++++++++++++++++
total:                                    24-34 octets


4)  typo in Sect. 3, 2nd para

OLD:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes for cover a potentially wide range of algorithms and
                   ^^^
   are likely not useful to a server.  [...]

NEW:

   Note that the PRIVATEDNS (253) and/or the PRIVATEOID (254) digital
|  signature codes both cover a potentially wide range of algorithms and
                   ^^^^
   are likely not useful to a server.  [...]


5)  Section structure

The current sections 3.2 and 3.3 are, from a logical/semantical
perspective, subordinate to the current Section 3.1 in the same
way as Sections 3.4.1 and 3.4.2 are subordinate to Section 3.4.
I suggest to restructure s3.1-3.3 and renumber the rest of s3:

    3.2    -->  3.1.1
    3.3    -->  3.1.2
    3.4    -->  3.2
    3.4.1  -->  3.2.1
    3.4.2  -->  3.2.2


6)  Reference update

The revised EDNS0 specification is ahead in the IESG, therefore I
suggest to update the citations to RFC 2671 toward the 'bis' document.


Best regards,
  Alfred.

_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext