On 5/13/19 5:17 AM, Brian Dickson wrote:
> Thoughts?
There's the hiding problem due to aggressive caching, especially when
forwarding to a resolver that does aggressive caching (1.1.1.1 is
well-known but there are more).
https://tools.ietf.org/html/rfc8145#section-5.3.1
If the label was extended
On Mon, May 13, 2019 at 11:21 AM Wessels, Duane
wrote:
>
> Thanks for the suggestions. I think the first discussion needs to be whether
> there is support for better signals at the expense of possibly less privacy.
> My sense of the way things are today is that "privacy is king."
>
> DW
I
On Mon, May 13, 2019 at 11:21 AM Wessels, Duane
wrote:
>
>
> > On May 13, 2019, at 10:17 AM, Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
> >
> > The original RFC 8145 gives the ability to gather trust anchor signal
> data.
> >
> > There are limitations related to inferring either
> On May 13, 2019, at 10:17 AM, Brian Dickson
> wrote:
>
> The original RFC 8145 gives the ability to gather trust anchor signal data.
>
> There are limitations related to inferring either reasons for behavior
> observed on the aggregate volumes, or identifying originating
>
The original RFC 8145 gives the ability to gather trust anchor signal data.
There are limitations related to inferring either reasons for behavior
observed on the aggregate volumes, or identifying originating
resolvers/forwarders versus upstream resolvers/forwarders (which could
include both NAT
