On Mon, 29 Oct 2018, Wessels, Duane wrote:
The feedback I have received regarding this point has been mixed. I have some folks saying "make it work with stable zones now, figure out dynamic zones later" and others saying "have to support incremental updates now."
This is why the authors propose proceeding with the Reserved field at this time. If it later turns out we can agree on a way to support incremental updates by using this 8-bit field, then that would be great. If not, we can, as you say, consume another RR type and the wasted 8-bits stays Reserved indefinitely.
This seems fine, although rather than yet another document, I think it would be better to handle it right the first time in this document.
This was a point of discussion in earlier revisions: FOR DISCUSSION: the serial number is included in order to make DNS response messages of type ZONEMD meaningful. Without the serial number, a stand-alone ZONEMD digest has no association to any particular zone file. If there is agreement that ZONEMD responses are not useful, this field could be removed. See also the end of Security Considerations. Based on feedback from that revision, seems like there was consensus to keep the Serial field and allow ZONEMD queries/responses.
Makes sense to me.
I was thinking it would be useful to have ZONEMD digest types track DS digest types, so that it wouldn't require a new RFC to define a new ZONEMD digest type. But I'm not sensing much support for this approach.
I think I lean towards not doing this, just so that when a new DS digest type is introduced, people don't have to update the zonemd code (or forget to do this, and thus limiting the real zonemd digest that can be used in practise)
As an implementor, you would be okay with, say SHA384 having value 4 when used in as a DS digest type, but value 1 when used as a ZONEMD digest type?
As a non-DNS implementor, I see no problem with this. Paul _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
