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

[Yuri Schaeffer <[e-mail]>]

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

> Is this example for considering that a 128.0.0.0/4/8 answer is
> different from a 128.0.0.0/4/4 answer when both are available
> answers to be returned by an auth for a 128.0.0.0/4/0 query?

Both 128.0.0.0/4/8 and 128.0.0.0/4/4 could satisfy a 128.0.0.0/4/0
query. But the former *might* motivate me to requery for 1XX.0.0.0/8.

I always read the document as, when receiving a SCOPE > SOURCE answer,
use it to answer the client. But do not use it to reply from cache for
future queries. Ofcourse as an implementer I would still cache it
because I don't want to disclose as much bits as the authority asks
for, but still have caching.

> Other than that, I don't see what saving SOURCE PREFIX-LENGTH
> seperately alongside <address,address-prefix-length> would provide.
> If both answers were treated identically, it can be cached at
> 128.0.0.0/4.

This might be the source of confusion? I don't see a difference
between 'address-prefix-length' and 'SOURCE PREFIX-LENGTH'. Are we in
the end arguing the same thing?

> If any one of these two different answers is found in cache, from
> the description above, you'd use it and not fetch from authority
> (where you might get the other answer for a 128.0.0.0/4 query).
> I.e., this is no different from caching at /SOURCE when SCOPE >
> SOURCE.
> 
> A 128.0.0.0/4/0 query will only have the first 4 ADDRESS bits set.
> So if we consider that a SCOPE > SOURCE answer is an answer to the
> question at all, the answer is only valid for those first 4 ADDRESS
> bits, i.e., SOURCE PREFIX-LENGTH bits. There are no more defined
> bits in ADDRESS. The answer's ADDRESS field has to equal the
> query's ADDRESS field.

Yes!

> It seems the scheme you are describing to save the SOURCE
> PREFIX-LENGTH is used in distinguishing between /SOURCE/SOURCE and
> /SOURCE/(>SOURCE) answers. It was in reply to this comment:
> 
>> 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.
> 
> You are describing what you're doing in implementation. I hope you 
> understand my concern that none of the above is specified.

I understand your concern. I myself am not a fan. OTOH I don't see a
particular problem in this case. Even if implementations don't do
exactly the same.

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

iEYEARECAAYFAlazcAwACgkQI3PTR4mhavjUFQCfQ3ytYuQlEY8a10Q+w5GGkgfG
jXcAniunv0feafIppP3kY2ALWlkC1M2I
=C/8U
-----END PGP SIGNATURE-----