Hi Richard, thanks for the review.
This and the earlier messages makes me think that perhaps it would be better to
bump the digest type (while possibly using the same hash algorithm) in a future
revision, when the reserved field takes on meaning.
> On Sep 10, 2019, at 10:10 PM, Richard
The following excerpts allow for and even encourage software written
against this document in its present form to behave in ways that will
hinder adoption of future changes, and should probably be altered in
order to foster the desired compatibility.
Section 2 requires "Each ZONEMD RR MUST
Thanks Shane & George, I agree this needs some clarification.
Something thats probably missing from the document is that in any future
revision of ZONEMD we expect backwards compatibility. For this version, it is
expected that Reserved is set to zero. In a future version, if the formerly
This is a not uncommon problem in 'make this protocol work in future' spec.
It could say "for version ZERO of this protocol" and then say "future
versions of this protocol should stipulate what other values mean, and how
this affects handling of all-zeros state, and other states"
Saying "must not
Duane,
On 2019-09-06 02:01, Wessels, Duane wrote:
With this version the authors feel that it is ready for working group last call.
Sorry for a late comment, but I decided to give this one thorough last
read-through.
I'm a little concerned that the way the Reserved field is described may
Dear DNSOP,
The primary change between -00 and -01 is the simplification of the
verification protocol
when multiple ZONEMD RRs are present, per the on-list discussions.
Additionally Shane Kerr kindly updated his implementation and confirmed that
his and the
author's implementations produce and
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
