Re: [DNSOP] Cache utilization review and suggestion for EDNS client-subnet

[Yuri Schaeffer <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Mukund,

> The draft doesn't state that the answer is for the SOURCE
> PREFIX-LENGTH when SCOPE > SOURCE. At all other times, the answer
> is meant to be cached at the SCOPE PREFIX-LENGTH.

I indeed use SCOPE to determine where the answer would fit in the tree
in my cache. But that doesn't mean I discard SOURCE. I still need
SOURCE to determine if this cache entry is applicable to the next
query. There's no contradiction here.

> I quote the draft (all that's there on the topic):
> 
>> The SCOPE PREFIX-LENGTH in the response indicates the network
>> for which the answer is intended.
>> 
>> A SCOPE PREFIX-LENGTH value longer than the SOURCE PREFIX-LENGTH 
>> indicates that the provided prefix length was not specific enough
>> to select the most appropriate Tailored Response.  Future queries
>> for the name within the specified network SHOULD use the longer
>> SCOPE PREFIX-LENGTH.
>  Where does it say that the answer is for the SOURCE
> PREFIX-LENGTH?

Even without it being mentioned explicitly it is clear to me that this
text means I get a suboptimal response given the SOURCE PREFIX-LENGTH
provided. Not that I would get a /wrong/ response.

>> You seem to imply that a SCOPE > SOURCE means an answer from
>> further down the tree. But I think it doesn't, or at least it
>> shouldn't. The SCOPE is not tied to an answer but rather used as
>> an indicator how many bits the authority needs/wants for the
>> most/more specific answer.
> 
> So you are saying that your assumption is more correct than my 
> assumption. :) That may be so, but both are assumptions and because
> we can both assume whatever we want, it would be best to describe
> what the correct meaning and behavior is in the draft, wouldn't you
> agree?

I agree.
But before describing it I would like to convince you my assumption is
more correct. ;)

> Having the auth and resolver sides doing different things in
> different flavours of implementation would lead to incorrect
> caching.

Meh. Suboptimal responses maybe. If you tell me something
authoritatively don't blame me for caching it.

//Yuri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlazPL8ACgkQI3PTR4mhaviNmwCbBmhaQNM+j0IQCwMwlYdblQHq
ZboAn1Y2eqzvij8kz6T3p0OW++lZUkRx
=kGs/
-----END PGP SIGNATURE-----