At Wed, 10 Aug 2016 16:54:39 -0700, "Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
> [[ A month later, we're still eager to hear responses to the draft. We > got a few that we have incorporated for a new version, but want to be > sure we're on the right track before we move ahead. ]] > > We understand that "specify more than one" is often an unpopular > > choice in the IETF, about as unpopular as "don't get consensus on > > one". This is a WG document so we need consensus even to go with two > > ways. We look forward to hearing from you about this choice and how we > > can move forwards. On this specific point I don't have a strong opinion. Personally, I can live with the two-solution approach if it's deemed to be nearly impossible to reach consensus on a single solution. While I'd definitely prefer a single solution, the current draft seems to provide a reasonable explanation on why we have two at least for now. Some specific comments on the 02 version follows: - Section 1.1 (or for general discussion): another obvious downside of the QNAME-based approach is that it can't be used for all possible zone names because of the size limitation (255 octets) while adding extra label. In practice, this is less likely to be a real issue since trust anchors would only be configured a higher level zones. But I think it's worth mentioning explicitly. - Section 4.3 A responder MUST NOT include the edns-key-tag option in any DNS response. I wonder whether it might be useful for a responder to signal its capability of understanding the option, either by including this option in the response or in some other way. Then the resolver may use that information to suppress further unnecessary generation and inclusion of the key-tag option. Not a strong opinion, but raising it just in case it's worth considering. - Section 5.3 Unless the zone operator has intentionally added "_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN response. Perhaps a pedantic comment, but I suspect this is not 100% accurate in that it could legitimately result in other response than NXDOMAIN, e.g., if there's a wildcard that would match the "_ta_xxxx" name even if (a record of) that specific name itself isn't added to the zone. On the other hand, ignoring this nitpicking this requirement seems to be too obvious; if a name really doesn't exist in the zone, the server MUST surely return an NXDOMAIN, but it's not specific to this protocol, right? So, in the end, I'd primarily suggest just removing this sentence. Then we don't have to worry about making it very accurate, while IMO not leaving any obscure points. - Section 5.3.1 Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec- aggressiveuse] may also affect the quality of key tag signaling. (nit) nsec-aggressiveuse is now a dnsop wg document. - Section 5.3.1 When the response code for a key tag query is NXDOMAIN, DNS resolvers that implement aggressive negative caching will send fewer key tag queries than resolvers that do not implement it. In the context of the interaction with nsec-aggressiveuse, I think this should be more generalized than the response to a key tag query itself, e.g.: When a query results in an NXDOMAIN response with NSEC or NSEC3 that covers the name of a key tag query, DNS resolvers that implement aggressive negative caching will send fewer key tag queries than resolvers that do not implement it. -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
