►
From YouTube: IETF105-ADD-20190723-1330
Description
ADD meeting session at IETF105
2019/07/23 1330
https://datatracker.ietf.org/meeting/105/proceedings/
A
Alright,
it
is
1:30
we're
going
to
start
I'm
Lars,
eager
business
tale
Lawrence.
We
are
your
MCS
for
the
session
on
applications,
doing
DNS
various
responsibilities.
This
is
a
non
working
group
forming
off.
As
far
as
I
remember,
we
are
super
organized.
We
already
have
minute
acres,
which
are
crisper
than
Paul
Hoffman.
Thank
you
very
much
they're
doing
minutes
in
the
ether
pad,
which
is
the
ether
pad.
A
You
would
expect
for
this
buff
if
you
want
to
help
them
out
when
you
you
know
in
case
you
get
bored
your
ad
names
of
people
that
you
know,
but
they
might
not
know
the
names
are
for
the
minutes
and
so
on
make
sure
we
have
a
good
record
of
all
of
this.
Aaron
Fork
is
Java
scribing,
which
is
mostly
sort
of
relaying
questions
from
the
jabber
to
the
microphones.
So,
if
Aaron
gets
into
line,
we
might
give
him
priority.
A
If
and
when
he
wants
to
channel
somebody
who's
been
waiting
a
long
time
in
jabber
land.
We
have
the
possibility
to
take
remote
questions,
so
we
need
to
look
at
this
thing
to
figure
out
whether
somebody
is
getting
into
line
remotely.
If
you
notice
us
missing
somebody,
who's
been
up
there
for
a
long
time
signals.
A
This
is
our
agenda.
It's
pretty
packed,
Kayla's
gonna,
do
a
little
background
presentation
and
we
have
a
few
very
short
presentations
on
various
possible
items
of
work
in
the
overall
space
that
the
buff
is
supposed
to
talk
about,
and
then
we
have
a
little
bit
of
an
open
mic
session
at
the
end.
That
is
the
plan.
Would
anybody
like
to
bash
this
agenda.
A
B
There
we
go
it
wasn't
on
before,
because
that
light
definitely
wasn't
on.
So,
even
though
an
awful
lot
of
you
in
the
room
are
kind
of
familiar
with
how
we
got
here,
we
just
want
to
do
a
really
quick
background
to
remind
people
of
it.
Very
briefly,
the
evolution
of
the
DNS
has
resulted
in
this,
in
particular,.
A
B
So
going
way
back
to
the
80s,
the
very
typical
way
that
we
did
the
Ennis
on
the
internet
was
stop
resolvers.
We
talked
to
local,
typically
local,
recursive,
resolvers,
full-service,
caching
resolvers.
That
then
talk
to
the
authorities
name
servers
for
their
data.
While
it
was
always
possible
to
use
a
different
model
for
getting
your
DNS
data.
This
was
the
one
that
almost
all
of
our
our
clients
were
using
on
the
internet.
B
It
was
using
plaintext,
UDP
packets
for
questions
and
answers,
and
one
really
interesting
thing
about
this:
is
it
made
the
DNS
traffic
susceptible
to
being
monitored,
and
so
the
Snowden
revelations
that
happened
half
a
dozen
years
ago
now
led
to
the
IPS
position
paper.
Essentially
RFC
7258,
the
pervasive
monitoring
on
the
Internet
is,
should
be
considered
an
attack
on
the
infrastructure,
and
so
at
that
point
there
were
a
couple
of
work
products
that
came
out
of
the
idea.
B
It
should
be
primitives
to
do
this.
This
query
in
response
model,
it
really
disrupted
the
traditional
DNS
model
on
which
a
number
of
different
services
have
been
built,
and
now
web
servers
were
really
kind
of
thinking.
Pretending
to
be
the
role
of
could
be
pretending,
the
role
of
a
traditional,
resolving
name
server,
and
so
there
has
been
a
lot
of
controversy
and
concerns
over
that
the
employment
models.
B
One
is
that,
with
a
lot
of
policy
now
being
implemented
in
local
DNS
resolvers,
it
was
really
easy
impossible
to
bypass
that,
and
not
just
the
policy,
but
actually
even
just
a
matter
of
things
that
you
might
not
consider
policy
for
example,
though,
just
an
internal
view
of
your
name
space
versus
an
external
view
of
your
name
space.
Some
of
these
issues
that
come
up
should
presumably
be
in
scope
for
the
idea.
Others
are
kind
of
really
above
all
of
our
pay
grade
and
maybe
need
to
be
considered
elsewhere.
B
One
of
the
issues,
a
few
of
the
issues
that
were
finding
with
doe
now,
is
essentially
this
kind
of
long
term
tension
that
our
entire
society
has
had
for
millennia.
Now,
since
human
beings
became
intelligent,
which
is
where
is
that
the
balance
that
you
find
between
things
like
safety
and
security
and
privacy
and
convenience
and
ease
of
use?
B
All
of
these
things
are
in
tension
with
each
other,
and
dough
is
really
complicated
to
increase
privacy
and
security,
for
example,
but
at
the
detriment,
perhaps
of
some
other
aspects
of
security,
and
so
there's
a
question
that
goes
on
about
filtering.
Can
we
filter,
you
know?
Is
it
being
us
a
good
place
to
filter
traffic?
B
You
know
how,
if
we're
going
to
achieve
the
privacy
goal
of
dough
of
not
being
able
to
let
people's
traffic
and
monitored
well,
that
also
enhances
the
ability
of
people
doing
bad
things
and
not
yet
monitor
and
the
network
as
a
neutral
computer.
You
just
really
can't
tell
the
difference
between
two
easily
between
what's
good
and
what's
evil,
and
so
in
this
environment,
where
traffic
DNS
traffic
is
not
being
able
to
be
monitored,
or
you
know,
are
we
able
to
somehow
still
find
a
good
way
of
addressing
this?
B
B
It's
also
worth
noting
that
there's
a
distinction
between
and
kind
of
some
operate,
the
operational
potential
operational
models
for
some
doe
deployments
are
kind
of
orthogonal
to
just
the
existence
of
dough
itself,
and
so
there's
a
discussion
that
really
has
to
be
ferreted
out
there.
We
I've
also
identified
several
other
areas
where
work
might
be
interesting
on
this
and
there's
just
no
clear
way
to
tell
what
the
best
way
path
forward
for
the
ITF
is
among
a
variety
of
options,
one
of
which
is
well.
B
The
ITF
says
this
is
difficult
and
involves
too
much
policy
we're
going
to
wash
our
hands
of
it
and
not.
You
know,
be
involved
in
further
work,
which
of
course,
doesn't
mean
that
nothing
happens.
It
only
means
the
ITF
isn't
dealing
with
it,
and
then
there
is
a
possibility
of
perhaps
adopting
this
work
into
the
more
closely
aligned
working
groups
with
whatever
the
particular
nature
is
like
HTTP
HTTP.
This
might
pick
up
a
part
of
it.
The
NSF
might
pick
up
a
part.
B
D5
might
pick
up
a
part,
and
then,
even
though
this
is
not
technically
a
working
group
farming
boss,
it
is
still
kind
of
an
open
question
of.
Perhaps
we
should
be
moving
in
the
direction
of
having
a
working
group
specifically
for
working
on
these
issues
and
in
fact,
this
you'll
notice
that
the
title
of
this
particular
baath
is
for
applications
doing
DMS,
not
applications
going
doe
or
the
OTS.
You
know
we're
we're
trying
to
identify.
B
How
can
we
look
more
closely
at
these
issues
where
the
architecture
of
the
Internet
could
be
possibly
moving
in
the
direction
where
the
traditional
stuff
to
local
resolver
to
in
remote,
authoritative?
Is
being
disrupted
and
with
doe
is
only
one
one
possible
method
of
that
happening,
but
not
by
any
means.
The
only
one.
B
So
the
three
drafts
we
were
talking
about-
this
is
they're,
probably
out
of
scope
for
the
current
doe
working
group,
which
has
not
been
shuttered
despite
it
was
supposed
to
be
this
grand
experiment
in
the
idea
where
we
could
have
a
pop
up
working
group
get
something
done
and
closed
down
the
working
group.
It
is
still
kind
of
lingering
on
right
now.
Trying
to
find
you
know
like.
Maybe
the
existing
doe
group
would
be
the
area
to
handle
a
lot
of
these
things.
B
So
we
want
to
continue
to
revisit
whether
the
topics
are
still
relevant
to
work
that
we
should
be
pursuing.
You
know,
should
it
doesn't
make
sense
for
the
idea
to
pursue
it?
What
can
we
reasonably
identify
as
our
own
work
effort
and
and
if
we
are
going
to
work
on
it?
Where
should
we
do
it
and
then
ultimately
will
your
course
be
looking
for
people
to
actually
great
documents
or
contribute
text
documents
and
so
on
and
I?
Think
that's.
Yes,
we're
not
doing
questions
now,
because
all
these
discussions
will
come.
A
C
Spencer
dawkins,
I
was
just
going
to
say
you
know,
on
the
question
of
deferring
layer,
nine
issues
to
someplace
else.
It
would
be
helpful
to
me
and
maybe
to
other
people
if
down
the
road.
Not
now
people
could
talk
about
whether
there
is
we're
a
place
for
these
individual
issues
to
go
exist.
I
know
we
can't
send
them
there,
but
if
it's
like,
we
have
to
spin
up
another
operator
community
or
something
like
that.
C
B
And
along
those
lines,
I
would
also
mention
that,
while
the
ITF
is
typically
eschewed
working
on
layer,
nine-
and
you
know
basically
had
the
same-
you
know
if
we
don't
do
policy,
it
is
worth
noticing
that
the
technology
decisions
we
make
are
absolutely
greasing
policy
in
one
direction
or
another.
So,
regardless
of
not
wanting
to
do
policy,
we're
still
doing
policy.
A
You'll
notice
that
we
have
tail
mention
that
we
have
a
there's
some
work
items
that
have
been
presented
and
discussed
earlier,
there's
a
few
more
that
we
have
today.
We
gave
everybody
a
very
short
slot
and
that
slot
actually
includes
a
little
bit
of
time
of
Q&A
for
clarification.
Questions
before
the
discussion
at
the
end
that
the
point
today
is
therefore
not
to
do
like
the
technical,
deep
dive
on
any
of
those
and
and
we're
probably
gonna,
stop
the
discussion
when
that
starts
to
happen.
A
So
if
none
of
them,
we
come
to
agreement
that
we
should
do,
then
we're
done
in
one
way
right,
but
but
I
guess
the
reason
to
have
the
buff
is
to
see
if
there's
a
few
of
those
where
they're
uncontroversial
enough
that
some
work
can
be
started.
Some
of
them
might
need
more
time,
but
but
the
whole
personally,
some
of
them
might
actually
be
able
to
go
forward
in
some
form,
either
new
working
groups.
Or
is
this
thing
working
groups
or
somehow
else?
But
that's
that's
the
the
point
of
the
box.
A
D
D
So
what
have
we
been
doing
for
the
past
couple
years?
Is
we've
been
working
on
this
thing
called
making
HTTP
more
accessible
and
easily
deployed
and
various
other
things?
That
was
a
massive
project
and
it
continues
but
we're
making
pretty
good
progress
and
well,
we
think
we're
reaching
the
point
of
diminishing
returns
in
that
regard.
It
is
now
considered
simply
good
hygiene
to
have
HTTPS
and
it's
an
accepted
norm
just
like
anyone
in
this
room
is
probably
expected
to
be
brushing
their
teeth.
We
expect
people
to
do.
D
D
The
first
one
being
bad
people
also
brush
their
teeth.
So
tracking
breaches,
all
those
sorts
of
things,
we're
paying
a
lot
of
attention
to
those
sorts
of
things
and
we're
hardening
the
platform
dealing
with
nasty
things
like
Spectre
and
friends
and
taking
encryption
thing
on
to
new
frontiers.
And
that
means
looking
at
what's
left
unencrypted
and
diving
into
in
a
little
bit
more
detail
into
things
like
traffic
analysis,
I.
D
But
the
point
here
is
that
when
we
think
that
in
encrypting,
DNS
is
a
good
thing,
but
we
do
also
care
about
who
gets
that
information
and
which
services
we
talk
to
so
principle
when
it
comes
to
the
trusted.
Recursive
resolver,
which
is
the
term
that
we
came
up
with
for
the
combination
of
encrypting
DNS
and
choosing,
who
you
encrypt
it
toward,
is
that
there
is
individual
control.
And
importantly,
here
there
are
strong
privacy
promise
properties
out
of
the
default
settings
that
people
get
okay.
D
Unfortunately,
we
might
debate
whether
or
not
this
is
an
essential
property
of
DNS
or
whether
it
is
an
unfortunate
byproduct
of
the
way
that
dearness
is
of
oh
I.
Don't
want
to
get
into
details
about
that
I'm
happy
to
have
a
drink
with
someone
on
that
subject,
but
that's
not
the
way.
Genesis
and,
of
course,
there
are
the
long
list
of
reasons
that
have
been
presented
in
the
various
drafts.
I
went
through
a
couple
of
those
one
for
not
doing
that
and
I'd
like
the
ones
on
the
right.
D
Oops
that
has
a
massive
lag
on
it.
That's
really
annoying
okay
and
I'm
not
going
to
go
through
in
detail.
Why?
All
these
thing
s
is
the
case,
but
to
throw
a
couple
of
examples
up
here:
alternative
known
resolution,
services
to
exist
and
applications
have
name
resolution
or
name
resi
resolution
like
things
built
into
them.
D
Rfc
1738
is
an
example
of
the
sort
of
things
that
I'm
talking
about
here
and
if
you
are
to
use
DNS
as
a
as
a
control
surface,
you
also
need
to
consider
all
of
the
ways
in
which
the
functions
that
the
NS
provide
might
be
being
provided
in
other
ways
and
ultimately,
without
engaging
with
endpoints
and
understanding
the
protocols
that
are
involved,
you
won't
be
able
to
have
effective
control,
happened
to
be
a
chair
of
a
working
group.
That's
dealing
with
this
one,
so
I
thought
I'd
throw
out
the
slide
on
this
one.
D
We
have
a
working
group
that
is
effectively
dealing
with
exactly
the
same
class,
a
problem,
no
we've
kept
ik
models
or
finding
that
the
techniques
that
they're
using
for
throwing
the
portal
page
up
in
front
of
someone
is
not
as
effective
when
there's
as
much
HTTP
as
there
is
in
the
network
today,
and
it
turns
out
that
the
techniques
they're
almost
universally
don't
use
DNS.
As
the
basis
of
that
there
are
a
couple
that
do
they
happen
to
be
less
effective
than
those
that
concentrate
on
strictly
intercepting
HTTP
in
clear-text.
D
Yeah
content
filtering:
this
is
one
of
the
hard
problems
for
us
using
DNS
names
to
decide
whether
content
is
allowed
or
not
only
works
in
the
very
broadest
sense.
It
can
do
things
like
over
block
and
under
block,
even
for
instance,
if
you
have
a
particular
page
on
a
site,
and
you
want
to
use
DNS
to
block
that
you
take
out
the
entire
domain
and
when
I
say
at
the
entire
domain
and
I
mean
not
just
that
origin,
but
every
co-hosted
origin
you
can
have.
D
Long
time
applications
will
encrypt
what
they
can,
they
will
choose
who
and
what
they
will
trust
with
information
and
in
order
to
engage
with
end
systems
and
exert
control.
You'll
have
to
don't
talk
to
the
person
who
owns
the
machine,
that's
being
operated.
That
is
how
ideal
situation
that
we
get
into,
and
that
is
you
can't
come
in
from
the
outside
and
impose
your
will
upon
someone
without
actually
talking
to
them
and
getting
their
consent.
D
A
And
that's
all
I
have.
Thank
you.
Thank
you.
We
have
maybe
time
for
one
very
curricular
vacation
question.
If
one
of
you
has
one
for
what
I
see
color
dr.
Jennings,.
F
As
you
know,
I
support
this
very
same
view
on
this,
but
you
you
talked
about
encrypting,
DNS
I.
Don't
really
think
that's
the
goal
that
that
is
a
mechanism
along
the
goal.
Obviously,
but
I
think
we
have
to
be
honest
too,
about
the
fact
that
one
of
the
things
that's
still
revealed
that
we
need
to
be
working
away
on
in
this
whole
thing
is
the
next
thing
which
is
instantly.
F
We
use
this
DNS
information
to
make
a
connection
to
an
address
and
nearly
all
the
information
that
was
in
the
encrypted
DNS
query
is
instantly
revealed
two
seconds
later
now.
Of
course,
it's
not
that
I,
don't
think
we
shouldn't
bankrupt
the
DNS.
It's
that
I
think
we
need
to
solve
both
of
these
on
our
path,
not
just
the
first
one
yeah.
Thank
you.
A
G
Don't
know
how
handsome
yet
nice
light,
so
my
name
is
Kenji
bow
on
Chrome
I'm,
a
product
manager,
I
work
on
loading,
api's
and
university.
S
is
one
thing
among
you
need
different
products,
so
I
can
explain
essentially
like
the
basic
principles
that
we
have
so
first
of
all,
I
think
at
some
point
it
was
some
confusion
about
whether
or
not
we
intended
to
force
a
DNS
change
to
have
all
our
users
to
use
your
DNS.
We
don't
want
to
do
that
for
a
couple
of
reasons.
G
One
is
that
some
of
the
users
are
currently
using
Adina's
provider
and
that
dns
providers
is
offering
different
like
features
like
family
filtering,
malware,
detection
and
whatnot.
That
might
not
be
the
right
way
to
do
it,
but
it's
currently
the
way
those
users
are
experiencing
the
internet,
and
so,
if
suddenly
they
lose
this
feature
just
by
us
forcing
a
new
dns
on
them.
It
could
potentially
create
some
breakage
of
user
expectations.
So
that's
the
first
point.
G
The
latest
update
is
that
I
think
last
week,
I
think
we
sent
a
PSA
to
our
public
mailing
list,
explaining
our
current
step,
which
is
we
want
to
do
an
experiment
to
make
sure
that
the
intervention
that
we
have
in
Chrome
is
reasonable,
that
it
performs
well
doesn't
crash
and
whatnot.
So
this
is
just
an
experiment.
It's
not
meant
to
be
something
that
we
are
going
to
ship
as
is,
and
what
we
do
is.
G
Essentially,
we
have
a
very
short
table
of
jeana's
provider
that
we
know
support
though,
and
so
we
reached
out
to
a
couple
of
providers
and
at
the
moment
we
have
five
of
them
that
are
interested
in
participating
and
complied
with
a
set
of
criteria
that
we
we
felt
we're
good
to
start
with
in
term
of
like
doing
an
experiment.
I
can
share
more
details
about
that.
G
What
happened
after
that
is
really.
There
are
a
lot
of
open
questions,
especially
if
you
think
about
like.
Maybe
should
we
have
a
UX
that
let
users
like
this
scientific
one
of
this
option?
How
do
we
communicate
that?
If
the
word
to
pick
this
version
do
user
expectation
that
they
currently
have
might
not
hold
true
anymore,
because
this
provider
doesn't
do
family
self
featuring,
for
instance,
you
know
a
lot
of
things
like
that.
We
still
need
to
understand,
and
there
are
also
countries
like
the
UK,
where
they
are
set
of
things
in
your
loan.
G
I
Okay,
thanks
very
much
I'm
going
to
keep
this
data
very
shot.
Look
it's
another
aspects
of
this
whole
problem
space
around
the
use
of
the
moon,
technologists
that
just
slightly
to
about
as
we
go
forwards,
the
use
of
that
and
manly
the
focuses
on
the
use
of
small
things
like
alt
tape,
devices,
web
browsers
and
so
on,
and
there's
a
questions
there
about
some
of
the
operational
policies
that
hope
these
things
are
configured.
How
are
these
devices
and
how
these
applications
going
to
do
trust
management?
How
are
they
going
to
get
a
trust?
I
Anchor
would
be
some
combination
like
we
in
Dane.
Was
it
going
to
be
something
else?
How
am
I
going
to
go
over
these
keys
when
I've
gotten
all
the
vendor
certificates
that
use
it
for
that
and
also
how
they
could
have
some
kind
of
device
configuration
policy
when
we
tried
all
fast
then
fall
back
to
dock
then
fall
back
to
vanilla,
dns?
Should
that
be
retrofitted
and
destroyed
and
suddenly
I
think
that's
potential
and
EDF
may.
J
I
To
look
at
specially
similar,
we
have
to
look
at
the
key
issues.
Roundabouts
was
configurator
for
there's
other
configuration
also
discovering
mechanisms.
How
can
these
devices
and
applications
find
a
suitable
resolver
that
they're
supposed
to
use
Abel's
provided
on
the
local
network
are
living
is
provided
by
the
vendor
themselves
and
if
you
want
to
have
the
situation
from
large
numbers,
these
things
perhaps
have
these
IP
addresses
hardwired
into
them
and
that
potentially
potential
disruptive.
I
Now,
from
my
point
of
view,
this
also
is
like
state
lease
of
the
bleedin
obvious,
but
the
fact
they're,
just
not
really
written
down
anywhere
and
I,
think
that's
potentially
something
that
really
needs
to
be
documented,
somehow,
somewhere
and
I.
Think
myself,
maybe
the
ATF
make
the
posted
second
name,
there's
a
way
that
issues
of
knowing
the
whole
issues
of
documentation
issues.
There
was
quite
a
number
of
big
gaps
there
that
I
think
need
to
be
filled.
We
started
to
figure
out
ways
to
try
and
mitigate
the
security
risks
of
the
use
of
these
technologies.
I
These
things
to
be
used
well,
but
we
also
have
to
understand
the
potential
downsides
and
printed
houses
if
they're
not
used
in
the
appropriate
way.
I
think
I
also
have
to
look
at
some
of
the
threat
model
stuff
and
use
cases,
because
that
doesn't
seem
to
have
been
done
yet
and
also
concerns
about
potential
information
leakages.
Well,
how
to
minimize
the
risk
of
that
happening
as
well
and
then
also
another
big
concern.
Something
that
really
worries
me
is
the
potential
for
malice
or
accidental
damage.
I
For
example,
if
the
resolving
server
gets
compromised
in
some
way
and
I'm
using
the
term,
resolving
sever
deliberately
loosely
in
effect
starts
humming
like
bad
data
to
the
end,
clients,
hurricanoes,
end
clients.
Well,
I
did
that
data
or
disregard
that
say,
for
example,
if
they're
giving
a
bogus
information
and
sending
people
to
a
fake
version
of
a
bank's
website
or
whatever
it
may
be
so
I
think
that's
another
to
be
looked
at
and
a
real
worry
I
have
is.
I
If
these
things
are
compromised
or
taken
an
IOT
time,
setting
the
potentials
of
down
stage
can
create
nasty.
You
know
some
of
the
stats
which
you're
killing
your
toaster
for
another
save
the
world
or
this
signals
a
door
lock
on
your
house,
while
you're
away
from
home-
and
nothing
can
be
done
about
it.
So
I
think
that's
another
thing.
There
could
be
at
least
documented
and
looked
at,
and
maybe
this
is
something
I
think
that
the
ATF
Koopman
house,
t-con
board
and
authority
equations
if
I
need.
K
Hi,
my
name
is
David's
colossi
I
woke
a
googol,
and
this
is
a
proposal
for
how
I,
like
servers,
communicate,
dough,
so
I'm
gonna
just
could
make
a
very
like
overview.
Presentation
of
this
and
I
I
personally
believe
that
it
fits
in
with
what's
been
discussed
before
in
terms
of
like
the
model
and
how
we
reason
about
dough-
and
this
is
just
maybe
one
more
tool
we
could
have
in
our
dough
toolbox.
K
So
one
problem
with
some
of
the
dough
deployments
today
is
that
some
browsers
will
just
send
all
of
their
DNS
to
one
dose
over
so
two
odd
cloud
provider,
and
so
that
has
two
problems
on
one
hand:
it's
inefficient
because,
let's
say
if
you're
resolving
names
that
use
DNS
for
load,
balancing
or
DNS
for
geographical
picking,
geographically
picking
the
right
data
center
going
through
a
doe
server.
That's
all
the
way
somewhere
else
might
be
inefficient.
Also,
you
expose
all
of
your
browsing
history
to
that
DNS
provider
also
on
ideal.
So
how
can
we
move
forward?
K
It's
helped
their
people
or
don't
word
option
by
not
having
these
problems
as
much
so
the
proposed
solution
or
a
proposed
solution,
is
somewhat
inspired
by
HSTs,
but
don't
think
about
it
too
much
that
way,
because
that
is
a
terrible
analogy
and
the
idea
is
the
HTTP
server.
The
origin
tells
the
client
by
the
way,
I
also
run
a
doe
server,
and
if
you
want
to
resolve
me,
I
would
prefer
you
use
this
one,
but
client
is
completely
free
to
do
what
it
wants.
K
The
one
way
to
deploy
this,
which
I
think
is
practical,
is
we
already
have
history
right
now,
where
there
is
a
number
of
DOE
servers,
it's
not
incredibly
large
and
some
of
them
have
been
vetted
in
terms
of
like
how
much
data
they
log
and
all
that
and
so
browsers
can
have
a
list
of
those
dos
servers
in
the
UI.
But
one
thing
you
can
do
is
if,
as
a
browser,
you
have
that
list-
and
you
receive
this
header
for
something.
That's
in
the
list.
You
can
say:
okay,
when
I
want
to
visit
this
website.
K
K
One
important
point-
and
this
is
what
makes
it
very
different
from
HSTs-
is
that
this
is
a
performance
feature,
allows
you
to
skip
jump
through
another
doe
server.
It's
not
a
security
feature,
so
you
can
fall
back
if
that
doe
server
that
was
recommended
doesn't
work.
You
fall
back
to
whatever
yes
mechanisms
you
had
before.
That
could
be
another
doe
server.
It
could
be
TNS
or
5380.
K
Whatever
you
generally
use,
and
one
point
that
was
brought
up-
that
I
want
to
mention
is
like
anything
that
the
client
caches
it
can
be
used
as
a
tracking
vector
or
super
cookie.
So
you
want
to
implement
if
what
we
ever
want
to
move
forward
with
this,
we
want
to
employ
mitigations
such
as
only
having
a
small
list
of
what
those
servers
there
are
to
avoid.
K
This
service
is
providing
one
unique
do--you're,
I
per
client
and
allowing
tracking,
and
of
course
you
also
want
to
double
key
this
caching
of
information
based
on
the
origin
and
iframes
and
everything
to
avoid
these
concerns,
and
that's
all
I
had
it's
a
simple
concept:
I
think
you
will
have
clarification,
questions
it's
the
usual
suspects.
They
never
had
starvation
questions.
You
still
feel.
L
K
That
is
indeed
the
most
important
part
of
the
talk.
I
might
have
forgotten
that
so,
let's
say,
if
you
go
to
browse
to
HTTP
called
Sascha
example.com.
It
is
for
that
same
origin
and
that
origin,
only
so
you
add
a
header
like
next
time.
You
want
to
resolve
example.com.
You
come
to
this
doe
server,
not
for
any
other
domain
name.
K
K
M
Yeah
I
mean
this
is
this
is
very
interesting
work.
This
means
no
coverage
of
it
in
this
kind
of
thing
for
a
while,
so
I'm
glad
to
see
McCord
I
think
there's
some
technical
details
from
not
entirely
sure
I
love
here,
but
you
know
something
work
out.
I
think
the
perhaps
why
this
interesting
question
is.
Is
it
worth
trying
to
expand
the
scope
on
I,
say
two
points
one?
Is
it
we're
trying
to
span
the
scope
outside
of
just
the
origin
itself?
Two
children
demands,
for
instance,
or
other
domains
in
the
surf.
M
There
are
questions
worth
asking.
Is
it
worth
priming?
A
Close
the
lines
already,
because
we
wanted
to
clarification,
questions
and
they're
getting
extremely
detailed,
which
is
not
what
this
was
supposed
to
be
about.
So
please
keep
it
at
the
clarification
level.
Thanks.
G
K
G
G
K
N
K
Absolutely
and
so
then
it
becomes
the
responsibility
of
whoever,
so
in
that
website,
to
try
to
be
smart
about
how
their
users
or
what
the
best
server
is
for
that
at
the
end
of
the
day,
if
they
were
thorough
server
that
they
run
is
further
and
yeah,
then
they
should
just
say:
use
your
eyes,
peas,
but
thank
you.
David.
A
O
P
P
P
As
an
example,
so
we
are
looking
at
deploying
it
well,
creating
a
proof
of
concept
of
of
the
dope
doze
over
in
our
network,
so
that
we
can
then
assess
if
it's
viable,
how
we're
gonna
roll
out
the
network.
But
in
order
to
prove
that
viability,
we
need
to
address
these
challenges
which
are
commodity.
Could
you
look
at
the
total
immigrant.
A
P
So
the
the
the
ITF
we
think
should
consider
developing
at
a
best
current
practice
which
documents
these
concerns
and
provide
the
appropriate
guidance
so
for
come
on
to
what
those
are.
So
the
first
is
how
operators
and
enterprise
networks
can
offer
Doh
and
dot
service.
Most
of
these
issues
are
common
to
both
Dell
and
dogs,
so
this
in
part
results
around
discovery
of
local
resolve
which
result
as
are
available.
What
policies
do
they
have?
P
Privacy
policies,
other
features
and
selection
of
that
now
that
there
are
two
existing
drafts
and
I'm
aware
of
there
talking
to
this
space,
you
need
to
build
a
complete
picture
there,
also
how
these
operator
and
enterprise
dos
servers
can
be
used
across
home,
mobile
and
enterprise
networks.
So
when,
obviously,
when
there's
mobility
between
those
networks,
there's
gonna
be
a
process
of
discovery
and
selection
and
you're
not
always
going
to
want
to
choose
the
local
resolver,
we
could
also
do
with
assessing.
P
Also,
the
impact
on
existing
infrastructure,
so
low
balances
captive
pools,
as
we
mentioned
nat64
has
that
going
to
work
proxies
CD
ends
the
impact
of
the
customer
premises,
equipment
so
out
of
the
box.
When
the
customer
first
opens
it
and
puts
it
event
system,
how
are
they
going
to
connect
and
be
taken
through
that
process?
P
Should
we
have
a
doe
resolver
on
of
the
CPE
like
we
do
it
them,
but
while
we
did,
we
have
a
DNS
resolver
at
the
moment.
What's
its
role
in
this
new
environment,
how
do
we
manage
the
certificates
if
it
is
going
to
be
offering
its
own
doe
service
they're,
providing
donat
servers
in
split
DNS
environments?
This
has
been
mentioned
a
number
of
times
and
over
xur
there's
a
draft
which
is
attempting
to
address
this
issue
so
I
hope
that
covers
it
off
completely.
P
The
interactions
between
applications
and
operating
system,
DNS
settings.
So
do
we
do
we
conclude
that
it
is
better
for
the
operating
system
to
to
implement
the
to
be
the
DNS
client,
the
advantage
there
is
that
it
is
one
point
that
holds
the
settings,
the
preferences
and
the
selection,
or
is
it
better
for
the
applications
do
that
and
if
we
do,
if
we
say
the
applications
need
to
do
that
opens
up
the
issues
of
managing
all
that
diversity.
P
P
How
do
clients
will
handle
policy
negotiation
the
service,
so
we
we've
mentioned
privacy
policies,
err,
there's
a
draft
that
says
yes,
we
can
learn
about
this
resolver
offers
these
policies
and
features,
but
also
could
this
be
negotiation
could
be?
Could
the
client
device
say
I'm
willing
to
accept
ECS
prefix
length
of
this
or,
if
any,
I'm
not
willing
to
accept
any
ECS
I'd?
Rather
it
was
not
sent.
Could
that
be
a
negotiation.
P
The
if
it's,
if
the
DNS
is
presented
simply
an
operating
system.
That's
that's
one
case.
If
we
think
there
is
a
role
for
applications
to
manage
their
DNS
settings,
then
let's
say:
okay,
we
have.
We
have
ten
different
applications
on
this
device.
They've
all
got
different
selections
if
there's
also
security
software
on
that
device
like
an
anti-virus
or
something
that's
attempting
to
secure
the
device.
Is
that
security
software
going
to
have
the
ability
to
do
audit
the
DNS
selections
of
all
the
applications
you
know,
so
they
can
ensure
that
that
malware
has
not
submitted.
P
P
Authentication
of
doand
got
resolved,
so
let's
say
that
my
device
is
on
the
ITF
Wi-Fi
I've
discovered
that
there
is
an
ITF
doe,
resolver
I've
learned
about
its
policies.
I
check
that
against
my
users,
preferences,
the
user
says
yeah.
If
there's
a
good
resolver,
it's
local,
it's
really
private
and
secure
use
that
one
we
need
to
state.
What?
How
do
we?
P
P
So
that
that
was
an
example
list
of
areas
that
we
think
there
is,
there
is
a
need
for
some
work.
Some
of
them
are
already
being
worked
on,
so
this
is
just
an
open
question
to
say
who's
willing
to
work,
to
identify
the
items
that
do
require
work
with
somewhere
to
check
that
overlap,
and
if
we
identify
there
is
something
who
are
the
volunteers
to
work
on
it.
Q
Barbara
stark
AT&T
thank
you
for
bringing
this
on
I'm
glad
to
see
that
one
of
the
presentations
today
actually
looked
at
operator
network
operator
issues
I'm.
Quite
honestly,
given
that
the
list
of
drafts
that
sort
of
precipitated
having
this
Boff
were
all
about
operational
concerns,
I
was
actually
kind
of
surprised
that
only
one
out
of
six
presentations
actually
tried
to
say
we
need
to
talk
about
operational
concerns.
Q
As
a
network
operator,
I
can
tell
you
that
this
has
risen
now
to
one
of
the
top
concerns
as
to
the
potential
impact
that
this
can
have
on
changing
Network
patterns.
Where
traffic
comes
from
the
paths
traffic
takes
coming
into
our
network,
will
it
still
use
some
of
those
private
hearing
links
if
it's
being
resolved
by
somebody
else?
Q
The
potential
on
calls
to
our
help
desk
when
things
don't
work,
the
way
they're
expected
to
work
on
those
calls
aren't
going
to
be
going
to
CloudFlare
or
Google
or
Mozilla,
or
any
of
those
they're
going
to
be
coming
to
our
help
desks.
This
is
huge.
We've
got
to
work
on
this
and
it
needs
to
not
be
given
short
shrift
or
shortchanged
in
any
way,
and,
quite
honestly,
absolutely
I
want
to
work
on
these
things
with
you,
wherever
they
happen.
Q
I'd
really
like
to
see
if
at
least
one
of
the
chairs,
if
there
is
an
a
DD
group,
is
an
operator
so
that
it's
not
that
operators
are
some
sideline
here.
Apologize.
A
I'm
glad
I'm
glad
people
agree,
so
this
is
probably
on
the
chair
is
mostly
for
not
reaching
out
more
and
trying
to
get
additional
operator
presentations
lined
up,
but
we
did
manage
to
get
one
which
we're
now
quite
happy
about
before
also
but
but
yeah.
Obviously,
we
agree
and
thank
you
for
clarifying
that.
R
Terri
mandersohn,
no
particular
hat.
Would
you
mind
going
back
to
the
previous
slide?
Please
sure,
would
you
consider
the
authentication
requirements
for
doe
and
DOD
resolvers
or
protection
of
application,
specific
doe
and
deity
resolver
configuration
to
cover
the
the
trust
anchor
store
issue
and
ensuring
that
the
appropriate
gating
and
validation
and
sanctity
of
the
ta
store
is
in
that
scope
and,
if
not,
why
so.
P
O
Why
why
is
this
about
doe
I?
Think
the
first
slide
is
the
first
bullet
on
the
first
flight
is
incorrect.
The
DOE
protocol
itself
does
not
create
any
of
these
technical
challenges.
The
technical
challenges
are
created
by
using
a
server.
That
is
not
the
one
that
the
network
configures
you
to
use.
So
this
is
not
specific
to
doe,
it's
not
specific
to
dot.
If
you
weren't
able
to
if
the
operator
weren't
already
able
to
rewrite
and
man-in-the-middle
UDP
DNS,
which
they
are
today,
the
same
problems
would
exist.
O
So
I
think
you
know,
with
framing
in
terms
of
dough,
is
wrong.
I
happen
not
to
have
a
duplication.
We
have
a
duty,
implementation,
Android
and
that
creates
some
of
the
challenges,
but
we,
it
actually
doesn't
create
many
of
the
challenges
you
have
here,
because
we
chose
not
to
change
the
deployment
model
and
to
use
either
or
user
selective
DNS
result
resolver
or
to
use
to
upgrade
the
network
provided
resolver
to
encryption,
and
so
it
may
seem
kind
of
specious,
but
I
think
it's
it's
unfair
to
blame
doe
for
this.
O
P
So
I
would
say
it's
it's.
It
is
RFC
84-84
that
has
brought
this
to
the
point
where
it's
it's
likely
that
there's
going
to
be
a
big
transition
of
of
the
DNS
traffic
I
agree.
Yes,
it
if
the
ISP
is
deploying
a
doe
server
or
any
kind
of
encrypted
DNS
server
and
the
devices
are
all
using
that
and
a
lot
of
the
issues
become
much
easier.
There
are
still
some
that
remains,
such
as.
How
do
you
manage
that
traffic
cut
the
lines
for.
A
C
Hardy,
if
you
could
go
forward
just
to
the
Middle's
like
please
first
I'm,
very,
very
sorry
that
this
was
not
an
exhaustive
list,
because
I
was
very
tired.
After
reading
it
and
I'm
really
sorry
that
you're
having
all
of
these
issues,
I
tend
to
agree
with
what
Lorenzo
caliche
said,
though,
that
a
fair
number
of
these
issues
occur.
C
If
you
let
the
user
trust,
whatever
DNS
they're
going
to
trust,
irrespective
of
whether
that
it's
transported
in
clear
text,
whether
it's
transported
over
a
TLS
or
overall
age
and
I,
also
think
that
there's
a
fair
number
of
these,
where
the
performance
side
of
this
there's
really
kind
of
no
difference
between
this
performance
issue
and
the
d-o-t
performance
issues
right,
you're,
gonna,
see
TLS
start
times.
You'll
have
a
concern
about
that.
You'll
have
HTTP
overhead.
You
need
to
do
a
bunch
of
that
stuff
if
what
you're
just
looking
at
is
result
for
performance.
C
If
what
you're
looking
at
is,
is
the
sorts
of
issues
that
barber
will
bring
up
about
where
the
traffic
is
coming
into
your
network
I
think
that's
again,
though,
because
you're
not
letting
the
user
control
the
resolution.
If
you
look
at
any
mechanism
by
which
the
user
is
in
control
of
the
resolution,
you
can
get
these
results
and
I
think
before
you
go
and
ask
the
question
on
your
final
slide,
looking
for
overlap
with
deprive
toh
other
operational
group.
C
If
you
really
handy
just
to
go
through
this
and
say
if
I,
let
the
user
trust
a
resolver
on
of
their
choice
and
did
not
make
any
efforts
to
insert
a
resolver
over
and
above
their
their
initial
choice.
Does
this
same
thing
happen?
Yes,
or
no
in
similar
for
the
performance
issues
once
you
have
that
trusted
answer,
no
matter
where
you've
got
it?
Would
this
same
performance
issue
happen?
Yes,
or
no,
and
I
think
the
result
of
that
once
you've
got
got
rid
of
all
the
ones?
C
A
G
From
Google
I
just
wanted
to
know
to
say
that
I've
spent
a
lot
of
time
talking
to
the
ISPs
and
I've
learned
a
lot
in
process
and
I
feel
that,
like
you
look
around
like,
there
is
a
lot
of
people.
There
are
some
hard
questions
to
solve
and
I
don't
have
any
service,
and
so,
if
there
are
things
on
that
slide,
maybe
not
on
the
slide
that
we
we
could
have
ways
that
are
rational.
I,
think
we
should
consider
them.
Thank
You.
J
Kathleen
Moriarty
so
on
the
dough
clients
handling
policy,
it's
not
just
that
it's
whether
they
have
an
opportunity
to
select
what
they're
using
for
DNS.
So
if
the
application
browser
on
the
client
side
doesn't
have
a
choice
and
they're,
not
behind
the
network
firewall
to
help
interfere
with
that
choice,
they
may
be
unaware
of
where
their
DNS
is
going
and
I
mean
there's
nothing
to
stop
a
DOS
or
server
from
doing
some
of
the
inspection
capabilities
from
you
know,
other
CMS
services
right
so.
G
I
Keep
this
very
short
and
he'll
just
say:
keep
it
gently
tight
level
thanks
so
much
very,
very
short
one.
You
know
this
was
the
basis
of
a
draft
that
john
dickinson
and
herself
kicked
it
out
before
the
prank
meeting,
but
it
never
got
to
the
stage
that
this
wall
today
but
I
think
identify
some
other
potential.
I
It
is
a
potential
lock
and
particular
innovation
is
the
interaction
between
HTTP
and
DNS
between
what
is
perhaps
notional
web
server
and
the
web
browser
type
activities,
and
the
potential
is
there
for
things
like
cache,
motion,
attacks
and
hijacking,
and
how
can
we
deal
with
unsolicited
unsolicited
HTTP
POST
messages
going
to
the
web
browsers
80-43?
For
us,
it's
a
little
bit
about
that,
but
I
think
that
perhaps
needs
to
be
expanded
and
filter
it.
I
A
little
bit
more
I
think
we're
Pro
not
done
enough
work
there
in
the
threat
model
down
looked
at
it,
I
think
that
could
be
looked
up
and
also
what's
going
to
the
scope
of
any
HTTP
push
messages.
Is
it
going
to
be
for
the
browser
as
a
central
global
entity
or
if
an
individual
frame
or
Taliban
the
browser?
I
What's
the
time
to
evaluate
those
but
push
data,
that's
good
to
be
shot
also,
maybe
we
need
to
articulate
something
clearly
that
you
know
whenever
we
get
a
DNS
lookup,
irrespective
of
the
transport
protocol,
the
mechanism,
if
you
use
dots
on
for
used
or
or
used
vanilla
DNS,
we
should,
broadly
speaking,
get
the
same
way
same
answer
back
every
time.
Generally
speaking
marginally,
some
things
may
be
said
going
to
vote
the
issues
of
clever
cast.
First
content,
delivery
networks,
changing
the
responses
back
but,
broadly
speaking,
you
should
get
the
same
answer.
I
That's
something
we
should
try
to
make
sure
is
it's
enshrined
in
all
these
and
protocol
deployments
also
and
for
web
caches?
What
we
do
about
negative
caching,
again,
80
40
84
sees
a
little
bit
about
that,
but
members
a
little
bit
more
depth
to
be
plotted
in
there.
No
take
the
line,
the
use
of
them
a
connection
of
mis-
caching
thing:
we've
just
come
it
as
an
81
98
film
recently.
Also,
there
are
some
things
that
both
some
of
the
feel
like
some
of
the
newer
fancier
dns
features
which
are
left
unseen
at
the
moment.
I
If
example,
a
web
client
is
using
t
sake,
how
does
the
web
browser
or
of
the
trusted
resolver
handle
that
he
said
data
they
shalt
over
the
HTTP
channel?
Why
do
we
do
other
things
to
do
with
Venus
header
bits?
What
what
does
it
mean
when
a
web
browser
sends
a
query
with
the
recursive
precautions
ahead,
but
not
set
how
this
awaked
resolved
over?
Do
you
with
that?
Does
it
give
back
an
undercover
gave
an
answer?
Discipline
cache.
Does
it
tightens
of
that
query?
I
think
things
like
that
need
to
perhaps
a
lot
also.
I
I
Make
sure
that
your
honor
of
the
a
I
know
route
if
we
win
the
public
Internet
I
think
this
is
a
general
thing
that
I
apply
is
not
adjusted
or
resolve
was
but
to
and
for
no
DNS
resolvers,
as
well
as
a
potential
here
that
the
potentially
could
be
hijacked
or
bypassed
or
ignored
and
I
think
it'd
be
good
to
break
something
going
about
that
and
also
gods.
Interesting
TNS
group
people
mentioned
ECS
was
also
a
DNS
options.
Should
you
support
DNS
SEC
and
by
that?
What
a
meaning
is
that
the
trusted
resolver
should
return.
I
The
DNS
tech
related
was
all
strikers,
got
necessarily
valuable
in
sales,
but
passed
them
back
to
the
end.
Clients
or
the
end
client
can
choose
to
validate
them
for
themselves
if
it
wants
to
or
not
so
think,
things
like
that
all
need
to
be
explained
because
those
requirements
at
the
moment
I'm
not
quite
clear
and
I-
think
the
kind
of
libyans
assume
making
an
assumption.
But
anybody
that's
operating
up.
Adored
resolver
will
actually
do
these
things
and
if
it's
a
website
it
may
not
choose
to
do
those
activities.
So
I
think
it'd
be
helpful.
S
L
Schwartz
yeah,
so
first
of
all,
I
think
that
this
work
is
largely
in
scope
for
dough
as
currently
chartered.
So
if
you
want
to
bring
this
kind
of
work
to
the
dough
working
group,
working
group
is
open.
Okay,
I
I
do
want
to
ask
a
couple
of
questions.
Do
you
do
you
think
that
these
requirements
do
not
currently
exist?
Oh.
I
It's
a
very
good
question
and
we
need
to
look
at
a
whole
bunch
of
and
I've
ceased
to
know
for
definite.
But
now
certain
things
are
plying
that
written
down
in
terms
of
resolver
requirements
of
being
Jennifer,
a
regular
DNS
resolver.
So
much
have
anything
written
down
that
specifies
that,
but
I
do
think.
There's
another
name
that
perhaps
needs
to
be
developed
in
scooped
a
little
bit
further.
L
I
They
compliant
saying
I,
don't
have
any
Creek
Rober
that
it's
not
so
much
I,
think
buggy
or
you
need
to
implement
these
things.
But
sorry,
no
there's
not
as
much
buggy
our
faulty
implementations
that
factors
will
make
a
minimum
set
of
requirements.
We
should
expect
these
resolvers
to
implement
and
support,
and
it's
not
really
clear
what
that
should
what
that
things
should
be,
and
just.
L
I
Well,
it
depends
how
the
door
is,
but
in
the
back
end
in
the
server
side,
is
it
going
to
the
web
server?
Is
it
going
to
be
a
regular
DNS
server
of
the
SCADA
to
person
out
there
types
to
if
it's
the
farmer,
then
we
have
to
look
at
these
other
kinds
of
issues
if
it's
the
latter,
some
of
that
stuff
almost
certainly
been
implemented
in
banging
with
a
front-end
module
or
unbound
to
the
front-end
budget
or
whatever.
It
is
so
broadly
speaking,
that
latter
case
to
polish
no
problem.
I
A
Oh,
you
are
right.
Anybody
have
any
more
questions
for
Jim
for
this
particular
stuff.
No
ok!
So
we
are
on
time
and
2
minutes
early,
which
is
excellent.
Thank
you
all
for
being
willing
to
be
cut
so
much
in
time,
so
the
dystopia
is
certainly
feels
larger
than
then
what
would
fit
into
one
working
group
in
the
ITF.
Traditionally,
that's
very
clear
and-
and
some
of
you
know,
the
work
is
maybe
a
bit
more
controversial
than
others.
T
Please
thanks
Wes
verdict.
Here
is
a
so
one
of
the
things
I
noticed
about
these
presentations
were
that
they
were
technical
and
down
on
the
weeds,
a
lot
and
in
a
good
way,
but
I
wanted
to
bring
up
some
sort
of
higher
level
view
in
terms
of
architectural
II.
You
know
how
we
think
about
things
and
first
off
so
you're
gonna
have
to
bear
with
me
for
a
minute
or
two,
but
protocols
are
not
evil
right.
T
So
one
thing
I
noted
is
that
we
have
many
technologies
today
that
send
packets
in
different
directions
than
maybe
the
ISP
expected.
Vpns
in
particular
do
that
user
logs
into
an
ISP.
They
they
jump
through
a
VPN
and
they're
no
longer
sending
traffic
the
same
way.
Well
then,
but
all
the
traffic
is
going
the
same
way,
so
you're
really
part
of
a
different
network
until
you
get
to
the
point
of
using
something
like
a
split
VPN.
T
Well,
when
you're
using
a
split
VPN,
some
of
your
traffic
does
some
way
in
some
traffic
goes
the
other
way
and
most
split
VPNs
actually
send
all
of
your
DNS
traffic
down
the
VPN.
So
to
some
extent,
you
NoDo
and
similar
technologies,
where
your
routing
stuff
at
different
direction
for
DNS,
is
kind
of
like
using
a
split
VPN
to
a
large
extent,
but
there's
a
significant
difference
in
that
and
I'm
gonna
hurt
back
on
this
a
few
times.
The
user
typically
has
awareness
that
they're
using
a
split,
VPN
or
APN
at
all.
T
A
T
The
lines
grown
okay,
so
what
does
change
the
difference?
Is
that
we're
doing
DNS
per
application
or
DNS
per
protocol
differences
and
that's
actually
quite
different
than
existing
stuff,
so
I'm
gonna
run
through
my
list
of
six
questions
without
commentary.
Does
the
IETF
need
this
to
be
standardized
Azure,
a
point
of
standardization?
Does
this
promote
alternate
nades
namespaces
I
can
currently
has
on
this
on
there
were
e
deck.
Do
we
care
that
we're
promoting
a
per
protocol
or
per
application
solution?
T
We
get
caught
in
the
tussle
a
lot
of
encrypted
data
center
like
let's
get
that
one,
oh
right,
so
it
boils
down
to
what's
the
benefit
of
standardizing
this,
and
if
we
were
going
to
re
architecture
things
today,
would
we
actually
pick
dough
or
are
we
using
dough
as
an
end-run
around
existing
network
problems
and
operational
problems
that
maybe
we'd
solve
a
different
way?
If
we
had
had
a
choice.
U
U
V
John
Porter
actually
clarification
question
for
David,
so
you
mentioned
that
the
information
that
you
should
use
a
particular
DHS
over
for
practical.
The
domain
should
be
keyed
to
whatever
identifies
me,
so
it
doesn't
turn
into
a
super
cookie.
That
does
imply
that
this
caching
is
extremely
limited
in
its
use.
Right,
so
probably
only
refreshed
connections
to
the
same
CDN
or
something
where
you
might
want
to
ask
the
CDN
to
refresh
sorry.
A
V
Yeah,
so
their
contract,
whatever
I,
am
arriving
at
the
point.
So
the
thing
is
that
the
end
result
is
you're
you're,
never
gonna
have
a
destination
specified
toh
server
for
the
initial
connection,
so
you're,
just
not
gonna.
Remember
it
for
long
enough,
so
that
that
pushes
me
down
the
direction
of
the
th
server
or
Quixote's
or
whatever
it's
gonna
be
specified
by
the
network
still
like
we
are
doing
currently
in
the
end.
That
is
why
we're
that
the
path
leads
me
down
to.
E
E
A
A
W
Run
for
a
sec
if
you're
going
to
progress
this,
the
one
thing
that
I
missed
in
in
the
discussions,
so
it
popped
up
this
fetid
list
of
trusted
resolvers
right.
How
is
that
list
composed
that
at
least
shoot
somehow
be
the
subject
of
a
draft,
because,
if
that
turns
into
a
cabal
of
the
cup,
for
that
takes
away
a
lot
of
control
from
users
right
now,
if
I
want
to
change
my
DNS
as
a
user,
there
are
a
handful
of
operating
systems
and
I
can
work.
W
I'd
have
to
change
that
if
every
application
does
that
and
comes
with
its
own
list,
and
there
is
no
control
whatsoever
over
how
that
list
is
composed.
What
does
that
mean
for
me,
as
a
user,
because,
basically,
all
of
the
I
I
lose
control
rather
than
gain
privacy
and
I
think
that
it
is
something
that
isn't
getting
discussed
enough
and
should
at
least
be
in
scope
for
this
kind
of
work,
picker
Heine.
M
Nervous
:
so
I
mean
this
is
like
AI
like
that
bulleted
list.
If
it's
very
long
I
think
there's
some
interesting
things
to
work
on
hiding
in
that
list
and
some
things
we
should
not
take
to
work
on
the
interesting
things
to
work
on
I
think
are
the
work
on
performance
measurement
and
performance
analysis
and
importance
cetera
of
these
deluge
technologies,
and
those
are
quite
interesting
in
our
in
our
debut
talk
yet
yesterday
about
this.
M
So
I
think
that
something
which
has
an
interesting
results
if
you
haven't
seen
that
we've
brought
the
kind
of
thing
won't
only
take
in
I,
think
discovery
of
the
sort
of
behavior
local
network
is
interesting
topic
as
I.
M
Think
and
you
go
overhead
graphing
this
and
more
and
alluded
to
you-
know
in
the
current
environment,
TNS
economies,
control
point
and
having
the
application
be
able
to
detect
that
at
least
for
now
and
deal
with
it
is
something
which,
like
the
German
interest,
the
short
term
I,
think
the
things
that
I
think
are
not
going
to
be
helpful
to
worker
are
the
the
validity
or
goodness
or
badness,
of
the
applications
opting
to
choose
our
own
DNS
resolvers
and
tell
into
them
of
the
users
being
able
to
discern
Janus
resolvers
without
the
network's
help
or,
conversely,
the
network
interfering
with
the
users
dance
revolution.
M
Those
are
things
which
will
on
not
have
good
outcomes,
as
you
I
think,
you'll
see
by
the
large
amount
of
heat
generated,
both
here
and
last
time.
So
I
was
true.
It
seems
like
there's
plenty
of
good
work
to
do,
but
braiding
off
bad
work,
which
will
just
cause
a
lot
of
pain
and
not
have
consensus.
It's
not
something
good
thing
to
do.
Roberto,
Roberto,.
X
And
you
know
let
that
sink
in,
because
it's
it's
gonna
be
true
of
any
of
the
things
that
we
decide,
including
where
we
put
this.
But
I
have
a
question,
however,
which
is
there
seem
to
be
a
lot
of
parallels
with
the
discussion
going
on
here
and
discussions
that
were
happening
around
the
time
when
we
were
looking
to
standardize
http/2
in
particular
around
having
requirements
on
TLS
and
what
that
was
going
to
do
to
intermediaries
and
look
at
what
that
was
going
to
do.
X
Q
Q
But
in
any
case
we
really
do
need
a
working
group,
because
we
need
to
address
the
network
operational
issues
that
come
about
from
this,
because
what
we're
hearing
you
know
if
I
look
at
Martin's
slides
is
you
know
we're
going
to
be
turning
this
default
on
and
therefore
obviating
the
users
choice
and
taking
place
of
the
users
choice.
The
user
chose
to
download
us
and
we'll
make
all
other
choices
for
them.
But
that's
beside
the
point.
A
K
Yaya
Eriksson,
so
I
have
two
points.
The
first
point
is
that
I
would
like
to
see.
A
working
group
addresses
the
operational
issues
and
obviously
we
have
some
work
to
do
to
narrow
down
what
what
that
exact
list
of
issues
is,
but
we
we
would
like
to
have
a
working
group,
and
the
other
point
is
that
there's
actually
several
issues
that
enemy
sort
of
always
seem
to
be
focused
on
some
some
aspect
of
that
and
obviously
seeing
the
full
full
picture.
K
So
we've
had
lots
of
discussion
today
on
like
DNS,
filtering
and
and
spookiness
and
blocking
and
and
so
forth-
and
you
know
I
have
some
views
about
that
topic.
It's
not.
You
know
basically
a
hook
topic
for
me,
but
it
seems
to
be
for
a
lot
of
the
crowd
here
and
a
lot
of
discussion,
but
but
there
are
other
things
so
I
think
like
the
concept
of
centralized,
DNS
and
like
applications
that
would
have
a
small
set
of
places
that
they
call
home
every
time.
K
K
Don't
have
this
like
one
view
over
the
world
default
thing,
if
you
can
spread
things
to
many
different
places
that
that's
great,
but
if,
if
we
are
centralizing
whatever
is
today
in
10
million
different
DNS
servers
locally
into
a
few
things
in
the
world,
that's
a
very
bad
outcome
for
the
infinite
I
think
the
IDF's
would
say:
that's
not
a
good
good
model.
Thank
you.
B
B
S
Leslie
Nagel
first
I
would
like
to
say
thank
you,
Jim
Reed
for
the
second
presentation,
I'm,
not
thankful
for
the
first,
because
I
do
you
think
those
his
points?
There
were
ones
that
actually
do
need
to
be
articulated,
consciously
that
it
may
be
inherently
assumed,
as
given
in
some
minds
and
I.
Think
it's
not
in
others.
What
I'm
hearing
in
a
lot
of
this
discussion
is
actually
a
call
for
applications
are
calling
for
different
functionality
in
the
internet.
S
As
it
stands,
I
think
there's
a
first
order
of
business
would
be
to
define
what
is
it
that
we
actually
mean
by
an
application
today,
because,
as
described,
Mozilla
becomes
Annapolis
service,
because
it's
no
longer
the
case
that
you
have
your
application
running
on
your
machine
and
you
have
your
network
configured,
but
in
fact
your
network
may
be
functioning.
Fine,
your
application
will
stop
working
because
of
some
configuration
deep
in
its
bowels,
where
it
relies
on
the
internet
for
doing
go,
and
you
have
no
idea
what
the
heck
is
going
on.
S
I
realize
that
that
is
hardly
unique
to
that
particular
aspect.
It's
hardly
unique
to
Mozilla.
It's
hardly
unique
to
this
particular
case
of
dough,
our
phones.
Do
it
all
the
time,
which
is
why
I
think
it's
worth
stopping
and
having
the
architectural
question
of
first
of
all,
what
is
an
application?
What
is
the
service?
What
is
a
naming
system
and
that
we
think
is
actually
useful
and
usable
in
today's
Internet.
F
Benkei
duck
I
like
both
unless
these
points
wrench
insert
from
the
first
and
Jim's
second
talk
in
terms
of
concrete
work
items
that
might
come
out
so
we're
writing
down
what
has
up
to
now
open
assumably
shared
assumptions
that
have
not
previously
written
down.
It
seems
useful.
You
know,
use
the
IANA
route.
Look
ISP,
has
knowledge
about
how
to
make
your
local
ISP
work.
Well,
that's
her
thing.
Y
Eric
Cline
I
was
just
two
points
when
I
was
going
to
agree
with
Lorenzo
earlier.
It's
the
an
operating
system
can
do
this
on
behalf
of
all
applications
without
the
applications
knowledge.
So
if
you
want
to
keep
the
same,
acronym
I
would
offer
that
it's
avoiding
designated
DNS
and
secondly,
I
also
agreed
with
them.
Leslie
I
was
wondering
whether
or
not
the
kind
of
thing
that
comes
out
of
this
isn't
going
to
be
an
IAB
Mar
new
report
style
document.
L
Schwartz
so
I've
heard
a
lot
of
concerns
about
DNS
related
operational
issues.
We
have
a
working
group
for
DNS
related
operational
issues
in
DNS,
so
I
think
that
we
should
take
those
issues
and
send
them
to
be
in
SL.
I
do
think
if
you
spend
some
time
in
DNS
op
recently,
you
might
notice
that
it
does
not
affect
seem
to
spend
a
lot
of
time
on
DNS
related
operational
issues.
L
Daniel
Kahn,
Gilmore,
ACLU
I
do
think
that
there's
work
that
needs
to
be
done
here,
I
think
I'm
in
agreement
with
then,
and
with
what
Stephen
said
earlier
about
trying
to
merge
together
some
of
the
different
places
where
this
conversation
is
happening
in
the
ITF
I
think
that
the
most
critical
thing
where
multiple
presentations
have
kind
of
maybe
even
disagreed
with
themselves
today,
has
to
do
with
questions
about
what
it
means
to
give
the
to
continue
to
give
the
user
some
level
of
control.
Here,
the
network
wants
to
enforce
their
will
on
the
user.
L
The
application
wants
to
enforce
their
will
on
the
user.
The
operating
system
wants
to
enforce
their
will
on
the
user.
We
know
that
we
can't
give
the
user
the
choice,
because
no
user
wants
to
make
this
choice
there's
a
fundamental
problem
there.
We
don't
talk
about
that
here
at
the
ITF
and
so
I,
don't
know
how
we
grapple
with
it.
But
that
seems
like
what's
missing.
H
John
Reed,
Akamai
I,
don't
think
repair
Braille
to
say
what
he
said,
but
secondly,
I
think
I've
heard
an
argument
in
favor
of
another
working
group.
For
this,
which
is
every
time
somebody
says
well,
the
protocol
is
not
evil
the
protocols,
not
a
problem,
it's
the
use
of
it
great.
Then
we
need
to
separate
those.
Do
you
things
and
I
we
have
dealt
with
protocol.
We
have
that
working
group
need
another
one.
Everything
else
in.
Z
Miserable
dollar
from
open
exchange
and
it's
DNS,
software,
implementers
and
recursive
operators
I
think
that
all
the
operational
concerns
that
have
been
shown
pretty
real.
So
please,
let's
have
a
place
where
we
can
discuss
or
whatever,
and
especially
please.
Let's
have
a
group
in
which
we
all
meet,
because
I
feel
that
part
of
the
problem
in
a
way
is
that
I
mean
part
of
the
community
was
going
in
one
direction.
AA
Vasily
do
notice
from
user
point
of
view.
That
reminds
me
a
lot
a
checklist
novel
watch
board,
so
we
are
trying
to
wait
from
some
control
on
DNS
servers
and
we
are
inventing
in
our
control
point
and
then
we
hand
the
control
to
the
application
developer.
All
the
website
owner,
which
is
even
not
network
operators,
so
I
really
doubt
that
it
is
better
choice
for
me
as
we
use
it
to
handle
the
control
to
those
groups.
Moreover,
I
have
heard
here
that
they
decided,
which
list
of
DNS
servers
to
use.
AA
M
Few
few
points
thank
I
as
I
said
earlier.
I
think
you
know
DP.
There
is
I,
think
a
wide
divergence
of
opinions
about
what
the
appropriate
place
the
application
is
in
this
system.
I,
don't
see
that
gap,
closing
ITF
does
not
handle
the
situation
well,
and
the
idea
that,
like
a
working
group,
will
somehow
resolve
the
consensus
statement
about
like
being
merits
or
demerits
of
an
application
or
network
control,
and
the
TNS
like
strikes
me
this
extreme
events
of
well.
M
What
will
happen
is
wish,
but
endless
amount
of
time
the
goosh
eaten
in
this
blot
land
possible
text.
That
seems
not
not
useful,
as
I
said,
there's
useful
to
do,
but
I
said
I
wanted
to
make
two
subjective
points
on
the
first.
Is
that
we're
talking
about
selection
of
at
motion
audience
question
defaults
currently
default
that
everything
has
whatever
network
offer
to
you
and
now
we're
talking
about
the
application
choose
any
different
at
fault.
M
I
can't
speak
for
Chrome,
but
I
can
tell
you
that
Firefox
perfectly
well
allows
you
to
enter
any
doe
resolver
of
your
choice
or
turn
off
doe
and
will
continue
to
do
so.
Even
if
we
pick
it
even
if
we
turn
on
all
button,
so
so
user
will
have
that
appropriate.
Oh
their
own
choice,
we
will
have
a
set
of
people
that
we
have
verified,
comply
with
our
policies,
but
I
will
not
preclude
these
are
from
doing
their
own
thing.
M
The
second
thing
is
a
little
surprised
to
hear
on
any
of
this
characterized
as
like,
as
like,
the
application
is
tracing
out
the
users
choice
like
the
user,
doesn't
know
what
DNS
is.
There's
no
idea.
That
network
is
offering
them
a
resolver
and
the
idea
these
are
likes.
It
like
to
opted
like
have
like
the
what
ihe
fy5
do
their
dns
resolution
in
some
like
informed
consent
way,
I
mean
it's
just
not
does
not
track
what's
actually
going
on
here.
So
you
may
not
think
it's
good
for
application.
A
I
think
Lorenzo
had
a
pretty
interesting
observation
that
some
of
these
issues
are
not
actually
they're,
not
related,
but
not
actually
related
to
choosing
non-traditional
resolution
points
and-
and
maybe
thinking
through
some
of
the
points
that
were
made
today
in
doing
the
talks
along
those
lines,
might
further
tease
them
apart,
and
maybe
we
can
sort
of
divide
and
conquer
parts
of
the
area
a
little
bit
better
by
trying
to
understand
what
actually
causes
the
problems
that
people
are
seeing
in
operations,
but
also
their
shipping
applications.
I
know
barrier
has
any
final
thoughts
for
that.
C
At
the
mic,
just
just
one
thing:
this
is
Barry.
There
was
a
lot
of
stuff
presented
today,
a
lot
of
stuff
discussed
with
microphones
I,
don't
want
to
try
to
tease
any
of
that
apart
now.
So
the
one
simple
question
I
just
want
to
ask
is:
does
anybody
think
that
there's
nothing
that
was
discussed
today
that
we
should
work
on
if
so
hum,
Napoli's?
C
A
C
Otherwise,
okay,
if
you
think
there's
something
that
would
that
came
up
today
that
should
be
worked
on
hum
yeah
I
mean
I
heard
that
at
the
mic
as
well,
we
didn't
really
need
it.
So,
let's
take
this
back
to
the
ad
D
list
and
discuss
I
would
like
the
people
who
hum
saying
there's
nothing
here.
That
should
be
worked
on
to
think
about
what
you
want
to
post
to
the
list
about
why
you
don't
think
we
should
work
on
this
because
I
think
that'll
be
an
interesting
start
to
further
discussion,
and
you.
AB
Lynch
that
hub
doesn't
work
for
me
because
the
stuff
I
would
like
to
work
on
his
stuff.
That
was
said
at
mic,
not
in
presentations.
I.
Think
there
is
a
fundamental
question
here
between
should
we
do
this
and
how
do
we
do
this,
and
how
do
we
do?
This
voices
have
been
very
loud
in
the
room,
but
yari
Leslie
dkg,
several
other
people
at
the
mic
or
the
should
we
do
this
voices?
That's
the
IAB
question,
not
the
IES
chicas.