On Sep 18, 2014, at 11:51 AM, Tim Wicinski <[email protected]> wrote:
> This document has been in WGLC and the working group has done an iteration on
> the document. The authors merged in several sets of changes, first back in
> July, and recently from the feedback from the working group reviewers and
> editors. The opinion is that this version reflects all suggestions and is
> ready to move forward again.
>
> Since the editorial changes are more than we originally expected, we're going
> to open up a Working Group Last Call on this document for another 2 weeks. We
> urge folks to read over the differences in the documents.
>
> This last call will end on October 2nd, 2014.
I did a clean read, and it feels *much* better than the early drafts. I have a
small number of editorial comments, but some bigger questions as well. I
strongly suspect the questions can be answered by small additions to the draft.
At the beginning of 2.1:
For ZSKs, the issue for the zone operator/signer is to ensure that
any caching validator has access to a particular signature that
corresponds to a valid ZSK.
"that corresponds to" seem wrong here. The following may be more accurate (or
it might be wrong...):
For ZSKs, the issue for the zone operator/signer is to ensure that
any caching validator has access to a particular signature has
access to the corresponding valid ZSK.
In 2.2, it says "It is important to note that this does not preclude the
development of key rollover logic"; I can't figure out what "this" refers to.
There are a bunch of things in the two preceding paragraphs that it might mean.
The introduction to 3.1 caught me, and I can't figure out whether or not it is
right.
A DNSSEC key contributes two pieces of information to the validation
process: the DNSKEY itself and the data created from it. In the case
of the validation of an RR, the data created from the DNSKEY is the
RRSIG. Where there is a need to validate a chain or trust, the data
created from the DNSKEY is the DS. In this section, the term
"associated data" refers to the RRSIGs created from a DNSKEY when
discussing a ZSK, or to the DNSKEY's corresponding DS record when
referring to a KSK.
Is the "associated data" for a KSK really just the DS? Shouldn't any RRSIG over
the ZSK that was created by the DSKEY also be "associated data"?
Also in 3.1:
Ready The DNSKEY or its associated data have been published for
long enough to guarantee that any previous versions of
the DNSKEY and/or associated data have expired from
caches.
This is discussing a new key. What is the "previous version"?
Section 3.3.5 is really important to some readers, but it could easily be lost.
There should be a sentence near the end of 1.1 that says "Note that
introduction of first keys is different than rolling a key; see Section 3.3.5
for more information about that topic."
Section 6 really should be Section 1.4. The paragraphs will make it much easier
for someone reading the document who exclaims (to no one in particular) "they
didn't consider X" as they are reading the meat of the document to understand
that the authors probably did think about it, but chose to not include it.
--Paul Hoffman
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
