Re: [DNSOP] Benjamin Kaduk's Yes on draft-ietf-dnsop-dns-zone-digest-13: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Hi Duane,

Thanks -- this all sounds good (and it sounds like Rob is okay with the new
thought for text about reporting, as well).

Thanks again!

-Ben

On Mon, Oct 12, 2020 at 03:54:02PM +0000, Wessels, Duane wrote:
> 
> 
> > On Oct 11, 2020, at 9:03 PM, Benjamin Kaduk via Datatracker <[e-mail]> 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
> 
>