On Jan 15, 2020, at 5:28 PM, Michael StJohns <[email protected]> wrote: > I think its a co-existence issue here. I don't think you should have two > different (calculation-wise) ZONEMD-like RRSets in the same zone for the > reasons you've mentioned.
That makes good sense. When someone defines an incremental zone hash RRtype, that protocol spec should likely either prohibit ZONEMD RRsets, or state that their interpretation is suppressed. The WG can cross that bridge when we see a reasonably filled-out proposal for INCZOEMD. > I don't think that reserving RR types is the right way of doing things and > I'm not sure how you'd write the IANA guidance to cover the later assignment > of those type numbers. Fully agree. > It's possible that we can tweak this a bit and get around the problem. > > So maybe: > > 1 byte - Scheme - 1 == SIMPLE > > Which has a body of > > 1 byte - digest - 1 == SHA384, a > > followed by N bytes of the appropriate digest length. Using a different RRtype would be significantly easier and safer due to applications having clearly separate code paths. --Paul Hoffman
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
