Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-resolver-priming-09: (with COMMENT)

["Paul Hoffman" <[e-mail]>]

[[ 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?

>> 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".

--Paul Hoffman