> On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker > <nore...@ietf.org> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dnsop-dns-zone-digest-13: Yes > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for addressing my discuss (and comment!) points. There are still > a few more threads to tidy up, but I'm happy with the direction we're > going. > > Section 1 > > We (implicitly) mention "integrity" here as provided in the absence of > DNSSEC, but later in Section 1.1 we say that integrity can only be assured > when the zone is signed. I leave it to Roman to say when his discuss is > resolved, but it seems likely that we should be consistent about which way > we go with it.
Looks like I missed that spot in when addressing Roman's point. Now changed
to this:
It allows a receiver of the
zone to verify the zone's integrity and authenticity when used in
combination with DNSSEC.
> Section 1.1
>
> It's perhaps unusual to follow "the motivation for this protocol" with "a
> secondary motivation"; instead writing "the primary motivation" would reduce
> the surprise at seeing a secondary motivation added later.
Agreed. This has been changed.
>
> Section 2.2.2
>
> This change seems to be a regression? The value 1 in question is the
> scheme value, not a Hash Algorithm value. (I would make this a
> Discuss point but I am sure we will get it resolved quickly.)
Oops, I changed that in the wrong place. Now it says "with Scheme value 1"
there
and "with Hash Algorithm value 1" in the next section.
>
> Section 3
>
> (nit) Right now the literal reading of "identical" is that the ZONEMD and
> the signature and the denial-of-existence records are identical, which
> is of course nonsensical. Perhaps adding "to the ones produced by this
> procedure" or similar would reduce the stress for people who habitually
> make sentence diagrams.
Changed to this:
Implementations that deviate from the
described algorithm are advised to ensure that it produces ZONEMD
RRs, signatures, and dential-of-existence records that are identical
to the ones generated by this procedure.
>
> Section 4
>
> I can't tell if there's a duplicate line in the XML source or not, here
> (as an editing leftover), but that's my guess as to what happened. In
> particular, I'm not sure how one would query for a DS RR *in the anchor*.
> If I'm reading the previous thread correctly we were only proposing to talk
> about querying for (and validating) DS RRs in the parent zone, not the
> anchor (whatever that means).
Yes indeed there was a line duplicated during editing. Now:
This is done by examining locally
configured trust anchors, and, if necessary, querying for (and
validating) DS RRs in the parent zone.
>
> Who is going to come to a conclusion on the "[ Maybe remove all the "SHOULD
> report" above and just say this:]"? (I'd be fine with it, for what little
> it's worth, but I don't think my opinion is anywhere close to the most
> relevant one.)
Both you and Rob asked about this -- the possibility of overly verbose
reporting.
I'd like to hear Rob's opinion.
DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
