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

[Scott Rose <[e-mail]>]

Thanks - we will fix those comments in the next revision.

Scott

On Mar 27, 2012, at 10:02 AM, Alfred HÎnes wrote:

> 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