►
From YouTube: IETF104-DOH-20190326-1120
Description
DOH meeting session at IETF104
2019/03/26 1120
https://datatracker.ietf.org/meeting/104/proceedings/
A
A
So
this
is
doe
the
DNS
over
HTTP
working
group.
If
you've
come
for
something
else,
you've
come
to
the
wrong
place.
We're
going
to
spend
the
next
hour
on
some
pretty
contentious
topics
as
you've.
Seen
on
the
mailing
list,
we're
gonna
first
start
off
with
Paul
Hoffman's
graph
today
and
I
should
mention
before
going
into
that.
However,
Ben
Schwartz
are
the
usual
DNS.
Doge
co-chair
could
not
be
present
this
week,
and
so
we
kindly
have
a
substitute.
Would
you
like
to
introduce
yourself,
Pete
or
any,
who
don't
know
most.
A
And
so
for
the
agenda.
Basically,
for
the
we've
allocated
the
first
half
hour
to
talk
about
Paul
Hoffman's,
existing
draft
adopted
by
the
working
group
for
associating
doe
resolvers.
And
then
we
are
going
to
use
the
balance
of
the
time
to
talk
about
other
work
that
has
come
up
and
where
it's
home
should
be.
A
Any
of
you
who
have
never
been
here
before
and
seen
this
sort
of
thing,
the
ITF
has
a
set
of
policies,
in
effect
that
cover
our
guidance
and
and
how
our
discussions
are
run.
If
you
have
not
previously
read
this,
you
really
should
because
this
basically
is
the
controlling
document
for
your
participation
in
the
ITF.
A
E
There's
the
full
stream
so
I'm
gonna
start
off,
while
he's
trying
to
find
full
screen.
This
is
not
Paul
Hoffman's
draft.
This
is
a
full
working
group
draft
and
for
those
of
you,
who've
been
following
it.
Since
it
was
Paul
Hoffman's
draft,
you
will
recognize
that
many
of
the
protocols
in
it
did
not
originate
with
me.
They
originated
with
people
from
the
working
group
and
from
the
community
who
said
your
original
ideas
suck
these
are
better
and
they
were
right.
So
I
just
want
to
be
really
clear.
This
is
a
working
group
draft.
E
D
E
Clicks,
isn't
life
good?
Okay?
So,
since
the
last
meeting
that
we
had
at
the
last
meeting,
it
was
still
Paul
Hoffman's
raft,
although
even
at
that
point
it
had
a
lot
of
stuff
in
it
that
I
did
not
originate
the
documents
been
adopted
by
the
working
group.
So
it
is
a
full
working
group
document.
It
follows
normal
working
group
rules,
I've
published
about
three
versions
and
I
say
three
ish,
because
one
of
them
was
a
mistake
that
so
it
sort
of
was
a
tombstone
II
one.
E
The
zero
two
was
a
major
reorganization
from
the
zero
zero
that
the
working
group
adopted
and
the
reason
we
did.
That
was
because
people
were
getting
caught
up
with
the
order,
since
it's
three
protocols
and
I'll
actually
cover
the
three
protocols
at
the
end
of
the
presentation,
people
assume
that
you
had
to
do
the
tree
protocols
in
order
or
the
three
were
more
important.
So
I
reorganized
to
be
that
what
people
were
indicating
as
the
one
they
understood
the
best,
the
one
that
they
sort
of
understood,
and
why
are
we
even
doing
this
one?
E
So
that's
the
current
order
and
then
the
zero
three
witches
came
out
a
couple
weeks
ago
before
the
cutoff
deadlines.
Smaller
changes,
but
many
people
asked
for
examples.
So
I
added
the
examples
and
clarifying
but
prabha
not
fully
clarifying
the
privacy
and
security
considerations
and
I
say
that,
because
a
lot
of
the
other
discussion,
the
discussion,
that's
happening
on
simultaneously
on
the
dough,
deprive
DNS
op.
You
know
thank
God.
E
We
haven't
actually
gotten
an
anti
ETF
general
yet,
but
it
only
will
take
time
those
things
people
have
then
you
know
pointed
out
privacy
and
security
considerations
that
affect
not
only
doe
dot
and
DNS
over
over
fifty
three,
but
also
this
document
as
well
so
I'm
trying
I
mean
this
document
is
going
to
remain
just
this
document.
It's
not
going
to
become
an
overarching
document,
but
there
are
still
more
privacy
and
security
considerations.
Probably
that
will
need
to
be
made
so.
E
Where
we're
at
now
is
hard
to
tell,
because
following
four
different
mailing
lists
for
the
same
topic
is
sort
of
difficult,
especially
when
not
everything
gets
posted,
all
them
I'm,
not
saying
they
should
all
be
posted
to
all
of
them.
I'm
just
saying
that
people
are
having
some
mismatch
issues,
it
seems
to
me
and
I'm
saying
this
as
an
individual,
that
there
is
still
strong
interest
in
having
the
capability
that
this
document
is
aiming
at.
Some
browser.
E
F
E
F
E
E
H
A
H
H
E
E
Is
we're
not
done
and
I'm
expressly
opening
up
the
ickiness
as
a
open
issue
that
multiple
people,
you
know
one
person
said
icky
and
one
person
said
yes,
it
is,
and
I've
heard
this
all
along
by
the
way,
so
I'm
not
a
proponent,
for
these
are
good
things
to
do
they're
the
normal
way
we
do
them
in
the
IETF.
They're
not
and
I'll,
actually
go
through
the
three
of
them.
Next,
but
short
of
that,
since
there
is
a
desire
for
the
goals
of
the
document
to
be
implemented
as
a
standard.
E
F
Paul
Elliot
leer.
Forgive
me
this
is
just
a
slightly
too
bit
abstract
for
me
in
terms
of
using
the
word
ickiness
all
right,
will
you
tell
sorry
it's
just
a
little
bit
too
abstract
for
me
in
terms
of
the
word
ickiness
I'm
sure
nobody's
ever
used
Nicki
as
being
abstract,
but
could
you
maybe
an
if
you
have
a
follow-on
slide
or
something
like
that?
Can
you
explain
what
can
you
summarize
the
the
ickiness
issues
or
something
like
that?
So
we
know.
E
No
because
they
didn't
come
from
me
so
if
either
Martin
or
Steve
Farrell
want
to
get
to
the
mic
line
when
we're
done,
they
can
do
so,
but
know
that
it
was
it
I
do
not
want
to
speak
for
other
people
on
this.
I
barely
want
to
speak
for
myself
on
this,
but
I
absolutely,
and
you
don't
want
me
speaking
for
other
people
either
as
Martin
just
pointed
out.
I
actually
got
this
slide
wrong
as
well.
So
ok,
ok!
So
our.
D
E
I
understand
they
might
come
to
the
mic
and
explain
what
they
don't
like.
Ok,
so
the
last
bullet
has
come
up
recently,
which
is
two
of
the
three
protocols:
don't
have
any
authentication
in
them
and
the
third
one
does,
but
that
authentication
it
bothers.
Some
people
in
that
Oh
that'll
be
harder
that
won't
work,
and
so
the
it
seems
like
there
is
now
discussion
both
for
this
document
and
in
general
about
authentication
in
this
realm.
Don't
know
where
that'll
go
occur.
We
did
you
want
to
talk
about
a
fennec
ation.
E
Don't
I
don't
know,
I've
got
more
slides,
so
why
don't
we
if
it
unless
it
was
like
a
clarification
on
this?
Why
don't
we
yeah
and-
and
we
do
have
time
for
Q&A
yeah-
we
definitely
have
time
for
Q&A.
So
let
me
do
so
I'm
just
on
those
are
the
three
things
I'm
about
to
discuss,
which
are
the
three
protocols
they're
in
the
same
order
as
they
are
in
the
draft.
I'm
gonna
just
show
you
what
they
are
I'm,
not
gonna,
explain
the
whole
thing.
E
Hopefully,
if
you
get
up
to
the
mic,
you've
read
the
draft.
I
know
that's
hopefully
in
many
cases,
but
since
we
have
such
limited
time
here,
that's
an
extra
hopefully
so
I'm
gonna
explain
to
three
and
then
we'll
have
the
last
slide
and
then
we'll
have
the
mic
line.
So
the
first
one
is
called
doe
service
from
HTTP.
It
uses
a
well-known
URI
dot,
well
known
with
there
that
can
be
resolved
and
it
will
return
the
URI
templates.
E
So
the
URI
would
look
like
this
and
that
the
all-caps
I
would
have
put
it
in
bold
and
blinking.
If
I
could
IP
address
goes
here,
a
an
application,
a
browser,
a
web
application-
you
know
JavaScript
or
something
who
has
the
IP
address
of
the
of
the
the
resolver-
sends
this
query
to
it
and
it
gets
back
a
JSON
blob.
That's
that's
that
protocol.
E
If
you
don't
have
the
IP
address
of
the
resolver,
but
you
know
you
can
send
text
queries,
you
can
do
doe
servers
from
DNS.
You
create
a
query
for
a
special
use
domain
name
that
is
being
invented
for
this,
which
is
called
resolver
associated
dodo
art,
but
plenty
of
bike
shedding
there
on
what
we
would
call
it
but
Warren.
If
you're
gonna
laugh
out
loud,
the
most
you're,
the
one
who
started
bike
shedding.
Okay,.
E
So
you
you,
you
send
a
query
with
for
a
text
record
and
you
get
back
so
you've
just
sent
a
normal
query.
You
say
who's
Oliver
associated
Doe,
our
type
of
text
and
you
get
back
and
since
it's
really
hard
to
show
what
people
get
back
without
going
into
the
bit,
so
I
actually
chose
the
master
file
format
for
the
current
draft.
You
get
back
some
tax
records
and
the
tax
records
have
the
URIs,
so
we've
also
started
talking
about.
Do
we
want
to
use
text
instead
of
this
a
new
case?
E
Do
we
want
to
use
the
URI
or
R,
but
that
then
you'd
have
to
actually
fill
in
you'd,
be
getting
back
information
you're,
not
using
so?
But
the
idea
is,
if
you
can
create
an
on
a
quad,
a
query
especially
text
query,
which
apparently,
some
operating
systems
can
do,
although
now
I'm
not
sure
why
I
think
that
so
I'd
love
to
hear
if
I'm,
just
imagining
that
you
can
get
these
back
and
now
you've
got
the
URI
templates
for
dough.
E
The
third
one
is,
if
you
can't
do
that,
but
you
want
to
get
the
a
or
quad
a
of
the
result
of
the
local
resolver
so
that
you
can
then
do
this.
One
here
is
a
way
to
get
the
a
or
quad
a
of
your
local
resolver.
You
make
a
different.
You
use
a
different
special
use.
Domain
name
in
this
case
result
for
addresses
dot
artha
the
resolver
caches.
That
says
here
are
my
addresses
and
send
them
back.
E
E
Questions
is
familiar
with
those,
because
those
have
been
in
the
draft
for
weeks
now
or
actually
more
than
weeks,
a
few
months
now
so
what's
next,
it
would
be
nice
to
get
some
feedback
from
resolver
vendors
saying
we
can
we
can't
we
already
have
we've
got
it
in
some
data
code
or
whatever,
but
also
it
may
be
that
these
are
not
the
way
that
the
working
group
wants
to
do
this,
which
goes
back
to
the
ickiness
question.
There
might
be
other
ways
and
then
we
have
to
decide
how
long
to
take
so
that's
it.
J
I
Brian
Dixon
from
GoDaddy.
Could
you
go
back
one
or
two
slides,
yes,
which
one
previous
one
that
one
mm-hmm
about
the
special
use
domain
name?
There's
one
issue,
I
think
as
far
as
the
use
of
possibly
those
servers
where
there's
an
existing
chain
of
forwarders
and
one
of
those
wants
to
be
the
thing
that
upgrades
itself
to
being
a
doe
server
as
well
as
a
DNS,
forwarder
I.
J
E
I
E
I
I
I
Even
if
it's
not
1000
one
with
very
high
five
OD,
you
got
it
from
your
DHCP
server,
which
means
you,
which
means
basically
the
network
aligned
to
you
in
your
network
security
problem
anyway.
Even
if
those
things
were
not
true
and
someone
had
to
actually
configure
the
address
in
here
on
the
ordinary
behavior
for
the
vast
majority
of
like
sensible,
Ando
resolvers
is
going
to
be
that
on
and
since
you
don't
actually
know,
you're
gonna
have
go.
I
You're
just
checking
right
is
to
try
this,
and
if
you
can't
connect,
then
you
go
gee,
I,
guess:
I,
don't
have
dough,
so
a
network
attacker
and
since
and
so
as
a
practical
matter,
and
then
you
fall
back
to
ordinary
DNS.
So
as
a
practical
matter,
any
attacker
was
any
significant
role
of
the
network
can
force
you
back
to
an
authenticated
posture.
So
this
method,
education,
doesn't
really
do
anything
for
as
I
can
make
out.
I
I
See
it
I
don't
see,
there's
no
value
at
at
so
the
question
I
was
gonna,
ask
best
question
I
was
gonna,
ask
was
gonna,
be,
is
the
only
additional
value,
I
suppose
of
the
ads
that
is
authentication?
If
that
is
so,
then
I
was
just
remove
it.
If
there's
some
other
value
that
I'm
not
seeing,
then
I'm
not
like
opposed
a.
E
E
I
Sure
I
don't
want
to
like
get
into
like
over
design
of
like
these
things,
but
you
know
I.
It
might
or
might
not
be
useful.
The
browser
vendor
to
be
aware
of
like
who
was
operating
the
system
that
the
local
dough
resolve
on
network
that
would
be
informational
might
be
able
to
use.
So
so
yes,
it's
possible.
We
pre-configure,
but
it's
also
possible
would
be
interested
in
what
the
local
dope
resolver
was.
Whether
we
chose
to
use
it
or
not.
Okay,.
K
Favor
akima
is
speaking
for
a
resolver
vendor
in
that
case.
So
the
thing
that
kind
of
I
have
a
bit
of
problem
is
I,
don't
want
to
run
an
HTTP
server
on
my
recursive
resolver,
so
I'd
rather
have
maybe
rearranged
documents
that
you
always
do
the
addresses
from
as
a
special
name
and
then
the
result.
The
resolver
can
hand
you
to
a
HTTP
server
farm
for
actually
doing
that.
Okay,
I
think
that.
E
D
H
The
objections
that
I
have
here
are
somewhat
more
fundamental
than
I.
Think
I.
Think
we've
been
discussing
at
this
level,
I
I,
I
kind
of
agree
with
the
folks
who
are
saying
I'd
rather
not
run
an
HTTP
server
on
my
resolver
I.
Think
that
makes
perfect
sense,
but
the
objection
is
more
fundamental
than
that
and
it
is.
Why
are
we
talking
to
an
HTTP
server
about
a
DNS
server
in
the
first
place?
E
H
Not
sure
what
that
is
and
part
of
the
problem
here
is
that
I
don't
have
enough
background
in
DNS
as
a
system,
and
the
system
is
resolves
to
know
whether
that's
a
good
idea
or
not.
But
the
fundamental
objection
is
you
don't
have
an
explicit
way
to
say.
I
would
like
to
talk
to
the
resolver
the
thing
at.
A
H
Other
end
of
this,
the
thing
that's
going
to
be
taking
this
message
that
I'm
going
to
be
sending
out
asking
for
an
a
record
or
what-have-you
I
can't
talk
to
that
thing.
Now
in
HTTP,
we
have
over
time,
evolved
the
ability
to
talk
to
the
other
end
of
the
connection
in
various
ways
we
can
put
in
header
fields.
H
That
say
this
is
a
header
field
intended
for
the
other
end
of
this
hop
or
we
have
settings
in
HTTP
2
that
allow
us
to
say
well,
this
connection
is
going
to
be
doing
the
following
things
and
so
on
and
so
forth,
and
if
we
were
able
to
talk
to
the
resolver
and
say
hey
resolver,
what
is
your
configuration
for
doe
explicitly
and
directly?
Then
I
think
we're
in
a
much
better
place
for
solving
this
problem,
finding
out
whether
Denisova
TLS
is
available
and
and
all
these
sorts.
H
A
E
E
E
We
can
change
that
by
making
it
using
you
are
or
whatever
so.
Yes,
I
chose
a
satin,
because
when
I
thought
I'm
running
a
resolver,
why
the
hell
would
I
give
more
than
one
and
if
I
gave
more
than
one,
what
does
it
mean
and
then,
as
I
thought
as
a
stub
resolver?
What
how
the
hell
would
I
choose?
I
just
said
this
would
take
five
paragraphs.
Why
don't
I
just
call
her
a
set
so
yeah?
That's
absolutely
an
open
question,
so
please
take
it
to
list.
Will
do
second
question.
E
Is
there
room
for
discussion
in
the
context
of
this
draft
about
end-user
interaction
and
information
such
that
you
know
we
say
what
happens
when
the
empty
set
empty
set
is
returned?
There's
no
dough
it.
Can
we
make
recommendation
that
you
know
the
application
should
tell
the
user
this
rather
than
falling.
E
Both
and
then
I
guess,
the
last
point
is
regarding
off
education
for
the
HTTP
query.
Http
query
for
IP
addresses
on
the
flip
side.
What
all
said
if
I
was
both
a
resolver
vendor
and
a
CDN
vendor
and
wanted
to
use
the
CDN
to
terminate
that
connection,
putting
IP
addresses
in
the
sand
entries
of
the
certificate,
as
well
as
all
the
DNS
names
that
are
in
there
is
problematic,
because
you
know
we
talked
about
if
TLS
fails.
We
should
consider
this
to
have
failed.
G
Hi
Paul
Pat
McManus,
oh
good,
good
slide,
so
I
largely
agree
with
ekor
on
the
front
that
what
you're
authenticating
here
is
basically
on
authenticated
information
that
you're
authenticating
at
the
next
level
and
that's
then
transitive
on
actually
to
your
connection
to
the
DOE
server
right
so
you're
connecting
to
the
DOE
server.
That's
something
when
you
go
all
the
way
down
the
rabbit
hole
told
you
that
was
unauthenticated
to
do
so.
G
G
E
G
G
M
L
M
Quick
questions
Oh
for
clarification,
one
in
the
draft.
What
you
currently
have
as
instructions
to
Ayanna
is
that
these
domains
under
DARPA
should
not
be
delegated,
must
not
and
okay,
would
it
be
okay
to
make
these
black
hole
delegations
instead
and
if
not,
why
not
could
be?
Oh?
That
would
be
great
for
Ayanna,
because
then
it
won't
get
bound
to
queries
to
these
and
in
leaks
we
can
do
black
hole
delegation.
The
same
way
we
did
for
send
text.
I
will
do.
The
second
is
a
scope
creep
question
yeah.
M
M
E
So
why
don't
you
hold
that
question
for
the
recharter
discussion,
because,
okay,
so
if
we
finish
this
work
for
just
doe,
it
probably
would
be
a
minor
Reece
pin
to
do
it
for
dot
or
something
like
that.
But
it's
it's
a
Charter
question,
not
a
document
question
at
this
moment
the
documents
about
doe
1030.
M
N
Apologize
I'm,
not
Martin,
Thompson
I
am
instead
Warren,
Kumari,
no
hats,
so
I
am
very
sympathetic
to
being
able
to
do
this
from
JavaScript,
but
I
also
really
think
that
people
should
be
able
to
do
this,
unlike
1918
space
etc,
and
they
won't
be
able
to
get
certificates.
If
you
do
the
HTTP
pot,
you
can
no
longer
do
it
with
JavaScript
right
cuz.
It's
really.
Okay,.
O
Aaron
I'm
one
question
afterwards:
do
we
really
need
all
three
of
these
mechanisms
and
I
think
to
Martin's
point
earlier,
which
I
kind
of
agreed
with?
Is
it?
Is
that
property
of
using
DNS
to
ask
the
DNS
resolver
a
question
about
DNS
has
is
really
attractive
rather
than
kind
of
the
some
of
these
other
mechanisms
they
get
start
getting
convoluted.
Okay.
From
that
perspective,
the
special
use
domain
name
really
jumps
out
as
being
a
highly
attractive,
solves
a
lot
of
the
problems
on
element
because
it
doesn't
have
the
it
doesn't,
require
the
IP
address
certificates.
O
It
doesn't
try
to
use
HTTPS
for
something
where
the
the
the
source
of
information
itself
is
unauthenticated.
It
is
something
that
actually
of
these
is
the
only
one
you
could
potentially
even
usefully
do
from
JavaScript,
because
in
the
JavaScript
world
the
bootstrapping
case,
if
you
need
to
know
what
your
resolver
is
in
the
first
place,
so.
E
That
is
absolutely
a
possibility
for
the
working
group
early
on
people
said
that
one
of
my
early
ones,
I,
don't
even
remember
which,
one
by
the
way
I
list
all
my
bad
ideas
and
appendix
if
you
haven't,
read
the
draft,
but
then
that
wasn't
enough,
they
wanted
it
to
be
more
extendable.
So
perfectly
valid
question
for
the
working
group
is
whether
we
want
to
simplify
down
to
one
that
is
going
to
a
DNS
server
and.
O
A
E
P
Least
two
different
options
listed
in
this
draft
I
think
that
it's
natural,
when
approaching
a
good
problem,
to
think
of
all
the
sort
of
possible
solutions
and
then
list
out
the
ones
that
seem
likely
to
work,
and
so
these
these
do
seem
likely
to
work.
But
I
do
think
that
we
should
prefer
to
in
find
a
single
solution
unless
we
actually
have
implementers
who
are
saying
that
they
eventually
intend
to
implement
one
and
canticle
meant
the
other.
P
So
I
would
really
appreciate
it
if
we
could
get
some
more
input
from
people
who
actually
intend
to
implement
this,
about
which
solutions
they
prefer
for
themselves.
So,
in
particular,
I
haven't
heard
any
input
from
people
who,
for
example,
are
build
little
network
appliances
about
which
one
they
would
be
to
implement
a
lot
of
input
from
crowds
or
vendors,
where
already
inventor
about
Ashwin
would
would
be
preferable
or
or
which
other
solution
makes
you
prefer
40.
P
Okay,
that's
the
rest.
My
first
cover
great
thank
you
next
and
my
my
second
comment
is
I.
Think
this
has
been
addressed.
I
just
want
to
be
clear,
so
there's
right
now,
there's
no
web
api.
No
JavaScript
accessible
web
api
for
reading
an
IP
address,
even
if
you,
even
if
you
can
resolve
a
name,
you
can't
find
out
the
IP
address
that
it
resolved
to
so.
E
So
I
didn't
know
that
the
first
of
the
things
that
you
said
was
true.
In
fact,
I
thought
that
it
wasn't
I
thought
that
there
is
a
JavaScript
API
in
like
the
last
few
years.
That
actually
says
get
me
the
address.
If
that's
wrong,
then
the
whole
thing's
wrong.
No
one
has
pointed
that
out
to
me
actually,
okay.
P
So
that
that
is
my
understanding,
that
my
understanding
is
that
there
is
no
defined
no
such
defined
API.
Now
it
is
true
that
if
we've
removed
the
HTTP
authentication,
you
could
go
to
HTTP
colon,
slash,
slash
special
use
domain
name,
whichever
one
it
is,
that
P
colon
slash
that
doh-doh
resolver
IP
resolver
addresses
ARPA
yep,
and
then
it
would
resolve
to
an
IP,
and
you
know,
attempt
to
set
up
a
socket
and
you
could.
You
could
go
from
there
all
right,
okay,
because
otherwise
we
can
talk
about
w3c
liaison
action.
A
C
E
Q
Their
projects
is
ethnic
now,
with
the
resolver
implementer
head
on.
First
of
all,
I
would
like
to
make
the
room
realize
that
for
us
assess
our
vendors,
there
is
no
point
in
implementing
do
H
if
nobody
is
going
to
find
the
endpoint
right.
So
if
you
want
to
see
th
implemented
in
open
source
resolvers,
we
need
this
or
something
else
which
will
allow
clients
to
detect
the
nth
one.
So
it's
very
more
important
than
it
seems.
Q
Otherwise
we
will
be
stuck
with
Google
and
called
for
doing
all
the
DNS
or
HTTP
HTTP,
and
that's
it
and
second
thing
I
would
suggest
not
to
get
stuck
with
the
authentication
problem
because,
for
example,
the
HCP
working
group
is
stuck
for
70
years
or
at
least
seven
years
with
trying
to
solve
the
secure
DHCP,
and
this
is
basically
the
same
thing
right.
So
at
the
buff
on
that
two
IDF's
ago,
the
DRI
you
bought-
and
we
came
to
that
conclusion-
I
mean
it's
just
hard
problem
and
yeah
I
shouldn't
wait.
A
A
B
B
But
to
sort
of
preface
this
I
want
to
point
out
that
what
we're
doing
here
is
soliciting
input
from
the
community.
We're
gonna
take
that
definitely
as
one
of
the
things
into
consideration
about
where
any
subsequent
work
might
go.
But
there
are
area,
directors
and
ops,
and
possibly
other
parts
of
the
iesg
are
probably
going
to
have
a
conversation
that
involves
other
logistics
as
well
about
where
this
work
work
ultimately
ends
up.
R
R
So
the
first
one
one
of
the
points
raised
primarily
is
around
the
issues
of
centralization
or
consolidation,
those
really
touch
on
stability,
security
and
privacy
and
if
some
other
knock-on
effects
around
software
diversity
and
so
on.
Oh
thank
you
and
so
I
think
at
the
end,
we're
will
come
to
the
basic
questions
across
all
these,
which
is
you
know
what
working
group
does
it
go
to?
Where
does
it
really.
S
R
As
it
in
charter
he
or
not,
and
then
the
other
issues
were
really
primarily
operational
in
nature.
Around
security
threat,
disability.
This
is
like
malware
detection,
sorts
of
things,
parental
and
other
content,
controls,
split,
DNS,
sort
of
an
enterprise
use
case,
enterprise
data
leaks,
national
level,
legal
mandates
which
exists,
particularly
in
a
bunch
of
European
countries,
captive
portal
impacts
and,
of
course,
other
operational
things.
Typical
things,
you'd
see,
performance
scaling
and
troubleshooting
Jim
yours
and.
C
T
Thanks
the
purpose
of
this
particular
draft
is
to
try
to
document
some
of
the
problems
are
going
to
exists
in
operator
networks.
One
still
gets
waiver
used
and
deployed
because
it's
going
to
have
a
significant
disruptive
impact
on
those
networks
and
the
purpose
we're
trying
to
do
in
this
particular
draft
is
document
that
and
come
up
with
some
use
cases
and
defame
problem
statement.
We're
definitely
not
talking
about
walking
of
them.
The
fact
to
see
that
blocking
that
you
usually
do
this
blocking
just
know.
T
These
networks
will
no
longer
work
in
one
module
is
wave
reuse
and
we
really
are
stealing
along
about
my
income
from
the
ITF
if
this
stuff
will
actually
go
forward.
So
the
question
you
would
like
to
hear
is
there
are
questions
about
that
left
open
in
the
current
draft.
There
are
things
that
need
further.
Take
meat
boil
initial
scale,
some
of
those
things,
those
little
bit
organ
issues,
and
there
may
be
some
other.
What
that
could
be
perhaps
picked
up.
Other
working
groups
in
the
ITF,
for
example,
or
only
secession,
take
a
sensation
resumption.
T
If
there's
lots
and
lots
of
dns
traffic
going
over
these
HTTP
connections,
we
also
have
between
the
jason's
document.
My
document
there's
a
degree
of
overlap
on
the
privacy
issues
and
pretty
much
it's
the
same
fundamental
problem.
That's
described
in
both
documents,
which
is
we've,
got
the
potential
for
dns
queries
going
to
third
party
Dory's,
all
of
us
for
some
definition
about
them
and
those
resolver
service
may
have
unknown
or
unclear
security
policies
and
what
could
be
the
potential
impact
of
those
in
also
some
other
settings?
Megan
it's
illegal
and
else's.
T
So
there's
certainly
some
concerns
around
that.
They
need
to
be
looked
at
now.
That
would
be
instable
potentially
for
this
working
group,
because
privacy
aspects
are
something
that's
mentioned
in
the
Charter,
but
we've
also
got
another
working
group,
which
is
also
looking
at
the
NS
previous
issues
deprived.
So
the
question
is
appropriate
to
do
endure.
T
That's
the
working
group
point
to
work
on
them
or
help
to
try
and
refine
these
documents
to
improve
them,
and
maybe
we
have
to
think
about
which
other
working
groups
make
appropriate
if
they
have
to
be
moved
elsewhere
and
so
we're
looking
at
essentially
operational
issues
rather
than
protocol
issues
in
these
documents,
so
that
cane
of
smells
a
little
bit
inappropriate
for
the
art
area.
So
maybe
the
stuff
needs
to
move
to
the
ops
area.
Who
knows
well,
that's
a
decision
for
other
people.
Maybe
some
people
will
may
have
a
particular
view
about
that.
T
So
it
looks
to
me:
is
there
are
several
options
of
possibilities?
Maybe
remove
the
working
group
into
the
ops
area.
Maybe
there'll
be
chartering.
Maybe
you
did
I'd
spit
up
on
your
working
room
or
maybe
take
an
existing
working
group
and
dump
all
the
stuff
in
to
them
and
have
them
deal
with
it.
Although
that
may
not
be
such
a
good
idea,
because
I
can't
see
any
media
office
fit
in
the
Obsidian,
where
there's
a
group
that
can
maybe
do
that
kind
of
thing.
T
Denisov
may
be
fine,
but
I
think
a
lot
of
the
web-based
people
would
Paula
find
participating,
leaders
or
working
group.
What
about
a
tall
order
for
them,
because
there's
so
much
other
DNS
stuff
going
on
in
there?
It
would
probably
linear
frustrate
them
and
I
thought
I'm
done
and
it's
time
for
questions.
Yeah.
A
T
C
C
We
are
looking
for
input
on
which
particular
issues
are
good
for
which
particular
places
and
which
should
be
booted,
and
that
kind
of
information
is
useful,
going
doing
a
deep
dive
on
what
they're
proposing
should
be
held
for
whatever
the
new
work
item,
the
new,
whether
it's
a
new
working
group,
new
charter,
new
area
will
be
so.
Let's
talk
about
where
stuff
should
go
and
what
are
important
things
to
go
just.
T
A
Also
wanted
to
put
a
one
bit
of
historical
context
for
the
short
history
that
those
existed
is.
This
was
going
to
be
the
model
of
a
pop
up
working
group.
You
know
some
with
one
and
done,
and
it's
so
the
question
of
that.
Whether
the
word
strings
along
for
years
is
also
comes
with
that
context.
Behind
it.
U
U
So
if
it
is
for
the
specific
case
of
the
DNS,
it
should
be
done
in
DNS
up
because
it's
clearly
what
DNS
operation,
if
there
is
interest,
but
I
would
like
to
point
out
that
it's
not
even
a
DNS
specific
problem.
It's
a
more
general
problem
in
the
internet
when
there
is
a
dominance
of
a
big
player
like
Gmail.
U
We
don't
ask
SMTP
working
group
to
change
a
protocol
about
it,
and
I
would
like
also
to
remind
people
that
there
is
some
work
at
the
IAB
on
the
draft
about
what
is
called
consolidation,
which
is,
if
I
understand
correctly,
more
or
less
the
same
as
centralization.
So
no
it's
not
for
the
door
walking
up
and.
V
U
W
U
W
Wanted
to
point
out
that
I'm,
the
third
author
of
the
draft
some
of
these
issues,
which
I
mean
it,
is
conceived
in
a
slightly
different
way
since
it's
basically
a
write-up
of
the
issues
from
general
for
all
types
of
users
in
the
set
of
recommendation
for
application
makers,
as
such
I
thought
it
would
fit
with
the
charter
of
deprived.
But
what
I
wanted
to
say
is
that
I'm,
of
course
happy
to
bring
it
I
mean
wherever
we
want
to
have
the
discussion.
I
think
that
this
discussion
has
to
be
just
one.
W
So
all
these
Tufts
and
all
these
issues
have
to
be
discussed
in
a
single
place
as
far
as
we
decide
that
they
are
in
the
Mandate
of
the
ITF.
What
you
want
to
do,
but
I
think
that
yeah,
but
I
think
that
in
the
end,
it's
advisable
to
just
bring
all
the
discussion
on
all
the
issues
in
a
single
place,
so
I'm
happy
to
hear
what
what
it
will
be.
If
there
will
be
one
and
bring
my
draft
there
as
well,
though
I
mean
I
guess.
W
This
will
also
be
an
item
for
discussion
with
the
deprived
working
group
which
hasn't
adopted
the
rough
yet
anyway.
Maybe
we'd
never
do
it,
but
so
I
mean
just
wanted
to
point
out
that
we
have
to
bring
everything
together
and
possibly
give
us
a
timely
solution,
because
I
think
time
is
of
the
essence
and
if
this
discussion,
by
the
way
starting
happen
in
other
places,
non-technical
places.
Two
weeks
ago,
the
ICANN
meetings
and
well
several
Costa
to
assist
us
in
to
discuss
the
issues
generated
by
the
age.
W
X
I'm
Watson
I
work,
opera
and
nothing
related
to
do
H,
R
I'm,
very
concerned
that
these
drafts
are
are
looking
at
the
OAH
and
looking
at
operational
issues
at
the
O
H
and
ignoring
a
long
history
of
misbehave
by
ISPs
on
DNS,
a
Verizon
is
in
notorious
for
faking
an
X
domain
queries.
They
will
not
respond
the
next
domain.
They
will
send
you
to
a
search
page.
This
breaks
several
systems
that
rely
on
an
X
queries
for
to
fall
over
to
another
site,
I.
Think.
X
If
we're
going
to
have
a
draft
about
operational
issues,
we
all
seem
discuss
the
operational
issues
which
users
are
solving
by
using
do
H,
which
is
the
SE,
is
previous
behavior
I'm
concerned.
As
draft
is
going
to
be
a
one-sided
threat
or
Menace
thing
and
isn't
going
to
give
a
over
comments
of
overview
of
the
issues.
The
benefits
of
voh,
as
well
as
the
costs.
Y
Right
student
vote
so
definitely
up
this
working
group.
I.
Think
the
analysis
in
these
drafts
is
not
sufficiently
baked
to
figure
out
what
you
should
do
with
them.
I
think
because,
for
example,
we
had
a
couple
of
people
already
say
this
issue
that
you
have
on
your
slide.
Jim
applies
also
to
TNS
over
53,
so
I
think
the
analysis
has
to
be
redone
better
before
I
would
have
a
clue
as
to
have
the
ITF
she
processes
you.
Z
And
Suzanne
Woolf,
first
as
DMS
up
Jeremy
and
then
and
then
I
will
switch
hats
for
my
next
trick.
This
doesn't
feel
like
Danis
out
work
to
me.
It
does
feel
operational
but
to
the
extent
that
there
are
technical
issues
implicated,
it
will
need
more
than
DNS
people
to
come
to
reasonable
analysis
and
correct
answers.
C
N
P
Warren
hi,
this
is
Ben
Schwartz,
not
speaking
as
a
chair,
yeah,
so
I
would
I
would
appreciate
a
clearer
taxonomy
of
the
different
kinds
of
issues
that
are
in
these
drafts
right
now,
each
of
them
seems
to
be
a
collection
of
many
different
concerns
of
different
kinds.
I
would
appreciate
if
those
were
structured
into
categories
a
little
more
clearly.
N
N
A
couple
of
weeks
ago,
when
the
discussions
were
happening
on
all
of
the
mailing
lists,
they
asked
for
a
new
mailing
list
to
be
graded,
which
I
was
calling
ad,
which
has
applications
doing
dns,
and
it
feels
like
that's
actually
a
fairly
good
sort
of
view
of
what
a
lot
of
the
concerns
boiled
down
to.
It's
not
actually
happening
over
a
specific
protocol
or
transport.
It's
actually
where
the
resolution
happens.
So
maybe
we
should
be
thinking
it
in
that
sort
of
way
instead
survive
level.
The
discussion
do.
N
A
S
Saying
guseva
growth
Center
for
Internet
and
Society?
Yes,
I
agree
with
Stefan
that
centralization
is
an
internet
problem,
but
principally
that
should
not
prevent
a
working
group
from
working
on
the
centralization
effects
of
a
particular
protocol.
That
said,
I
think
there
are
several
issues
in
the
drafts
as
they
currently
stand.
S
Some
issues
are
just
superficial
like
relating
to
privacy.
Even
if
you
use
a
dose
over
for
DNS
queries,
you
can
have
a
privacy
policy
that
you're,
accepting,
etc
and
I
mean,
even
though
the
living
would
drop
doesn't
say
it's
from
a
network
operator
side.
It
does
feel
that
way.
There
are
several
advantages
to
know
that
I
mean
the
talks
will
benefit
from
recognizing.
L
Curse,
TP
and
CSA
and
I'll
be
brief.
I
just
want
to
thank
you
for
bringing
the
drafts
to
the
group.
I
know
they
represent
a
lot
of
concerns
that
I've
heard
from
various
industry
and
players
and
I
think
it's
good
that
you're
bringing
them
into
the
group
I'm
a
relatively
new
attendee
here
so
I'm
afraid,
I,
don't
know
exactly
where
these
this
work
should
go.
But
it
does
seem
to
me
that
the
dough
charter
says
it
will
consider
privacy
and
security
issues
you're
bringing
privacy
and
security
issues
about
dough
to
the
group.
L
F
Eliot
Lear,
this
work,
I
think
is,
should
continue
and
it
should
continue
in
the
IETF,
because
we've
created
the
protocols
involved
that
you're
reacting
to
I
agree
with
Ben
Schwartz
on
the
point
that
the
taxonomy
could
use
a
little
bit
of
work,
and
probably
it's
worth
the
IAB
chiming
in
as
to
how
much
they
want
to
take
in
from
the
concentration
discussion
that
you
raised
in
particular,
Jason
and
I.
Think.
The
previous
comment
that
was
made
is
also
relevant.
J
Some
of
the
there
is
some
overlap,
I
believe
in
the
operational
side
of
things
between
do
H
and
do
T
and
in
particular,
I
think
there
are
some
problems
raised
that
may
be
better
handled
in
the
d-o-t
context
and
be
worth
exploring
together,
regardless
of
where
it
ends
up
specifically
in
DoD.
There's
a
new
thing
in
DNS,
which
is
DNS
stateful
operations,
which
has
applicability
to
d-o-t.
J
That
would
potentially
give
the
ability
to
signal
to
the
first
doah
server
about
a
second
do:
H
server
that
you
want
to
use
for
privacy,
that
I
don't
know
if
it's
possible
to
do
in
do
H,
but
working
together
on
both
of
them
together
in
a
different
working
group
or
new
working
group
or
with
the
recharter
I
think,
would
be
very
mutually
beneficial.
I.
K
Favored
outcome:
I,
thanks
for
bringing
that
all
this
is
up
I,
think
some
of
the
issues
are
really
do.
H
and
B
OTE
sort
of
are
in
the
same
boat.
It's
a
security
and
s
transport
and
we
need
to
come
up
with
operations
way
to
deal
with
security,
and
s
transporter
or,
and
one
of
the
things
that
came
up
was
provisioning,
and
this
is
something
that
needs
to
be
solved.
So
it
needs
to
be
solved
for
dough
and
for
dot.
So
maybe
having
something
that
tries
to
solve
this
together
would
be
good
idea.
AA
Leslie
Nagle
thinking
cat
enterprises
I
stood
up
specifically
to
push
back
on
the
idea
that
this
you
just
get
punted
to
the
w3c,
because
I
don't
think
it's
just
a
browser
issue
to
the
extent
that
the
documents
make
it
about
a
browser
browser
issue,
then
that's
an
editing
issue
because
really
fundamentally,
the
question
is:
how
are
how
is
how
is
doe
and
maybe
doand
dot?
How
are
they
breaking
our
hosts
assumptions
about
how
DNS
is
used
from
the
from
the
host
perspective,
so
I
think
there
is
work
to
be
done
here.
AA
I,
don't
think
it's
just
the
secure
transport
issue.
I
think
there
are
issues
at
the
level
of
operationally
what
are
our
expectations
in
terms
of
how
how
resolution
happens?
So
maybe
it's
an
ops
area
thing.
It's
fine
to
do
a
further
exploration
of
other
documents
that
should
be
referenced,
including
possibly,
yes,
wouldn't
it
be
nice
to
kill
an
X
domain
falsification
that
dead
bed
thanks.
V
Similarly,
that
plenty
of
issues
that
are
at
w3c
concerns
that
fine
to
have
addressed
here
and
I,
don't
see
a
reason
for
w3c
to
jump
in
and
say
they
should
only
happen
over
in
that
group.
If
the
right
people
are
in
this
conversation,
then-
and
I
haven't
particularly
heard
this
conversation
in
w3c
groups,
if
there
are
more
groups
that
you
would
like
to
have
engaged
I,
can
poke
at
some
of
those.