Late to the party, but FWIW: I also support adoption and am willing to discuss and review this work.
Some comments: - Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver SHOULD support aggressive NSEC usage and enable it by default. This to me seems inconsistent use of the key words. - In section 4.3 I suggest to replace the second paragraph with: If the full-service resolver's cache contains an NSEC3 matching the closest encloser, an NSEC3 covering the next closer name, and an NSEC3 covering the source of synthesis, it is possible for the full-service resolver to respond with NXDOMAIN immediately. Also, what exactly defines a full-service resolver? I think we care about caching and validating only here. - Section 4.3 suggests to build a separate cache of NSEC and NSEC3 resource records for each signer domain name. This to me seems like an implementation detail and is not necessarily required. In fact, a zone may switch from NSEC to NSEC3 and vice versa, so you will need to check them both if you implement it as a separate cache. - I don't see why setting the CD bit is an indication that NSEC(3) aggressive usage should not be used. Could you elaborate on that? - My body shivers when reading that resolvers MAY use NSEC(3) records in a NXDOMAIN response without validating them. Luckily the draft already highly recommends that it should do validation. I would like to make it even stronger and remove the MAY key word here, and perhaps use the formal key word SHOULD do validation. Best regards, Matthijs On 04/26/2016 12:33 AM, Tim Wicinski wrote: > All > > The Call for Adoption has passed and there seems to be strong consensus > to adopt it. Thanks everyone who has signed up to offer review comments, > etc. > > A new version will be uploaded soon by the authors once they incorporate > the comments made during the Call for Adoption. > > thanks > tim > > > On 4/10/16 10:18 AM, Tim Wicinski wrote: >> This was discussed in Buenos Aires Friday morning, but the sense we >> received from the room is that the group should move forward with this >> draft. While we like the simplicity of Warren and Geoff's cheese-shop >> draft (draft-wkumari-dnsop-cheese-shop), it is basically a simple >> proof-of-concept. The suggestion was to document the cheese-shop idea >> in this draft. >> >> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3 >> draft-fujiwara-dnsop-nsec-aggressiveuse >> >> The draft is available here: >> >> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/ >> >> Please review this draft to see if you think it is suitable for adoption >> by DNSOP, and comments to the list, clearly stating your view. *Speak >> Up* if you have strong opposition to this work. >> >> *More Importantly* >> Please also indicate if you are willing to contribute text, review, etc. >> We will want several dedicated reviewers on this. >> >> I'm going to make this a short call for adoption, as we've discussed >> this in a few meetings. >> >> This call for adoption ends 17 April 2016. >> >> Thanks, >> tim wicinski >> DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
