Hi, Paul, On Tue, Dec 6, 2016 at 8:39 PM, Paul Hoffman <paul.hoff...@vpnc.org> wrote:
> [[ BTW, sorry for not changing the subject line on this thread. It really > does relate to all the IESG comments, not jus Ben's. ]] > > On 6 Dec 2016, at 18:32, Spencer Dawkins at IETF wrote: > > On 30 Nov 2016, at 22:48, Spencer Dawkins wrote: >>> >>> I find myself curious about both SHOULDs in >>> >>>> >>>> Resolver software SHOULD treat the response to the priming query as a >>>> normal DNS response, just as it would use any other data fed to its >>>> cache. Resolver software SHOULD NOT expect exactly 13 NS RRs. >>>> >>>> Do you think these SHOULDs (especially the first one) are required for >>>> interoperation? >>>> >>>> >>> Yes. >>> >>> I'm wondering (1) why they aren't MUSTs, and (2) why RFC >>> >>>> 2119 language is actually needed at all. If they are RFC 2119 SHOULDs, >>>> what happens if the resolver software violates them? >>>> >>>> >>> We cannot tell. For the first one, if a resolver treats the response to >>> the priming query in a special way, we don't know what "special" means. >>> >> >> >> I'm somewhat curious about why this isn't a MUST, but ... ok. >> > > For example, an implementation might treat the responses special by > altering the TTLs based on some understanding that the vendor has that only > is relevant to priming queries. Why prevent that? That wasn't my intention. Thanks for indulging my curiosity. Sometimes, I'm a curious guy ;-) > > > For the second one, if a resolver expects exactly 13 NS RRs and gets >>> fewer, we don't know what it will do (fail to come up? retry incessantly? >>> ...?) >>> >>> >> I'm really curious about why this is not a MUST - can anything good happen >> when you expect 13 NS RRs? Usually, we're saying "SHOULD NOT, unless you >> can assess the risks of doing it". Is that possible, in this case? >> > > We could certainly say "SHOULD NOT expect exactly 13 NS RRs because > historically some root servers have returned fewer". That is exactly the kind of thing that seems uber-helpful to mention! Thanks for the background. Spencer
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
