> On Oct 24, 2018, at 12:16 AM, Paul Hoffman <[email protected]> wrote: > > Section 5 says: > > FOR DISCUSSION: The authors are willing to remove the Reserved field > from this specification if the working group would prefer it. It > would mean, however, that a future version of this protocol designed > to efficiently support large, dynamic zones would most likely require > a new RR type. > > Please strongly consider removing the Reserved field so that designing an way > to do a message digest over a dynamic zone can be done independently. > > Quite frankly, if the Reserved field isn't there and it's clear that this is > for complete zones, I see no reason why this should even be considered > experimental. The mic line at the presentation at the recent DNS-OARC seems > to agree with wanting this for real, as soon as possible.
Thanks for the feedback, Paul. Personally I feel like keeping the Reserved field is potentially useful in the future, but harmless if it never gets used. Can you say more about why keeping it prevents independent work? I would be very happy with standards track, but to the extent the WG is skeptical I would settle for experimental at this time. DW
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
