►
From YouTube: IETF101-DPRIVE-20180321-1330
Description
DPRIVE meeting session at IETF101
2018/03/21 1330
https://datatracker.ietf.org/meeting/101/proceedings/
A
C
All
right
we're
gonna
go
ahead
and
get
started
if,
if
you're
not
here
for
the
Rock
and
Roll
Hall
of
Fame,
you
can
step
outside
now
sorry
Joe,
alright,
everybody!
This
is
the
deprived
working
group.
If
you
weren't
intending
to
be
here
too
bad,
we
locked
the
doors
I'm
Brian.
This
is
Tim,
where
your
we're
your
host
for
the
evening
afternoon,
whatever
first
things
first,
everybody
loves
us.
I
had
to
put
it
on
two
slides
note.
Well
behave
yourselves.
Follow
the
rules
read
this.
C
C
C
D
So
the
status
of
these
traps
is
that
it's
very
much
a
draft
right.
It's
full
of
to
those.
We
submitted
it
here
for
four
to
get
some
initial
round
of
feedback
and,
as
I
was
sort
of
going
over
the
slides
to
know
what
I
had
to
tell
you,
comments
were
actually
coming
in,
so
we've
had
some
feedback
already,
and
one
of
the
questions
that
we're
going
to
ask
at
the
end
is
is
where
this
is
something
that
people
would
want
in
this
working
group
or
whether
it
would
be
better
place
somewhere
else.
D
D
Now
there
is
some
existing
implementation
guidance.
If
you
run
DNS
over
TLS,
there
is
Profiles
RFC
8310
just
out
that
has
some
must
some
shoot,
so
the
musts
are
to
follow
sort
of
t,
respect,
best
practices,
some
things
about
seal
accession,
resumption
resumption,
barbecues,
etc,
and
there
are
some
shoots
in
there
about
whether
or
not
to
use
eating
as
you're
partying
and
to
say
something
god:
Idina
s--,
zero,
client
subnet.
There
is
a
question.
D
E
D
Completely
agreed,
so
we
are
actually
we
were
discussing
this,
so
we
discussed
the
craft.
The
four
of
us,
this
Monday
and
and
ECS
is
one
of
the
things
that
came
up
so
is
it
should
not
in
so
we
haven't
got
anything
in
our
draft
about
it
yet,
and
I
said
there
should
be
something
in
a
draft
and
it
should
probably
should
be
well.
At
least
you
should
be
transparent
about
whether
or
not
you
do
it,
whether
it's
a
shoot,
not,
I
don't
know
we
can
discuss
so
to
be
clear.
D
D
Now
we
we
needed
to
sort
of
find
a
definition
for
a
dns
privacy,
server
and,
and
we
sort
of
came
up
with
what
is
in
the
green
box,
which
is
that
it
is
a
service
offered
via
a
privacy
enabling
dns
server,
and
there
is
some
sort
of
document
that
has
an
informal
statement
of
how
you,
as
an
operator,
handle
people's
data.
If
you
run
this
service
for
them
with
this
particular
focus
on
privacy,
and
there
could
be
a
formal
practice
statement
that
has
some
sort
of
structure
like
the
in
a
sec
practice
statement
does
now.
F
Already
yeah,
it
may
be
worth
looking
at
the
port
recommendations
and
distinguishing
between
port
443
for
TLS
and
port
443,
using
this
over
DTLS,
because
there's
a
much
larger,
chancer
I
think
some
potential
issues
with
quick
eating,
D
machst
on
to
the
same
fork
there.
So
we
may
may
want
to
look
at
that
guidance
and
make
specific
guidance
for
four
for
three
TCP
and
four
for
three
UDP.
Okay,
thank.
G
D
Yes,
thank
you.
Thank
you.
Dan
for
channeling
Sara,
that's
very
much
what
we
discuss
so,
if
he
there
is
this
EDS
client
subnet
option
as
a
client,
you
can
request
that
your
data
is
not
forwarded
to
any
authoritative
upstream
by
setting
a
slash,
zero
scope
in
the
in
the
requests
to
your
recur.
Sir,
and
the
draft
very
much
says
that
you
should
honor
that
I
think
by
these
implementations
that
I
know
of
do
that.
D
Yeah.
Sorry,
yeah
anyway,
any
mistakes
from
mine.
So
then
there
is
the
the
may
I
guess,
which
is
that
what
the
question
was
about,
where
you
should
also
run
a
service
on
port
4
for
3-4
people,
for
each
port,
853
is
getting
blocked.
But
then
you
get
into
a
discussion
at
some
point
whether
or
not
that's
gonna
work
in
the
presence
of
DOE.
So
that's
something
to
keep
an
eye
on,
and
there
have
been
some
suggestions
that
you
could
run
both
things
simultaneously
and
that
would
lead
to
something
really
horrendous,
so
No.
D
Then
you
could
have
roots
on
on
loopback,
of
course,
that
make
that
ensures
that
your
when
you
do
a
recursion
that
you're
not
going
to
be
exposing
some
of
your
traffic.
If
you
have
an
empty
cache,
getting
sent
to
two
root
servers
and
you
could
also
be
using
aggressive
at
the
intersect
but
cache
stuff.
The
N
SEC
aggressive,
insuk
thing
where,
if
the
recur,
sir,
can
synthesize
an
annex
domain
for
you
from
n
SEC
data
that
it
already
has
available.
D
There's
been
some
debate
about
client,
query,
obfuscation
for
a
very
small
deployment
where
basically,
users
can
be
very
still
be
very
traceable,
because
there
are
very
few
users
using
a
single
over
cursor
where
you
would
mix
in
other
traffic
to
sort
of
obfuscate.
A
client
traffic
really
haven't
really
had
time
to
debate,
whether
that
makes
sense
or
not
so
Sarah
asked
me
to
remind
you
that
this
might
seem
obvious,
but
we
we
were
we're
going
to
include
recommendations
about
a
certificate
management,
because
that
is
where
things
have
been
going
wrong.
D
Operationally
now,
certificates
almost
expired
and
things
going
wrong
and-
and
it
seems
so
obvious,
but
this
is
something
that
people
need
to
take
care
of
when
they're
operating
a
DNS
privacy
server
and
we're
not
quite
Korea
what
the
best
practice
is
on
that
are
whether
you
could,
if
you
reuse
your
key,
you
have
the
same
public
key
pin,
but
it
doesn't
make
sense
to
reuse
your
key.
That
might
not
always
be
good
practice.
So
that's
something
that
we're
very
much
thinking
about
yet
and
no
fee
ously.
D
You
need
to
monitor
whether
your
search
expire
right,
especially
if
certs
are
in
there
they're
gonna,
be
lasting.
Multiple
years
we
I
mean
I
personally
have
configured
DNS
over
TLS
on
on
our
operational
service.
At
my
employer
and
I
generated
certificates,
I
were
just
valid
for
10
years,
because
this
was
experimental
but
I
just
put
notes
in
my
calendar
to
remind
myself
that
I
need
to
check
those
certs
every
year
or
so
another
thing
on
operational
management.
D
We
want
to
discuss
whether
what
the
limitations
are,
if
you
use
it
a
TLS
proxy
and
then
send
a
traffic
on
to
I,
say
an
ordinary
DNS
for
curser
over
over
TCP.
What
happens
indicates
you
of
any
caste
that
is
still
blank
in
the
draft,
but
is
something
that
needs
to
get
discussed
and
I
hope
that
Sarah
is
going
to
channel
through
Dan
if
I
say
something
that
was
already
in
there
any
that
I
forgot
about
now
data
handing
this
is
something
that
is
sort
of
closer
to
my
heart.
D
It's
something
that
we've
been
in
discussing
and
is
this
is
about
if
you
do
dns
over
TLS
you're
solving
one
problem
because
you're
protecting
people's
privacy
on
the
wire
as
they
communicate
with
their
recur,
sir,
but
then
the
operator
of
that
worker,
sir
still
can
do
a
lot
of
stuff
with
the
queries
that
are
coming
in
right.
They
can
do
logging
monitoring,
etc.
So
a
lot
of
the
focus
in
the
drafts
is
going
to
be
about
what
you
do
with
that,
and
you
can.
D
If
we
can
do
this
in
a
privacy
conscious
manner
where
we
achieve
some
of
the
goals
of
detecting
stuff
without
actually
storing
everybody's
queries,
then
you
need
to
think
about
if
you're
storing
data,
what
period
are
you
storing
that
data?
For
how
long
are
you
going
to
keep
it
anonymous?
When
are
you
going
to
analyze
it?
Who
is
access
to
that
stored
data?
Are
you
going
to
be
used?
Are
you
going
to
be
using
it
to
track
users
or
not,
and
are
you
going
to
share
with
their
parties
and
in
both
cases
we're
saying?
D
Well,
you
shouldn't
be
trekking
users
and
you
shouldn't
be
sharing
this
data
with
third
parties
and
right
now
very
much
as
I'm
clear
about
things
like
Google
says:
well,
we're
not
going
to
share
that
data
if
you
use
Google
for
the
DNS,
but
is
that
the
case
what
I
mean
and
I
mean
one
Department
of
a
huge
corporation
that
talks
to
another?
Is
that
sharing
or
not
and
that
also
sort
of
ties
into
who
has
access
to
stored
data?
D
Some
of
the
things
that
we've
been
discussing
is
how
do
you
quote:
unquote:
pseudo
anonymize
or
do
other
sorts
of
the
entity
identification
on
the
data
that
is,
that
you're
recording
there
was
a
talk
at
the
DNS
privacy
workshop
in
NGSS
last
month
from
virtue
eridan
office
in
the
room
yeah
about
IP
cipher.
If
you
haven't
seen
it
I
recommend
having
a
look
at
it.
D
The
Bloomfield
of
thing
I'm
going
to
be
talking
about
next,
so
I'm
not
going
to
go
into
detail
here,
but
we're
very
much
open
to
other
suggestions,
so
people
that
have
suggestions
on
how
you
can
have
some
logging
facilities
but
may
ensure
that
not
all
your
users
are
visible
and
that
anymore
are
not
visible
anymore.
After
some
time
that
is
used
for
information
for
us
to
have
in
this
draft,
then
the
DNS
privacy
policy
and
practice
statement.
The
deep
PPS.
D
The
idea
is
that
you,
in
terms
of
policy,
you
specify
things
like
what
data?
Are
you
collecting?
How
long
are
you
keeping
it?
Is
it
getting
shared,
what
are
exceptions,
what
are
third
parties
that
have
access
to
it
and
whether
you're
currently
you're
doing
data
correlation
between
this
data
and
other
data?
D
Now
this
is
something
that
people
that
have
to
comply
with
gdpr,
and
it's
probably
pretty
much
everyone
will
have
to
think
about
anyway
right.
So
it
is
it's
worth
thinking
about,
and
we're
gonna
be
thinking
about
providing
some
guidance
in
the
draft
about
about
this.
How
you
have
you
set
this
up?
How
you
you
write
up
your
policy
around
that
and
that
might
even
be
used,
so
if
you
have
to
be
able
to
comply
with
gdpr
anyway,
now
in
terms
of
practice,
how
do
you
deal
with
a
temporary
or
permanent
permanent
deviation
from
your
policy?
D
How
do
you
communicate
about
this?
What
kind
of
capabilities
are
you
providing
on
on
certain
addresses
or
certain
ports?
If
you
look
at,
for
instance,
the
operators
of
quad
9,
they
filter
some
traffic.
If
you
use
our
quad
9
address,
but
if,
where
they
filter
out,
say
what
they
think
is
malicious
are
malicious
names,
but
they
have
a
secondary
service
that
they
talk
about.
That
does
not
do
that
filtering,
and
we
are
thinking
about
whether
we
need
to
mention
in
the
draft
whether
people
should
specify.
If
they
do
this
or
not.
D
Maybe
it's
not
privacy,
it's
it's
some
form
of
filtering
or
censorship
or
whatever,
but
it
there
seems
to
be
a
relation
and
we're
not
quite
sure
where
that
should
go
yet
and
again
eating
as
clients
that
uses
usage
right,
Court
9
again
has
a
statement
on
this
where
they
say,
if
you
use
our
main
court
9
thing,
we
will
not
do
it
UNESCO
and
subnet,
but
they
have
another
one
where
we
I
think
the
unfiltered
one
does
do
EDS,
client
subnet
and
they
are
transparent
about
this,
and-
and
this
is
something
that's
important,
why
people
should
be
transparent
about
what
they
do
and
in
any
case
and
I'm
I'm
gonna
so
correct
myself.
D
They
must
respect
clients
that
request
that
their
information,
not
before
worded
in
India,
that
et
miss
client
submit
extension
and
other
things,
are
inner
or
authentication
credentials.
How
do
you
know
that
this
is
the
correct,
DNS
prophecy,
server
that
you're
talking
to
and
contact
and
support
information?
Obviously,.
D
There
are,
as
far
it's
gonna,
be
tricky
if
you
write
a
practice
statement
like
this
to
somehow
do
have
technical
solutions
to
validate
whether
people
are
sticking
to
this
policy
or
not
right.
There
are
some
things
that
you
can
check
right.
Things
like
eating
ask
line
segment.
You
can
probably
check
if
they're
sending
this
someone
there.
D
There
are
test
services
for
that,
but
whether
or
your
queries
are
getting
stored,
your
your
your
sort
of
have
to
going
to
take
the
operator
at
face
value
for
that
or
your
you're
going
to
have
to
go
there
and
ask
them
or
send
them
a
data
access
request
again.
This
might
be
something
that
that
gdpr
might
be
useful
for
because,
if
you're,
an
EU
citizen,
you
can
now
start
asking
companies
what
they're
storing
about
you
and
they
have
to
tell
you
they
have
to
comply
with
this.
D
D
Is
this
a
trusted
service,
or
is
this
a
trustworthy
service,
and
given
that
you
can't
check
everything
that
is
their
probably
trustworthy
is
a
better
term
right,
because,
if
they're
being
transparent,
then
you
might
sort
of
give
them
the
benefit
of
the
doubt.
Do
you
think
well
they're
they're
worthy
of
my
trust,
so
I'm
going
to
use
that
service,
because
they're
transparent
about
what
they
do,
whether
or
not
you
can
make
claims
about
whether
it's
services,
trust
or
not,
that's
very
much
up
in
the
air
in
it,
it
seems
unlikely.
D
So
we
come
to
the
end
with
the
the
questions
for
the
for
the
room,
one
of
the
things
about
the
scope
of
the
document.
Should
we
have
a
section
in
there
about
a
third
of
servers
or
not
about
what
they
do
with
queries
that
they
could
in
and
and
data
that
they
store
on
that
analysis
that
they
do
on
that,
whether
there
should
be
exemptions
or
special
provisions
for
research
data
there
are.
D
D
If
you're
listening
correct
me,
if
that's
not
what
you
meant
by
saying
filtering,
but
if
you
are
doing
this,
whether
or
not
you
should
mention
this-
is
that
something
that
is
within
the
scope
of
this
draft
or
is
that
something
that's
outside
of
the
scope
of
the
draft?
And
finally,
it's
about
our
approach
or
the
approach
is,
is
currently
very
respect.
D
F
Here
are
the
things
you
should
be
thinking
about
and
if
you're
providing
DNS
service,
even
without
all
of
these
things,
you
may
want
to
think
about
some
of
the
data
handling
practices
because
they
may
be
required
in
your
jurisdictions.
Okay,
although,
honestly,
if
you're
going
to
write
a
primer
on
how
to
handle
the
GDP,
are
normal.
A
If
I'm,
not
my
I,
think
the
good
thing
about
a
very
prescriptive
approach
is
that
it
makes
writing
the
policy
statement
or
data
privacy.
Part
is
not
simple.
If
you
have
a
sweater,
annaliese,
dayes,
detail,
options,
etc.
It's
much
more
complicated
to
explain
this
in
the
data
privacy
statement,
but
I
wanted
to
talk
mostly
about
the
choice
of
the
forum
for
the
discussion.
You
mentioned
the.
Why,
for
instance,
I
think
that
today
there
are
very
few
people
who
have
actual
experience
with
the
DNS
privacy
Shadow,
it's
something
very.
A
We
see
and
I
guess
that
most
of
these
people
are
in
this
woman.
I,
don't
really
see
outside
of
IETF
who
can
after
experience,
because
if
you
want
to
talk
about
best
practice,
you
need
some
sort
of
practical
experience
before
so
today.
I
think
I.
Don't
think
that
was
the
first
place
on
the
disco
right.
J
Right,
so
those
were
the
things
that
I
wanted
to
bring
up
in
the
group
as
well.
That
I
think
the
terminology
that
you
used
in
the
draft
is
not
really
conformance
with
RFC
69,
73
and
and
I
like
author
referentiality
and
documents,
so
I
propose
that
you
use
like
pseudonym
ization
instead
of
pseudo
a
minimization,
but
then
I'm
also
wondering
why
you
make
a
distinction
between
logging
and
monitoring
and
data
retention.
J
D
D
Logging
is,
if
I
have
to
say.
Logging
is
probably
something
that
you
do
to
be
able
to
see
why
something
went
wrong
in
the
past.
Monitoring
is
is
something
that
you
do
to
see
if
there
is
abuse
on
a
surface
or
there's
other
stuff.
That
needs
your
attention
immediately.
So
that's
sort
of
guaranteeing
the
continuity
of
your
service,
safeguarding
their
security
and
logging,
is
something
that
you
look
at
after
stuff
has
gone
wrong
right.
So
these
are
there
some
subtleties
in
there
and.
J
D
J
J
I
guess
what
would
be
defined
by
this
group
in
the
980
F
concept
could
could
actually
itself
be
used
to
define
what
the
legal
obligations
for
privacy
protections
are
in
Europe
since,
since
the
law
refers
to
the
state
of
the
art
technology,
if
you
produce
a
draft
standard
here,
an
RFC
or
recommendation
that
could
itself
influence.
What
is
the
expected
level
of
privacy
in
Europe
and
that
might
be
valuable
information
for
this
group
to
take
into
account
if
it
goes
forward
to
this
process.
Okay,.
D
K
It's
team
foul,
so
I
generally,
would
be
supportive
of
doing
this
kind
of
work.
I
think
I
agree
except
and
it's
hard
to
say.
Where
else
you
could
do
it.
I
would
have
a
little
concerned
that
maybe
we
are
a
bit
early
for
BCPs
on
this
I
think
it's
no
harm
to
start
the
work
and
but
I
don't
know
that
we
have
great
amount
of
actual
practice
to
rely
on,
and
one
thing
that's
it
might
be
were
thinking
about
you
know.
K
D
Well-
and
thank
you
for
that,
for
a
for
the
comment
and
for
support,
I
mean
that
is
still
that's.
Also
why
this
is
we
some
I
want
this
to
be
a
living
document
which
can
be
a
bit
tricky,
which
is
also
why
we
were
opening
asking
the
question
to
the
room.
Is
this
something
that
should
be
here?
Should
we
consider
doing
it
as
a
ripe
document
which
might
be
more
of
a
living
document?
And,
yes,
it
might
still
be
quite
early
for
to
do
something
like
this,
but
we
I
mean
the
DNS
a
practice
statement.
L
Jim
Jim
reads
pretty
much
what
Stephen
said.
I
think
some
of
the
things
here
are
premature.
I
also
think
that's
trying
to
come
up
with
a
koozie,
overarching
potential
policy,
Fremont
discussion
in
analyses
or
soloing
about
Internet
document
in
this
working
group
is
going
to
be
a
very
difficult
job
and
I
think
it
makes
why
we're
trying
to
boil
the
ocean.
So
my
suggestion
for
what
is
worth
would
be
to
first
of
all
start
by
getting
some
of
the
people
are
deploying
privacy
services
to
document
some
use
cases
and
things.
L
These
are
the
things
that
we
thought
about
will
realize
their
service,
and
these
are
the
problems
that
we
encountered
once
the
service
was
noised
when
the
data
protection
authority
started,
knocking
on
our
door
and
state
repeating
over
her
shoulder
and
asking
questions,
I
think
that
by
good
a
better
place
to
start
but
I'm
trying
to
find
an
overarching
solution
for
everything
which
would
probably
never
terminate
and
thought
you
would
just
seem
for
Roland
with
Medina
sec
policy
statement.
That
was
a
relatively
simple,
easily
constrained
problem
space
by
comparison.
L
So
it's
relatively
easy
to
do
simple,
math
of
programming
rate,
but
in
this
context,
what
we're
trying
to
achieve
is
much
much
more
difficult.
There's
a
bigger
problem
space,
it's
much
more
rapidly,
moving
in
all
sorts
of
different
contrasting
directions
and
I
think
it's
probably
very
very
difficult
to
try
to
come
up
with
something
which
encapsulates
everything
unless
end
or
something.
So
generic
is
completely
useless.
Yeah.
M
M
That
is
probably
something
that
will
never
end
yeah
so
in
in
a
in
a
updated
version.
I
think
that
there
could
be
could
be
a
split
of
documents
by
target
audience
and
then
a
void
for
the
for
the
operators,
for
the
ITF
part
avoid
the
policy
definitions,
which
does
not
mean
avoid
the
enumeration
of
policy
options,
but
lots
the
the
recommendations
in
certain
directions,
like
especially
at
issues
with
the
onion,
for
example.
That
doesn't
really
have
a
ever
places
therein.
So.
D
Just
just
to
clarify
a
short
clarification:
would
you
think
that
if
we
were
to
go
for
a
more
contextual
or
discursive
way
of
writing
this
document,
that
that
would
address
some
of
those
concerns
because
it
would
be
I
mean
making
it
less
prescriptive,
and
more
of
these
are
the
options
that
you
have
this
way
you
can
do
if
you're.
In
this
context,
you
should
consider
looking
at
these
options
if
you're
in
this
context,
bar
than
saying
you
should
do
this,
you
should
do
this
so
yeah.
That's
that's!
Probably.
M
It
I
had
a
bit
of
interference
here,
so
I
couldn't
really
completely
understand
what
you
said,
but
the
we
do
have
the
privacy
considerations
in
the
DNS.
But
there
is
not
specifically
focused
on
the
univer
on
the
perspective
of
the
resolver
operator
or
the
user
of
a
resolver.
Only
so
focusing-
and
that
might
be
might
be
a
good
starting
point
and.
M
The
policy
part
I
think
another
venue
might
be
better
I,
don't
know
which
one
but
I
am,
as
I
said,
I'm
pretty
sure
that
the
idea
would
be
the
wrong
one.
Despite
what
Stefan
said
that
people
would
have
to
be
educated
about
the
technology,
however,
we
do
have
human
rights
people.
Well,
we
did
have
human
rights
people
here
in
the
room
which
is
great,
but
more
of
them
and
data
protection,
practitioners
and
so
on
and
so
forth.
M
We
need
that
on
the
scope
and,
of
course,
being
partly
an
operator
of
an
authoritative
server,
I,
don't
like
being
in
the
scope
of
this
no
seriously.
No,
that's
not
the
point.
I
was
kidding.
I'm,
sorry,
I,
think
that
makes
little
sense.
If
you
talk
about
the
server,
because
many
zones
are
served
by
servers
in
different
and.
M
M
O
You
MP,
so
Warren
Kumari,
both
relaying
a
comment
from
Jim
and
my
own,
so
firstly,
various
privacy
organizations
or
agencies
view
the
gdpr
differently,
and
so
it's
sort
of
the
GDP
are
viewed
through
a
lens.
Not
the
GDP
are
and
then
also
following
up
from
what
both
Peter
and
Ted
sort
of
started.
Saying.
O
I
would
really
like
this
technology
to
be
widely
deployed
and
I'm
kind
of
concerned
that
people
who
look
at
this
document
are
going
to
assume
that
unless
they're
doing
this
specifically
for
privacy,
you
know
they
shouldn't
bother
doing
it
and
so
I
think
it
needs
to
be
clearer
that
you
know,
even
if
you're,
not
a
privacy,
DNS
resolver.
Turning
this
on,
because
it's
a
good
thing
to
do
is
you
know
no.
I
This
is
dkg,
so
thank
you
for
working
on
this
I
do
think
this
is
worth
pursuing
and
I
think
this
working
group
is
a
reasonable
place
for
concluding
the
policy
section.
I
think
the
positive
section
is
going
to
be
tough,
but
I
think
that
coupling
it
with
the
deceptive
discussions
about
specific
technical
measures
is
worthwhile
a
couple
of
technical
points.
I
As
far
as
I
think
Stephen
was
saying,
we
need
more
practice
before
we
can
get
to
best
current
practice.
I
don't
have
any
problem
with
documenting
the
best
current
practice
from
a
small
pool
of
current
practice.
If
it
causes
other
to
start
practicing
and
saying
hey,
we've
got
better
practice,
we'll
make
a
new
draft
bread,
so
so
I
think
making
sure
that
those
of
us
who
are
currently
trying
to
operate
services
like
this
get
together
and
encourage
each
other
to
make
better
practices
by
documenting
them.
I
D
C
Right
well,
while
Tim
gets
to
the
slide
switch
over
the
next
talk,
I,
just
we're
both
interested
in
seeing
how
many
people
actually
read
this
document.
C
All
right
how
many
people
think
this
is
actually
a
document
worth
working
on,
regardless
of
the
venue.
D
Oh
yeah,
but
but
this
time
it's
my
name
on
the
slide.
So
if
I
make
mistakes
now,
it's
even
worse,
so
I
asked
for
I
asked
the
chairs
for
a
little
bit
of
time
to
talk
to
you
about
an
experiment
that
we're
doing
at
surface
so
surface.
National
research
in
education,
networking,
Netherlands
and
they're.
My
employer
and
sort
of
privacy
is
a
value
that
we
hold
really
strongly
within
the
organization,
and
so
that's
why
we're
involved
in
the
in
the
Dames
privacy
area
as
well.
D
So
we
run
some
of
the
servers
that
you
can
use
today,
the
the
DNS
prophecy,
experimental
servers
and,
and
one
of
the
things
that
we
thought
was
well.
Okay.
Can
we
do
something
about
this
collecting
query
data
because
we
are
as
an
operator
we
want
to
know
if
some
of
our
colleges
or
universities
are
getting
hit
by
say,
for
instance,
some
indicator
of
compromise.
There's
some
malware
out
there
that
we
can
recognize
by
looking
at
the
NS
queries.
How
can
we
do
this
without
sacrificing
user
privacy?
D
D
So
I'll
explain
what
bloom
filters
are
and-
and
we
are
now
starting
to
experiment
with
this
in
practice-
we're
going
to
run
this
against
our
operational
DNS
recursos
and
see
if
we
can
use
this
as
an
alternative
to
to
registering
queries,
hands
up.
Who
knows
what
a
bloom
filter
is
Wow?
Okay,
good
should
I
skip
the
slide.
Analogous
III
I
went
through
all
this
trouble
to
make
really
nice
pictures
about
it
so
think
of
a
bloom
filter.
D
So
a
bloom
filter
is
something
that
was
this
originally
designed
in
in
1978
as
a
space
efficient
way
to
index
large
amounts
of
data
right.
So
if
you
have
to
find
your
area
and
the
database,
if
you,
if
you
do
a
query
in
a
traditional
database
database,
it
like
Postgres
or
my
sequel,
then
odds
are
that
they're
using
a
bloom
filter
to
to
work
out
whether
the
thing
that
you're
looking
for
is
actually
in
that
table
or
not
or
in
that
column
or
not
because
it's
it's.
D
It's
a
fail
fast
way
of
looking
up
data
in
large
datasets.
But
if
you
take
a
step
back,
you
can
think
of
a
bloom
filter
as
a
probabilistic
set
membership
test
right
you.
So
you
you
have
this
unordered
collection
of
data
that
you
stop,
keep
cramming
distinct
items
into,
and
then
you
can
ask
that
a
question
is
this
element
that
I
that
I'm
now
looking
for?
Is
that
in
this
data
set
or
not?
And
if
the
filter
says
no,
it's
not
endured
and
it's
guaranteed
not
to
be
in
there.
D
And
if
the
filter
says
yes,
it
is
in
there.
Then
there's
a
small
probability
of
a
false
positive,
depending
on
how
you
configured
your
filter.
So
how
does
it
work
in
practice?
You
take
a
domain
name
say
here:
doubled
up
example:
comm.
You
run
that
through
a
shrinks,
your
set
of
hash
functions,
and
then
you
use
the
output
of
that
to
pick
a
number
of
indexes
in
a
bit
array
that
you
then
set
to
1.
D
If,
for
certain
specific
values
that
came
out
of
the
hash
function,
and
then,
if
you
want
to
do
a
lookup,
you
you
run
the
the
lookup
that
you
want
to
do
through
the
hash
function.
Again,
you
compute
the
indexes
that
should
be
set
to
1.
If
this
element
is
present
and
then
you
look
in
the
end
of
it
or
a
whether
or
not
that
element
is
present
or
not,
and
so
that
the
picture
shows
two
examples
of
things
that
hash
to
different
array
indexes.
D
If
you
pick
a
reasonable
sized
bit
array
say:
16
megabytes,
128
megabytes
and
you
cram
a
few
million
queries
in
there.
You
have
a
very
low
false,
positive
probability,
which
means
that
this
is
actually
a
really
nice
way
to
be
able
to
detect
if
a
query
was
executed
now
using
this
kind
of
technology
in
a
privacy
context
is
really
interesting,
because
these
filters
don't
store
the
original
query
names
right
and
there
are
no
enumerable,
because
I'm
not
storing
Lee.
D
If
I
were
to
store
queries
as
the
hashed
query
name,
then
I
could
still,
presumably
with
some
knowledge
of
the
data
that's
going
to
be
in
there
reverse-engineer.
What
query
was
performed
when
what
query
it
was
and
somehow
reverse
the
hashing
with
things
like
remote
tables
or
just
brute,
forcing
it
with
GPUs,
but
that's
still
simply
not
possible
with
this.
D
D
Now
there
are
some
other
considerations
there.
There
are
some
privacy
risks
right.
If
you,
if
you
know
of
a
query
that
unambiguously
and
identifies
a
certain
user,
you
can
still
track
them,
say
I
record
a
query.
Sorry
collective
filter,
once
every
hour,
I
can
still
if
I
know
that
some
user
is
always
going
to
this
one
site
that
only
that
user
is
going
to
and
there's
the
NSP
for
query
for
it.
I
can
check.
D
If,
if
that
query
will
query
was
in
that
filter
or
not
and
know
that
that
user
was
active
at
that
time,
it
is
almost
impossible
to
correlate
it
with
other
queries
for
that
user,
though
so
you
will
simply
know
whether
that
user
is
active
or
not.
So
whether
that's,
whether
a
serious
or
not,
is
something
that
you
need
to
think
about.
But
that
is
one
of
the
risks
and
of
course
there
are
additional
benefits.
D
D
So
I
think
I'm
gonna
skip
over
this.
So
maybe
a
little
bit
about
this
picture.
What
we
want
to
do
so
we
run
a
network
for
like
I,
could
academia
in
the
Netherlands
right.
That
means
that
we
have
roughly
about
200
institutions
of
higher
education
and
research
on
a
network
about
a
million
million
and
a
half
end-users.
D
We
want
to
use
data
that
we
collect
on
the
resolvers
sort
of
strategically
and
tactically.
So
we
want
to
be
able
to
see
say
if
we
have.
This
indicate
indicator
of
compromise
that
says
that
there
is
a
very
serious
breach
of
security.
We
want
to
be
able
to
say
which
institution
was
hit.
We
don't
we're
not.
We
don't
really
care
anymore,
which
specific
user.
D
That
was
because
that
is
the
task
of
the
individual
institution,
but
we
want
to
be
able
to
say
they
were
hit,
so
we're
gonna
be
aggregating,
or
at
least
that's
our
current
thinking,
users
from
certain
networks
into
certain
filters
for
that
I
have
a
master
student
working
on
this.
Who
is
going
to
be
sort
of
designing
a
system
that
not
only
collects
the
data
but
allows
us
to
query
the
data
we
we're
going
to
deploy
this
in
in
practice
on
on
our
on
our
busy
resolvers
I'm?
D
The
master
student
will
be
using
looking
at
three
particular
use
cases,
so
we
get
indicators
of
compromise
from
our
national
cybersecurity
center
and
they
come
through
the
intelligence
services.
So
they
claim
that
these
are
sort
of
serious
things
that
we
should
be
looking
at
and
currently
we
have
no
way
of
looking
at
the
NS
data
for
this,
because
we
don't
want
to
store
a
query
data,
and
this
gives
us
a
way
to
do
that.
We
have
a
particular
issue
that
young
students
in
our
network
seem
to
think
it's
a
good
idea
to
DDoS
their
institution.
D
If
they
don't
want
to
go
to
class,
and
we
want
to
know
if
they
use
booters
for
this-
and
we
thought
it
would
be
interesting
to
see
if
our
mail
filtering
service
hit
certain
names
on
black
lists.
Whether
those
names
we
get
resolved
by
other
people
as
well
in
the
network,
I
think
this
is
the
final
thing.
I
want
to
say
the
bloom
filter
library
that
we
that
was
developed
specifically
for
this
purpose.
We
funded
the
development
of
that
as
an
open
source
solution.
P
P
H
H
D
One
thing
that
you
can
do
is
have
multiple
filters,
side-by-side
that
have
different,
that
use
slightly
different
hash
functions
for
inspired
by
pre,
salting
them,
and
then
you
enter
your
data
into
separate
Bloomfield's.
You
can
then
combine
them
to
see
to
get
some
sort
of
cardinality
there
are.
There
is
such
a
thing
as
a
counting
bloom
filter,
but
we're
not
using
that.
D
For
the
moment,
it's
not
so
we
are
actually
from
us
from
a
strategic
tactical
point
of
view
were
really
interested
in
whether
aquaria
query
occurred
and
not
necessarily
how
frequently,
because
whether
a
query
occurred
is
then
probably
going
to
be
a
trigger
for
we
need
to
look
into
this
more
with
much
more
detail
and
then
how
it
occurred
is
going
to
be
the
next
thing
to
look
at
that
answer.
Your.
G
In
York
relaying
for
OMA
Ramaiah
see,
and
he
said
from
the
presentation,
it
is
unclear
how
the
author
intends
to
use
bloom
filtered
names,
especially
for
checking
if
some
query
was
performed
before
yeah,
because
there's
no
guarantee
for
lack
of
false
positives.
The
bloom
filter
might
tell
you
that
someone
that
example.org
was
queried
when
it
was
not.
D
D
What
we
want
to
know
is
what
is
the
impact
of
a
false,
positive
right,
because
for
the
parameters
that
we're
going
to
be
using
the
risk
of
a
false
positive
is
like
something
like
7
times,
10
to
the
power
of
minus
7.
So
that's
a
very
slim
chance,
but
if
we're
going
to
be
basing
a
decision
to
to
actually
start
inspecting
traffic
on
a
hit
in
the
filter
or
not,
then
a
false
positive
has
a
much
larger
impact
on
privacy.
Then
then
you
you
you
might
want.
D
D
Q
A
nice
idea,
nice
presentation
but
I'm
a
bit
worried
whenever
I
see
things
that
are
based
on
hashes,
because
a
bloom
filter
is
effectively
based
on
hashes
I'm,
worried
about
the
attacks
on
ashes,
in
which
the
specific
names,
for
example
of
botnets
could
be
chosen.
So
they
collide
with
also
names
or
combination
of
names
in
your
botnet,
so
in
your
in
your
filter,
so
they
hide.
Q
Q
O
I
A
Okay,
hello,
everyone.
So,
as
you
know,
the
charter
of
deprive
expressed
the
idea
that
we
will
walk
first
on
the
stubs
over
to
resolve
a
link
to
secure
it
to
make
it
more
private,
with
other
clean
off
with
the
approval
of
ITF
padding
policies.
Sorry
of
TLS
supporting
policies,
I
think
that
this
first
part
is
done.
So
we
can
congratulate
ourselves.
We
managed
to
do
everything
which
was
in
the
Charter
now
it's
time
to
think
about
the
future
and
mostly
about
with
over
two
authoritative
link,
which
creates
some
interesting
challenge.
A
I
already
ordered
draft
about
the
possibilities
for
this
resolver
to
authoritative
link
with
a
lot
of
different
possibilities.
Apparently,
there
was
very
little
discussion,
so
I
decided
to
do
instead,
a
specific
proposal
with
a
specific
solution
for
the
wizard
road
to
authoritative,
link
and
I
would
like
people
to
discuss
it
now.
So
the
idea
is,
of
course,
to
use
DNS
of
a
TLS.
A
Dtls
is
done,
seem
to
be
used
a
lot
up
to
now
so
DNS
over
TLS,
which
means
tcp,
RFC,
2766,
etc.
The
big
problem,
of
course,
with
a
resolver
to
authoritative
link,
is
authentication.
A
stub
resolver
talks
to
only
a
few
with
ulvor,
sometimes
only
one,
so
you
can
have
static
configuration
of
will
enroll
a
resolver
talks
to
a
lot
of
authoritative
servers,
so
you
cannot
have
a
static
column
notes.
You
need
something
else.
A
A
A
good
thing
about,
then,
is
that
it's
a
signal
that
the
server
supports
this
protocol,
so
in
theory
with
then
you
don't
have
to
prop
the
server
you.
Can
you
know
that
it
will
work?
You
can
try
it
immediately.
The
problem
is
that
in
the
real
world
many
things
can
go
wrong,
because
then
I
can
only
signal
that
the
server
is
willing
to
serve
you,
but
then
cannot
dwell
on
tea,
that
you
have
a
clean
path
with
the
server.
If
you
have
a
middle
box
higher
water,
that,
where
are
you
posted?
A
Also,
if
you
use
Dana,
you
don't
get
the
data
always
from
the
dns.
You
can
get
them
directly
from
the
TLS
server
through
the
chain
extension.
That's
why?
Currently,
it
was
recommend
that
you
try
TLS
even
before
just
before
looking
at
dinner
because
of
the
high
risk
of
port
853
being
blocked.
I
know
that
it
is
a
deviation
from
what
from
the
original
idea
behind
them.
So
it
may
require
discussion
also
because
for
a
long
time
a
lot
of
authoritative,
nameserver
won't
have
a
dns
or
TLS.
A
Today,
the
draft
mention
that
a
resolver
can
operate
in
strict
mode.
We
hiring
authentication,
successful
authentication
or
opportunistic
murder.
Well,
you
don't
have
such
a
requirement.
Of
course
today
there
are
no
authoritative
servers
with
TLS,
so
strict
murder
is
impossible
today
and
will
probably
be
unrealistic.
Unfortunately,
for
many
years,
so
some
people
said
that
it
should
be
dropped
completely
from
the
draft
I
heard
that
the
TLS
working
group
decided
that
years
1.3.
Yes,
it's
really
done
it's
okay,
so
we
make
for
DNS
over
TLS
Monday,
it's
use
it.
A
This
would
require
walking
on
this
draft
would
require
we
shuttering
of
the
group.
You
have
seen
the
new
charter
proposed
on
the
mailing
list,
because
the
current
chapter
only
talks
about
the
link
between
stub
liens
on
the
full
resolvers.
So
the
previous
charter
said
that
we
may
consider
mechanism,
but
it's
probably
better
to
have
a
new
charter
I
support
the
proposal
also
on.
Unfortunately,
we
have
a
big
problem,
because
the
first
draft
about
this
idea
of
a
second
stage
of
deprive
met
very
little
discussion.
A
I
mean
there
have
been
very
few
discussion,
not
even
strong
opposition,
so
I'm
wondering-
and
this
is
something
that
we
have
to
consider
if
there
is
still
interest
to
continue
the
deprive
working
group
or
if
we
lose
steam
after
the
success
of
the
first
stage.
That's
something
interesting
and
of
course,
we
have
to
update
the
Charter.
If
we
want
to
do
it
otherwise
deprived
it
is
closed
and
we
can
go
back
to
something
else.
Thank
you.
Now,
description,
2,
etcetera,.
F
Tara
speaking,
thank
you
very
much
for
making
the
presentation
I
I.
Note
that
your
your
concern
that
you
you're
looking
for
a
mechanism
to
provide
security
here
that
relies
on
familiarity
with
the
DNS
rather
than
other
mechanisms,
I
wondered
if
you
had
considered
using
the
DNS
challenge
for
the
acne
protocol,
which
simply
requires
you
to
provision
a
specific
DNS
record
to
demonstrate
control
of
a
particular
name
and
then
from
there
provision
a
standard
CA
certificate
from
acne.
It
seems
in
many
ways
to
be
simpler
and
the
tool
chains
for
acne
are
definitely
coming
along
nicely.
A
Didn't
think
of
it,
there
is
something
I
really
don't
like
in
CA.
It's
a
fact
that
if
you
don't
find
the
record,
you
climb
back
the
tree
up
to
the
TLD,
which
means
that
dot,
FR
dot
com
could
put
a
recorder
used
by
aldermen.
Some
dummies
I
always
thought
that
it
was
a
bad
idea,
but
yet
maybe
something
to
consider.
A
S
John
Dane
is
doing
functionally
what
you
want
already.
This
is
West
vertical
USC,
I,
say
I,
like
the
idea
of
going
this
direction.
Absolutely
add
the
one
question
I
have
is
the
happy
eyeballs
comment,
because
it
sounds
like
you
want
to
send
it
over
the
clear
and
encrypted
at
the
same
time
is
that
is
that
really
the
the
goal?
What.
A
One
possibility
is
to
try
API
both
do
not
actually
require
that
you
send
at
the
same
time,
but
one
just
before
the
other
and
with
the
opet.
You
get
a
reply,
because
today
the
problem
of
course,
if
you
send
that,
if
you
wait
a
very
short
time
and
then
you
send
the
request
in
clear,
you
don't
have
any
privacy,
but
today,
because
most
of
the
authoritative
server
not
mask
all
for
that.
If
server
don't
support
the
DNS
of
our
TLS
yeah.
S
A
S
Me
give
you
a
counter
proposal,
because
if
you
use
Dane,
you
can
actually
send
a
query
for
the
DNS
key
in
the
Dane
record
at
the
same
time,
and
then
the
Dane
record
could
be
as
a
could
be
used
as
a
signal
that
that
port
should
be
open.
So
that
will
allow
you
to
know
by
the
time
you
get
down
to
the
point
of
processing
the
DNS
SEC
chain
down
to
the
Dane
record.
You'll
actually
have
both
of
those
at
the
same
time
and
then
can
decide
where
to
send
that
the
actual
real
data
requested.
A
Problem
opportunities
mode,
the
problem
with
then,
is
that
then
signal
that
you
should
be
able
to
talk
to
the
server,
but
in
practice-
and
this
is
something
that
was
often
mentioned
about
DNS
or
TLS-
that
there
is
a
I
are
some
probabilities
at
853
is
blocked.
So,
even
if
there
is
a
dinner
record,
you
may
be
unable
to
talk
to
the
server
on
by
the
way.
This
is
one
of
the
reason
why
doe
was
developed.
A
L
Reed
Stefan
I'm
sympathetic
to
the
idea
of
having
some
kind
of
encrypted
channel
between
resolving
servers.
North
of
servers
well
in
my
opinion,
is
very,
very
premature
to
talk
about
me
chartering
at
this
stage,
there's
so
many
other
variables
to
consider
I
think
it's
far
far
to
have
to
stop
or
not
work
right
now.
First
of
all,
we
have
very
little
way
of
operational
experience
with
this
door,
so
with
depriving
this
current
state
they're,
only
a
small
number
of
experimental
servers
set
up.
For
that
just
know.
L
We
don't
have
a
great
deal
of
operating
operational
insights
and
try
to
run
these
servers.
What
the
impact
is
going
to
be
what
the
impact
is
on
the
end
user,
what
the
impact,
the
end
users,
plus,
what
all
this
horrible
policy
could
coming
down
the
track
for
all
these
privacy
considerations
and
GTR
will
have
the
same
thing
on
the
authoritative
side
as
well.
So
that's
a
concern.
L
Number
one
concern
number
two
is
there's
our
other
stuff
going
on
another
deal,
another
idea
of
working
groups,
particularly
in
door
and
the
lots,
if
there's
a
lot
more
mayhem
to
paint
or
than
the
rest
beside
the
workings
in
deep
life,
in
my
opinion,
so
we
should
also
take
that
into
consideration
too
I.
Think
I,
thought
I
thought
very.
Very
important
point
is
we
need
feedback
from
the
people
that
are
operating?
L
Some
modeling
some
data,
some
testing,
some
analysis
before
we
start
doing
that
path,
so
good,
at
least
and
understanding
is
something
that
if
we
come
up
with
something
from
this
working
at
some
point
in
the
future,
there's
a
reasonable
chance,
it's
actually
going
to
get
backed
up
and
used,
and
what
I'm
concerned
the
rotate.
With
this
encrypted
channel
between
the
dissolving
servers
enough
authority
services,
we're
opening
up
a
brand
new
channel
for
really
nasty
DDoS
attacks,
in
which
case
nobody
can
get
service
from
the
thought
of
service
because
of
too
busy
doing
all
the
crypto.
A
Regarding
the
last
point,
first
I
can
switch.
My
ad
can
go
from
IETF
participant
to
engineer
a
technique.
We
operate,
authoritative,
name
server
for
TLD
I
discussed
this.
Of
course,
a
lot
with
my
colleagues
before
presenting
this,
because
I
don't
want
to
propose
a
draft
that
we
can
create
trouble
for
us
later
on.
The
problem
does
not
seem
impossible,
for
instance,
the
risk
that
the
last
risk
that
you
mentioned.
A
L
I'm
just
saying
hang
on
before
we
go
down
now,
we
should
try
to
get
some
data
before
we
go
down
a
particular
path.
We
need
to
do
some
analysis.
Yes,
you
can
talk
about
these
techniques,
define
and
maybe
they
were
about,
maybe
the
world.
But
that's
not
the
point.
I
think
before
we
start
down
that
path.
We
should
start
dying
with
the
basis
of
empirical
evidence
rather
than
six,
but
this
seems
like
a
good
idea.
C
All
right
hold
on
so
I'm
gonna
cut
the
mic
line
at
all
of
her,
but
keep
it
keep
in
mind
that
we
do
have
a
charter
item
to
talk
to
talk
about
too.
So
some
of
the
stuff
is,
if
it's
related
to
the
to
reach
our
Turing.
You
can
hold
it
till
that,
but
you
know
so.
Let's
focus
on
the
comments
for
first
up
on
the
drop
this.
I
I
T
T
We
don't
wait
if
the
cache
element
is
about
to
expire,
we
will
refresh
it
before
it
expires,
so
the
only
time
that
we're
ever
looking
doing,
authoritative
to
recursive
whatever
in
response
to
a
request
from
a
user
or
or
whatever
is
in
the
rare
case,
that
is
the
elements
is
not
already
in
in
cash.
So
what
we're
looking
at
here
is
a
fairly
small
subset
of
the
traffic
and
what
we've
also
got
to
look
at
is
okay.
T
I
may
not
be
able
to
see
the
bits
on
the
wire
because
you've
encrypted
them,
but
the
next
problem
that
you
have
is
the
traffic
analysis
and
leaking
the
information
from
the
DNS
server
that
you're
directing
to
and
given
the
amount
of
effort
that
we
have
to
go
to
to
achieve
the
encryption
I'm,
not
sure
that
the
privacy
improvements
that
we
get
our
are
justified
by
the
number
of
attacks
that
are
blocked
by
the
encryption
that
are
not
blocked
by
traffic
analysis.
So
I'm
extremely
skeptical
of.
A
Smaller
percentage
of
queries,
I
love
to
run
TCP
dump
on
the
authoritative
name,
servers
and
I
see
a
lot
of
requests
on
a
lot
of
very
private,
because
because
many
people
don't
use
kuna
minimization,
so
I
can
see
very
long
queue
names
already
going
in.
So
maybe
this
is
only
a
part
of
the
request,
but
it's
an
important
part
still
now
for
the
traffic
analysis
were
already
of
padding
on.
A
K
U
Ben
Schwartz
so
I
think
that
yeah.
This
is
a
hard
problem,
although
maybe
not
not
so
hard
that
there's
a
lot
of
consolidation
of
shared,
authoritative
servers
so
seeing
the
IP
address
of
a
particular
authoritative
server
gives
you
less
information,
probably
than
it
used
to
about
what
name
is
actually
being
resolved
or
what
what
subtree
of
names
is
being
result.
U
N
Hola
gloom,
Sun,
Thank,
You,
Stefan,
I,
think
this
is
a
topic
we
should
be
seriously
thinking
about
I'm,
not
sure
whether
we
should
go
forward
with
this
document.
Right
now,
I
worry
about
the
fan-out
from
a
resolvers
to
authority--
lives.
We
have
a
lot
of
authoritative
addresses
compared
to
how
many
resolver
addresses
other,
and
so
probably
what
I
would
suggest
is.
N
We
started
studying
a
little
bit
more
how
we
could
coalesce
connections
into
sites
that
are
all
hosts,
many
authoritive
servers
and
then
scatter
them
locally
and
I'm
thinking
of
using
possibly
something
like
the
NS
dist
to
be
the
Terminator,
and
so
we
need
a
protocol
in
here
that
we
can
tell
it
what
address
range
is
descent
on
it
and
that
will
also
help
defeat.
Some
of
these
traffic
analysis
that
people
are
doing.
G
C
Alright,
so,
while
while
Tim
pulls
up
the
one
slide,
we
have
for
this,
the
slides
referred
to
a
charter
I
did
send
out
a
link
to
a
charter
2.1.
Let's
stick
to
charter,
because
the
only
thing
that's
different
between
charter
2
and
charter
2.1
was
mention
of
a
potential
work
item
related
to
the
BCP
that
that
we
talked
about
earlier.
So.
C
The
most
for
the
most
part,
what
I
want
to
focus
on
you
can
you
can
look
at
the
the
Charter
text
if
you
haven't
already,
but
in
essence
it's
really
the
work
items
that
are
probably
gonna
be
of
most
interest
to
people.
We
can
wordsmith
the
Charter
to
fit.
So
what
I'd
like
to
do
is
solicit
comments
from
people
who
have
either
positive
things
to
say
negative
things
to
say
or
questions
about,
the
text
that
we've
thrown
up
on
the
github
and
we
have
and.
B
I
think
we'll
have
to
probably
recharge
slightly,
so
we
can
actually
start
even
studying
some
of
this
a
little
more
in
detail
which
probably
isn't
a
bad
thing,
and
even
if
we
say
we
want
to
recharter
some,
but
we're
not
gonna
move
forward
on
resolver
authoritative.
Do
we
have
more
substantive
data
I
think
even
the
ad
is
probably
okay
with
that.
B
You
know.
I
know
when
I
spoke
with
Terry
about
this,
we
both
felt
that
we
could.
Actually,
if
we
reach
our
turd,
we
would
also
be
considering
the
idea
that
the
whole
thing
would
be
an
abject
failure,
because
we,
you
know
we
could
get
some
result
30
of
servers
to
work
on
it,
but
we
could
never
walk
the
chain
all
the
way
to
the
top
without
a
whole
bunch
of
political
stuff
right.
B
So
a
lot
of
people
when
they
think
of
30
or
they
think
killed,
root,
servers
and
I
started
thinking
about
just
people's
authoritative
zones.
It's
start
there
and
start
collecting
that
data,
because
you're
gonna
have
to
prove
each
step
of
the
way
you
you
know
you
know,
will
it
work
operationally
right
all
right,
coming
away?
Hi.
V
V
We
may
need
to
add
functionality
to
the
DNS
which
doesn't
exist
today,
which
is
outside
of
the
scope
of
this
in
order
to
get
efficient,
efficient
operations,
and
things
like
that,
so,
while
I'm
very
very
much
in
favor
of
having
the
work
proceed
of
trying
to
trying
to
encrypt
or
otherwise
at
confidentiality
from
the
resolver
to
the
authoritative
side,
it's
not
clear
to
me
that
it
fits
well
in
the
ITF
working
group
model
and
I.
Guess
you
probably
considered
this
teri
that
maybe
there's
some
better
way
to
do
this.
W
Teri
Magnuson
responsible
ad
yeah
I
thought
about
that.
That's
why
I
put
in
experimental
on
the
second
bullet
point
just
to
start
people
thinking
about
how
this
could
go
forward.
Whether
it's
in
the
working
group
is
always
an
option
for
an
ia
by
RT
F
work
area,
I'm
still
just
here
to
listen
to
what
everyone
here
thinks.
First
I've
not
made
any
decisions,
so
I
want
to
get
a
sense
of
really
is
their
willingness.
How
do
people
feel
about
going
for
various
modes
of
attack
on
this
sort
of
a
problem.
P
Alex
Mia
Hoffer
I
have
a
similar
comment.
I'm
happy
with
the
first
two
bullet
points.
Yeah,
that's
fine,
also
experimental
sounds
very
reasonable
to
me.
The
third
bullet
point
I
I
think
in
agreement
with
what
you
guys
said.
I
think
we
should
push
that
to
the
irt
FMF
archie
or
somebody
else.
I
idea
working
groups
are
not
great
at
doing
measurements.
P
X
Fetish
projects
is
ethnic,
I'm
very
much
to
support
this
work,
and
the
proposal
seems
to
be
okay.
To
me
at
least
the
experimental
part,
and
maybe
I,
should
reply
to
Stephanie's
question
why
there
was
a
silence,
at
least,
if
I
speak
for
us
and
not
resolver
developers,
we
just
had
full
hands
with
the
DNS
over
TLS
from
stop
the
liqueurs.
X
C
Y
B
B
C
Right
so
my
esteemed
co-chair
actually
put
this
Charter
up
on
on
github.
So
if
you
have
comments,
and/or
suggested
change
this
to
it
feel
free
to
do
a
pull
request.
If
you
don't
have
a
github
account
and
don't
want
to
get,
one
then
feel
free
to
either
post
at
the
mailing
list
or
send
it
to
the
chairs
any
other
things
that
people
want
to
talk
about
in
the
seven
or
eight
minutes,
we've
got
left
all
right
going
once
going
twice,
enjoy
the
recipe.