On Tue, Jan 7, 2020 at 10:06 PM Brian Dickson <brian.peter.dick...@gmail.com> wrote:
> > > On Tue, Jan 7, 2020 at 6:18 PM Paul Hoffman <paul.hoff...@icann.org> > wrote: > >> On Jan 7, 2020, at 6:03 PM, Joe Abley <jab...@hopcount.ca >> <jab...@hopcount..ca>> wrote: >> > I don't object to the intended status (standards track). There are >> reports of multiple independent implementations included in the document, >> which seems pleasing and proper. >> >> Definitely proper. The calls for making this RFC "experimental" go >> against the definition for that designation in RFC 2026, Section 4.2.1. >> > > While I think the WG list has been rather quiet on this draft, I think it > is probably best to wait for more responses either way regarding > "experimental" vs "proposed standard". > > (ibid) section 4.1 and 4.1.1 does make reference to the maturity level of > standards track documents, and includes the possibility of changes or even > subsequent withdrawal of a standard based on experience. > > I concur with Joe, in that the document seems pretty clear, and I support > moving it forward in the standards track. > > My $0.02 on the size issue: > I think the onus should be on whoever is publishing a zone with a ZONEMD > to provide guidance on what to do if a failure occurs. > Similarly, publishers should be sensible on whether to include a ZONEMD > based on total size and rate of change. > > The onus is on operators to operate their infrastructure with appropriate > levels of caution. > Blindly turning on processing of ZONEMD on zones from random senders might > not be wise. > > Brian > Good point. Perhaps the RFC should recommend that there be per-zone options for enabling ZONEMD processing, and perhaps rate limits? -- Bob Harold
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
